Acme Corporation decided to use EvilCorp to provide connectivity between their branches (Site A and Site B). They agreed to use the BGP protocol and establish a neighbor relationship between R1 (Site A) and R3 (EvilCorp) as well as R4 (Site B) and R3 (EvilCorp). There are numerous problems in the network. Would you be able to solve them to provide connectivity between client sites?
Topology
- Every router has a Loopback0 configured with IP address X.X.X.X/32, where X is the router number, i.e R2 (2.2.2.2/32)
- Transit links are configured with IP addresses 10.X.Y.0/24, where X and Y are adjacent router numbers, i.e. the link between R1 and R2 is 10.1.2.0/24
- In EvilCorp (AS 64666) network OSPF is configured as IGP
- Both client sites (A, B) are configured with the same AS number 65001
Configuration
R1-Acme-A
hostname R1-Acme-A
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/0
no shutdown
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
media-type rj45
router bgp 65001
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.1.2.2 remote-as 64666
!
address-family ipv4
network 1.1.1.1 mask 255.255.255.255
neighbor 10.1.2.2 activate
exit-address-family
R2-EvilCorp
hostname R2-EvilCorp
!
ip cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface GigabitEthernet0/0
description LINK TO R1
no shutdown
ip address 10.1.2.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
description LINK TO R3 EvilCorp
no shutdown
ip address 10.2.3.2 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
duplex auto
speed auto
media-type rj45
!
router ospf 1
!
router bgp 64666
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 3.3.3.3 remote-as 64666
neighbor 3.3.3.3 update-source Loopback0
neighbor 10.1.2.1 remote-as 65001
!
address-family ipv4
neighbor 3.3.3.3 activate
neighbor 10.1.2.1 activate
exit-address-family
R3-EvilCorp
hostname R3-EvilCorp
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface GigabitEthernet0/0
description LINK TO R4
no shutdown
ip address 10.3.4.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
description LINK TO R2 EvilCorp
no shutdown
ip address 10.2.3.3 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
duplex auto
speed auto
media-type rj45
!
router ospf 1
!
router bgp 64666
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 64666
neighbor 2.2.2.2 update-source Loopback0
neighbor 10.3.4.4 remote-as 65001
!
address-family ipv4
neighbor 2.2.2.2 activate
neighbor 10.3.4.4 activate
exit-address-family
R4-Acme-B
hostname R4-Acme-B
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/0
no shutdown
ip address 10.3.4.4 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router bgp 65001
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.3.4.3 remote-as 64666
!
address-family ipv4
network 4.4.4.4 mask 255.255.255.255
neighbor 10.3.4.3 activate
exit-address-family
Troubleshooting
Your goal is to provide connectivity between client sites. Let’s try to ping R4 (Site B) loopback (4.4.4.4) from R1 (Site A) loopback (1.1.1.1).
R1-Acme-A#ping 4.4.4.4 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)
Clearly, there are some problems and your job is to fix them.
Note: There are no silly tricks like disabled interfaces, misconfigured IP addresses, or subnet masks. Also, ACLs are not configured.
I would start troubleshooting by simply checking if R1 has a route to 4.4.4.4.
R1-Acme-A#show ip route 4.4.4.4
% Network not in table
That’s not the case. Prefix 4.4.4.4/32 should be propagated via BGP. In the second step, I would check if all BGP peerings are established.
R2-EvilCorp#show bgp ipv4 unicast summary
BGP router identifier 2.2.2.2, local AS number 64666
! output omitted
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3.3.3.3 4 64666 6 6 7 0 0 00:01:24 1
10.1.2.1 4 65001 307 308 7 0 0 04:34:55 1
R3-EvilCorp#show bgp ipv4 unicast summary
BGP router identifier 3.3.3.3, local AS number 64666
! output omitted
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 64666 6 6 2 0 0 00:01:40 1
10.3.4.4 4 65001 308 308 2 0 0 04:34:44 1
Output shown indicates that BGP peerings are established. Based on config, I would assume that R4 originates route 4.4.4.4/32 into BGP, but let’s double-check it.
R4-Acme-B#show bgp ipv4 unicast
BGP table version is 2, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 0.0.0.0 0 32768 i
Indeed, R4 originates route 4.4.4.4/32. According to the diagram that route should be sent via BGP update to R3 and this is true.
R3-EvilCorp#show bgp ipv4 unicast 4.4.4.4/32
BGP routing table entry for 4.4.4.4/32, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65001
10.3.4.4 from 10.3.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Next, that prefix should be sent to the R2 and that router should propagate it to R1.
R2-EvilCorp#show bgp ipv4 unicast
BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.1.2.1 0 0 65001 i
* i 4.4.4.4/32 10.3.4.4 0 100 0 65001 i
R1-Acme-A#show bgp ipv4 unicast
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
That may be not obvious, but the output on R2 indicates that there is some problem with prefix 4.4.4.4/32. If you look closely, you will see that > sign is missing. What is the reason? R2 and R3 are iBGP peers and by default, when advertising a route to an iBGP peer, the advertising router (R3) does not change the next-hop address (10.3.4.4).
R2-EvilCorp#show ip route 10.3.4.4
% Subnet not in table
R2 does not know how to reach 10.3.4.4, because that link was not advertised into OSPF. Thus, R2 cannot install this route into the RIB and obviously can NOT send it to R1, because this will create a black hole in the network.
There are a few solutions to this problem:
- Change the default iBGP behavior with the
neighbor neighbor-ip next-hop-selfcommand under address-family - Advertise mentioned next-hop to the IGP, which will provide reachability
- Change the default iBGP behavior with the
In this case, I will stick with the first solution and I will explicitly tell R3 to set next-hop to itself when sending routes to iBGP peer.
R3-EvilCorp#show run | s router bgp
router bgp 64666
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 64666
neighbor 2.2.2.2 update-source Loopback0
neighbor 10.3.4.4 remote-as 65001
!
address-family ipv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 next-hop-self
neighbor 10.3.4.4 activate
exit-address-family
Note that the problem occurs in the reverse direction as well and the same command is needed on R2, but I'm not showing it for brevity.
Now, the output on R2 looks much better. Route 4.4..4.4/32 is considered as a best-path and it is installed in R2 RIB and sent to the R1.
R2-EvilCorp#show bgp ipv4 unicast
BGP table version is 8, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.1.2.1 0 0 65001 i
*>i 4.4.4.4/32 3.3.3.3 0 100 0 65001 i
R2-EvilCorp#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "bgp 64666", distance 200, metric 0
Tag 65001, type internal
Last update from 3.3.3.3 00:01:20 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 3.3.3.3, 00:01:20 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65001
MPLS label: none
I told you that prefix is sent to R1.
R1-Acme-A#show bgp ipv4 unicast 4.4.4.4
% Network not in table
But output shown indicates that there still must be problem because R1 does not have 4.4.4.4/32 installed in the BGP table. Why is that? Is R2 even sending that prefix? Let’s try to debug BGP updates on R2 and request route refresh.
R1-Acme-A#debug bgp ipv4 unicast updates
BGP updates debugging is on for address family: IPv4 Unicast
*Dec 25 22:18:35.533: BGP(0): 10.1.2.2 rcv UPDATE about 4.4.4.4/32 -- DENIED due to: AS-PATH contains our own AS;
*Dec 25 22:18:35.533: BGP: nbr_topo global 10.1.2.2 IPv4 Unicast:base
R1-Acme-A#undebug all
All possible debugging has been turned off
As a matter of fact, R2 sent prefix 4.4.4.4/32 in the BGP update, but R1 can NOT use it. Why?
A router discards BGP network prefixes if it sees its ASN in the AS-Path as a loop prevention mechanism. That happened in this case - R1 sees its own AS number (65001) in that update and because of that discards the route 4.4.4.4/32.
Again (this is a kinda pattern in BGP), there are at least 2 solutions to this problem:
- On R1 loop prevention mechanism can be disabled with the command
neighbor neighbor-ip allowas-inunder proper address-family - We can configure R2 to replace originating AS a number of originating router (65001) with the AS number of the sending BGP router (64666).
I will use the first solution.
R1-Acme-A#show run | s router bgp 65001
router bgp 65001
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.1.2.2 remote-as 64666
!
address-family ipv4
network 1.1.1.1 mask 255.255.255.255
neighbor 10.1.2.2 activate
exit-address-family
Warning, warning, warning: disabling loop prevention mechanism should be done with caution.
Now, R1 puts the route into BGP table and installs it into the RIB.
R1-Acme-A#show bgp ipv4 unicast
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 4.4.4.4/32 10.1.2.2 0 64666 65001 i
R1-Acme-A#show ip route | i 4.4.4.4
B 4.4.4.4 [20/0] via 10.1.2.2, 00:03:01
R1-Acme-A#ping 4.4.4.4 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/13 ms
Finally, R1 can ping R4. Connectivity was provided according to the requirement. This network had 2 problems or maybe not problems because that is BGP behavior:
- Next-hop reachability - I fixed it by issuing the command next-hop-self and told routers R2 and R3 to explicitly set next-hop to themselves when sending routes to each other.
- The network was designed in a way that sites have the same AS number. Routes were discarded at the destination, because of the default loop prevention mechanism. That mechanism was disabled with the command
allowas-in.