CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 1

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 1 Ticket 3 - BGP Traffic Engineering R18 of the Large Office 1 must be able to reach 4 BGP networks located behind R100 in the Internet SP (AS 10000). The traffic from R18 to these networks must pass through the Global SP (AS 65111) and must be engineered in this way: Traceroute from R18 to 100.1.0.1 must pass through R2 and R7. Traceroute from R18 to 100.1.1.1 must pass through R1 and R7. Traceroute from R18 to 100.1.2.1 must pass through R2 and R8. Traceroute from R18 to 100.1.3.1 must pass through R1 and R8. You are not allowed to modify the configuration of R100 and R200. Solution This ticket is quite challenging. It is a BGP traffic engineering ticket in which you must establish two main things: IP reachability between R18 and 4 BGP networks located behind R100. The traffic must be engineered according to the rules requested in the question. You begin as usual by determining the devices of interest to the ticket, which are R18, R1, R2, R3, R4, R5, R6, R7, and R8. Remember that you are not allowed to modify the configuration of R100 and R200. R100 13 9 BGP RR BGP RR E0/0 E0/0 E0/1 E0/1 E0/0 E0/0 S1/0 S1/0 R7 34 33 R5 26 25 R3 2 1 R1 100.1.100.8/30 10 10 E0/1 53 41 E0/3 E0/3 21 E0/2 E0/2 E0/2 E0/2 9 E0/1 46 37 14 5 200.1.100.8/30 Global SP BGP AS 65111 100.1.100.12/30 OSPF E0/2 E0/2 E0/2 E0/2 S1/0 38 45 155.1.0.X/30 6 13 10 E0/1 E0/1 54 42 E0/3 E0/3 22 14 S1/1 E0/0 E0/0 E0/1 E0/1 E0/0 E0/0 14 R8 50 49 R6 30 29 R4 18 17 R2 9 R200 13 5 200.1.100.12/30 200.1.100.4/30 In BGP traffic engineering tickets, you must follow two main steps to obtain the requested traceroute output(s): 1. Ensure that there is a bidirectional IP reachability between the source of traffic and the destination network(s). 2. Ensure that the proper BGP traffic engineering policies are applied in the appropriate routers. We will follow these 2 main steps, and at the end, we will get the requested traceroute outputs. R18 Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 1

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 2 1. Check of bidirectional IP reachability In this step, you must ensure that R18, the source of the requested traceroutes, is receiving and installing the 4 BGP routes located behind R100. Reciprocally, you must ensure that the destination of the traceroutes, is receiving a route for 200.1.100.4/30 so that it can respond to the traceroutes sourced from R18 s S1/0 interface. The question states that you cannot touch R100, so normally it should be advertising the 4 BGP routes to both of R7 and R8. You check them and you find that your assumption was correct: R7# show ip bgp * 8.8.4.0/24 155.1.100.14 0 65001 10000 i *> 100.1.100.9 0 0 10000 i * 100.1.0.0/24 155.1.100.14 0 65001 10000 i *> 100.1.100.9 0 100 0 10000 i * 100.1.1.0/24 155.1.100.14 0 65001 10000 i *> 100.1.100.9 0 100 0 10000 i * 100.1.2.0/24 155.1.100.14 0 65001 10000 i *> 100.1.100.9 0 0 10000 i * 100.1.3.0/24 155.1.100.14 0 65001 10000 i *> 100.1.100.9 0 0 10000 i R8# show ip bgp *> 8.8.4.0/24 100.1.100.13 0 0 10000 i *> 100.1.0.0/24 100.1.100.13 0 0 10000 i *> 100.1.1.0/24 100.1.100.13 0 0 10000 i *> 100.1.2.0/24 100.1.100.13 0 100 0 10000 i *> 100.1.3.0/24 100.1.100.13 0 100 0 10000 i R7 and R8 will in turn advertise these routes to their BGP neighbors inside the Global SP (AS 65111), so find their neighbors: R7# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 100.1.100.9 4 10000 17 19 9 0 0 00:11:10 8 155.1.5.5 4 65111 0 0 1 0 0 never Active 155.1.100.14 4 65001 17 18 9 0 0 00:11:15 8 R8# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 100.1.100.13 4 10000 20 18 10 0 0 00:13:43 8 155.1.5.5 4 65111 20 21 10 0 0 00:12:40 1 R7 and R8 are both BGP neighbor with R5, which is a BGP route reflector (RR) inside AS 65111 (according to the diagram). However, the BGP neighborship between R7 and R5 is stuck in the Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 2

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 3 Active state, so you must fix it because the ticket states that 2 traceroutes among 4 must pass through R7. To this purpose, you decide to check the BGP configuration in both routers. The configuration on R7 is correct, however, on R5 the BGP neighborship was administratively shutdown, so bring it up and check if the BGP neighborship is established after that: R5# show run section bgp router bgp 65111 bgp router-id 155.1.5.5 bgp cluster-id 65111 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor RR-CLIENTS peer-group neighbor RR-CLIENTS remote-as 65111 neighbor RR-CLIENTS update-source Loopback0 neighbor 155.1.3.3 peer-group RR-CLIENTS neighbor 155.1.6.6 peer-group RR-CLIENTS neighbor 155.1.7.7 peer-group RR-CLIENTS neighbor 155.1.7.7 shutdown neighbor 155.1.8.8 peer-group RR-CLIENTS! address-family ipv4 neighbor RR-CLIENTS route-reflector-client neighbor 155.1.3.3 activate neighbor 155.1.7.7 activate R5(config)# router bgp 65111 R5(config-router)# no neighbor 155.1.7.7 shutdown R5# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 155.1.3.3 4 65111 24 25 10 0 0 00:16:55 1 155.1.6.6 4 65111 8 15 46 0 0 00:03:19 0 155.1.7.7 4 65111 0 0 1 0 0 never Idle 155.1.8.8 4 65111 26 25 10 0 0 00:17:04 8 Despite fixing the neighbor 155.1.7.7 shutdown issue, the BGP neighborship is still in an Idle state, so you suspect that there is an OSPF issue between R5 and R7 because the BGP protocol is using OSPF as un underlay mechanism to build neighborships on top of it in AS 65111. In fact, when a BGP configuration is correct whereas the BGP neighborship doesn t come up, then most likely there is an OSPF issue (or a routing issue generally). The BGP neighborship between R5 and R7 is configured to be sourced from their respective Loopback0 interfaces, so check if each one of them is receiving a route to the Loopback0 interface of the other: R5# show ip route section 155.1.7.7 R5# Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 3

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 4 R7# show ip route section 155.1.5.5 O 155.1.5.5/32 [110/11] via 155.1.0.33, 00:19:11, Ethernet0/0 R7 is receiving a route to R5 s Loopback0 interface, however, R5 isn t receiving a route to R7 s Loopback0, so check the OSPF configuration of R7 interfaces: R7# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/2 1 0 155.1.0.46/30 10 DR 1/1 Et0/1 1 0 155.1.0.53/30 10 BDR 1/1 Et0/0 1 0 155.1.0.34/30 10 DR 1/1 Lo0 10 0 155.1.7.7/32 1 P2P 0/0 R7# show run interface Loopback0 interface Loopback0 ip address 155.1.7.7 255.255.255.255 ip ospf 10 area 0 You find that R7 s Loopback0 interface is advertised in a wrong OSPF process, so correct it: R7(config)# interface Loopback0 R7(config-if)# ip ospf 1 area 0 Now, the R5-R7 BGP neighborship is established, and R5 is receiving the 4 BGP routes from both R7 and R8: R5# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 155.1.3.3 4 65111 31 34 18 0 0 00:23:03 1 155.1.6.6 4 65111 8 15 46 0 0 00:03:19 0 155.1.7.7 4 65111 8 13 18 0 0 00:00:41 8 155.1.8.8 4 65111 33 34 18 0 0 00:23:12 6 R5# show ip bgp *>i 8.8.4.0/24 155.1.7.7 0 100 0 10000 i * i 155.1.8.8 0 100 0 10000 i *>i 100.1.0.0/24 155.1.7.7 0 100 0 10000 i * i 155.1.8.8 0 100 0 10000 i *>i 100.1.1.0/24 155.1.7.7 0 100 0 10000 i * i 155.1.8.8 0 100 0 10000 i *>i 100.1.2.0/24 155.1.7.7 0 100 0 10000 i * i 155.1.8.8 0 100 0 10000 i *>i 100.1.3.0/24 155.1.7.7 0 100 0 10000 i * i 155.1.8.8 0 100 0 10000 i The output of the show ip bgp summary on R5 showed that it is also BGP neighbor with R3 (in addition to R7 and R8), so move to R3 and check if it is receiving and installing the 4 BGP routes: Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 4

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 5 R3# show ip bgp r> 155.1.100.0/30 155.1.100.2 0 0 65000 i *>i 200.1.100.4/30 155.1.2.2 0 100 0 20000 65003 i R3 doesn t have the 4 BGP routes in its BGP table, so return to R5 and ensure that these routes are being advertised to R3: R5# show ip bgp neighbors 155.1.3.3 advertised-routes *>i 8.8.4.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.0.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.1.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.2.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.3.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.100.0/30 155.1.7.7 0 100 0 65001 i *>i 100.1.100.4/30 155.1.7.7 0 100 0 10000 65006 i *>i 155.1.100.0/30 155.1.3.3 0 100 0 65000 i *>i 155.1.100.12/30 155.1.7.7 0 100 0 65001 i Total number of prefixes 9 The 4 BGP routes are being advertised from R5 to R3, however, none of them is installed into R3 BGP table, so you decide to debug the received BGP routes in R3: R3# debug ip bgp 155.1.5.5 updates BGP updates debugging is on for neighbor 155.1.5.5 for address family: IPv4 Unicast Trigger a BGP soft reconfiguration on R5 to speed up the debug output on R3: R5# clear ip bgp * soft out You return to R3 and you find that the BGP routes are being dropped because they contain the same BGP cluster-id configured locally: R3# *May 1 16:41:02.820: BGP(0): 155.1.5.5 rcv UPDATE about 100.1.0.0/24 -- DENIED due to: reflected from the same cluster; *May 1 16:41:02.820: BGP(0): 155.1.5.5 rcv UPDATE about 100.1.1.0/24 -- DENIED due to: reflected from the same cluster; *May 1 16:41:02.820: BGP(0): 155.1.5.5 rcv UPDATE about 100.1.2.0/24 -- DENIED due to: reflected from the same cluster; *May 1 16:41:02.820: BGP(0): 155.1.5.5 rcv UPDATE about 100.1.3.0/24 -- DENIED due to: reflected from the same cluster; R3# R3# undebug all Note: Don t forget to turn off the debugging after you find the information you were searching for. Use the undebug all command. Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 5

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 6 R3# show run section bgp router bgp 65111 bgp router-id 155.1.3.3 bgp cluster-id 65111 R5# show run section bgp router bgp 65111 bgp router-id 155.1.5.5 bgp cluster-id 65111 Configure two different BGP cluster-ids for R3 and R5 to fix the issue, and ensure that R3 is installing the 4 BGP routes in its BGP table. You can also change the cluster-id in only one router: R3(config)# router bgp 65111 R3(config-router)# bgp cluster-id 155.1.3.3 R5(config)# router bgp 65111 R5(config-router)# bgp cluster-id 155.1.5.5 R3# show ip bgp *>i 8.8.4.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.0.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.1.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.2.0/24 155.1.7.7 0 100 0 10000 i *>i 100.1.3.0/24 155.1.7.7 0 100 0 10000 i Now R3 is installing the 4 BGP routes. After that, it must advertise them to both R1 and R2 because the requested traceroutes must pass through them, so check if R3 is BGP neighbor with both of R1 and R2: R3# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 155.1.2.2 4 65111 11 16 29 0 0 00:05:03 1 155.1.4.4 4 65111 6 13 34 0 0 00:01:22 0 155.1.5.5 4 65111 16 12 29 0 0 00:05:04 8 155.1.100.2 4 65000 52 57 29 0 0 00:43:28 1 R2-R3 BGP neighborship is established, however, the neighborship with R1 hasn t been configured, so add it: R3(config)# router bgp 65111 R3(config-router)# neighbor 155.1.1.1 peer-group RR-CLIENTS R3(config-router)# address-family ipv4 R3(config-router-af)# neighbor 155.1.1.1 activate Now, the R1-R3 BGP neighborship is established, in addition to the R2-R3 neighborship: Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 6

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 7 R3# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 155.1.1.1 4 65111 5 12 30 0 0 00:00:16 1 155.1.2.2 4 65111 16 21 30 0 0 00:09:07 1 155.1.4.4 4 65111 6 13 34 0 0 00:01:22 0 155.1.5.5 4 65111 22 17 30 0 0 00:09:09 8 155.1.100.2 4 65000 56 61 30 0 0 00:47:32 1 You also find that the 4 BGP routes are properly received and installed on R1, R2, and R18. However, when you issue the traceroutes requested in the question you don t match the required traffic engineering. For example, the traceroute for 100.1.2.1 passes through R2 and R7 instead of R2 and R8: R18# traceroute 100.1.2.1 Type escape sequence to abort. Tracing the route to 100.1.2.1 VRF info: (vrf in name/id, vrf out name/id) 1 200.1.100.5 10 msec 10 msec 10 msec 2 200.1.100.14 19 msec 18 msec 20 msec 3 155.1.0.14 21 msec 28 msec 22 msec 4 155.1.0.26 [MPLS: Label 17 Exp 0] 24 msec 25 msec 23 msec 5 155.1.0.34 29 msec 27 msec 31 msec 6 100.1.100.9 38 msec * 45 msec Therefore, pass to step 2 to enforce the proper BGP policies in the appropriate routers. Note: We said at the beginning of this step that we must also check that the destination has a route to R18 s S1/0 network. The success of the traceroute to 100.1.2.1 guarantees that this condition is met. 2. Check of BGP traffic engineering policies In this step, you check the BGP policies which usually are implemented at the border of a BGP AS, so check R7, R8, R1, and R2: R7# show run section route-map neighbor 100.1.100.9 route-map LOCAL-PREF in route-map LOCAL-PREF permit 10 match ip address 100 set local-preference 100 route-map LOCAL-PREF permit 20 R7# show run section access-list access-list 100 permit ip 100.1.0.0 0.0.1.255 any You find that the route map is applying a BGP local preference of 100, which is the default value in the BGP protocol, so increase it to force the traffic destined to 100.1.0.1 and 100.1.1.1 to pass through R7 instead of R8: Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 7

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 8 R7(config)# route-map LOCAL-PREF permit 10 R7(config-route-map)# match ip address 100 R7(config-route-map)# set local-preference 101 You find the same issue in R8, so use the same correction to force the traffic destined to 100.1.1.1 and 100.1.2.1 to pass through R8 instead of R7: R8# show run section route-map neighbor 100.1.100.13 route-map LOCAL-PREF in route-map LOCAL-PREF permit 10 match ip address 100 set local-preference 100 route-map LOCAL-PREF permit 20 R8# show run section access-list access-list 100 permit ip 100.1.2.0 0.0.1.255 any R8(config)# route-map LOCAL-PREF permit 10 R8(config-route-map)# match ip address 100 R8(config-route-map)# set local-preference 101 Now check the BGP policies in R1 and R2. You begin with R1 and you find a route map called MED that matches the routes 100.1.0.0/24-100.1.2.0/24 and advertises them with a metric (100) higher than the default (0) to R200. This higher metric causes R200 to prefer R2 for these 2 routes. However, this route map has a single clause, which causes the rest of route advertisements (and specifically 100.1.1.0/24-100.1.3.0/24) to be dropped due to the implicit deny at the end of the route-map. Fix the issue by adding another clause to the route-map: R1# show run section route-map route-map MED permit 10 match ip address 100 set metric 100 R1# show run section access-list access-list 100 permit ip 100.1.0.0 0.0.2.255 any R1(config)# route-map MED permit 20 The route map isn t also applied outbound towards R200, so apply it: R1(config)# router bgp 65111 R1(config-router)# address-family ipv4 R1(config-router-af)# neighbor 200.1.100.9 route-map MED out On R2, the route map is configured correctly outbound to R200, so everything seems to be fine now, and we can try the traceroutes on R18 to ensure that the ticket is resolved: Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 8

CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 9 R18# traceroute 100.1.0.1 Type escape sequence to abort. Tracing the route to 100.1.0.1 VRF info: (vrf in name/id, vrf out name/id) 1 200.1.100.5 11 msec 10 msec 11 msec 2 200.1.100.14 21 msec 21 msec 22 msec 3 155.1.0.18 [MPLS: Label 18 Exp 0] 29 msec 28 msec 22 msec 4 155.1.0.30 [MPLS: Label 17 Exp 0] 29 msec 30 msec 23 msec 5 155.1.0.46 25 msec 25 msec 26 msec 6 100.1.100.9 35 msec * 44 msec R18# traceroute 100.1.1.1 Type escape sequence to abort. Tracing the route to 100.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 200.1.100.5 11 msec 11 msec 11 msec 2 200.1.100.10 20 msec 20 msec 21 msec 3 155.1.0.2 [MPLS: Label 16 Exp 0] 25 msec 22 msec 24 msec 4 155.1.0.26 [MPLS: Label 17 Exp 0] 23 msec 18 msec 23 msec 5 155.1.0.34 25 msec 25 msec 24 msec 6 100.1.100.9 35 msec * 37 msec R18# traceroute 100.1.2.1 Type escape sequence to abort. Tracing the route to 100.1.2.1 VRF info: (vrf in name/id, vrf out name/id) 1 200.1.100.5 11 msec 8 msec 9 msec 2 200.1.100.14 18 msec 21 msec 19 msec 3 155.1.0.14 20 msec 16 msec 21 msec 4 155.1.0.26 [MPLS: Label 20 Exp 0] 22 msec 22 msec 22 msec 5 155.1.0.38 25 msec 25 msec 23 msec 6 100.1.100.13 33 msec * 33 msec R18# traceroute 100.1.3.1 Type escape sequence to abort. Tracing the route to 100.1.3.1 VRF info: (vrf in name/id, vrf out name/id) 1 200.1.100.5 13 msec 12 msec 13 msec 2 200.1.100.10 20 msec 23 msec 29 msec 3 155.1.0.2 [MPLS: Label 20 Exp 0] 26 msec 24 msec 23 msec 4 155.1.0.26 [MPLS: Label 20 Exp 0] 42 msec 43 msec 31 msec 5 155.1.0.38 23 msec 34 msec 24 msec 6 100.1.100.13 35 msec * 36 msec Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 9