Solved: A question about mutual redistribution between EIGRP and BGP

shibindong · ‎09-11-2007

hi: I setup a lab with 6 routers as you can see from the attachment, PE1 run IBGP with PE2, PE1 run EBGP with CE3, PE2 run eBGP with CE4, and CE3, CE4, R5 and R6 run EIGRP1. I configured mutual redistribution on CE3 and CE4 (take CE3 as example:)

router eigrp 1

network 35.0.0.0

redistribute bgp 200 metric 100000 100 255 1 1500

!

router bgp 200

no synchronization

bgp log-neighbor-changes

network 3.3.3.3 mask 255.255.255.255

redistribute eigrp 1

neighbor 13.13.13.1 remote-as 500

no auto-summary

and CE4 has the samiliar config except the IP address.

1. I know mutual redistribution is quite compilcated issue and it may creat routing loop, you need to use route-map to prevent routing loop, but after I config redistribution without route-map, I check every route, it looks fine, can I say it will not cause routing loop?

2. When I tried to add route-map on both CE3 and CE4 router, my solution is that:

router eigrp 1

network 35.0.0.0

redistribute bgp 200 metric 100000 100 255 1 1500 route-map e2b

!

router bgp 200

no synchronization

bgp log-neighbor-changes

network 3.3.3.3 mask 255.255.255.255

redistribute eigrp 1 route-map b2e

neighbor 13.13.13.1 remote-as 500

no auto-summary

route-map e2b deny 10

match tag 1000

!

route-map e2b permit 20

set tag 2000

!

route-map b2e deny 10

match tag 2000

!

route-map b2e permit 20

set tag 1000

and the samiliar configuration on CE4.

but when I applied "redistribute eigrp 1 route-map b2e" I got warining msg:"% "b2e" used as redistribute eigrp into bgp route-map, set tag not supported". After that I tried to check the route tag, I found all the route learn by BGP has route tag:500, and I am not able to see the route tag leared by EIGRP?

How to work this issue?

Kevin Dorrell · ‎09-12-2007

Are you are going to get any routing loops here? Let us think this through ..

Any route that finds its way into BGP from EIGRP on CE3 will come from AS200, pass through AS 500, and end up on CE4. There it will have an AD of 20, being eBGP, and will take preference over the same route learned from EIGRP (AD 90). That could be a problem. One way to get over that is to put an AS_PATH filter in CE4 to filter out anything that comes from AS 200. And vice versa in CE3 for anything that came from AS200.

In this respect, you could think of the AS PATH as a tag, which is what you were trying to do with your route maps. Just that BGP does not support tags as such (although communities and AS Paths can fulfil the same functions).

But it may be that you want to use the BGP as redundancy in case you use the link between R5 and R6. In that case you could declare the internal EIGRP routes as backdoor routes in BGP on CE3 and CE4. That means that routes from R5 will be re-distributed into BGP on CE3, say, go through the BGP cloud, and end up on CE4. Normally, they would have an AD of 20, which would give you a problem. But if they are declared as backdoor, then they would have an AD of 200, which would give the EIGRP route priority.

In the other direction, how about BGP routes getting redistributed into EIGRP, and back out to BGP again on the other router. You can get over that by only re-distributing EIGRP internal routes, and not its externals.

This is a particular example of a general class of problem that often occurs in CCIE labs, but rarely in the real world: that is, where you have an IGRP domain that spans several BGP domains.

Hope this makes sense.

Kevin Dorrell

Luxembourg

View solution in original post

Kevin Dorrell · ‎09-12-2007

Are you are going to get any routing loops here? Let us think this through ..

Any route that finds its way into BGP from EIGRP on CE3 will come from AS200, pass through AS 500, and end up on CE4. There it will have an AD of 20, being eBGP, and will take preference over the same route learned from EIGRP (AD 90). That could be a problem. One way to get over that is to put an AS_PATH filter in CE4 to filter out anything that comes from AS 200. And vice versa in CE3 for anything that came from AS200.

In this respect, you could think of the AS PATH as a tag, which is what you were trying to do with your route maps. Just that BGP does not support tags as such (although communities and AS Paths can fulfil the same functions).

But it may be that you want to use the BGP as redundancy in case you use the link between R5 and R6. In that case you could declare the internal EIGRP routes as backdoor routes in BGP on CE3 and CE4. That means that routes from R5 will be re-distributed into BGP on CE3, say, go through the BGP cloud, and end up on CE4. Normally, they would have an AD of 20, which would give you a problem. But if they are declared as backdoor, then they would have an AD of 200, which would give the EIGRP route priority.

In the other direction, how about BGP routes getting redistributed into EIGRP, and back out to BGP again on the other router. You can get over that by only re-distributing EIGRP internal routes, and not its externals.

This is a particular example of a general class of problem that often occurs in CCIE labs, but rarely in the real world: that is, where you have an IGRP domain that spans several BGP domains.

Hope this makes sense.

Kevin Dorrell

Luxembourg

shibindong · ‎09-12-2007

thanks for your reply, I am not able to understand" re-distributing EIGRP internal routes, and not its externals", can you explain in detail?

royalblues · ‎09-12-2007

Another best way to do away with mutual redistribution would be to use network statements under BGP rather than redistributing EIGRP into it.

Though this approach would be feasibel only when you do not have many networks with EIGRP

Narayan

Kevin Dorrell · ‎09-12-2007

route-map e2b permit 10

match route-type internal

This will distribute into BGP only those routes that came from the EIGRP domain itself, and not ones it learned from the BGP of the other BGP<->EIGRP border router.

Kevin Dorrell

Luxembourg

royalblues · ‎09-12-2007

Kevin

Does the internal keyword works with EIGRP too? i was thinking that it works with only OSPF

Narayan

Kevin Dorrell · ‎09-12-2007

Narayan,

Now you have sown a seed of doubt in my mind. I think it applies to EIGRP as well as OSPF, but I am prepared to be corrected. (If so, I will have learned something today. :-)

P.S. Yes, according to the doc. it does apply to EIGRP as well. Useful!

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d029.html#wp1039216

Kevin Dorrell

Luxembourg

royalblues · ‎09-13-2007

Thanks Kevin,

Atleast i learnt something today :-)

I had never used it with EIGRP and hence was not sure.

Narayan

robert.ward · ‎09-12-2007

This process works and I ahve done it many times over for dual homed clients coming into different buildings where BGP then has to drop into the regional EIGRP network.

I can only imagine you have some syntax slightly wrong.

router eigrp 1234

redistribute bgp 65001 metric 100 200 255 1 1500 route-map BGPtoEIGRP

route-map BGPtoEIGRP permit 10

match ip address from-site

set tag 54321

route-map EIGRPtoBGP deny 10

match tag 54321

you set the tags on each side and deny in one direction and permit in the other depending on what tag is already set. Works well and fails over fine even through firewalls which is the main reason for doing this.

Kevin Dorrell · ‎09-12-2007

That's fine for the re-distribution from BGP to EIGRP - setting a tag on the way in, and forbidding any tagged routes to go out again to BGP. That works because EIGRP supports tagging.

But I think the original question was about distributing EIGRP routes into BGP, and stopping them from coming back in again via another AS connection. That you cannot do with tags because BGP does not support tagged routes. Even if it did (hypothetically) there would be no guarantee that the tag would not get stripped on its way through the BGP cloud.

Kevin Dorrell

Luxembourg

shibindong · ‎09-13-2007

thanks for your great help again!

I use your instruction, and it works except some thing:

1. backdoor need to be hard code the subnet each by each. let say we have over 100 network need to be used for backdoor, I have to type it one by one.

2. I tried your route-map e2b and only redistribute internal route, but

I realized it if I shut down R5 and R6, R5 cannot learn rotue from R3, except only 1 route which CE3's lo0 ip route.

for example, before I apply route-map in the redistribution, I can see the route in the R6:

R6#sh ip ro

Gateway of last resort is 46.46.46.4 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets

D EX 1.1.1.1 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

35.0.0.0/24 is subnetted, 1 subnets

D EX 35.35.35.0 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

2.0.0.0/32 is subnetted, 1 subnets

D EX 2.2.2.2 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

3.0.0.0/32 is subnetted, 1 subnets

D EX 3.3.3.3 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

4.0.0.0/32 is subnetted, 1 subnets

D 4.4.4.4 [90/130816] via 46.46.46.4, 00:12:10, Vlan3

5.0.0.0/24 is subnetted, 1 subnets

D EX 5.5.5.0 [170/51456] via 46.46.46.4, 00:00:18, Vlan3

6.0.0.0/32 is subnetted, 1 subnets

C 6.6.6.6 is directly connected, Loopback0

12.0.0.0/24 is subnetted, 1 subnets

D EX 12.12.12.0 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

46.0.0.0/24 is subnetted, 1 subnets

C 46.46.46.0 is directly connected, Vlan3

13.0.0.0/24 is subnetted, 1 subnets

D EX 13.13.13.0 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

D*EX 0.0.0.0/0 [170/51456] via 46.46.46.4, 00:00:50, Vlan3

and after I apply the route-map e2b on CE4, I saw the routes in the R6 changed;

R6#sh ip ro

Gateway of last resort is not set

35.0.0.0/24 is subnetted, 1 subnets

D EX 35.35.35.0 [170/51456] via 46.46.46.4, 00:08:34, Vlan3

3.0.0.0/32 is subnetted, 1 subnets

D EX 3.3.3.3 [170/51456] via 46.46.46.4, 00:08:34, Vlan3

4.0.0.0/32 is subnetted, 1 subnets

D 4.4.4.4 [90/130816] via 46.46.46.4, 00:19:54, Vlan3

5.0.0.0/32 is subnetted, 1 subnets

D EX 5.5.5.5 [170/51456] via 46.46.46.4, 00:01:32, Vlan3

6.0.0.0/32 is subnetted, 1 subnets

C 6.6.6.6 is directly connected, Loopback0

46.0.0.0/24 is subnetted, 1 subnets

C 46.46.46.0 is directly connected, Vlan3

And I compare the route in CE4 and R6, I noticed only BGP route with AD 200 (backdoor) been redistributed and forward to R6, other BGP route with AD 20 did it.

can explain?

thanks again.

Kevin Dorrell · ‎09-13-2007

You are absolutely right on both of your points. Perhaps I should be clear that I was suggesting either the e2b route-map, or the backdoor, but not both. Let's look at those one at a time.

Considering the e2b route-map, this should be applied on both CE3 and CE4, and will stop routes from EIGRP getting redistributed into BGP and then back again at the other brorder router. At you point out, this will work OK until you lose the link R5-R6 so the EIGRP domain becomes discontiguous. At that point it would be useful to use the BGP as a "backdoor" to repair the EIGRP domain, but that is forbidden by the route-map. That is the downside of that solution.

(The third solution I hinted at - an AS_Path filter on CE3 and CE4 - would suffer the same problem.)

The alternative is the backdoor command on both CE3 and CE4. This allows the route feedback, but penalises it to such an extent (AD 200) that the fed-back routes do not take effect unless the EIGRP domain is broken. Which is precisely what you want. But, as you rightly point out, it is not scalable if your EIGRP domain has 100 routes that you might want to backdoor.

I have always argued that it would be really really useful if you could set the AD from within a route-map. This is precisely the sort of scenario where it could help.

I just thought of a fourth, perhaps more elegant, solution that you could try. No route-map, no backdoor. On CE3 and CE4, try:

router eigrp 1

distance 15 170

I'm sure you can work out what I am trying to do there. ;-)

BTW, I read your console log carefully, and I was surprised that R6 could still see 35.35.35.0/24, 3.3.3.3/32, 5.5.5.5/32 even with the route-map in place. Well, I can understand 35.35.35.0/24 and 3.3.3.3/32 if CE3 has included those in the BGP. But not 5.5.5.5/32. I wonder if those were stale routes that simple had not died yet. If you clear ip route * on R6 and CE4 after you add the route map you will be sure to clear out any obsolete routes.

Kevin Dorrell

Luxembourg