Junos Cup 2014
Junos Cup 2014

Tournament 4: Croatia Challenge & Solution: The Reverse Engineering Saga, Episode 4 – The Puzzling MPLS

[ Edited ]
‎07-03-2014 07:03 AM

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.





Challenge Instructions:

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.


TIP: There may be a hidden gem in ISIS.log.



NOTE: If you have issues connecting to the Junosphere topology please check Junosphere Technical documentation, or request assistance in the Junosphere forum 




R1 is advertising

R2 is advertising

R3 is advertising


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 route because it fails BGP next hop resolution so there is no route towards R2 loopback in the inet.3 table of R3.

Julie Wider
Advocacy Manager
Twitter: @JNetCommunity & @jawider