Multiple EIGRP autonomous systems on the same device and Poisoned Routes

[nickhesson]

Hello All,  I can't believe, I'm not finding anything on the subject of running multiple EIGRP autonomous systems on the same set of routers. I'm hoping my Google skills are down. :)

Here's what we are trying to accomplish and the problem we are running into. Today we have two data Centers connected together over a 1Gb P2P link. We have remote sites connected to both Data Centers in a Dual Hub DMVPN configuration. The whole network is running in EIGRP AS 1 today. The goal is to break up the DCs into their own EIGRP autonomous system, and then deploy BGP between the DCs. So at the remote sites, they would be configured with both ASes. Tunnel interfaces going to DC1 would be in AS 1, and tunnels going to DC2 would be in AS2. The plan was to roll out the configuration with as little downtime as possible.

We are using Nexus 7k's as our core. That connects to a pair of ASR's that connect to the P2P link and terminates the DMVPN tunnels. N7Ks also connects to downstream 4500's as our access layer.

So at DC2 we decided to overlay (or run in parallel) EIGRP AS 2 with AS 1. In the hopes that both AS topologies would be close to the same in DC2. Then use BGP to redistribute AS1 @ DC1, and AS2 @ DC2. That way when we light up BGP over the P2P Link, the EIGRP AS1 routes would lose to BGP @ DC2. Then we would start removing AS 1 off all the devices at DC2.

With all the information I can find, I don't see a problem with that deployment. But we are running into a problem where the IOS devices (being the ASRs, and 4500's) are route poisoning the routes in AS2. AS1 is fine. The NX-OS devices are NOT doing this, where both AS1 and AS2 look fine for all routes in both topologies. But the advertised routes from the N7K for AS2 are being poisoned at the ASR's and 4500's (and of course not being advertised).

Here is an example of the problem:

 

Does anyone know why this is happening?  Can someone point me to the documentation that describes this behavior? 

Thanks for your time and help,

Nick

[Jon Marshall]

Nick

It's the way IOS behaves ie. it two equal cost routes are learnt by two EIGRP processes only the route from the lower AS number is used.

Just tested it myself on IOS 15.x on an emulator and it behaves exactly as yours does.

Obviously Nexus switches behave differently.

Jon

[nickhesson]

Thanks Jon for the quick reply.  But it looks like my google skills are intact (at least so far), as I have already read through the EIGRP FAQs.  I know that if two different processes have the same prefix, with the same metric, the route from the process with the lowest AS (Wins) gets into the RIB.  But doesn't explain why the IOS is route poisoning routes in AS 2.

We don't care which EIGRP process gets routes into the RIB, as both topologies "should be" exactly the same.  The topologies are not the same, because these IOS devices are poisoning routes in AS2.  That is really the main question. 

Why is the IOS route poisoning the routes in the other ASes (or processes)?

In order for our plan to be successful, we need to make sure that all routes exist in AS2 at the ASR that will be redistributing into BGP.  That's not happening because both ASRs and the 4500s are killing routes in AS2.

We have already confirmed that if we remove AS1 from the IOS device, then the routes in AS2 go back to normal (and subsequently get install into the RIB).  

Thanks,

Nick

[Jon Marshall]

Nick

I was assuming it was to stop those routes being advertised to any neighbors.

I expect it is because EIGRP needs a consistent view of the topology and you could in theory run many processes where some routers use one AS and others use another.

I suspect this could lead to routing issues but to be honest it is a best guess as I haven't come up with an example as yet.

Not a great answer I know but it looks to be the default IOS behaviour.

Jon

[paul driver]

Hello

Your post looks like you have duplicate eigrp rids , if so this will deny external/res distribute routes between each other

res

Paul

[nickhesson]

Hi Paul,

We were never planning on redistributing between EIGRP ASes.  Kinda of a bad idea givin' our goals.  AS1 and AS2 were to be independent topologies.

Nick

[Masoud Pourshabanian]

Hello,

Do you have any interface flapping? Interface flapping may cause this behavior. Your Tunnel interface is partitipating in EIGRP? If so, what is the source of tunnel?  I experienced before that advertising routes on both tunnel and physical interface may cause tunnel flapping. Check to see whether you are advertising on both interface and its corresponding tunnel.

Masoud

[paul driver]

Hello Msoud

that advertising routes on both tunnel and physical interface may cause tunnel flapping

I assume this would be down to recusrive routing -when the tunnel destination is seen through the tunnel itself

In this case i assume you would see error log messages to accompany this- unless logging/terminal moniter is turned off?

res

Paul

[Jon Marshall]

Paul, Masoud

This is not about flapping routes or redistribution.

The OP wants to advertise the same routes in two different ASs.

What happens with IOS is if the same route with the same metric is received from two different EIGRP processes  then only one route is installed in the RIB, the one from the lower AS.

In addition the other route is marked as infinite in the topology table which means it is not advertised  to any other routers.

I tested in a lab and I got exactly the same results.

Jon

[Masoud Pourshabanian]

John,

Thanks for taking time and tested it

[paul driver]

Hello Jon
Understood - But FYI mate I did just mention this in case the OP did have duplicate rids as possibilty to why routes between eigrp processes would not be advertised

Hence I thought it was worth a post

res

Paul

[Jon Marshall]

Hi Paul

Sorry I must have misunderstood your post.

I thought you were talking about redistributing between EIGRP processes as opposed to each process just advertising it's own routes within the same process.

Edit - I did test with unqiue router ids and it stil showed the same behaviour.

Jon.

[paul driver]

Hello

LOL  Apologies for the confusion  I meant if either opposing router had the same rids mate -this will negate any prefix that was originated by either router as they have the same rid.

res

Paul

[Murad]

Hi,

It looks you are using VIRL for testing. Why are you not using CSR1000V which is like ASR?

Try it and see if you get it to working there.

HTH

[nickhesson]

(Off Topic reply)

Hi Murad,

Yes, I was using VIRL to validate the problems we were having in our production environment. Yes, the CSR1000V is like an ASR in the fact that both "devices" run the underlying OS of IOS-XE. No, it wouldn’t make a difference, let me explain. The issue we are investigating is related to IOS itself. Which is a running process (daemon) in the IOS-XE platform (aka IOSd). Regardless of which Operating System we choose to use, IOS-XE or an IOS device like “IOSv”, the configuration and IOS behaviors itself are exactly the same (depending on IOS version being used, 15.5.3 vs. 15.4.2 may not be exactly the same). So IOSd (on IOS-XE), IOSv, and IOS running on a 29xx/39xx series ISR is technically the same OS.

Now if your validating or simulating something within IOS by itself, use GNS3. Haha. Not really joking. But if you must use VIRL (in my case I needed NX-OS), then use just the IOSv image. Because if you’re not doing anything with IOS-XE itself, then running CSR1000V is just using extra resources that you’re not using. VIRL is a resource hog.

HTH,

Nick