This article discusses the solutions for quiz 14.
Have a look at the quiz to understand the problem.
The network engineer noted that CORE has a default route received from the Border Router (BR) via internal BGP (iBGP) and he wanted to push this default into the OSPF toward the DIST router. In order to achieve this, he configures
To understand the problem you need to know that command "default-information originate" represents a redistribution of prefix 0.0.0.0/0 into OSPF ( and as with any redistribution, it requires the prefix to be in the routing table - except when using the keyword
The key of the quiz is that internal BGP (iBGP) routes are not, by default, redistributed into any IGP (OSPF, in our case) - this is the reason why CORE does not send the default route to DIST.
CORE#sh ip ospf database external OSPF Router with ID (192.168.255.2) (Process ID 1) CORE#
As you can see, the default does not appear in the OSPF database.
As many of you replied to the quiz, to make CORE redistribute the default iBGP into OSPF you need to configure
bgp redistribute-internal under the BGP process. While the purpose of quiz was to open the discussion about this topic, you need to know that using this command you open the door to routing loops.
bgp redistribute-internal dangerous ?
As mentioned, redistributing internal BGP (iBGP) into any IGP is disabled by default and it can be overridden using this command, but it is never recommended. In my opinion, a network that requires this command, needs to be re-designed !
Everybody's talking about how this command is dangerous but there are few scenarios on the web showing the problem, so I will try to present such a routing loop.
The potential for routing loops is given by several facts:
- redistribution means that you loose some information about the "real" source of that prefix
- iBGP loop prevention mechanisms requires only a full mesh and does not consider other information (such as metrics, real originator etc) + using Route Reflection, you loose this protection
- iBGP administrative distance (AD) is higher than the AD of any IGP, so redistributed routes will always be preferred via the IGP
Let's consider the same scenario as in the quiz but with the addition of the 2nd core, with full mesh of iBGP between BR and the two COREs, as shown below:
CORE-1 redistributes the iBGP default route into the OSPF domain => CORE-2 receives both the iBGP (from BR with AD 200) and the OSPF (from CORE-1 with AD 110) and chooses CORE-1 as best, due to lower AD of OSPF vs. iBGP:
sh ip route | i 0.0.0.0... O*E2 0.0.0.0/0 [110/1] via 192.168.1.17, 01:51:31, FastEthernet1/0CORE-2# CORE-2# sh ip route 0.0.0.0Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path Tag 1, type extern 2, forward metric 1 Last update from 192.168.1.17 on FastEthernet1/0, 01:51:21 ago Routing Descriptor Blocks: * 192.168.1.17, from 192.168.255.2, 01:51:21 ago, via FastEthernet1/0 Route metric is 1, traffic share count is 1 Route tag 1 CORE-2# CORE-2# sh ip bgp... Network Next Hop Metric LocPrf Weight Path r>i0.0.0.0 192.168.255.1 0 100 0 100 i CORE-2# CORE-2# sh ip bgp rib-failureNetwork Next Hop RIB-failure RIB-NH Matches 0.0.0.0 192.168.255.1 Higher admin distance n/a
You can immediately notice two (small) problems:
- CORE-2 does not correctly identify the "real" source of the default route
- CORE-2 choses a longer path (via CORE-1) to reach internet prefixes (to exit), instead of direct path to BR
I said "small" problems because there's nothing wrong with the connectivity - CORE-2 can ping ISP link on BR:
ping 126.96.36.199Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/62/88 ms CORE-2# CORE-2# traceroute 184.108.40.206Type escape sequence to abort. Tracing the route to 220.127.116.11 1 192.168.1.17 52 msec 28 msec 16 msec 2 192.168.1.1 64 msec * 64 msec
Now let's imagine that link between BR and CORE-1 gets down. Since the iBGP peering is configured between loopbacks, BGP session will remain up (CORE-1 and BR can reach each other via CORE-2). As a result:
CORE-1 has a default route via iBGP from BR with a next-hop 192.168.1.18 = CORE-2 (BGP performs recursive routing to resolve the BGP next-hops):
sh ip route | i 0.0.0.0... B* 0.0.0.0/0 [200/0] via 192.168.255.1, 00:00:24CORE-1# CORE-1# sh ip cef 192.168.255.11918.104.22.168/32, version 60, epoch 0, cached adjacency 192.168.1.18 0 packets, 0 bytes via 192.168.1.18, FastEthernet1/0, 1 dependency next hop 192.168.1.18, FastEthernet1/0 valid cached adjacency CORE-1#
CORE-2 still has two sources of information for default, OSPF and iBGP, and chooses OSPF back to CORE-1:
sh ip route 0.0.0.0Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path Tag 1, type extern 2, forward metric 1 Last update from 192.168.1.17 on FastEthernet1/0, 00:02:28 ago Routing Descriptor Blocks: * 192.168.1.17, from 192.168.255.2, 00:02:28 ago, via FastEthernet1/0Route metric is 1, traffic share count is 1 Route tag 1 CORE-2#
The result of this:
CORE-2# ping 22.214.171.124Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 126.96.36.199, timeout is 2 seconds: ..... Success rate is 0 percent(0/5) CORE-2# =================================================================== DIST# ping 188.8.131.52Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: ..... Success rate is 0 percent(0/5) DIST# DIST# traceroute 220.127.116.11Type escape sequence to abort. Tracing the route to 18.104.22.168 1 192.168.1.5 36 msec 24 msec 24 msec 2 192.168.1.18 44 msec 28 msec 24 msec 3 192.168.1.17 36 msec 68 msec 36 msec 4 192.168.1.18 72 msec 48 msec 36 msec 5 192.168.1.17 68 msec 64 msec 88 msec 6 192.168.1.18 56 msec 40 msec 68 msec 7 192.168.1.17 72 msec 100 msec 56 msec ... and so on...
A final note: this command is not necessary in case of MPLS VPNs, but this is another topic, maybe a new quiz :-)
Solutions for the quiz
In the end, let's consider all solutions for the quiz.
1. Using "bgp redistribute-internal" on CORE-1
This solution and its potential dangerous situation was detailed above.
The quiz was purposely intended towards the "bgp redistribute-internal" solution, in order to open this discussion/article.
2. Inject the Default Route on the BR
Since the "real" last resort in AS 200 is/are the border router(s), from design perspective, the recommended solution is to generate the default route on the BRs, not on CORE(s).
always option on CORE-1 or Using any Route-Map
Using "default-information originate always" is not equivalent to a redistribution because it does not consider/check whether a default route exists before being advertised into OSPF.
CORE#conf t Enter configuration commands, one per line. End with CNTL/Z. CORE(config)#router ospf 1 CORE(config-router)#
default-information originate alwaysCORE(config-router)#end CORE#sh ip osp database external OSPF Router with ID (192.168.255.2) (Process ID 1) Type-5 AS External Link States LS age: 127 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 0.0.0.0 (External Network Number )Advertising Router: 192.168.255.2 ...
always in this case creates the same routing loop scenario between CORE-1 and CORE-2 when uplink between CORE-1 and BR fails !
Using a route-map, has the same result as with "always" as long as the match condition in the route-map is true, no matter whether a default route exists or not.
Thank you for your comments and interest in the quiz!
Subscribe to this blog to get other more interesting quizzes and detailed solutions.