RIP, EIGRP, OSPF, IS-IS, BGP, MPLS, VTP, STP.
SteveAllen
New Member
Posts:
38
Joined:
Tue Feb 28, 2012 3:29 pm
Certs:
CCNA Security, CCNA, CCENT

GRE + OSPF Dropping

Sun Apr 28, 2013 2:39 pm

Hi

I recently set up a GRE tunnel between 2 Cisco routers and notice it drops out "randomly".

Is it normal for GRE tunnels to drop out every now and then or should they be rock solid?

Below is the logs when it drops out.

Code: Select all
.Apr 26 17:53:47.343: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 17:58:28.260: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:02:43.717: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:07:36.273: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
.Apr 26 18:07:36.273: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Interface down or detached
.Apr 26 18:07:39.277: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
.Apr 26 18:07:39.413: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:09:51.419: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
.Apr 26 18:09:51.419: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Interface down or detached
.Apr 26 18:09:54.423: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
.Apr 26 18:09:54.559: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
.Apr 26 18:10:56.230: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:12:53.369: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:18:49.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
.Apr 26 18:18:49.091: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Interface down or detached
.Apr 26 18:18:52.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
.Apr 26 18:18:52.231: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
.Apr 26 18:20:38.963: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:30:46.997: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
.Apr 26 18:30:46.997: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Interface down or detached
.Apr 26 18:30:53.001: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
.Apr 26 18:30:53.149: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:35:34.089: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
Apr 26 18:44:49.796: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done


Below is the configuration of the tunnel interface at one side.


Code: Select all
interface Tunnel0
 description GRE TUNNEL TO HQ
 ip address 192.168.147.2 255.255.255.252
 ip ospf message-digest-key 1 md5 7 xxxxxxx
 ip ospf mtu-ignore
 keepalive 3 2
 tunnel source GigabitEthernet0/0
 tunnel destination 31.x.x.x
end



I'd be greatful if others could share there experiences on the reliability of GRE tunnels.

Steve

User avatar
srg
Post Whore
Posts:
1709
Joined:
Thu Dec 30, 2010 2:05 pm
Certs:
CCIE SP, CCNP SP, CCNP, CCDA, CCNA DC/W, HP MASE

Re: GRE + OSPF Dropping

Sun Apr 28, 2013 2:47 pm

should be solid. got packet loss on the underlying link?
som om sinnet hade svartnat för evigt.

User avatar
davidrothera
Ultimate Member
Posts:
992
Joined:
Thu Jan 13, 2011 5:10 pm
Certs:
CCIE R&S #38338, CCNP, CCIP

Re: GRE + OSPF Dropping

Sun Apr 28, 2013 4:34 pm

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.
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

dschuemann
Member
Posts:
101
Joined:
Tue Dec 01, 2009 9:07 pm
Certs:
CCNP, VMware VCP

Re: GRE + OSPF Dropping

Sun Apr 28, 2013 9:37 pm

Does debugging the hello messages show anything?

Also why are you telling OSPF to ignore the MTU?

SteveAllen
New Member
Posts:
38
Joined:
Tue Feb 28, 2012 3:29 pm
Certs:
CCNA Security, CCNA, CCENT

Re: GRE + OSPF Dropping

Mon Apr 29, 2013 2:55 pm

dschuemann wrote:Does debugging the hello messages show anything?

Also why are you telling OSPF to ignore the MTU?



Thank you all for your replies.

I used ignore MTU as this is something I read on a configuration example. Also, without this the OSPF neighbors failed to form.

I'll perform some debugging to see if this can shed some light.

User avatar
burnyd
Post Whore
Posts:
3154
Joined:
Fri Nov 13, 2009 5:15 pm
Certs:
CCIE R&S/SP,CCNP-SP,JNCIA,VCP510,VCA-DCV

Re: GRE + OSPF Dropping

Mon Apr 29, 2013 4:40 pm

dschuemann wrote:Does debugging the hello messages show anything?

Also why are you telling OSPF to ignore the MTU?



the following things have to match for ospf to work properly...

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.
http://danielhertzberg.wordpress.com - I blog about networks!

User avatar
burnyd
Post Whore
Posts:
3154
Joined:
Fri Nov 13, 2009 5:15 pm
Certs:
CCIE R&S/SP,CCNP-SP,JNCIA,VCP510,VCA-DCV

Re: GRE + OSPF Dropping

Mon Apr 29, 2013 4:42 pm

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.
http://danielhertzberg.wordpress.com - I blog about networks!

User avatar
bakergarry
Senior Member
Posts:
387
Joined:
Mon May 30, 2011 1:51 pm
Certs:
ccna, ccna security, ccna voice, ccnp, ccip

Re: GRE + OSPF Dropping

Mon Apr 29, 2013 6:03 pm

turn the keepalives off, or adjust them so that you do not drop keepalives, or fix the underlying link
"With sufficient thrust, pigs fly just fine..." - RFC 1925

User avatar
WhiteFeather
New Member
Posts:
37
Joined:
Sat Jan 19, 2013 9:48 am
Certs:
CCNP | CCDP

Re: GRE + OSPF Dropping

Mon Apr 29, 2013 7:06 pm

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

SteveAllen
New Member
Posts:
38
Joined:
Tue Feb 28, 2012 3:29 pm
Certs:
CCNA Security, CCNA, CCENT

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 6:03 am

Same problem today

Here is the output from debug ip ospf adj when the link starts to drop out:

Code: Select all
RT-HESSLE#
Apr 30 10:50:25.704: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:50:34.964: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:50:44.168: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:50:53.700: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:51:03.629: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:51:12.673: OSPF-10 ADJ   Tu1: Send with youngest Key 1
Apr 30 10:51:12.897: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
.Apr 30 10:51:12.897: OSPF-10 ADJ   Tu1: Route adjust notification: DOWN/DOWN
.Apr 30 10:51:12.897: OSPF-10 ADJ   Tu1: Interface going Down
.Apr 30 10:51:12.897: OSPF-10 ADJ   Tu1: 1.1.20.1 address 192.168.147.5 is dead, state DOWN
.Apr 30 10:51:12.897: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Interface down or detached
RT-HESSLE#
.Apr 30 10:51:12.897: OSPF-10 ADJ   Tu1: 1.1.22.1 address 192.168.147.6 is dead, state DOWN
.Apr 30 10:51:12.897: OSPF-10 ADJ   Tu1: Interface state change to DOWN, new ospf state DOWN
RT-HESSLE#
.Apr 30 10:51:15.901: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
RT-HESSLE#
.Apr 30 10:51:15.901: OSPF-10 ADJ   Tu1: Route adjust notification: UP/UP
.Apr 30 10:51:15.901: OSPF-10 ADJ   Tu1: Interface going Up
.Apr 30 10:51:15.901: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:15.901: OSPF-10 ADJ   Tu1: Interface state change to UP, new ospf state P2P
.Apr 30 10:51:16.005: OSPF-10 ADJ   Tu1: 2 Way Communication to 1.1.20.1, state 2WAY
.Apr 30 10:51:16.005: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Prepare dbase exchange
.Apr 30 10:51:16.005: OSPF-10 ADJ   Tu1: Send DBD to 1.1.20.1 seq 0x2173 opt 0x52 flag 0x7 len 32
.Apr 30 10:51:16.005: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:16.005: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x1152 opt 0x52 flag 0x7 len 32  mtu 1476 state EXSTART
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: First DBD and we are not SLAVE
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x2173 opt 0x52 flag 0x2 len 112  mtu 1476 state EXSTART
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: NBR Negotiation Done. We are the MASTER
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Summary list built, size 4
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: Send DBD to 1.1.20.1 seq 0x2174 opt 0x52 flag 0x1 len 112
.Apr 30 10:51:16.109: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Rcv LS REQ from 1.1.20.1 length 36 LSA count 1
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Send LS UPD to 192.168.147.5 length 64 LSA count 1
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x2174 opt 0x52 flag 0x0 len 32  mtu 1476 state EXCHANGE
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Exchange Done with 1.1.20.1
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Synchronized with 1.1.20.1, state FULL
.Apr 30 10:51:16.181: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
RT-HESSLE#
.Apr 30 10:51:16.181: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Clean-up dbase exchange
RT-HESSLE#
.Apr 30 10:51:18.397: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
.Apr 30 10:51:22.569: OSPF-10 ADJ   Tu1: Cannot see ourself in hello from 1.1.20.1, state INIT
.Apr 30 10:51:22.569: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:22.621: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0xA29 opt 0x52 flag 0x7 len 32  mtu 1476 state INIT
.Apr 30 10:51:22.621: OSPF-10 ADJ   Tu1: 2 Way Communication to 1.1.20.1, state 2WAY
.Apr 30 10:51:22.621: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Prepare dbase exchange
.Apr 30 10:51:22.621: OSPF-10 ADJ   Tu1: Send DBD to 1.1.20.1 seq 0x2176 opt 0x52 flag 0x7 len 32
.Apr 30 10:51:22.621: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:22.621: OSPF-10 ADJ   Tu1: First DBD and we are not SLAVE
.Apr 30 10:51:22.669: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x2176 opt 0x52 flag 0x2 len 112  mtu 1476 state EXSTART
.Apr 30 10:51:22.669: OSPF-10 ADJ   Tu1: NBR Negotiation Done. We are the MASTER
.Apr 30 10:51:22.669: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Summary list built, size 4
.Apr 30 10:51:22.669: OSPF-10 ADJ   Tu1: Send DBD to 1.1.20.1 seq 0x2177 opt 0x52 flag 0x1 len 112
.Apr 30 10:51:22.669: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:22.777: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x2177 opt 0x52 flag 0x0 len 32  mtu 1476 state EXCHANGE
.Apr 30 10:51:22.777: OSPF-10 ADJ   Tu1: Exchange Done with 1.1.20.1
.Apr 30 10:51:22.777: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:22.777: OSPF-10 ADJ   Tu1: Send LS REQ to 1.1.20.1 length 36 LSA count 1
.Apr 30 10:51:22.873: OSPF-10 ADJ   Tu1: Rcv LS UPD from 1.1.20.1 length 88 LSA count 1
.Apr 30 10:51:22.873: OSPF-10 ADJ   Tu1: Synchronized with 1.1.20.1, state FULL
.Apr 30 10:51:22.873: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
RT-HESSLE#
.Apr 30 10:51:22.873: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Clean-up dbase exchange
RT-HESSLE#
.Apr 30 10:51:25.373: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:51:25.569: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
.Apr 30 10:51:35.437: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
.Apr 30 10:51:44.689: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
.Apr 30 10:51:54.681: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
.Apr 30 10:52:04.573: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
.Apr 30 10:52:14.561: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:52:23.965: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:52:32.989: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:52:42.161: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:52:51.541: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:00.709: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:10.130: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:19.726: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:29.438: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:38.542: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:47.978: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:53:57.650: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:54:07.563: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:54:16.575: OSPF-10 ADJ   Tu1: Send with youngest Key 1
RT-HESSLE#
Apr 30 10:54:26.199: OSPF-10 ADJ   Tu1: Send with youngest Key 1
Apr 30 10:54:28.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
.Apr 30 10:54:28.131: OSPF-10 ADJ   Tu1: Route adjust notification: DOWN/DOWN
.Apr 30 10:54:28.131: OSPF-10 ADJ   Tu1: Interface going Down
.Apr 30 10:54:28.131: OSPF-10 ADJ   Tu1: 1.1.20.1 address 192.168.147.5 is dead, state DOWN
.Apr 30 10:54:28.131: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from FULL to DOWN, Neighbor Down: Interface down or detached
RT-HESSLE#
.Apr 30 10:54:28.131: OSPF-10 ADJ   Tu1: 1.1.22.1 address 192.168.147.6 is dead, state DOWN
.Apr 30 10:54:28.131: OSPF-10 ADJ   Tu1: Interface state change to DOWN, new ospf state DOWN
RT-HESSLE#
.Apr 30 10:54:31.135: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
RT-HESSLE#
.Apr 30 10:54:31.135: OSPF-10 ADJ   Tu1: Route adjust notification: UP/UP
.Apr 30 10:54:31.135: OSPF-10 ADJ   Tu1: Interface going Up
.Apr 30 10:54:31.135: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:54:31.135: OSPF-10 ADJ   Tu1: Interface state change to UP, new ospf state P2P
.Apr 30 10:54:31.251: OSPF-10 ADJ   Tu1: 2 Way Communication to 1.1.20.1, state 2WAY
.Apr 30 10:54:31.251: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Prepare dbase exchange
.Apr 30 10:54:31.251: OSPF-10 ADJ   Tu1: Send DBD to 1.1.20.1 seq 0x16CF opt 0x52 flag 0x7 len 32
.Apr 30 10:54:31.251: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:54:31.251: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x2178 opt 0x52 flag 0x7 len 32  mtu 1476 state EXSTART
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: First DBD and we are not SLAVE
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x16CF opt 0x52 flag 0x2 len 112  mtu 1476 state EXSTART
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: NBR Negotiation Done. We are the MASTER
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Summary list built, size 4
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: Send DBD to 1.1.20.1 seq 0x16D0 opt 0x52 flag 0x1 len 112
.Apr 30 10:54:31.347: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Rcv LS REQ from 1.1.20.1 length 36 LSA count 1
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Send with youngest Key 1
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Send LS UPD to 192.168.147.5 length 64 LSA count 1
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Rcv DBD from 1.1.20.1 seq 0x16D0 opt 0x52 flag 0x0 len 32  mtu 1476 state EXCHANGE
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Exchange Done with 1.1.20.1
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Synchronized with 1.1.20.1, state FULL
.Apr 30 10:54:31.515: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.20.1 on Tunnel1 from LOADING to FULL, Loading Done
RT-HESSLE#
.Apr 30 10:54:31.515: OSPF-10 ADJ   Tu1: Nbr 1.1.20.1: Clean-up dbase exchange
RT-HESSLE#
.Apr 30 10:54:33.631: OSPF-10 ADJ   Tu1: Send with youngest Key 1



Tunnel Int Dia1

Code: Select all
RT-HESSLE#show run interface dialer 1
Building configuration...

Current configuration : 388 bytes
!
interface Dialer1
 description KC ADSL DIALER INTERFACE
 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in max-reassemblies 1024
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 ppp authentication chap callin
 ppp chap hostname xxxxxx
 ppp chap password 7 xxxxxxx
 ppp ipcp route default
 no cdp enable
end

RT-HESSLE#


Tunnel 1

Code: Select all

RT-HESSLE#show run interface tun1
Building configuration...

Current configuration : 261 bytes
!
interface Tunnel1
 description GRE BACKUP TUNNEL TO HQ
 ip address 192.168.147.6 255.255.255.252
 ip ospf message-digest-key 1 md5 7 xxxxxxx
 ip ospf mtu-ignore
 keepalive 3 2
 tunnel source 83.x.x.x
 tunnel destination 31.x.x.x
end

RT-HESSLE#



Output from show interface dialer1

Code: Select all
RT-HESSLE#show int dia 1
Dialer1 is up, line protocol is up (spoofing)
  Hardware is Unknown
  Description: KC ADSL DIALER INTERFACE
  Internet address is 83.x.x.x/32
  MTU 1500 bytes, BW 56 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 255/255, rxload 255/255
  Encapsulation PPP, LCP Closed, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 1 seconds on reset
  Interface is bound to Vi2
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 1w6d
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 2065000 bits/sec, 324 packets/sec
  5 minute output rate 836000 bits/sec, 285 packets/sec
     105025658 packets input, 852575100 bytes
     77153388 packets output, 1444364568 bytes
Bound to:
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  MTU 1500 bytes, BW 56 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 255/255, rxload 255/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoE vaccess, cloned from Dialer1
  Vaccess status 0x44, loopback not set
  Keepalive set (10 sec)
  Interface is bound to Di1 (Encapsulation PPP)
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters 4d18h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 2067000 bits/sec, 326 packets/sec
  5 minute output rate 882000 bits/sec, 302 packets/sec
     39004670 packets input, 2217172858 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     30991876 packets output, 2608641696 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
RT-HESSLE#



Do I need to manually set the bandwidth and MTU on both interfaces?

SteveAllen
New Member
Posts:
38
Joined:
Tue Feb 28, 2012 3:29 pm
Certs:
CCNA Security, CCNA, CCENT

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 6:06 am

One thing to add is at the moment we are using an ADSL line which is our back up Internet connection.

Could these problems be related to the ADSL being at 100% utilization ?

User avatar
phoeneous
Senior Member
Posts:
316
Joined:
Tue Dec 30, 2008 2:43 pm
Certs:
Pimp status

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 7:35 am

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?
thelostpackets.blogspot.com - randomness from the bit bucket

User avatar
mynd
Ultimate Member
Posts:
883
Joined:
Fri Jul 23, 2010 9:43 am
Certs:
CCNA, A+, Net+, Sec+, Server+

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 8:39 am

phoeneous wrote:
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
http://justnetworked.wordpress.com

User avatar
burnyd
Post Whore
Posts:
3154
Joined:
Fri Nov 13, 2009 5:15 pm
Certs:
CCIE R&S/SP,CCNP-SP,JNCIA,VCP510,VCA-DCV

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 8:56 am

mynd wrote:
phoeneous wrote:
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.
http://danielhertzberg.wordpress.com - I blog about networks!

User avatar
davidrothera
Ultimate Member
Posts:
992
Joined:
Thu Jan 13, 2011 5:10 pm
Certs:
CCIE R&S #38338, CCNP, CCIP

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 9:09 am

Not always, I've seen some IOS versions warn you and others not so don't always rely on it.
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

User avatar
kannies
Post Whore
Posts:
1210
Joined:
Thu Jan 10, 2008 7:43 am

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 11:31 am

The tunnel is dropping.

Code: Select all
Apr 30 10:51:12.897: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
Apr 30 10:51:15.901: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
Apr 30 10:54:28.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
Apr 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.

User avatar
burnyd
Post Whore
Posts:
3154
Joined:
Fri Nov 13, 2009 5:15 pm
Certs:
CCIE R&S/SP,CCNP-SP,JNCIA,VCP510,VCA-DCV

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 11:42 am

does the tunnel bounce just by being up without a routing protocol?
http://danielhertzberg.wordpress.com - I blog about networks!

User avatar
routerdork
Post Whore
Posts:
1525
Joined:
Tue Feb 22, 2011 9:40 am
Certs:
CCNA, MCDST, MCP, A+

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 12:57 pm

burnyd wrote:
dschuemann wrote:Does debugging the hello messages show anything?

Also why are you telling OSPF to ignore the MTU?



the following things have to match for ospf to work properly...

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.

Code: Select all
Apr 20 02:03:56.830: %OSPF-5-ADJCHG: Process 1, Nbr 10.99.8.8 on Vlan899 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
Apr 20 02:04:28.838: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.0.10 on Vlan899 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
Apr 20 02:04:56.830: %OSPF-5-ADJCHG: Process 1, Nbr 10.99.8.8 on Vlan899 from DOWN to DOWN, Neighbor Down: Ignore timer expired
Apr 20 02:05:28.838: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.0.10 on Vlan899 from DOWN to DOWN, Neighbor Down: Ignore timer expired

SteveAllen
New Member
Posts:
38
Joined:
Tue Feb 28, 2012 3:29 pm
Certs:
CCNA Security, CCNA, CCENT

Re: GRE + OSPF Dropping

Tue Apr 30, 2013 1:57 pm

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?

'

Return to Cisco Routing and Switching

Who is online

Users browsing this forum: ngagnon, sergeyrar and 59 guests