Redistribution OSPF-to-BGP (Some routes not going)

[jeremyarcher]

I'm experiencing an issue with OSPF redistribution to BGP.  I have 3 sites (as seen in the diagram) - Site A, Site B and a number of remote locations represented as "Site C".

I'm attempting to redistribute routes learned from Site A (via EIGRP) through Site B's MPLS (BGP) network and vice versa.  However, in looking at Site B's advertised route it only shows networks it knows about that are local.  Site A's routes are not being advertised, even though they appear in the routing table an OSPF database.

Currently, I have Site A's MPLS network down (for other troubleshooting reasons).

Here is some (hopefully) helpful output:

Site B (Configuration)

----------------------------------------------------------

router bgp 1

bgp log-neighbor-changes

bgp redistribute-internal

network 10.10.10.0 mask 255.255.255.0 backdoor

network 10.10.20.0 mask 255.255.255.0 backdoor

network 10.10.30.0 mask 255.255.255.0 backdoor

network 10.10.40.0 mask 255.255.255.0 backdoor

network 10.10.50.0 mask 255.255.255.0 backdoor

network 10.10.100.0 mask 255.255.255.0 backdoor

network 10.10.109.0 mask 255.255.255.0 backdoor

network 10.10.111.0 mask 255.255.255.0 backdoor

network 10.10.112.0 mask 255.255.255.0 backdoor

redistribute connected

redistribute ospf 1 metric 110 match internal external 1 external 2 nssa-external 1 nssa-external 2 route-map To-BGP

neighbor x.x.x.x remote-as 65000

neighbor x.x.x.x default-originate

router ospf 1

redistribute bgp 1 metric 110 subnets route-map BGP-Routes

network 192.168.51.0 0.0.0.255 area 10

ip prefix-list To-BGP: 26 entries

   seq 5 permit 10.10.10.0/24

   seq 10 permit 10.10.20.0/24

   seq 15 permit 10.10.30.0/24

   seq 20 permit 10.10.40.0/24

   seq 25 permit 10.10.50.0/24

   seq 30 permit 10.10.100.0/24

   seq 35 permit 10.10.109.0/24

   seq 40 permit 10.10.111.0/24

   seq 45 permit 10.10.112.0/24

   seq 50 permit 172.18.1.0/24

   seq 55 permit 172.18.2.0/24

   seq 60 permit 192.168.100.0/24

   seq 65 permit 192.168.101.0/24

   seq 70 permit 192.168.102.0/24

   seq 75 permit 192.168.103.0/24

   seq 80 permit 192.168.104.0/24

   seq 85 permit 192.168.105.0/24

   seq 90 permit 192.168.106.0/24

   seq 95 permit 192.168.107.0/24

   seq 100 permit 192.168.108.0/24

   seq 105 permit 192.168.109.0/24

   seq 110 permit 192.168.110.0/24

   seq 115 permit 192.168.111.0/24

   seq 120 permit 192.168.113.0/24

   seq 125 permit 192.168.120.0/24

   seq 130 permit 192.168.121.0/24

----------------------------------------------------------

Site B (troubleshooting output)

----------------------------------------------------------

sh ip bgp neighbors x.x.x.x advertised-routes

BGP table version is 750, local router ID is 192.168.51.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter

Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path

*> 172.18.1.0/24    192.168.51.1           110         32768 ?

*> 172.18.2.0/24    192.168.51.1           110         32768 ?

*> 192.168.51.0     0.0.0.0                  0         32768 ?

*> 192.168.100.0    192.168.51.1           110         32768 ?

*> 192.168.101.0    192.168.51.1           110         32768 ?

*> 192.168.102.0    192.168.51.1           110         32768 ?

*> 192.168.103.0    192.168.51.1           110         32768 ?

*> 192.168.104.0    192.168.51.1           110         32768 ?

*> 192.168.105.0    192.168.51.1           110         32768 ?

*> 192.168.106.0    192.168.51.1           110         32768 ?

*> 192.168.107.0    192.168.51.1           110         32768 ?

*> 192.168.108.0    192.168.51.1           110         32768 ?

*> 192.168.109.0    192.168.51.1           110         32768 ?

*> 192.168.110.0    192.168.51.1           110         32768 ?

*> 192.168.111.0    192.168.51.1           110         32768 ?

*> 192.168.113.0    192.168.51.1           110         32768 ?

*> 192.168.120.0    192.168.51.1           110         32768 ?

*> 192.168.121.0    192.168.51.1           110         32768 ?

This network is not getting advertised (10.10.109.0/24) nor are any other of Site A's networks (included in the route-map prefix-list above)

sh ip route 10.10.109.0

Routing entry for 10.10.109.0/24

  Known via "ospf 1", distance 110, metric 110, type extern 2, forward metric 1

  Redistributing via bgp 1

  Advertised by bgp 1 metric 110 match internal external 1 & 2 nssa-external 1 & 2 route-map To-BGP

  Last update from 192.168.51.1 on GigabitEthernet0/0, 1d21h ago

  Routing Descriptor Blocks:

  * 192.168.51.1, from 192.168.51.1, 1d21h ago, via GigabitEthernet0/0

      Route metric is 110, traffic share count is 1

But, this network is getting redistributed (192.168.101.0/24)

sh ip route 192.168.101.0

Routing entry for 192.168.101.0/24

  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1

  Redistributing via bgp 1

  Advertised by bgp 1 metric 110 match internal external 1 & 2 nssa-external 1 & 2 route-map To-BGP

  Last update from 192.168.51.1 on GigabitEthernet0/0, 2d09h ago

  Routing Descriptor Blocks:

  * 192.168.51.1, from 192.168.51.1, 2d09h ago, via GigabitEthernet0/0

      Route metric is 20, traffic share count is 1

In this output, networks that are connected or static on the Site B's ASA are being redistributed.  However, networks learned via EIGRP (such as 10.10.109.0/24) on the ASA at Site B and learned via OSPF on the Site B router are not being advertised even though they are both external type 2 routes and are included in the prefix-list controlling the route-map.

Thanks in advance for any advice or recommendations!

EDIT:  Updated topology drawing to show routing protocols.

[Peter Paluch]

Jeremy,

I believe your problem is caused by the network 10.10.109.0 mask 255.255.255.0 backdoor command (and similar for other networks). From the IOS BGP Command Reference at

http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp4.html#wp1145478

A backdoor network is assigned an administrative  distance of 200. The objective is to make Interior Gateway Protocol  (IGP) learned routes preferred. A backdoor network is treated as a local  network, except that it is not advertised. A network that is marked as a  back door is not sourced by the local router, but should be learned  from external neighbors.

Is there a particular need to mark these routes as backdoor routes? I do not entirely understand your flow of routing information yet so please bear with me.

Best regards,

Peter

[jeremyarcher]

Yes, the main reason we have been using the backdoor command was to force the route to that network over the EIGRP 1Gbps link (with a higher AD) than the BGP network (which is slower).

However, while a food idea, and I suspected the same I did try removing the backdoor command but it did not change the advertised routes.

Sent from Cisco Technical Support iPhone App

[Peter Paluch · Accepted solution]

Jeremy,

Let's try to remove the backdoor command for a single network and leave it that way for while so that we can make some experiments. According to the description of the command, it is absolutely sure that it can prevent the route from being locally injected. Removing this command is a necessary condition - perhaps even something more has to be amended, but for sure, the routes will not be injected into your BGP unless they are not marked as backdoor routes.

In addition, after removing the backdoor keyword or the entire network command, wait for a minute or two. I have a feeling that the redistribution into BGP is not done immediately but rather in 1-minute intervals as the BGP scanner process wakes up.

In any way, please, let have a single network, say, 10.10.109.0/24, without the backdoor keyword to be able to perform further experiments.

Best regards,

Peter

[jeremyarcher]

Thanks Peter,

I have removed the following:

router bgp 1

network 10.10.10.0 mask 255.255.255.0 backdoor

I'll let it sit for awhile.  I also did a "clear ip bgp * soft" to see if that will make a difference.

Maybe I misunderstand the backdoor keyword.  My understanding was that it would alter the AD but not advertise the altered AD but would still advertise the route. 

I'll update after a few minutes to see if the route starts getting advertised now that we've removed the backdoor command.

[jeremyarcher]

Peter,

Thank you for your help.  That did resolve the issue.

I'll  do some more testing later to confirm that my Site B hosts don't get  routed over the BGP network instead of the NLAN network.

I'm  guessing that it's going to be ok though since the AD of EIGRP is lower  than the AD of the advertised OSPF route via BGP to the same network.

Actually, this will not work becaues it will prefer the BGP network (AD 20) vs. the EIGRP.

[Peter Paluch]

Jeremy,

I am glad to see the issue is starting getting solved.

Regarding the backdoor - as you can see yourself, it prevents your router from injecting a backdoor route into its BGP database. Even if it was learned via BGP, it would get the AD of 200 regardless of eBGP/iBGP source, and the route would not be advertised further.

If the BGP routes are learned via iBGP on Site B then they would have their AD set to 200 anyway. If they are learned via eBGP, they will have their AD set to 20 and EIGRP will not be able to beat them. In such case, I believe it would be necessary to selectively increase the AD of these routes; one way to do it would be as follows:

access-list 1 permit 10.10.10.0
access-list 1 permit 10.10.20.0
... ! continue for each network currently marked as backdoor
router bgp XXX
 distance 200 0.0.0.0 255.255.255.255 1

This will cause the selected networks identified by ACL 1 and via any next-hop (0.0.0.0 255.255.255.255) to be assigned the AD 200.

Best regards,

Peter

[jeremyarcher]

Thank you, Peter!

I will implement this tonight in my change window and test again.

Great work here!

[Peter Paluch]

Jeremy,

You are heartily welcome. If the suggested changes do not work as expected, be sure to let me know. And if they do... well, I'd be glad to hear about that as well

Best regards,

Peter

[jeremyarcher]

Thanks again, Peter.

I'm sorry to bother you with another question but I'm afraid that tonight I'm going to run into more issues from the perspective of the "Site C" locations.

Previously, traffic for Site A was routed directly to Site A.  And traffic from Site C to Site B was routed directly to Site B.  I believe that this was mistakenly working simply because the backdoor command was masking the redistribution issue.

However, since (hopefully) that will change tonight both locations will advertise routes from both locations (e.g. Site A will advertise networks for both Site A and Site B).

How will Site C (or more accurately, the BGP network) determine where to route traffic for a destination network?

I'm starting to think that I need another access-list on each site to increase the AD for the networks at the other side (e.g. Site A's networks are an AD of 200, as you recommended, but Site A advertises Site B's networks at, for example, 210)?

Does this make sense or am I making up problems that won't exist?

Thanks again!

[Peter Paluch]

Jeremy,

You have a valid point but what you are seeking for is basically reevaluating your entire routing policy.

In order to answer your question, I would need to know in more detail how your BGP and IGP peerings look like. Your diagram is fine in that it describes the individual routing domains; however, for BGP, I do not see what are the exact peerings (who to whom) and which peerings are iBGP/eBGP.

Would it be possible to modify the diagram so that the peerings are more visible?

In any case, as the Site C is running BGP only, your case can be solved simply by using appropriate BGP tools (local preference or weight in particular) to influence the routing decisions on Site C. Do not modify the AD on Site C just yet.

By the way, how many locations of the type "Site C" do you have? I will try to look for a solution that requires as few changes as possible.

Best regards,

Peter

[jeremyarcher]

Thank you very much Peter.  I really do appriciate the help with this.  It's been a very long week, multiple TAC calls and an ever-growing complexity. :-)

I'd be happy to provide an updated diagram for the BGP peers but there are about 25 of them total.  Each location's BGP peer is also it's next-hop router so they are all unique.

I wasn't intending (yet, at least) to modify the AD on Site C but instead modify the AD for Site B's network on Site A and Site A's network on Site B.  But.. maybe Site C won't respect those modified ADs.  I'm no BGP expert so I may be thinking of a solution that isn't possible.

Does that answer your question?

[Peter Paluch]

Jeremy,

I suggest - let's try to update the diagram with two type-C locations. I assume that the remaining locations are set up in a similar fashion.

Best regards,

Peter

[jeremyarcher]

Thanks Peter!

Attached is the new diagram including the BGP peers.  Also, a sample config I'm using at one of them (the others are the same minus the neighbor address)

router bgp 1

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 162.152.207.129 remote-as 65000

distribute-list 10 out

no auto-summary

[jeremyarcher]

I'm also entaining the idea of eliminating OSPF all together.  I originally made that move because of the original problem described with some routes not getting advertised.  However, since that problem has been resolved, thanks to your help, it seems like a good idea (thus avoiding more complexity and longer convergence times).

If you think that would eliminate some of the issues, and it provides additional benefits, I may make that change tonight.

Moreover, I suspect that the routes (according to "Site C"'s perspective) would both appear with a similar path and origin then.