Make sure you don't have an issue with recursive routing where the tunnel endpoints are being advertised over the tunnel.

It is best practice if running a routing protocol over a tunnel to not advertise the tunnel endpoints over said routing protocol, or if you have to then make the metric over the tunnel higher than the normal path.

area,subnet,stub flag,authentication and mtu. Alot times when you will have different size mtu per interface so the command is needed. I cant remember exactly but there are some potential issue if you are using mtu-ignore with a large different in mtu size. What are the MTU's on the interfaces you are trying to form an adjacency over?

Give us a short debug of the ospf adjacency.

Last edited by burnyd on Mon Apr 29, 2013 4:42 pm, edited 1 time in total.

davidrothera wrote:Make sure you don't have an issue with recursive routing where the tunnel endpoints are being advertised over the tunnel.

It is best practice if running a routing protocol over a tunnel to not advertise the tunnel endpoints over said routing protocol, or if you have to then make the metric over the tunnel higher than the normal path.

Could be, but Usually there is a syslog message generated that says specifically that it is down due to recursive routing.

To avoid recursive routing you can use a loopback as the source IP. I would set the mtu size on the tunnel interfaces and the physical interfaces and remember that your tunnel adds 24 bytes of overhead for encapsulation

davidrothera wrote:Make sure you don't have an issue with recursive routing where the tunnel endpoints are being advertised over the tunnel.

Would you mind explaining this a little further?

If I understand it correctly, if you advertise the endpoints (where the tunnel is supposed to terminate) over the tunnel, then the traffic to establish and keep the tunnel up will to to go through the tunnel. Essentially, the packets that keep up the tunnel and maintain it, will be encapsulated within the tunnel, instead of encapsulating the tunneled traffic.

davidrothera wrote:Make sure you don't have an issue with recursive routing where the tunnel endpoints are being advertised over the tunnel.

Would you mind explaining this a little further?

If I understand it correctly, if you advertise the endpoints (where the tunnel is supposed to terminate) over the tunnel, then the traffic to establish and keep the tunnel up will to to go through the tunnel. Essentially, the packets that keep up the tunnel and maintain it, will be encapsulated within the tunnel, instead of encapsulating the tunneled traffic.

--Richard

the easiest way to explain it is so you do not use the tunnel peers points to recurse routes. Normally it will show up in the syslog and tell you the tunnel is down due to recursive routing.

Apr 30 10:51:12.897: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to downApr 30 10:51:15.901: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to upApr 30 10:54:28.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to downApr 30 10:54:31.135: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

I would say there is a problem with the underlying link rather than routing. Perhaps the ADSL link being congested might have something to do with it. Try running an extended ping between the end points ie; send 10000 packets to see how many you lose.

area,subnet,stub flag,authentication and mtu. Alot times when you will have different size mtu per interface so the command is needed. I cant remember exactly but there are some potential issue if you are using mtu-ignore with a large different in mtu size. What are the MTU's on the interfaces you are trying to form an adjacency over?

Give us a short debug of the ospf adjacency.

To add to burnyd's explanation of the OSPF MTU and MTU ignore issue. If you are running into an issue with MTU you will see log messages stating there are too many re-transmissions as shown below. Ignoring the MTU size can cause larger updates to be ignored causing the need to re-transmit them.

burnyd wrote:does the tunnel bounce just by being up without a routing protocol?

Yes.

kannies wrote:The tunnel is dropping.

I would say there is a problem with the underlying link rather than routing. Perhaps the ADSL link being congested might have something to do with it. Try running an extended ping between the end points ie; send 10000 packets to see how many you lose.

Hi kannies

I think I have to agree with you. I ran some ping test sourced from Dialer1 and packet loss is roughly 17%.

My guess is the packet loss is being caused by the ADSL being hammered.

Just going back to the interface configuration, is it best practise to manually set the MTU on all interfaces? including the tunnel interfaces? What about manually setting the bandwidth on the interfaces?