Help with EIGRP

[rhltechie]

Hi All,

a few questions about a setup i will be putting into place in a few months.

I am going mpls with five remote sites. Two of which are getting two T1's from the same company terminating on a 2821 at each site. mlppp is not fully supported so i was thinking i must use cef. Also, at first i was thinking static routes but after doing some reading maybe i should aim for EIGRP?

also, am i going to get the speed with cef of both T's that i might get with mlppp?

another issue is we have a DR internet connection at one of the remote sites. with all going well, everyone comes back to the hub to go to the internet. if for some reason the connection between the hub and the mpls cloud is broken, everyone should go to the DR internet site. what is the best way to make sure in this event that all sites get a route to the DR site? a second default route with higher cost?

Thanks for any info.

[pkhatri]

Hi,

A few comments:

- if you are getting two T1s to one of the sites, I would advise that you get the provider to terminate them on different PEs at their sites. This gives you redundancy against a single PE failover. However, that precludes the use of MLPPP.

- you can use CEF to give you reasonable load-sharing performance but it cannot fully match what you get with MLPPP

- are you sure your provider will support EIGRP as a PE-CE protocol ? Not too many do... Since your have two T1s to one of the sites, it would be preferable to use a dynamic protocol than statics to get better failure detection. Also, your DR requirements mean that you need to use a dynamic protocol

- to get the DR system working, configure both the hub site and the DR site to inject defaults with the hub site using a better metric. The PEs will switch to the backup default when the link to the hub is lost.

Hope that helps - pls rate the post if it does.

Paresh

[rhltechie]

Thanks for your response.

-I have asked to have the two T's terminated on different PE's, so i assume they will comply. (ha!)

-so if at all possible you want to use mlppp? are there any advantages to using cef?

thanks again for your help.

[pkhatri]

Hi,

MLPPP is okay, but can result in high CPU utilisation since it is software-based. CEF will get you pretty close to MLPPP so I would not be too concerned about this matter. CEF should do just fine for what you are after.

What I mean by 'inject defaults' is simply to advertise a default route. Typically, in a MPLS VPN environment such as yours, you do the following:

- the hub site advertises a default to the PE via whatever routing protocol they are using

- the spoke sites advertise the specific networks present at the site

- the PE advertises all spoke site routes to the hub

- the PE advertises a default route to the spoke sites

Pls do remember to rate posts that help...

Paresh

[rhltechie]

you were right, they only allow BGP and static. For a wan this small, would it really be feasible to run BGP?

If I have to go static, can a second route be added to the spokes with a higher cost to the DR site?

thanks again

[pkhatri]

Hi Mate,

No setup is too small for BGP when you want the flexibility it gives you..

Things get a bit messy with static routes in such cases. You provider will have to explicitly make one default more preferable to the other. If they are willing to do so, then your problem is solved. However, in most cases they will want you to use BGP. BGP is not that much more complicated to set up, really. In fact, what I suggest is that you run static routing out to your spoke sites and run BGP between the hub and the PE, as well as the DR site and the PE. That way, you can influence which default is preferred by setting BGP attributes accordingly. Most providers will let you add communities to your routes which are then used by the provider to assing Local Preference values to the routes. You can set the communities on the defaults in such a way that your primary default gets a higher Local Pref.

This hybrid approach of static and BGP routing should work well for you.

Paresh

[rhltechie]

Thanks so much for your help.