Routing EIGRP between multiple Autonomous Systems

[viper1284]

Need some advice on how to configure EIGRP for multiple sites. 10 sites will be connected to core L3 switch via 10GB fiber. Protocol used will be EIGRP. Each site will be their own Autonomous System. Total 10 AS exchanging routing tables. Anyone ever work with this type of design?

EIGRP will be the ONLY protocol used.

[sundar.palaniappan]

That shouldn't be a problem :) Configure your L3 switch with 10 EIGRP processes and everyone of them would have to be in the same AS as the one that it's peering with. For connectivity between the remote sites, if needed, you would need to redistribute between the EIGRP processes.

It would look something like this;

Hub:

int f0/0

description 'connection_to_site_1'

no switchport

ip add 10.1.1.1 255.255.255.0

int f0/1

descritipn 'connection_to_site_2'

no switchport

ip add 10.1.2.1 255.255.255.0

router eigrp 1

net 10.1.1.0 0.0.0.255

redistribute eigrp 2 --> optional, if site one and two need to talk to each other.

router eigrp 2

net 10.1.2.0 0.0.0.255

redistribute eigrp 1 --> optional, if site one and two need to talk to each other.

HTH

Sundar

[ilya.varlashkin]

One way to get that working is as Sundar suggested, the other way is to have each of the sites to run its own AS and backbone AS while core L3 switch run only backbone AS. This way you reduce number of processes on the core router (L3 switch).

On the other hand, what is your motivation to run multiple AS'es? With EIGRP being capable of route summarization you will only make your life easier if you configure all sites within single autonomous system and enable route summarisation between sites and the core router.

[m-haddad]

Hello,

Another suggestion is to configure OSPF instead of EIGRP and configure each branch as a stub area. This would make routing algorithm and routing tables smaller.

You can also do summarization for each area. In short, having multiple areas best to work with OSPF.

Regards,

[viper1284]

The sites just expanded to 17 sites. What are the Pros and Cons about having each site it's own AS and what are the Pros and Cons about having all 17 sites as one AS with EIGRP?

Any feedback will be great!!! :o)

[sundar.palaniappan]

One's advantage is another one's disadvantage. Here are some of the advanatages with each setup;

Single AS:

1. Easy to configure

2. Less burden on the CPU on the host router - as single process/eigrp topology table will consume less CPU cycles when compared to multiple processes.

3. Route propogation is automatic between all the sites - no manual configuration is needed.

Multiple ASs:

1. More control in route propogation - routes have to be manually redistributed between ASs for one remote site to talk to another one.

2. Topology change in one AS will not affect another AS and thus, the CPU/bandwidth at another remote site will not be affected.

With that said, if possible, keep all the sites in single AS for config simplicity and easy to troubleshoot in the future.

HTH

Sundar

[ruwhite]

"Topology change in one AS will not affect another AS and thus, the CPU/bandwidth at another remote site will not be affected."

Okay, so I have a slightly loose leash today, and was actually looking at the stuff flying by in the forums today. :-) In reality, for any redistributed route, the AS redistribution point doesn't really "stop" the query. The query is stopped in one AS, but begins anew in the other AS, and goes all the way through.

Now, the way to solve this is to not redistribute all the routes. At the same time, route filters have the same impact. As for filtering at a redistribution point being more or less difficult than filtering at any other point in EIGRP--I don't know that there's much of a difference between the two. You still have to configure a route map, or an access list, or prefix list, or something, to select which routes are being redistributed, in either case.

Now, you can use tags to filter between processes, but tags/communities are in newer versions of EIGRP for internal routes, so this isn't much of an advantage any longer.

:-)

Russ

[sundar.palaniappan]

"In reality, for any redistributed route, the AS redistribution point doesn't really "stop" the query. The query is stopped in one AS, but begins anew in the other AS, and goes all the way through"

This is assuming that the poster wants to redistribute between the ASs. What if the poster wants to maintain just a hub-spoke connectivity and no spoke-spoke connectivity then there's no need for redistribution between the processes. This would be true if all the resources are located at the central site or keep the remote sites from talking to each other for security reasons!!

It depends on what the poster wants to achieve and we don't have all the facts to really make any conclusion. My response was something generic about the pros and cons of using single Vs. multiple ASs :)

HTH

Sundar

[ilya.varlashkin]

Now you can see that sub-optimal multiple AS design could lead you to scalability problem - with number of sites increasing you'd endup adding more and more EIGRP processes on your core router.

I agree with Sundar regarding topology change effect on the whole EIGRP domain, but I don't think redistribution provides significantly more control that you couldn't achieve within single EIGRP. With EIGRP being derivative of a vector-distance protocol, it has capability of filtering routing announcements on the interfaces (unlike link-state protocols, which propagate announcements throughout the whole area).

How many networks do you expect to have in the routing table on the core router and how many routers do you have in total at all sites? How is the topology of the network - do all sites have only links to the core router(s) or do you also have direct link between some sites?

[sundar.palaniappan]

Ilya,

Yes, you can filter routes in EIGRP but my point was this would involve more configuration work. As a matter fact, there's a feature in OSPF that lets you filter type 3 LSAs.

HTH

Sundar

[viper1284]

I think we're going to go with the single AS. After looking into the design a little deeper a single AS will be much easier to administer. 17 AS for 17 sites would become a nightmare and if new sites are ever added the AS process on the core router will start to consume too much CPU power on the core router. In this case it's either going to be a L3 switch 6509 or 6513.

All of your replies also helped us look at the design deeper. Thank you all!!!

I can keep you all posted on the process of the install.

Tomorrow all the Engineers will meet to start discussing the final design. We're going to also be implementing VLANs. Huge design! :o)