Does it still make sense to use EIGRP?

[Owen Mould]

Our wide-area network started out pretty meshed, with three Metro Ethernet (multi-point) sites and half a dozen sites connected with T1s. We used EIGRP for resiliency.

Now it's evolved almost completely into a Metro Ethernet WAN, and I'm beginning to wonder if EIGRP has outlived its usefulness. Most sites have only one way in/out--Metro Ethernet--so it doesn't really make sense for them to advertise their routes to other sites.

Just to make it more fun, we're transitioning to two clouds: a new Metro Ethernet product that will eventually replace the old one (but is currently overlaying it at four sites) and a VPLS WAN from TPx (practically the same thing, but a little different in the last mile).

With the new circuits coming up, we're seeing a lot of route flapping as EIGRP neighbors find new high-bandwidth routes through each other. I'm beginning to wonder if we wouldn't do better to just stick in two or three IP SLAs in each router and have them switch between static routes that way. Cruder, but maybe easier to manage.

What do people think?

[Reza Sharifi]

I agree with Jon.  Dynamic routing protocols are easier to manage and maintain. If you want to use a protocol that has multi-vendor support, you can use OSPF.

HTH

[Joseph W. Doherty]

Like Jon, I too lean toward using a dynamic routing protocol.

As to "route flapping" when you bring a new circuit up, yea, but using a new high-bandwidth route is really bad?  If you're using some sites for transit, that you don't desire to, that might also be addressed using EIGRP features.  Or, rather than using statics and IP SLA, you might convert from EIGRP to BGP.

Also if your devices support PfR (PIRO) you can have dynamic routing with IP SLA under the covers.

[Owen Mould]

Thanks all for your replies.

Route flapping is bad when you've got users at a dozen sites doing RDP connections to servers at a colo reached over an MPLS cloud with three entry points on your side and some both static and dynamic NATting happening when your traffic enters the MPLS cloud. (Not the most elegant design, but we've all seen situations where growth got ahead of design.) When a route changes, dynamic NAT changes the user's TCP socket address too, which breaks the RDP session; upper layers eventually figure it out and reconnect, but in the meantime....

I agree that IP SLAs wouldn't be an improvement--their behavior seems easier to predict than EIGRP's, but on further thought having ~60 of them spread over 30 routers sounds like Hell.

Could be one of my problems is that most routers have the entire private network (10.0.0.0/8) in the EIGRP configs. That made sense when the network was more meshed and less multipoint; now, maybe not. Right now I'm trying to convince the EIGRP peers that the branch-office router with a new high-cap connection to the central offices is actually not the best way to reach the colo.

[Jon Marshall]

I would have thought you could modify the delay on the branch router interface with the new connection but that is just a suggestion (which you may already be doing).

Jon

[Owen Mould]

Thanks for the suggestion. I did try that. I made the delay on the old connection 2048 (!). I was afraid I'd cripple the interface, but it's still way popular among its EIGRP neighbors.

I actually went through the three routers that pass traffic to the colo and give them all different delays--1, 2, and 4--but then backed up a little and let the two main gateways have the same delay. Probably a mistake.

I looked up the eigrp network command and found it didn't mean what I thought it did, so no need to correct me on that, if you were thinking of it. At this point I'm inclined to agree and say delay and maybe offset statements will save the day.

What's a little crazy-making is that this particular branch router, unlike all the others, is expected to help out as a transit router, either as a failover or as a load sharer. Two Metro Ethernet connections on one side, four T1s on the other connecting to another site's router, which has an MPLS cloud on its other side.

[Jon Marshall]

I think offset lists are a more precise tool and because you can apply them in both directions it gives you more flexibility in what you are trying to do.

I'm logging off now but if you need help just post up a topology diagram together with a description and I'm sure some bright spark will help you out :)

Jon

[Joseph W. Doherty]

NAT?

Ah, so from what you explain, it's really your NAT being impacted by route changes that's the issue?

If so, if you're running across private (?) MetroE or MPLS, why are you doing NAT?

If you do need NAT, you might also investigate if your equipment and topology would allow you to use stateful NAT.

[Owen Mould]

Yes, NAT is the joker in the deck.

A consortium of multi-site organizations with their own existing private networks got together to set up a colo and run all their traffic to it through a single MPLS cloud. With multiple private networks that had grown up independently, the only feasible way to keep traffic separate in the colo was build a massive NAT table and parcel private subnets out to each organization. The edge router configs are something to see.

So having three edge routers and a fairly reliable Metro Ethernet WAN takes us only so far. Normally sessions look like this:

[PC]<->[local-gw]<->(WAN)<->[hub-gw]<->[edge router||NAT<->(MPLS)->[termserver]

When the nearest edge router hiccups (which I just discovered one of them has been doing all week!) traffic is re-routed to the next-best edge router, but that means the session gets another dynamic NAT applied to it and the server gets confused. Quite likely the EIGRP re-convergence process is only a fraction of the delay users report; most of it would be in the session timing out and resuming (or being re-established manually) under a new NAT.

Stateful NAT? I'll have to look that up.

Thanks, and have a good weekend!

[Jon Marshall]

This is just my opinion but personally I would always choose a dynamic routing protocol over using IP SLA because it is just plain easier :)

In addition if each site has multiple routes to choose from EIGRP should be a lot quicker to fail over.

I would only use IP SLA for reachability when you cannot run a dynamic routing protocol.

That said it is just my opinion and so if you feel more comfortable running IP SLA then that is what you should do.

Jon