Buckle up, it’s BGP time. This ticket, or tickets features multiple fault points. I went a little overboard to be completely honest. So here we go! When all tickets are resolved, both R6 and R7 should have full readability to R1. You are not allowed to modify the configuration on R1.
*Note, recommended that you fix tickets in order.
Ticket #1
AS 5432 has a new customer, the data activation team has completed work but BGP isn’t peering between R4 (AS 5432) and R6 (AS 6).
– Do not remove any security features.
– You have permission to access the CE device, R6, however you are only allowed to modify routing configurations that are directly related to R4/R6 peering. No global changes may be made.
Ticket #2
R3 is not able to peer to R1, a network admin has observed an odd BGP peer state on R3. R1 an edge router from an upstream ISP and is not accessible in this lab. Ensure that R3 is able to peer with R1.
– NO static routes may be added to R1
– Peering must be between Loopback interfaces
– eBGP multihop may not be altered.
Ticket #3
R7 can not ping R1. You remember reading an email from the upstream ISP about security changes with regard to AS Path. However, that’s all you can recall.
– Resolve this ticket without using any summarization or NAT.
Diagrams:
Solution(s):
