EIGRP AS 5 --> BGP --> EIGRP AS 9 on same router

[fsebera]

We have a need to redistribute EIGRP AS 5 nets into BGP AS 65000 and then redistribute these BGP prefixes into EIGRP AS 9,  all on the same router.

Needless to say, this is not working.

The redistribution of EIGRP AS 5 nets are being redistributed into BGP AS 65000 without fail as shown by the sh ip bgp; Prefixes show as ?.

But cannot figure out how to get these new BGP AS 65000 prefixes into EIGRP AS 9 on the same router to be send on to other EIGRP peers

Any ideas would be greatly appreciated.

Thanks Frank

[John Blakley]

You may need to place "bgp redistribute-internal" under your bgp process.

HTH,
John

*** Please rate all useful posts ***

[Richard Burts · Accepted solution]

Frank

The routes that are redistributed from EIGRP 5 into BGP are in the BGP table and will be advertised to other BGP peers. But as far as that router is concerned they are still EIGRP routes and not BGP routes. So they will not redistribute from BGP to EIGRP 9 on the same router. It should work if you redistribute from EIGRP 5 to EIGRP 9 directly.

HTH

Rick

[fsebera]

Hey Richard,

Thanks for responding and Yes I do agree with your redistribution from EIGRP AS 5 to AS 9 directly but this presents a problem. If we redistribute EIGRP AS 5 into AS 9, EIGRP queries from AS 5 will be sent into EIGRP AS 9 and then back into AS5 on a different path thus a suspect causing a query loop (topology not shown or talked about yet.)  Even though the sh ip bgp displays the prefixes (from EIGRP AS 5), I just assumed they were BGP prefixes. I guess this is my misunderstanding. I guess we could use a different protocol for AS 9 if this definitely won't work.

Thanks

Frank

[cadet alain]

Hi Frank,

As Richard stated the  router redistributes what it has in its routing table and these prefixes are installed as EIGRP routes not BGP routes so  these prefixes can't be redistributed from BGP to EIGRP.

I don't think that queries traverse ASes so it shouldn't be a problem if you redistribute from 1 EIGRP AS to another and if these queries were propagated outside the AS which I doubt then surely the stub feature would take care of this for you and furthermore  if you design your network to always have a feasible successor you will never  emit any queries.

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts]

I do not believe that an AS boundary does stop the EIGRP query, so Frank may have a valid concern. I do not understand his environment well enough to suggest what the solution should be. But it is clear that attempting to redistribute from EIGRP 5 into BGP, and immediately from BGP into EIGRP 9 on the same router will not work.

HTH

Rick

[cadet alain]

Hi Rick,

I've searched a little bit and it seems you are correct:

Taken from Optimal routing design book

"

In short, AS boundaries do not really stop queries. The query itself  might stop, but a new query is generated at the AS border and propagated  through the neighboring AS."

I will sleep more knowledgeable tonight 

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts]

Alain

Thank you for doing the research and confirming what I thought I understood. It is a somewhat common misunderstanding and I am glad that we got it clarified

HTH

Rick

[fsebera]

To bad Cisco doesn't provide a method to use redistribution with some sort of virtual cache thus allowing multiple filtering and announcement on the same box.

Never-the-less it appers anytime a route is lost in my current topology, the EIGRP queries from AS 5 will be regenerated at AS 9 (due to redistribution) and while quering for the lost route will be regenerated into AS 5 (due to redistribution again) thus causing a query loop.  Seems the queries would have a loop mechanism build-in to protect against double redistribution- perhaps they do but having a hard time finding these details.

Without boring you guys with the details of my topology; without some sort of control in place, it appears due to mutal redistribution we could run into an issue with EIGRP queries looping due to the setup of the network.

I have decided to use the 3 fixes that are available:

1. Summarization to peers after redistribution

2. Tag at redistribution points; deny looping tag routes.

3 Distribute-list to hard block prefixes

I'm testing in the lab now and can post the results if anyone is interested.

Thanks again for your input!!

Frank

[dslice]

As the one who wrote that statement in Optimal Routing Design, it's rewarding to see the book used to answer a question for a real problem. BTW, to be more accurate, the original Query is indeed stopped, but when the route is removed from the rib on the redistributing router, it will Query its peers in the second AS looking for an alternative path. This continues until one of the Query ending situations is hit; i.e., an alternative path found, no information on the prefix, or end of the network.

It sounds like the right approach is being taken by using summarization and filtering to bound the reach of the Query.



Sent from Cisco Technical Support iPad App

[fsebera]

Hey Guys,

If only one-way redistribution is configured between EIGRP AS 5 and EIGRP AS 9,

I.E.

router eigrp 5

net a

!

router eigrp 9

redistribute eigrp 5

net b

And EIGRP AS 9 summarizes to AS 9 EIGRP peers, will EIGRP AS 9 ever query EIGRP AS 5?

Thanks

Frank

[dslice]

First, AS 9 will never query AS 5 under any circumstances.  A better way to think about it is that EIGRP will send a Query for a prefix that goes away (or becomes not feasible) if it doesn't have a feasible path and it has any peers to ask. The exception is if a router receives a Query for a prefix it doesn't know about, it has nothing to remove and just responds without sending a Query to anyone else.

On the redistributing router you describe above, if a prefix is learned in AS 9 and is then redistributed into AS 5, it becomes known within AS 5.  If later the route is removed (goes down) in AS 9, when that knowledge reaches the redistributing router, it will remove the prefix from the RIB. The EIGRP process running AS 5 will then get a call back from the RIB saying the prefix has been removed, and the process for AS 5 will go active on the prefix looking for an alternative path.

I don't understand your statement that AS 9 also summarizes to AS 9 peers.  I don't see where that has any bearing on the operation since you've stated a concern about what happens in AS 5.  What am I missing?

[fsebera]

Ok a little clarification

Topology:

           <-------------EIGRP AS 9--------------->

R1------R2------R3_____VPN_____R4-----R5-----R6

|                                            |

^                                            ^

|                                            |

R7-----R#-----R#------R#-----R#-----R#-------R8

            <------------EIGRP AS 5---------------->

R1 and R6 run EIGRP AS 5 and EIGRP AS 9

R1 and R6 redistribute EIGRP AS 5 into EIGRP AS 9

R1 summarizes all AS 5 (now AS 9) nets to R2

R6 summarizes all AS 5 (now AS 9) nets to R5

R7 and R8 have the full Intranet (not Internet) routing table, un-summarized.

EIGRP AS 9 is not redistributed into EIGRP AS 5

It appears to me (based on my limited EIGRP understanding) that when an EIGRP AS 5 net is lost,

queries from R7 will be passed to R1 and since R1 is summarizing nets to R2, queries are stopped.

queries from R8 will be passed to R6 and since R6 is summarizing nets to R5, queries are stopped.

My understanding is EIGRP queries are stopped when:

1. EIGRP summarization is in effect

2. Distribute-list are used to filter nets

3. EIGRP is redistributed into another routing protocol (other than EIGRP)

If EIGRP is redistributing into a different EIGRP AS domain and no summarization or distribute-list are used, then queries continue on into the new AS. (The queries are not really passed into the new domain, but rather an EIGRP timer is set and a new query is generated and that new query is forwarded).

What I don't know (yet, lab testing being performed) is if EIGRP queries are forwarded -in this example- from EIGP AS 9 to EIGRP AS 5 since I am not redistributing AS 9 to AS 5.

Thanks again

Frank

[dslice · Accepted solution]

You have it close (and probably close enough.)  Summarization stops Queries one hop beyond the summary point, by denying the specific knowledge to the peer receiving the summary.  As I stated before, if a router has never heard of a prefix, it immediately Replies without sending any additional Queries.  In your description, you state that queries from R7 to R1 will stop at R1 because of the summarization.  Actually, the summary doesn't stop R1 from sending a Query to R2, but R2 will Reply without further Queries since he only has the summary and not the component prefix.

As for the second question about Queries from AS 9 into AS 5, no Queries will be generated into AS 5 because of the lack of redistribution.  I mentioned in the earlier response that EIGRP gets a callback from the RIB when a prefix is removed.  It only gets that callback for prefixes it has registered itself as interested in.  With your example, AS 5 is not redistributing AS 9 and thus isn't registered as interested.

[fsebera]

Donald,

THANK YOU for the clarification and clear understanding!

Best Regards

Frank