EIGRP neighbors with different AS numbers

[sagarshah3]

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?

Any input will be helpful

Thanks!

Sagar

[Peter Paluch · Accepted solution]

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:

router eigrp 1
 redistribute eigrp 1000
!
router eigrp 1000
 redistribute eigrp 1

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.

Would this option work for you?

Best regards,
Peter

[sagarshah3]

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

Thanks!

[Peter Paluch]

Hi Sagar,

You are welcome.

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.

So the configuration would be slightly more extensive:

route-map E1-to-E1000 deny 10
 match tag 1000
!
route-map E1-to-E1000 permit 20
 set tag 1
!
route-map E1000-to-E1 deny 10
 match tag 1
!
route-map E1000-to-E1 permit 20
 set tag 1000
!
router eigrp 1
 redistribute eigrp 1000 route-map E1000-to-E1
!
router eigrp 1000
 redistribute eigrp 1 route-map E1-to-E1000

This configuration applied to all routers doing redistribution between the two EIGRP domains would make sure that a route is never injected back where it came from.

Best regards,
Peter