Tournament 4: Croatia Challenge & Solution: The Reverse Engineering Saga, Episode 4 – The Puzzling MPLS
[ Edited ]
Country Flag: Croatia
Author: Diogo Montagner
Title: The Reverse Engineering Saga, Episode 4 – The Puzzling MPLS
Type: Service Provider
Difficulty: Medium (1 point).
Technical Description: Discover the MPLS issue that is preventing certain (AFI=1, SAFI=128) prefixes from being installed in the FIB of certain routers.
For this challenge, you need to start the topology called: “CROATIA – The Reverse Engineering Saga, Episode 4 – The Puzzling MPLS”.
As was the case with previous Episodes of this saga (England, Chile, etc.), your Junos user has very few privileges. This time you can can clear protocol sessions, launch ping, or inspect log and traceoptions files.
The relevant traceoptions files result from the following configuration:
- At hierarchy level [edit snmp]: SNMP.log
- At hierarchy level [edit routing-options] or below: RT.log and RSLV.log
- At hierarchy level [edit protocols] or below: OSPF.log, ISIS.log, BGP.log, MPLS.log, RSVP.log, and LDP.log
This challenge is built on top of the topology of Episode 3 (Chile - The Strange BGP), except that this time the two BGP issues are already fixed.
This challenge is related to the BGP/MPLS VPN service, also known as L3VPN. Certain routers in the network are exchanging inet-vpn unicast (AFI=1, SAFI=128) prefixes via BGP. More specifically, some routers are exporting via BGP a static route (200.200.<x>.0/24, where <x> is the router number), in the context of the same VPN.
In some cases, these routes are correctly processed and installed in the forwarding table (FIB) of the receiving routers. But other times, it is not the case.
There might be more than one MPLS issue in this topology. But you must not list them all. Instead, you only need to find the MPLS issue that prevents certain router(s) from installing in the FIB certain VPN route(s) 200.200.<x>.
To solve this challenge briefly explain the specific MPLS issue causing the problems.
The following RSVP LSPs are correctly established:
R1-R2, from R1 to R2
R1-R3, from R1 to R3
R2-R1, from R2 to R1
R2-R3, from R2 to R3
However, R3 does not have any ingress RSVP LSPs defined.
R3 relies on LDP for next hop resolution. However, the two interfaces ge-0/0/1.0 and ge-0/0/2.0 at R2 do not have family mpls configured. This does not prevent the RSVP LSPs from coming up because the ge-0/0/3.0 interface at R2 has family mpls.
However, it prevents LDP from coming up between R3 and R2. As a result, R3 cannot install the 188.8.131.52/24 route because it fails BGP next hop resolution so there is no route towards R2 loopback in the inet.3 table of R3.