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

Transcription

1

2 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 must pass through R2 and R7. Traceroute from R18 to must pass through R1 and R7. Traceroute from R18 to must pass through R2 and R8. Traceroute from R18 to 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. R BGP RR BGP RR E0/0 E0/0 E0/1 E0/1 E0/0 E0/0 S1/0 S1/0 R R R3 2 1 R / E0/ E0/3 E0/3 21 E0/2 E0/2 E0/2 E0/2 9 E0/ /30 Global SP BGP AS /30 OSPF E0/2 E0/2 E0/2 E0/2 S1/ X/ E0/1 E0/ E0/3 E0/ S1/1 E0/0 E0/0 E0/1 E0/1 E0/0 E0/0 14 R R R R2 9 R / /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

3 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 /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 * / i *> i * / i *> i * / i *> i * / i *> i * / i *> i R8# show ip bgp *> / i *> / i *> / i *> / i *> / 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 :11: never Active :11:15 8 R8# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd :13: :12:40 1 R7 and R8 are both BGP neighbor with R5, which is a BGP route reflector (RR) inside AS (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

4 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 bgp router-id bgp cluster-id bgp log-neighbor-changes no bgp default ipv4-unicast neighbor RR-CLIENTS peer-group neighbor RR-CLIENTS remote-as neighbor RR-CLIENTS update-source Loopback0 neighbor peer-group RR-CLIENTS neighbor peer-group RR-CLIENTS neighbor peer-group RR-CLIENTS neighbor shutdown neighbor peer-group RR-CLIENTS! address-family ipv4 neighbor RR-CLIENTS route-reflector-client neighbor activate neighbor activate R5(config)# router bgp R5(config-router)# no neighbor shutdown R5# show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd :16: :03: never Idle :17:04 8 Despite fixing the neighbor 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 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 R5# Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 3

5 CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 4 R7# show ip route section O /32 [110/11] via , 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/ /30 10 DR 1/1 Et0/ /30 10 BDR 1/1 Et0/ /30 10 DR 1/1 Lo /32 1 P2P 0/0 R7# show run interface Loopback0 interface Loopback0 ip address 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 :23: :03: :00: :23:12 6 R5# show ip bgp *>i / i * i i *>i / i * i i *>i / i * i i *>i / i * i i *>i / i * i 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

6 CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 5 R3# show ip bgp r> / i *>i / 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 advertised-routes *>i / i *>i / i *>i / i *>i / i *>i / i *>i / i *>i / i *>i / i *>i / 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 updates BGP updates debugging is on for neighbor 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): rcv UPDATE about /24 -- DENIED due to: reflected from the same cluster; *May 1 16:41:02.820: BGP(0): rcv UPDATE about /24 -- DENIED due to: reflected from the same cluster; *May 1 16:41:02.820: BGP(0): rcv UPDATE about /24 -- DENIED due to: reflected from the same cluster; *May 1 16:41:02.820: BGP(0): rcv UPDATE about /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

7 CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 6 R3# show run section bgp router bgp bgp router-id bgp cluster-id R5# show run section bgp router bgp bgp router-id bgp cluster-id 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 R3(config-router)# bgp cluster-id R5(config)# router bgp R5(config-router)# bgp cluster-id R3# show ip bgp *>i / i *>i / i *>i / i *>i / i *>i / 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 :05: :01: :05: :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 R3(config-router)# neighbor peer-group RR-CLIENTS R3(config-router)# address-family ipv4 R3(config-router-af)# neighbor 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

8 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 :00: :09: :01: :09: :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 passes through R2 and R7 instead of R2 and R8: R18# traceroute Type escape sequence to abort. Tracing the route to VRF info: (vrf in name/id, vrf out name/id) msec 10 msec 10 msec msec 18 msec 20 msec msec 28 msec 22 msec [MPLS: Label 17 Exp 0] 24 msec 25 msec 23 msec msec 27 msec 31 msec 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 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 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 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 and to pass through R7 instead of R8: Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 7

9 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 and to pass through R8 instead of R7: R8# show run section route-map neighbor 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 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 / /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 / /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 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 R1(config-router)# address-family ipv4 R1(config-router-af)# neighbor 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

10 CCIE R&Sv5 Mock Lab 1 Mohamed Jaziri 3xCCIE P a g e 9 R18# traceroute Type escape sequence to abort. Tracing the route to VRF info: (vrf in name/id, vrf out name/id) msec 10 msec 11 msec msec 21 msec 22 msec [MPLS: Label 18 Exp 0] 29 msec 28 msec 22 msec [MPLS: Label 17 Exp 0] 29 msec 30 msec 23 msec msec 25 msec 26 msec msec * 44 msec R18# traceroute Type escape sequence to abort. Tracing the route to VRF info: (vrf in name/id, vrf out name/id) msec 11 msec 11 msec msec 20 msec 21 msec [MPLS: Label 16 Exp 0] 25 msec 22 msec 24 msec [MPLS: Label 17 Exp 0] 23 msec 18 msec 23 msec msec 25 msec 24 msec msec * 37 msec R18# traceroute Type escape sequence to abort. Tracing the route to VRF info: (vrf in name/id, vrf out name/id) msec 8 msec 9 msec msec 21 msec 19 msec msec 16 msec 21 msec [MPLS: Label 20 Exp 0] 22 msec 22 msec 22 msec msec 25 msec 23 msec msec * 33 msec R18# traceroute Type escape sequence to abort. Tracing the route to VRF info: (vrf in name/id, vrf out name/id) msec 12 msec 13 msec msec 23 msec 29 msec [MPLS: Label 20 Exp 0] 26 msec 24 msec 23 msec [MPLS: Label 20 Exp 0] 42 msec 43 msec 31 msec msec 34 msec 24 msec msec * 36 msec Copyright 2017 Mohamed Jaziri CCIE R&Sv5 Mock Lab 1 P a g e 9