Follow-Up on OSPF and BGP Puzzle

Couple of days ago, I posted a small problem faced by one of our students and asked our readers to try and solve it. In this article, I will overview the possible solutions to that small puzzle. You should read the original “OSPF and BGP Puzzle” before we proceed. I’ll wait right here!

The network in question dealt with the following diagram.

This was the task:

• Redistribute only 0.0.0.0/0 into OSPF on R2
• Make sure the default route is received in OSPF on R5 and advertised in BGP to R4

Many of you responded with the possible solutions and I’m delighted to say that the vast majority of you picked up on what was wrong with the configuration. There is more than one problem though. There are, in fact, three. Let’s examine them one by one.

OSPF Problem

Simple redistribution of the static routes will not inject the default route into OSPF domain even if there was an actual static route in place. That was of course the reason for the route not to be present in OSPF on R5. Let’s take it from there. Here’s the most relevant configuration on R2.

R2:

ip route 0.0.0.0 0.0.0.0 Null0
!
router ospf 1
 redistribute static subnets route-map Connected
!

Even though there is a route-map attached, it was configured in such a way to permit the default route. As we’ve established, this route never made it to the OSPF.

R2:

R2#show ip ospf database external

            OSPF Router with ID (192.168.0.2) (Process ID 1)

In order to install the default route, we’ll need to use the “default-information originate” command under the OSPF process.

R2:

router ospf 1
 default-information originate
!

Things are now looking much better on R5, since we’ll see the default route in OSPF.

R5:

R5#show ip route ospf
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 00:58:43, Serial0/2/0
O*E2 0.0.0.0/0 [110/1] via 192.168.25.2, 00:01:11, Serial0/2/0

There is something I’m not telling you right now, but we’re not on a very good path. I’ll come back here later on.

BGP Problem

Let’s take a look at the second part of the problem, which is advertising the default route to R4 over the BGP session. Even though we’re redistributing the OSPF routes into BGP, the default route is not making it.

R5:

router bgp 5
 redistribute ospf 1
 neighbor 172.16.45.4 remote-as 4
!

There are two reasons for this behavior. The first one is somewhat obscure behavior of BGP and OSPF interaction, which is the fact that when redistributing the routes form OSPF into BGP, only internal OSPF routes will be redistributed by default. To test this, we’ll quickly remove the route-map from the redistribution on R2. This should cause our other static route from R2 to be advertised into OSPF.

R2:

ip route 10.0.0.0 255.0.0.0 Null0
!
router ospf 1
 no redistribute static subnets route-map Connected
 redistribute static subnets
!

Let’s check the routing and BGP tables on R5.

R5:

R5#show ip route ospf
O E2 10.0.0.0/8 [110/20] via 192.168.25.2, 00:01:09, Serial0/2/0
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 01:07:25, Serial0/2/0
O*E2 0.0.0.0/0 [110/1] via 192.168.25.2, 00:09:54, Serial0/2/0

R5#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.2/32   192.168.25.2            65         32768 ?
*> 192.168.0.5/32   0.0.0.0                  0         32768 ?
*> 192.168.25.0     0.0.0.0                  0         32768 ?

As we can see, 10.0.0.0/8 route didn’t make it into the BGP and neither did the default route. Let’s configure BGP to take external routes into account in addition to the internal routes.

R5:

router bgp 5
 redistribute ospf 1 match internal external
!

R5#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         192.168.25.2            20         32768 ?
*> 192.168.0.2/32   192.168.25.2            65         32768 ?
*> 192.168.0.5/32   0.0.0.0                  0         32768 ?
*> 192.168.25.0     0.0.0.0                  0         32768 ?

We can now see that 10.0.0.0/8 route made it into the BGP, but the default route is still missing. This brings us to the real problem. Similarly to OSPF when redistributing the routes into BGP, IOS will not consider the default route as the valid route for redistribution, unless we tell it explicitly.

There are several ways to do that, but I will use the solution suggested by most of the readers in the previous article (democracy wins), which is a “neighbor default-originate” command.

R5:

router bgp 5
 neighbor 192.168.45.4 default-originate
!

R4:

R4#show ip route bgp
B    192.168.25.0/24 [20/0] via 172.16.45.5, 01:14:22
B    10.0.0.0/8 [20/20] via 172.16.45.5, 00:04:40
     192.168.0.0/32 is subnetted, 2 subnets
B       192.168.0.2 [20/65] via 172.16.45.5, 01:14:22
B       192.168.0.5 [20/0] via 172.16.45.5, 01:14:53
B*   0.0.0.0/0 [20/1] via 172.16.45.5, 00:00:55

That’s it, problem solved! Well… not so fast.

The Devil is in the Details

Let’s remind ourselves again of the original task. I don’t like repeating myself repeating myself, repeating … but bear with me here.

• Redistribute only 0.0.0.0/0 into OSPF on R2
• Make sure the default route is received in OSPF on R5 and advertised in BGP to R4

We have certainly accomplished the task, as instructed, since we have the default route on R5 and on R4. What would happen though if I removed the default route from R2?

R2:

no ip route 0.0.0.0 0.0.0.0 Null0

R5:

R5#show ip route ospf
O E2 10.0.0.0/8 [110/20] via 192.168.25.2, 00:15:04, Serial0/2/0
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 01:21:20, Serial0/2/0

Obviously, it will be gone from OSPF and not available on R5. What about R4?

R4:

R4#show ip route bgp
B    192.168.25.0/24 [20/0] via 172.16.45.5, 00:02:00
B    10.0.0.0/8 [20/20] via 172.16.45.5, 00:02:00
     192.168.0.0/32 is subnetted, 2 subnets
B       192.168.0.2 [20/65] via 172.16.45.5, 00:02:00
B       192.168.0.5 [20/0] via 172.16.45.5, 00:02:00
B*   0.0.0.0/0 [20/0] via 172.16.45.5, 00:02:00

Where did that default route come from? It was generated by R5 to R4, even though R5 never had it in the routing table.

As many of you correctly stated in the previous article’s comments, there are multiple ways of generating the default route in BGP. Other methods include:

• Redistribute the original source protocol and using “default-information originate”
• Aggregate the prefixes using “aggregate-address”
• Use the “network” statement

Any of these methods would be useful and as always when dealing with the CCIE lab, you should probably use one that requires the least amount of work and produces the least amount of side effects. The easiest solution to use is the “network” statement. If we opt for “default-information originate”, we’ll need to redistribute OSPF into the BGP and that causes other routes to be advertised, too. If we use the aggregate-address, we’ll generate the default route if any route is present in the BGP table, unless we use conditional advertising. None of these are as easy as a simple “network” command. So, let’s change our configuration, but don’t forget to put the original static default back in.

R2:

ip route 0.0.0.0 0.0.0.0 Null0

R5:

router bgp 5
 no neighbor 172.16.45.4 default-originate
 no redistribute ospf 1
 network 0.0.0.0 mask 0.0.0.0
!

The beauty of this solution is that only the default route will be advertised to R4 as the result of the OSPF configuration on R2 and no other routes.

R4:

R4#show ip route bgp
B*   0.0.0.0/0 [20/1] via 172.16.45.5, 00:01:26

For testing purpose, let’s remove the static route on R2 and see what happens.

R2:

no ip route 0.0.0.0 0.0.0.0 Null0

R4#show ip route bgp

Brilliant, but we’re not quite done yet. We have now established the correct relationship between BGP and OSPF on R5. How about the relationship between the static routes and OSPF on R2, the very origin of our routes?

We clearly saw what happens when we add or remove the static routes. We can see them being added and removed as a part of our redistribution process. We did have a requirement to redistribute only the default route and no other routes. Our original solution was to use the “redistribute static subnets route-map” command. There is no need for it though.

One Step Further

I should point out that we’re now entering the exercise zone. What follows was never a requirement of the original task, but it’s an interesting behavior and those are always fun to explore, if only a little bit.

When we configured “default-information originate” under the OSPF process, we configured an implicit redistribution of the 0.0.0.0/0 route from whatever source it came from. As it is, the default route could come from any valid source on R2! If we removed the static and we learned the default from EIGRP, R2 would still advertise the default route into OSPF. Can we actually solve the task in such a way to cause the injection of the default route in OSPF only if the original route came from the static route? The answer is – not really, but we can get very close to it.

It’s not a very straight-forward solution, but it can work. As a food for thought, I’ll leave it up to you to discuss why I did it this way and not some other way.

R2:

no ip route 0.0.0.0 0.0.0.0 Null0
ip route 192.0.2.1 255.255.255.255 Null0
ip route 0.0.0.0 0.0.0.0 192.0.2.1
!
access-list 10 permit host 0.0.0.0
access-list 11 permit host 192.0.2.1
!
route-map Static-Only permit 10
 match ip address 10
 match ip next-hop 11
!
router ospf 1
 no redistribute static
 default-information originate route-map Static-Only
!

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Follow-Up on OSPF and BGP Puzzle, 4.3 out of 5 based on 8 ratings

Tags: BGP, CCIE, OSPF, r&s, Routing & Switching