EIGRP neighbors with different AS numbers

Hello Guys,

We're in a process of refreshing a network and one of the things is to keep the old network running as we transition into the new one.

Now my question is:

We're running EIGRP AS 1 on our core routers right now, we plan to use a different AS (# 1000) for the new Core's, now in order for both the networks to operate simultaneously, we will need to enable routing and make the new cores talk to the old ones through EIGRP.

I know we need the same AS# to form EIGRP neighborship, but is there a way to manually set up neighborship between 2 routers running different AS numbers?

Hi Sagar,

I know we need the same AS# to form EIGRP neighborship, but is there a way to manually set up neighborship between 2 routers running different AS numbers?

No, there is absolutely no way of forcing two EIGRP routers with different AS numbers to talk to each other.

However, this is what you can do: Run two EIGRP processes on a single router, one in AS 1, the second in AS 1000, let it form adjacencies with both old and new neighbors, and do a mutual redistribution:

You should not even need to set up a seed metric for redistribution, as the original metrics will be directly retaken from the source EIGRP process. Redistributed routes will obviously be advertised as external in the other EIGRP AS but at least they will provide a workable connectivity until the migration is complete.

Hi Sagar,

I know we need the same AS# to form EIGRP neighborship, but is there a way to manually set up neighborship between 2 routers running different AS numbers?

No, there is absolutely no way of forcing two EIGRP routers with different AS numbers to talk to each other.

However, this is what you can do: Run two EIGRP processes on a single router, one in AS 1, the second in AS 1000, let it form adjacencies with both old and new neighbors, and do a mutual redistribution:

You should not even need to set up a seed metric for redistribution, as the original metrics will be directly retaken from the source EIGRP process. Redistributed routes will obviously be advertised as external in the other EIGRP AS but at least they will provide a workable connectivity until the migration is complete.

Hi Peter,Thank you for the

Hi Peter,

Thank you for the prompt response

I had the same thing in mind but just wanted to be very sure that we cannot establish any manual EIGRP neighborship between the Cores with different AS numbers as this would have been the easiest way out.

But, I guess, we will have to run multiple EIGRP instances on each of the cores and do manual redistribution until we retire our old cores and infrastructure (We're re-IPng our network too)

Now on manual redistribution, are the commands as simple as you mentioned above? Just the redistribute statements on all cores with the EIGRP AS instances? Any other statements we will need to put?

Agreed the redistributed routes will be External EIGRP routes but we're fine with that and are not worrying about the route selection as long as the network stays up during the migration of each department and remote site

Hi Sagar,

Now on manual redistribution, are the commands as simple as you mentioned above? Just the redistribute statements on all cores with the EIGRP AS instances? Any other statements we will need to put?

Almost ;) You would do such a simple configuration if you performed this redistribution just on a single router, and it would work (just tested it on 12.4T).

However, from what you have described, it seems that you intend to perform this redistribution on multiple routers in your core. Doing mutual redistribution between two routing protocols on multiple routers opens an opportunity for creation of routing loops. In this case, every router should be configured to mark an original route from one protocol with a unique tag as it is redistributed into the other, and never redistribute it back to the original protocol if the tag shows it has been taken from there already.

With today’s day and age, connectivity has become ubiquitous. Not only do people expect a reliable and fast connectivity in their offices, but also at their favorite coffee shops and grocery stores. Setting up the network to provide such connectivity is n...
view more

Join us November 15 at 10 am PT as we talk to Cisco’s senior Enterprise Networks executives about our recent announcements around SD-WAN and the Catalyst expansion.
As always, our Cisco experts are ready to answer your questions, so...
view more

The more I learn about the applications Cisco partners are building using the DNA Center’s open APIs, the more I am impressed by the creativity by which they are using these APIs. Their solutions are helping network operations by removing the guesswork an...
view more

The Catalyst 9000 family of switches is at the heart of Cisco’s Network Intuitive strategy. The success of Catalyst 9000 Series Switches is inspiring! We are extending the success further by introducing our newest Cisco Catalyst 9200 Series Switches...
view more