Intermittant routing loops

Unanswered Question

I have 2x 2811 routers at a remote hub connected to the network core using GRE tunnels & using HSRP for redundancy. I have recently employed EIGRP in the core which extends over the GRE tunnels to the remote hub routers. The remote hub connects to ships using satellite & as the vsat equipment only uses RIP i am redistributing RIP into EIGRP. I am seeing an intermittant routing loop on the active router for the 1800 Cisco router on board the vessels which doesn't seem to affect the vsat modem it is connected to & the loop disappears after a certain period of time. I can get rid of it by adding a /32 static route to the router & if i remove the static route the loop does not return. Only when the vessel drops out the network & comes back in does the loop return. I am using dynamic routing because ships can roam from from one satellite beam to another & therefore one remote hub to another which is supposed to be fully automated but at present i have to add or remove static routes as ships come & go.

The tunnel is mapped to the routers fa0/0 interface & recently i have seen %IP_VFR-4-FRAG_TABLE_OVERFLOW: messages on the routers log. I have increased the value from 16 to 32 then 64 using the "ip virtual-reassembly max-reassemblies" interface command, but this doesn't seem to have made any difference.

The traces i have run show the packets reaching the active router at the remote hub but instead of taking the rip route to the remote vessel it takes the default route out into the internet, back into our core & back out to the remote hub via the GRE tunnel. The Eigrp & RIP routes are being propagated properly so i am not sure why this is happening. We have another remote hub where RIP from the ships is redistributed into EIGRP without any problems & only difference being the link to the core in an E1 not GRE tunnels.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Mon, 10/20/2008 - 10:59

Hello Graeme,

in order to get better help you should provide more details.

If you like you can post a filtered version of your config of a remote router and the hub router.

For example, are your GRE packets travelling inside IPSec packets or they travel directly over the satellite links ?

Do you use any form of GRE keepalive ?

RIP routes have AD 120 and EIGRP external routes have AD 170.

the VSAT device acts as the router on the vessel if I understand correctly.

Just one doubt:

if you use RIP on the Vsat modems to route GRE packets to the hub and EIGRP is used within the GRE tunnels you can build EIGRP adjacencies between the remote 1800 on vessel and the 2811 hub.

But if this is the case you shouldn't redistribute RIP into EIGRP to avoid possible problems. RIP should stay there just to allow GRE packets to travel over VSAT links to advertise GRE endpoints.

"The traces i have run show the packets reaching the active router at the remote hub but instead of taking the rip route to the remote vessel it takes the default route out into the internet, back into our core & back out to the remote hub via the GRE tunnel."

this is the point to be cleared

Hope to help

Giuseppe

Hi Giuseppe

Thanks for replying.

The GRE tunnels are using ipsec & keepalives but are only linking our network core to the routers at the remote hub, there are no tunnels from the remote hub over the satellite link to the vessels.

On the vessels, the vsat modem is connected to the sat dish with the router sitting behind it connected to the modems 8 port built in switch. Both the modem & the router are on the same /29 subnet.

The vsat hub equipment & vessel modems can only use rip & as i don't want to run rip over the core i am redistributing into EIGRP at the remote hub routers with an incoming distribute list to prevent the hub routers seeing all EIGRP routes from the core. The remote hub has internet breakout via the default route & voice is routed into the core through the gre tunnels using a static route.

I hope this clears up any confusion.

Regards

Graeme

Actions

This Discussion