OSPF Routing problem on DSL Link - need help!!!!! 1

[LiNuXGuRL]

Hi

we are experiencing the following problem:

On a 2611 router with a DSL WAN link, the OSPF Hello packets are being discarded when the bandwidth is highly utilized, if this happens back to back, the OSPF link is being anounced as dead and data transfer is no longer possible. i.e. if the congestion on the line was caused by an FTP session, this session will be terminated when OSPF says the link is dead, and all FTP packets are being discarded. The line becomes clear again at which time the OSPF hello packet can make their way thru and the link is re-established. At this time the FTP session will be started over and the same scenario happens again.

is there any way to limit the bandwidth utilization to avoid those type of problems?????

Please help

 

[stoney66]

A basic way to do it would be to setup qos. Since the routers default is first in first out, ftp or other apps can cause problems like this. Setting up custom queuing would be a good start, putting primary needed protocols first like ospf, and putting less needed protocols last like ftp. Make sure though with ftp, you use data port 20 if its active ftp. Using control port 21 wont do you much good since that just sets up the ftp session.

stoney.

 

[marsd]

I agree with the previous post set up a custom queue
and prioritize your traffic. What queueing scheme are you using now?

 

[LiNuXGuRL]

How can you prioritize OSPF update packets when they are not being sent or transmitted to the router but generated by the router itself??? I don't think this is possible. I know I could implement custom queueing placing all high bandwidth protocols like FTP in a medium queue, however, I really dont want to do that since I would have to think of every possible protocol/application that the customer is using. Also...the connection runs thru a gre tunnel.

Therefore I am searching for a way to limit the bandwidth

 

[stoney66]

Applying the queuing on your outside interface prioritizes outbound traffic, not inbound, including your ospf traffic (from what I rem you have to create a ext acl for routing protocols). I havent done this with ospf, but I do it currently with eigrp. Using the byte-count per queue is what limits the "bandwidth" per application. What we did was setup queues for applications we knew, snmp, http, https, telnet, ftp-data, & nbt. Then made a default queue for anytihng else that wasnt covered. Since most of normal traffic that uses a lot of bw is ftp and nbt, this worked. Make sure to use queue number 0, this is the system queue and its checked/emptied before any other queue and is used for critical packets, like routing protocols and keepalive packets. If you have more than one type of critical piece, use an acl instead of a port number.

Are you encrypting data in the gre tunnel? I'm sure you are but had to ask.

hope this helps

stoney

 

[LiNuXGuRL]

thank you stony----i will try that. and yes we are encryping...
with md5

thanx a lot for your help!!

 

[stoney66]

hope it helps ya, though I dont know about the encryption part, not sure what takes place first, encryption or qos. I would think encryption would take place first, therefore using qos in your config wont work since the router cant read the packet types. There is some qos stuff to do for tunnel interfaces. Let me know if the custom queueing doesnt work, then we can try and work through the tunnel issue.

good luck!

stoney.

 

[LiNuXGuRL]

thanx stoney! we'll try what you suggested and i keep you posted on the outcome

THANX A MILLION!

 

[LiNuXGuRL]

thanx a lot stoney, we'll try what you suggested. i let you know the outcome.


thanx a million!

 

[marsd]

No, I don't think encryption takes place first.
The algo is still going to decide your queue.
When the packet arrives and is processed according
to the queue is before encryption.