Service Provider Routing and Switching
This domain covers how Junos devices build and exchange routes in a service provider core and how those routes become customer services. The exam tests reasoning about IS-IS/OSPF, BGP policy and scaling, MPLS label distribution, and the L2/L3 VPN constructs that ride on them.
Core rules and concepts
- Run one IGP (IS-IS Level 2 or OSPF area 0) across the core and put loopbacks in it; VPNv4 next-hop resolution depends on the next hop being reachable in inet.3, not just inet.0.
- Scale iBGP with route reflectors (cluster IDs) or confederations; a reflector reflects only its best path and adds originator ID and cluster list to prevent loops.
- LDP distributes labels for IGP prefixes; RSVP-TE adds constrained paths. Enable LDP on the loopback and core interfaces (set protocols ldp interface ...), or a labeled path to the egress PE never forms.
- An L3VPN routing instance binds a VRF table to an RD and route targets (vrf-target); MP-BGP carries VPNv4 routes with the RD prepended and the RT as a community.
- For L2 services, VPLS uses a full mesh of pseudowires signaled by BGP or LDP, while EVPN uses MP-BGP route type 2 for MAC/IP and type 3 for inclusive multicast, avoiding VPLS flooding limits.
Worked example
PE1 and PE2 run iBGP with family inet-vpn unicast. PE1's VRF has vrf-target target:65000:1 and PE2's has target:65000:2. PE1 exports the CE route as 65000:1:10.1.1.0/24 with RT 65000:1. PE2's VRF imports only 65000:2, so no RT match and the route stays hidden in bgp.l3vpn.0. Fix: set matching vrf-target import/export on both PEs; PE2 then resolves the next hop in inet.3 via LDP and installs the route in the VRF.
Traps that cost marks
Both iBGP and eBGP have preference 170 in Junos, so a stale eBGP path can hide a better iBGP path until you check local preference and MED. Forgetting family inet-vpn unicast on the PE-PE session silently blocks VPNv4 exchange. Missing LDP on the loopback breaks the labeled next hop even when the IGP route exists.