Need help figuring out how to redistribute a learned route between EIGRP and BGP and back to EIGRP

[davebornack]

So - I'm trying to figure out how to get a subnet distributed down an EIGRP and BGP path from a data center to a site through an MPLS network.

The subnet in question is 10.80.0.0/16

An example of a subnet that IS getting learned from the same R1 is 10.170.0.0/16

I can't for the life of me figure out how to get this distributed properly.  Here are the relevant configs and basic topology:

R1 (Has static route to where 10.80 lives, and has the 10.80 advertised in the EIGRP process)

R2 (Data Center MPLS Router) - (Learns the 10.80 subnet through EIGRP) - (There's some sort of redistribute happening into BGP before we hit MPLS provider)

R3 (remote site MPLS Router)  (NEEDS to learn the 10.80 subnet somehow)

R4 (Core Switch that needs to also learn the 10.80 route)

R1 - (EIGRP) Directly Connected to (EIGRP) - R2

R2 - (EIGRP)(BGP) MPLS Provider (BGP)(EIGRP) - R3

R3 - (EIGRP) Directly Connected to (EIGRP) - R4

Here are relevant configs from all 4 Routers:

R1:

I'll leave this config out, as we're successfully advertising this into R2

(D EX     10.80.0.0/16 [170/51456] via 10.170.20.21)

R2:

router eigrp 200

bfd interface GigabitEthernet0/0/0

bfd interface GigabitEthernet0/0/1

network 10.170.20.18 0.0.0.0

network 10.170.20.22 0.0.0.0

network 10.170.254.5 0.0.0.0

network 10.220.0.0 0.0.255.255

network 10.228.0.0 0.0.255.255

network 172.21.0.153 0.0.0.0

redistribute bgp 65035 metric 2000000 10 255 1 1500 route-map BGP->EIGRP

eigrp router-id 10.170.254.5

nsf

!

router bgp 65035

bgp log-neighbor-changes

network 0.0.0.0

network 10.170.254.5 mask 255.255.255.255

network 172.21.0.153 mask 255.255.255.255

aggregate-address 10.170.0.0 255.255.0.0 summary-only

neighbor 172.21.0.154 remote-as 1803

neighbor 172.21.0.154 soft-reconfiguration inbound

!        

ip default-gateway 10.170.99.1

ip route 0.0.0.0 0.0.0.0 10.170.99.1

ip route 10.170.11.0 255.255.255.0 Null0

ip route 10.170.254.0 255.255.255.0 Null0

ip prefix-list CR_NETWORK seq 5 permit 10.170.0.0/16 le 32

route-map BGP->EIGRP deny 10

 match ip address prefix-list CR_NETWORK

!

route-map BGP->EIGRP permit 20

 set tag 90

R3:

router eigrp 200

network 10.7.99.102 0.0.0.0

network 10.7.254.2 0.0.0.0

redistribute bgp 65026 metric 20000 10 255 1 1500 route-map BGP->EIGRP

!        

router bgp 65026

bgp log-neighbor-changes

network 10.7.0.0 mask 255.255.0.0

network 199.160.70.60 mask 255.255.255.255

aggregate-address 10.7.0.0 255.255.0.0 summary-only

timers bgp 3 15

neighbor 172.21.0.106 remote-as 1803

neighbor 172.21.0.106 timers 10 32

ip prefix-list CHARLOTTE-NETWORKS seq 5 permit 10.7.0.0/16 le 32

ip prefix-list CHARLOTTE-NETWORKS seq 10 permit 10.107.0.0/16 le 32

ip prefix-list CHARLOTTE-NETWORKS seq 15 permit 10.207.0.0/16 le 32

ip prefix-list CHARLOTTE-NETWORKS seq 20 permit 192.168.170.0/24

logging host 10.160.1.254

!        

route-map BGP->EIGRP deny 10

match ip address prefix-list CHARLOTTE-NETWORKS

!        

route-map BGP->EIGRP permit 100

!

R4:

router eigrp 200

network 10.7.0.0 0.0.255.255

network 10.7.99.2 0.0.0.0

network 10.7.254.3 0.0.0.0

redistribute static metric 50000 10 255 1 1500 route-map STATIC->EIGRP

passive-interface default

no passive-interface Vlan299

no passive-interface TenGigabitEthernet1/0/48

eigrp router-id 10.7.254.3

eigrp stub connected static summary

ip route 0.0.0.0 0.0.0.0 10.7.11.11

ip route 10.7.254.4 255.255.255.255 10.7.20.2

ip route 10.70.10.0 255.255.255.0 10.7.11.11

ip route 10.170.0.0 255.255.0.0 10.7.99.3 160

ip prefix-list STATICS seq 5 permit 10.70.10.0/24

ip prefix-list STATICS seq 7 permit 10.7.254.4/32

ip prefix-list STATICS seq 10 permit 10.7.0.0/16

route-map STATICS->EIGRP permit 10

match ip address prefix-list STATICS

!

route-map STATIC->EIGRP permit 10

match ip address prefix-list STATICS

So basically, I need R4 to learn about the 10.80 we're advertising from R1. 

We get it to R2 no problem, but I need to figure out how our example 10.170 subnet gets advertised to give myself an example of how to get the 10.80 subnet advertised down the chain over BGP to R3 and R4.

Thanks SO MUCH in advance.

[davebornack]

I see this in the R2 BGP Process:

aggregate-address 10.170.0.0 255.255.0.0 summary-only

Is that what's getting 10.170 down to R3?

[Giuseppe Larosa]

Hello @davebornack ,

on R2 BGP

network 10.170.254.5 mask 255.255.255.255

+

aggregate-address 10.170.0.0 255.255.0.0 summary-only

means prefix 10.170.0.0/16 sent to BGP neighbors

the aggregate-address needs at least one component route in the BGP table to exist the summary-only will suppress each componet subnet

Hope to help

Giuseppe

[davebornack]

Right, R2 is where I'd like to make the change to affect R3/R4.

SO you're saying I need the 10.80.0.0 aggregate statement, as well as a component route that matches that, such as "network 10.80.0.0 0.0.255.255" under the BGP process?

[Elliot Dierksen]

I have some idea what you are trying to do, but the notion of redistributing EIGRP into BGP, and then back into EIGRP makes me cringe. These are the kind of situations where you end up with routing loops that are REALLY HARD to unsnarl. I would encourage you to look at this in a different way. Routers that are spokes DO NOT need every route, IMHO. They need to be able to reach networks, but they don't need to know the details.The routers with a bunch of WAN links need to know the details, but none of the other ones do. Find those boundaries, and distribute either a default route (if applicable) or a really broad summary like 10.0.0.0/8. Summaries are great because the summarizing router will create a NULL route for the summary itself so you don't end up with loops where you don't have a more specific route. Think about this as well. If your spoke router has 5000 routes all with the same next hop, that is using RAM in that router and CPU making it traverse a needlessly long routing table when it only has one WAN path. That isn't a good use of resources there. That is particularly true at spokes where you are more likely to have a lower end router.

[davebornack]

Yeah I get that.

So here's the kicker.  Each remote site, has 3-4 different paths to any given data center over redundant MPLS, and redundant P2P links.  Don't ask why ALL of that is there, I'm new here and we're in the process of reducing links right now.

So really, R1 is at the Data Center, R2 is Primary MPLS in Data Center, R3 is MPLS Router at Remote site, and R4 is the Core SW at the Remote Site.  So simply advertising at R1 isn't going to take our preferred MPLS path, which is why I think this is becoming so tricky.  The connection between R2 and R3 is a managed MPLS provider, which is why the BGP.

I may turn this back around, and just take the **bleep** P2P links in the meantime, which is Pure EIGRP and much easier.  Problem is, we're getting rid of the P2Ps before the MPLS.  But perhaps the answer is P2P for now, and when that goes away, We'll default route over the MPLS, which will make things easy because I don't need to figure out all of the distribution/redistribution.

[Richard Burts]

I have several comments:

- There are many things about your environment that we do not know and some of them might impact the advice that we offer. But based on the little that we know now here are my suggestions.

- You ask "Is that what's getting 10.170 down to R3?"  yes the aggregate address is what is getting 10.170.0.0 to R3. Your partial config seems to show that there are at least 3 subnets in the network that are part of 10.170.0.0/16 (and I think it likely that there are more than 3). Instead of advertising the individual subnets you want to advertise just the summary route. That works well for the 10.170.0.0 subnets.

- You have a very different situation with 10.80.0.0/16. What you have posted shows that R2 has an entry in its routing table for 10.80.0.0/16 (EIGRP external). If you add a network statement under router bgp 65035 

network 10.80.0.0 mask 255.255.00

This would result in R2 advertising the subnet to R3. Pretty simple. And I believe that the network statement is a much better approach than trying to do some type of redistribution (especially given the concerns expressed by @Elliot Dierksen) 

- On R2 you probably want to add something similar to this

ip prefix-list CR_NETWORK seq 15 permit 10.80.0.0/16 le 32

This helps to prevent the loops that Elliot warns about.

- R3 should receive the BGP advertisement of 10.80.0.0/16 and should redistribute into EIGRP without needing any config changes.

- R4 should receive the advertisement of 10.80.0.0/16 from R3 without needing any config changes. 

- I do see a floating static route on R4 for 10.170.0.0/16. I assume that if you lose the BGP advertisement then this is an alternate path (perhaps one of the P2P links that you mention. You might want a similar one for 10.80.0.0/16.

It is not related to the main question that you are asking, but I see this in R2 and want to comment on it:

ip default-gateway 10.170.99.1

This does not hurt anything. But it does not do any good for anything. default-gateway is used only in circumstances where ip routing is not enabled. You typically see it on layer 2 switches, where it is very important. When it is in the config of a device where ip routing is enabled (which it certainly is if you are running both EIGRP and BGP) then it is ignored.

[paul driver]

Hello
Obviously you are not redistributing eigrp  or bgp on R2 and R3  and trying to advertise aggregates 
you could try the following:

Example R2:

ip route 10.80.0.0 255.255.0.0 <R1 nexthop>
ip prefix-list 10 permit 10.80.0.0/16

route-map eigrp permit 10
match ip address prefix-list 10
match source-protocol static

router bgp 65035
redistribute static route-map eigrp

R3

ip prefix-list 10 permit 10.80.0.0/16
route-map bgp permit 10
match ip address prefix-list 10
match source-protocol bgp 65035
router eigrp 200
redistribute bgp 65026 metric 1 1 1 1 1 route-map bgp

[Richard Burts]

@paul driver I am puzzled why you are suggesting a static route on R2 for 10.80.0.0/16. The original post is pretty clear that R2 learns that prefix via EIGRP and the prefix is already in the routing table. So why introduce a static? 

And while it would work to redistribute static into BGP, we do not know if there are other static routes on R2 that would need to be managed. And it seems to me that a simple network statement in BGP for 10.80.0.0/16 works, is simpler and would be preferable in the BGP route selection algorithm. 

[Richard Burts]

As far as using aggregates is concerned, there is good reason to use aggregate address on R2 for 10.170.0.0/16. The config is fairly clear that there are multiple smaller subnets included in the block 10.170.0.0/16. The intent is to advertise a single larger block and not advertise multiple smaller subnets. That is not the case with 10.80.0.0/16. The config is clear that on R2 there is a single entry in the routing table. So no reason to try aggregate address for 10.80.0.0/16.

[paul driver]

Hello

it was only an alternative to not redistribute eigrp in to bgp on R2 as it clearly shows R1 is a stub router as such that router doesn’t need to have a dynamic routing applied and just a default would be applicable-

However is you did want to redistribute eigrp then you would just replace the static route and redistribution with eigrp 

example:

no ip route 10.80.0.0 255.255.0.0 <R1 nexthop>
ip prefix-list 10 permit 10.80.0.0/16
route-map eigrp permit 10
match ip address prefix-list 10
match source-protocol eigrp 200

router bgp 65035
redistribute eigrp route-map eigrp