I do see one benefit to using the stitched LT VPWS solution - MAC learning. On the VPWS solution, your PE devices are not learning the MAC addresses.
I also noticed that Juniper is a bit strange with VPLS attached to the IRB in that you never see the IRB MAC in the VPLS instance. But I think this has more to do with the behavior of IRB in general on Juniper as I don't see any of the IRB MAC addresses present in the table, even for IRBs not used on the VPLS circuit. It's entirely possible I'm using the wrong commands. :) -ben On Mon, Mar 19, 2018 at 4:27 PM, Ben Bartsch <uwcable...@gmail.com> wrote: > The other solution is a stitched LT configuration. One LT is the L3 > endpoint, the other is the PW endpoint. You use VPWS with this one. I > suppose you might be able to do VPLS instead if you wanted to. I am > running eBGP on this circuit too. It's a bit more complicated for > troubleshooting. I'm not sure what benefit this has over the IRB method. > > Again, Junos 15.1R6.7: > > show configuration interfaces lt-0/0/10 | display set > set interfaces lt-0/0/10 mtu 9192 > set interfaces lt-0/0/10 unit 998 description LT-0/0/0.998->VLAN_998->PW > set interfaces lt-0/0/10 unit 998 encapsulation vlan-ccc > set interfaces lt-0/0/10 unit 998 vlan-id 998 > set interfaces lt-0/0/10 unit 998 peer-unit 10998 > set interfaces lt-0/0/10 unit 998 family ccc > set interfaces lt-0/0/10 unit 10998 description > LT-0/0/0.10998->VLAN_998->L3 > set interfaces lt-0/0/10 unit 10998 encapsulation vlan > set interfaces lt-0/0/10 unit 10998 vlan-id 998 > set interfaces lt-0/0/10 unit 10998 peer-unit 998 > set interfaces lt-0/0/10 unit 10998 family inet address 10.240.16.97/30 > > show configuration protocols l2circuit | display set > set protocols l2circuit neighbor 10.240.0.73 interface lt-0/0/10.998 > virtual-circuit-id 998 > set protocols l2circuit neighbor 10.240.0.73 interface lt-0/0/10.998 mtu > 9100 > > show l2circuit connections > Layer-2 Circuit Connections: > > Legend for connection status (St) > EI -- encapsulation invalid NP -- interface h/w not present > MM -- mtu mismatch Dn -- down > EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down > CM -- control-word mismatch Up -- operational > VM -- vlan id mismatch CF -- Call admission control failure > OL -- no outgoing label IB -- TDM incompatible bitrate > NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration > BK -- Backup Connection ST -- Standby Connection > CB -- rcvd cell-bundle size bad SP -- Static Pseudowire > LD -- local site signaled down RS -- remote site standby > RD -- remote site signaled down HS -- Hot-standby Connection > XX -- unknown > > Legend for interface status > Up -- operational > Dn -- down > Neighbor: 10.240.0.73 > Interface Type St Time last up # Up trans > lt-0/0/10.998(vc 998) rmt Up Mar 18 19:14:28 2018 1 > Remote PE: 10.240.0.73, Negotiated control-word: No > Incoming label: 347440, Outgoing label: 52785 > Negotiated PW status TLV: No > Local interface: lt-0/0/10.998, Status: Up, Encapsulation: VLAN > Flow Label Transmit: No, Flow Label Receive: No > > > > > The PE is again a Dell S4048-ON running IPI OcNOS v1.3.3 > > sh run mpls > ! > mpls l2-circuit VLAN_BASED_PW_0998 998 10.240.0.11 > ! > router ldp > router-id 10.240.0.73 > targeted-peer ipv4 10.240.0.11 > exit-targeted-peer-mode > transport-address ipv4 10.240.0.73 > > sh run int xe4 > ! > interface xe4 > description XE4->POD1-3550-S1_GI0/2 > speed 1g > switchport > load-interval 30 > mtu 9100 > mpls-l2-circuit VLAN_BASED_PW_0998 vlan 998 tpid 8100 > > sh ldp mpls-l2-circuit detail > vcid: 998 type: vlan, local groupid: 0, remote groupid: 0 (vc is up) > destination: 10.240.0.11, Peer LDP Ident: 10.240.0.11 > Local label: 52785, remote label: 347440 > Access IF: xe4, Network IF: xe2 > Local MTU: 9100, Remote MTU: 9100 <--THIS IS SUPER HANDY - IT WILL > SHOW YOUR REMOTE MTU EVEN IF THE CIRCUIT IS DOWN > Local Control Word: disabled, Remote Control Word: disabled, Current use: > disabled > Local PW Status Capability : disabled > Remote PW Status Capability : disabled > Current PW Status TLV : disabled > Local VCCV Capability: > CC-Types: None > CV-Types: None > Remote VCCV Capability: > CC-Types: Type 1 Type 2 Type 3 > CV-Types: > LSP ping > BFD IP/UDP-encapsulated, for PW Fault Detection only BFD > PW-ACH-encapsulated, for PW Fault Detection only > > sh ldp mpls-l2-circuit > Transport Client VC VC Local Remote > Destination > VC ID Binding State Type VC Label VC Label > Address > 998 xe4 UP Ethernet VLAN 52785 347440 > 10.240.0.11 > > > > > > Finally the CE is the same old Cisco 3550 with a VLAN: > > POD1-FREY113-3550-S1#sh run int vlan 998 > Building configuration... > > Current configuration : 114 bytes > ! > interface Vlan998 > description VLAN_998_VLAN-BASED-VPWS-ROUTED-PW > ip address 10.240.16.98 255.255.255.252 > end > > POD1-FREY113-3550-S1#sh run int gi0/2 > Building configuration... > > Current configuration : 219 bytes > ! > interface GigabitEthernet0/2 > description GI0/2->POD3-4048-S1_XE4 > switchport trunk encapsulation dot1q > switchport trunk allowed vlan 998 > switchport mode trunk > load-interval 30 > speed nonegotiate > end > > > > > > I also forgot to show y'all what the VPLS circuit show commands look like > on the OcNOS node for the VPLS solution: > > sh mpls vpls detail > Virtual Private LAN Service Instance: VPLS-LAB-0997, ID: 997 > SIG-Protocol: LDP > Attachment-Circuit :UP > Learning: Enabled > Group ID: 0, VPLS Type: Ethernet VLAN, Configured MTU: 9100 > Description: none > service-tpid: dot1.q > Operating mode: Tagged > Svlan Id: 0 > Svlan Tpid: 8100 > Redundancy admin role: Primary > Redundancy oper role: Primary > Configured interfaces: > Interface: xe4 > Vlan Id: 997 > oper-state UP > Mesh Peers: > 10.240.0.11 (Up), PW Status Local:0 Remote:0 > > sh mpls vpls mesh > VPLS-ID Peer Addr Tunnel-Label In-Label Network-Intf > Out-Label Lkps/St PW-INDEX SIG-Protocol Status > 997 10.240.0.11 52496 52786 xe2 > 262148 2/Up 7 LDP Active > > > On Mon, Mar 19, 2018 at 4:15 PM, Ben Bartsch <uwcable...@gmail.com> wrote: > >> Absolutely! I'm running a eBGP session over this ATM. We are going to >> try to backhaul our customers through a Dell whitebox running IPI OcNOS >> configured with an 'LDP fabric' to a core MX. >> >> >> To use an IRB as a L3 endpoint you have to use VPLS on the MX (Junos >> version 15.1R6.7). I was missing a couple of key commands highlighted in >> red: >> >> show configuration interfaces irb.997 | display set >> set interfaces irb unit 997 description VLAN-997->PWHE->POD1-3550-S1_V >> LAN_997 >> set interfaces irb unit 997 bandwidth 10g >> set interfaces irb unit 997 family inet mtu 9178 >> set interfaces irb unit 997 family inet address 10.240.16.101/30 >> >> show configuration routing-instances VPLS-LAB-0997 | display set >> set routing-instances VPLS-LAB-0997 instance-type vpls >> set routing-instances VPLS-LAB-0997 vlan-id 997 >> set routing-instances VPLS-LAB-0997 routing-interface irb.997 >> set routing-instances VPLS-LAB-0997 protocols vpls encapsulation-type >> ethernet-vlan >> set routing-instances VPLS-LAB-0997 protocols vpls no-tunnel-services >> set routing-instances VPLS-LAB-0997 protocols vpls vpls-id 997 >> set routing-instances VPLS-LAB-0997 protocols vpls mtu 9100 >> set routing-instances VPLS-LAB-0997 protocols vpls neighbor 10.240.0.73 >> set routing-instances VPLS-LAB-0997 protocols vpls connectivity-type irb >> >> show vpls connections extensive >> Layer-2 VPN connections: >> >> Legend for connection status (St) >> EI -- encapsulation invalid NC -- interface encapsulation not >> CCC/TCC/VPLS >> EM -- encapsulation mismatch WE -- interface and instance encaps not >> same >> VC-Dn -- Virtual circuit down NP -- interface hardware not present >> CM -- control-word mismatch -> -- only outbound connection is up >> CN -- circuit not provisioned <- -- only inbound connection is up >> OR -- out of range Up -- operational >> OL -- no outgoing label Dn -- down >> LD -- local site signaled down CF -- call admission control failure >> RD -- remote site signaled down SC -- local and remote site ID collision >> LN -- local site not designated LM -- local site ID not minimum >> designated >> RN -- remote site not designated RM -- remote site ID not minimum >> designated >> XX -- unknown connection status IL -- no incoming label >> MM -- MTU mismatch MI -- Mesh-Group ID not available >> BK -- Backup connection ST -- Standby connection >> PF -- Profile parse failure PB -- Profile busy >> RS -- remote site standby SN -- Static Neighbor >> LB -- Local site not best-site RB -- Remote site not best-site >> VM -- VLAN ID mismatch HS -- Hot-standby Connection >> >> Legend for interface status >> Up -- operational >> Dn -- down >> >> Instance: VPLS-LAB-0997 >> VPLS-id: 997 >> Number of local interfaces: 0 >> Number of local interfaces up: 0 >> lsi.1048592 Intf - vpls VPLS-LAB-0997 neighbor >> 10.240.0.73 vpls-id 997 >> Neighbor Type St Time last up # Up >> trans >> 10.240.0.73(vpls-id 997) rmt Up Mar 19 10:25:38 2018 >> 1 >> Remote PE: 10.240.0.73, Negotiated control-word: No >> Incoming label: 262148, Outgoing label: 52786 >> Negotiated PW status TLV: No >> Local interface: lsi.1048592, Status: Up, Encapsulation: VLAN >> Description: Intf - vpls VPLS-LAB-0997 neighbor 10.240.0.73 >> vpls-id 997 >> Flow Label Transmit: No, Flow Label Receive: No >> Connection History: >> Mar 19 10:25:38 2018 status update timer >> Mar 19 10:25:38 2018 PE route changed >> Mar 19 10:25:38 2018 Out lbl Update 52786 >> Mar 19 10:25:38 2018 In lbl Update 262148 >> Mar 19 10:25:38 2018 loc intf up lsi.1048592 >> >> >> >> >> The other end of my VPLS circuit is a Dell S4048-ON running IP Infusion >> OcNOS (it is very Cisco IOS-ish) v1.3.3: >> >> sh run mpls >> mpls vpls VPLS-LAB-0997 997 >> redundancy-role primary >> signaling ldp >> vpls-type vlan >> vpls-peer 10.240.0.11 >> exit-signaling >> ! >> router ldp >> router-id 10.240.0.73 >> targeted-peer ipv4 10.240.0.11 >> exit-targeted-peer-mode >> transport-address ipv4 10.240.0.73 >> >> sh run int xe4 >> ! >> interface xe4 >> description XE4->POD1-3550-S1_GI0/2 >> speed 1g >> switchport >> load-interval 30 >> mtu 9100 >> mpls-vpls VPLS-LAB-0997 vlan 997 >> ac-admin-status up >> exit-if-vpls >> >> >> >> >> And the CE is just a simple L3 VLAN. We are using an old Cisco 3550 >> running 12.2(46)SE IPSERVICESK9 that we found laying around: >> >> POD1-3550-S1#sh run int gi0/2 >> Building configuration... >> >> Current configuration : 219 bytes >> ! >> interface GigabitEthernet0/2 >> description GI0/2->POD3-4048-S1_XE4 >> switchport trunk encapsulation dot1q >> switchport trunk allowed vlan 997 >> switchport mode trunk >> load-interval 30 >> speed nonegotiate >> end >> >> POD1-3550-S1#sh run int vlan 997 >> Building configuration... >> >> Current configuration : 115 bytes >> ! >> interface Vlan997 >> description VLAN_997_VLAN-BASED-VPWS-ROUTED-PW >> ip address 10.240.16.102 255.255.255.252 >> end >> >> >> >> Hope this helps. My head hurts from banging it my desk for the last >> couple of weeks. :) >> >> -ben >> >> On Mon, Mar 19, 2018 at 3:25 PM, Chuck Anderson <c...@wpi.edu> wrote: >> >>> Would you mind sharing the solution(s)? I've stiched a L2 PW using >>> lt-interfaces. >>> >>> Thanks. >>> >>> On Mon, Mar 19, 2018 at 11:51:36AM -0500, Ben Bartsch wrote: >>> > I want to thank everyone who contacted me on and off list on this >>> request. >>> > I now have two methods to land a layer 3 endpoint on a layer 2 circuit >>> to a >>> > remote PE. I very much appreciate the input, feedback, and >>> assistance. I >>> > hope I personally get to meet all of you that reached out to me at a >>> future >>> > NANOG meeting. Thanks again! >>> > >>> > -ben >>> > >>> > On Sat, Mar 17, 2018 at 9:25 AM, Ben Bartsch <uwcable...@gmail.com> >>> wrote: >>> > >>> > > When we had Cisco ASR 920/903 and ASR9k, I could attach a layer 2 >>> > > pseudowire endpoint on that device to a layer 3 BDI/BVI. I'm trying >>> to do >>> > > the same thing on a Juniper MX 480/960 and it does not appear to be >>> > > supported (for LDP at least - MP-BGP might be supported). We could >>> do >>> > > either VPWS or VPLS on the PE device handoff to the CE (layer 2 >>> only). >>> > > JTAC has somewhat confirmed this is not supported for LDP, but they >>> only do >>> > > break/fix, not new config. We do not have professional services (we >>> are >>> > > broke). >>> > > >>> > > Any Juniper routerheads out there that have seen this done using LDP >>> > > without having to hairpin on the MX? >>> > > >>> > > Thanks, y'all. >>> > > >>> > > -ben >>> >> >> >
