Routing

Expand all | Collapse all

VPLS confusion

Jump to Best Answer
  • 1.  VPLS confusion

    Posted 04-30-2009 14:07

    Hi everyone,

     

    i'm somewhat confused by my own VPLS configuration -- specifically as it relates to BGP v LDP for signaling and discovery.

     

    Here is my sample config (using J-Series routers in this scenario) --

     

    set interfaces ge-0/0/1 description "BACKBONE Interface"
    set interfaces ge-0/0/1 vlan-tagging
    set interfaces ge-0/0/1 unit 129 vlan-id 129
    set interfaces ge-0/0/1 unit 129 family inet address 10.129.0.102/24
    set interfaces ge-0/0/1 unit 129 family mpls
    set interfaces ge-0/0/1 unit 130 vlan-id 130
    set interfaces ge-0/0/1 unit 130 family inet address 10.130.0.102/24
    set interfaces ge-0/0/1 unit 130 family mpls
    set interfaces ge-0/0/2 description "VPLS1 and VPLS2 Interface"
    set interfaces ge-0/0/2 vlan-tagging
    set interfaces ge-0/0/2 encapsulation extended-vlan-vpls
    set interfaces ge-0/0/2 unit 2000 description "VPLS1 Interface"
    set interfaces ge-0/0/2 unit 2000 vlan-id 2000
    set interfaces ge-0/0/2 unit 2000 family vpls
    set interfaces ge-0/0/2 unit 2001 description "VPLS2 Interface"
    set interfaces ge-0/0/2 unit 2001 vlan-id 2001
    set interfaces ge-0/0/2 unit 2001 family vpls
    set interfaces lo0 unit 0 family inet address 10.229.0.102/32
    set interfaces lo0 unit 0 family inet address 127.0.0.1/32
    set routing-options static route 0.0.0.0/0 next-hop 10.129.0.1

     

    set protocols mpls interface ge-0/0/1.129
    set protocols mpls interface ge-0/0/1.130
     set protocols bgp group vpls-rtrs type internal
    set protocols bgp group vpls-rtrs local-address 10.229.0.102
    set protocols bgp group vpls-rtrs family l2vpn signaling
    set protocols bgp group vpls-rtrs cluster 10.229.0.0
    set protocols bgp group vpls-rtrs peer-as 65000
    set protocols bgp group vpls-rtrs neighbor 10.229.0.103
    set protocols bgp group vpls-rtrs neighbor 10.229.0.110
    set protocols bgp group vpls-rtrs neighbor 10.229.0.113
    set protocols bgp group vpls-rtrs neighbor 10.229.0.111
    set protocols ospf area 0.0.0.0 interface lo0.0 passive
    set protocols ospf area 0.0.0.0 interface ge-0/0/1.129
    set protocols ospf area 0.0.0.0 interface ge-0/0/1.130


    set protocols ldp interface ge-0/0/1.129
    set protocols ldp interface ge-0/0/1.130

     

    set routing-instances vpls-VPLS1 description "VPLS1 VPLS Instance"
    set routing-instances vpls-VPLS1 instance-type vpls
    set routing-instances vpls-VPLS1 interface ge-0/0/2.2000
    set routing-instances vpls-VPLS1 route-distinguisher 10.229.0.102:200
    set routing-instances vpls-VPLS1 vrf-target target:65000:200
    set routing-instances vpls-VPLS1 protocols vpls site-range 30
    set routing-instances vpls-VPLS1 protocols vpls mac-table-aging-time 120
    set routing-instances vpls-VPLS1 protocols vpls no-tunnel-services
    set routing-instances vpls-VPLS1 protocols vpls site coreA site-identifier 1
    set routing-instances vpls-VPLS2 description "VPLS2 VPLS Instance"
    set routing-instances vpls-VPLS2 instance-type vpls
    set routing-instances vpls-VPLS2 interface ge-0/0/2.2001
    set routing-instances vpls-VPLS2 route-distinguisher 10.229.0.102:100
    set routing-instances vpls-VPLS2 vrf-target target:65000:100
    set routing-instances vpls-VPLS2 protocols vpls site-range 30
    set routing-instances vpls-VPLS2 protocols vpls mac-table-aging-time 120
    set routing-instances vpls-VPLS2 protocols vpls no-tunnel-services
    set routing-instances vpls-VPLS2 protocols vpls site coreA site-identifier 1

     

     

     

    I was under the impression that either BGP or LDP was used for signaling and discovery in a VPLS environment.  However, if I only have BGP configured (the LDP configuration is removed), a show vpls connections reports a status of "VC-Dn" on all of my PEs, and I cannot ping from CE to CE

     

    However when I configure LDP on my Backbone interface(s), the status transitions to Up, and I can then ping from CE to CE.

     

    Could someone with more knowledge about the subject explain why that is, if LDP and BGP are supposed to accomplish the same thing?  or is my BGP configuration missing something that LDP is providing?

     

    Thanks,

     

    Will

    Message Edited by wimclend on 04-30-2009 02:08 PM

    #ldp
    #vpls


  • 2.  RE: VPLS confusion

    Posted 04-30-2009 15:52

    Hi wimclend,

     

     If you don't have RSVP, then LDP's the only protocol for label exchange in your core and the behavior you're seeing is expected because your backbone routers can't "talk mpls" to eachother in this case.

     

     

     Cheers,

     Erdem



  • 3.  RE: VPLS confusion
    Best Answer

    Posted 04-30-2009 18:07

    wimclend,

     

    That's a common point of confusion.

     

    In a VPLS environment there are effectively two planes of operation for LDP.

     

    First, in order to run VPLS, you must have a labeled path to the remote VPLS PE.  This is done by looking up the remote PE loopback address to match a FEC (the /32 loopback address of that remote PE router). In JUNOS, either LDP or RSVP will advertise this reachability into the inet.3 routing table.   This is where traffic is associated with MPLS labels for forwarding purposes.  However, this has no bearing on whether you are using targeted-LDP based VPLS or draft-kompella BGP-based VPLS. 

     

    Next, once the remote reachability is advertised, then VPLS must be able to communicate between remote PEs.  This done using either targeted LDP or via BGP l2vpn signaling.

     

    So,  

     - For the outer (tunnel) label resolution you can use either LDP or RSVP.  This populates /32 routes for your endpoint PE routers into inet.3

     

    - To resolve the inner (VPN) label, you can use either BGP (l2vpn-signaling) or Targeted-LDP.  

     

    In your configuration, you are using BGP-based VPLS, but using LDP for the BGP next-hop to label resolution.   

    It's worth noting that this is a very common deployment model for draft-kompella VPLS, as it doesn't require a full-mesh of RSVP LSPs.

     

    The [ edit protocols ldp ] stanza, where you added ge-0/0/1.129 and ge-0/0/1.130, JUNOS simply turned on standard LDP FEC advertisement, which should have populated a /32 loopback route for each LDP speaker in the topology.  This isn't at all used by VPLS, except to resolve the next-hop.  But without it, VPLS won't come up (as the remote sites will be unreachable).

     

    In your VPLS routing-instance where you configured the vrf-target, route-distinguisher and site-ID, you were specifying criteria for BGP VPLS.  This instructed JUNOS to auto-discover remote VPLS PEs matching your vrf-target and automatically setup virtual ports (connections) to all discovered PEs (assuming, of course, that BGP is setup with the appropriate l2vpn address family across your network).

     

    If you wish to use targeted-LDP for VPLS signaling, you would first add the lo0 interface to LDP (to enable targeted-mode), and then would specify a vpls-id and a remote neighbor.  The remote neighbor IP would be used to start a targeted LDP session to exchange the inner label.  Note that the process of adding remote VPLS neighbors is not automatic in LDP-based VPLS, so you have to manually keep all neighbors configured.

     

    For this reason, Juniper recommends using BGP-based VPLS for its autodiscovery capabilities in many environments.  In addition, there are some additional advantages in terms of spanning tree mitigation that are only available in kompella-based VPLS.



  • 4.  RE: VPLS confusion

    Posted 01-17-2018 15:18

    very good explanation...



  • 5.  RE: VPLS confusion

    Posted 04-30-2009 19:41

    thank you both for your replies -- definately helped clear it up!

     

    we are going to use the BGP-based VPLS because we will have like 13-16 sites when all is said and done -- i dont want that nightmare of meshing that with LDP based VPLS 🙂

     

    Thanks again,

     

    Will