10-12-2003 03:46 PM - edited 03-02-2019 10:57 AM
It´s possibly during heavy load periods on a WAN link E1 speed (2.048MB), have a lose adj on ospf (because "dead time expired")??
Should I configure some priorization for hello packets?? What´s recommended??
At the moment I´m using priority queueing with DLSw on "high" queue and default traffic on "low" queue.
It´s neccesary to put the ospf (TCP/UDP) ports on any especific priority queue?
Any idea?? Thanks in advance...Pedro
10-12-2003 09:32 PM
How much is the RTT for ping responses, on this leased line.Do you experience, flaps on this link ?
10-13-2003 06:23 AM
The average round-trip is 180ms. It´s a Frame-Relay link and I do not have seen any packet droped on the frame-relay broadcast-queue, asking to the carrier they do not see any flaps on the cloud.
10-13-2003 05:03 AM
What you can do is increase the hello interval to 30 seconds , this has helped me in the past
ip ospf hello interval 30
10-13-2003 06:34 AM
I will try, but it is always necessary??, until 3 weeks ago all was working fine.
What´s up with traffic priorization?
It´s necessary for ospf control traffic (like hellos)?
Thanks..
10-13-2003 07:02 AM
I have only had to do this on overutilized links , was there a new application that was turned up recently that caused additional traffic on this pipe ?
10-13-2003 08:46 AM
No David.
The fail appears at 2:00 to 6:00 am when FTP traffic overloads the link, but it is normal. The comms were fine over 1 year ago until this month.
The only changes were routing redistribution betwen ospf and eigrp at the remote end and config of IPsec encryption over a GRE Tunnel (in order to permit the flow of routing traffic) on the main link (it´s an international FRelay link).
What´s the main reason for lose adj in this case?
Another important fact is that the lose ospf adj appears on neighbor associated with the Tunnel interface, not with the DLCI. Both have different ip address
Any idea..Thanks
10-13-2003 08:54 AM
Remember a tunnel is only a virtual interface not a physical pipe, you may have a physical pipe that is bouncing , what you can do is trace from to an interface that is in another ospf area on the other router , this will show you the physical path that it traverses , then run pings across all the hops , by doing this you can determine if you have a dirty circuit.
10-13-2003 12:07 PM
Hello Pedro,
I wonder if the OSPF goes down just because the tunnel goes down...try and increase the keepalive timers on the tunnel to e.g. 10 2 and check if the OSPF adjacency still experiences the same problem. I usually also put the ip ospf mtu-ignore command on both sides of the tunnel configuration.
Regards,
Georg
10-13-2003 01:41 PM
Hi Georg,
At this moment the tunnel interfaces dont´n have any keepalive configured ("no keepalive").
Is this parameter necessary?
Thanks...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: