Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TechLibrary
Navigation

Example: NG-VPLS Using Point-to-Multipoint LSPs

This example shows how to configure next-generation VPLS (NG_VPLS) using point-to-multipoint LSPs. The topology is shown in Figure 1 and Figure 2. This example is organized in the following sections:

Requirements

Table 1 lists the hardware that is used and the software that is required for this example:

Table 1: Hardware and Software Used

EquipmentComponentsSoftware

Six MX Series 3D Universal Edge Routers

DPC-4 10GE-X, DPC-40 1GE-X

Junos OS Release 9.3R4 or later

One T Series Core Router

FPC3, 10GE-Xenpak

Junos OS Release 9.3R4 or later

Eight EX4200 Ethernet Switches

EX4200 virtual switches

Junos OS Release 9.3R4 or later

One M7i Multiservice Edge Router

Gigabit Ethernet interfaces

Junos OS Release 9.3R4 or later

Overview and Topology

The logical topology of the NG-VPLS example is shown in Figure 1.

Figure 1: Logical Topology of NG-VPLS Using Point-to-Multipoint LSPs

Logical Topology of NG-VPLS Using Point-to-Multipoint LSPs

The routers in this example are preconfigured with the following:

  • OSPF area 0 is configured on all the PE routers and P routers with traffic engineering enabled.
  • All of the core-facing interfaces are configured with the mpls protocol address family.
  • The RSVP and MPLS protocols are enabled for all the core-facing interfaces.
  • All the MX Series routers have their network services mode set to Ethernet. The network services mode is configured by including the network-services statement and specifying the ethernet option.
  • All the PE routers are configured for autonomous system 65000.

The physical topology of the NG-VPLS example is shown in Figure 2. The topology consists of six MX Series routers connected with redundant links in the core. Four MX Series routers are acting as PE routers and two are core routers.

Figure 2: Physical Topology of NG-VPLS Using Point-to-Multipoint LSPs

Physical Topology of NG-VPLS Using Point-to-Multipoint LSPs

Note the following topology details:

  • A route reflector is configured in the topology to reflect the family l2-vpn routes to all the PE routers for BPG-VPLS.
  • The GOLD VPLS routing instance is configured with two sites in each of the PE routers.
  • One GOLD site is connected to the CE router and the other one is directly connected to the test equipment on each PE router.
  • The no-tunnel-services statement is included in the GOLD VPLS instance to enable the use of LSI interfaces for VPLS tunnel services.
  • Router CE1 and Router CE2 are EX Series Virtual Chassis switches acting as CE routers.
  • Router CE3 is an M7i router acting as a CE router.
  • Two multicast sources are configured. One is connected to Router CE1 (Site 1) and the other to Router PE2 (Site 4) to simulate different scenarios.
  • Router CE1 is configured as the rendezvous point (RP).
  • Unicast traffic is enabled on all the test equipment ports and is sent to all the sites in the GOLD VPLS instance.

Configuration

This example shows how to configure next-generation VPLS using point-to-multipoint LSPs. It is organized in the following sections:

Configuring the PE Router Interfaces

Step-by-Step Procedure

On the customer-facing PE interfaces, enable VLAN tagging, configure the encapsulation type, and enable the VPLS address family. There are four possible interface encapsulations for VPLS routing instances that you can choose depending on your needs.

  1. If your network requires that each logical interface on the PE router-to-CE router link be configured to only accept packets with VLAN ID 1000, include the vlan-tagging statement, include the encapsulation statement, and specify vlan-vpls as the encapsulation type. Also include the vlan-id statement and specify 1000 as the VLAN ID.
    [edit interfaces]
    ge-1/1/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}

    With this configuration, you can configure multiple logical interfaces with different VLAN IDs and associate each logical interface with a different routing instance.

  2. If your network requires each physical interface on the PE router to CE router link to be configured to use the entire Ethernet port as part of a single VPLS instance, include the encapsulation statement, and specify ethernet-vpls as the encapsulation type.
    [edit interfaces]
    ge-1/2/0 {encapsulation ethernet-vpls;unit 0 {family vpls;}}

    With this encapsulation mode, you cannot create multiple logical units (VLANs).

  3. If your network requires that each logical interface of the single physical interface on the PE router to CE router link be configured to use a mix of different encapsulations, include the encapsulation statement, and specify flexible-ethernet-services as the encapsulation type at the [edit interfaces interface-name] hierarchy level. Also include the encapsulation statement, and specify vlan-vpls or vlan-ccc as the encapsulation type at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.
    [edit interfaces]
    ge-1/2/0 {vlan-tagging;encapsulation flexible-ethernet-services;unit 1 {encapsulation vlan-vpls;}unit 2 {encapsulation vlan-ccc;}}
  4. If your network requires support for using a mix of single and dual tagged VLANs configured in different logical interfaces on a single physical interface, include the encapsulation statement, and specify flexible-vlan-tagging as the encapsulation type.
  5. Configure the core-facing CE router interfaces. The CE router and PE router logical interface configuration must match encapsulation types and VLAN IDs. Typically the IP address is configured on the core-facing CE router interfaces if the CE device is a router and terminates the Layer 2 domain into the Layer 3 network. In this example, the interface is configured for single tagging with a VLAN ID of 1000.
    [edit interfaces]
    ge-1/1/0 {vlan-tagging;unit 1 {vlan-id 1000;family inet {address 40.40.40.1/24;}}}

Configuring a Route Reflector for all PE Routers for BGP-Based VPLS

Step-by-Step Procedure

Configuring a route reflector is the preferred method to enable any BGP-based service offerings. Configuring a route reflector avoids the requirement for a full mesh of BGP peer sessions, and it scales well. BGP redundancy can be achieved using multiple route reflectors in a single cluster.

  1. To enable BGP to carry Layer 2 VPN and VPLS NLRI messages, create a peer group, include the family statement, specify the l2vpn option, and include the signaling statement. To configure the route reflector cluster and complete the BGP peer sessions, include the cluster statement and specify the IP address for the cluster ID. Then include the neighbor statement and specify the IP address of the PE routers that are BGP client peers in the cluster.
    [edit protocols]
    bgp {group RR {type internal;local-address 7.7.7.7;family l2vpn {signaling;}cluster 7.7.7.7;neighbor 1.1.1.1;  # To PE1neighbor 2.2.2.2;  # To PE2neighbor 3.3.3.3;  # To PE3neighbor 4.4.4.4;  # To PE4}}
  2. Configure OSPF and enable traffic engineering on the route reflector to create the Constrained Shortest Path First (CSPF) database for the egress LSPs terminating from the PE routers.
    [edit protocols]
    ospf {traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}}
  3. Enable the MPLS and RSVP protocols on all interfaces connected to the MPLS core. This terminates the RSVP egress LSPs from the PE routers.
    [edit protocols]
    rsvp {interface all;interface fxp0.0 {disable;}}
    mpls {interface all;interface fxp0.0 {disable;}}

Establishing BGP-Based VPLS with a Route Reflector

Step-by-Step Procedure

For BGP-based VPLS, all PE routers need to have a full mesh of BGP peer sessions with each other or have a single peer with the route reflector. The route reflector reflects the routes received from the other PE routers. In this example, the PE router is configured to establish a peer relationship with the route reflector.

  1. To have all the PE routers establish a BGP client peer session with the route reflector, create an internal peer group, include the local-address statement, and specify the IP address of the PE router. Also include the neighbor statement, and specify the IP address of the route reflector. To enable BGP to carry Layer 2 VPN and VPLS NLRI messages, include the family statement, specify the l2vpn option, and include the signaling statement.
    [edit protocols]
    bgp {group to-RR {type internal;local-address 1.1.1.1;family l2vpn {signaling;}neighbor 7.7.7.7;  # To the route reflector}}
  2. Configure a point-to-point RSVP LSP from the PE routers to the route reflector. To create the LSP, include the label-switched-path statement, give the LSP a meaningful name, include the to statement and specify the IP address of the route reflector as the LSP end point. This LSP is needed to resolve the BGP next hops in the inet.3 routing table for the routes received from the route-reflector.
    [edit protocols]
    mpls {label-switched-path to-RR {to 7.7.7.7;}interface all;interface fxp0.0 {disable;}}

Configuring Point-to-Point LSPs Between PE Routers

Step-by-Step Procedure

In next-generation VPLS, point-to-multipoint LSPs are only used to transport broadcast, multicast, and unknown unicast frames. All other frames are still transported using point-to-point RSVP LSPs. This is a more efficient use of bandwidth, particularly near the source of the unknown, broadcast, and multicast frames. The trade-off is more state in the network, because each PE router is the ingress of one point-to-multipoint LSP that touches all other PE routers, and n point-to-point LSPs are needed, one going to each of the other PE routers.

  1. To create a point-to-point LSP, include the label-switched-path statement, give the LSP a meaningful name, include the to statement, and specify the IP address of the other PE router as the LSP endpoint. The example shows the configuration of LSPs from Router PE1 to Routers PE2, PE3, and PE4.
    [edit protocols]
    mpls {label-switched-path to-PE2 {to 2.2.2.2;}label-switched-path to-PE3 {to 3.3.3.3;}label-switched-path to-PE4 {to 4.4.4.4;}}

Configuring Dynamic and Static Point-to-Multipoint LSPs Between PE Routers

Step-by-Step Procedure

This procedure describes how to enable the creation of dynamic point-to-multipoint LSPs and how to configure static point-to-multipoint LSPs. On a router configured with static point-to-multipoint LSPs, the LSPs come up immediately. On a router configured with dynamic point-to-multipoint LSPs, the LSP comes up only after receiving BGP neighbor information from the route reflector or from the other PE routers participating in the VPLS domain.

For each VPLS instance, a PE router with dynamic point-to-multipoint LSPs enabled creates a dedicated point-to-multipoint LSP based on the point-to-multipoint template. Whenever VPLS discovers a new neighbor through BGP, a sub-LSP for this neighbor is added to the point-to-multipoint LSP.

If there are n PE routers in the VPLS instance then the router creates n point-to-multipoint LSPs in the network where each PE router is the root of the tree and includes the rest of the n-1 PE routers as leaf nodes connected through a source-to-leaf sub-LSP.

  1. In this step, you configure Router PE1 and Router PE2 to use a dynamic point-to-multipoint LSP template for LSP creation. When these routers receive a new BGP route advertised from the route reflector for a new neighbor, they create a point-to-multipoint sub-LSP to that neighbor. To create the dynamic point-to-multipoint LSP template, include the label-switched-path statement, give the LSP template a meaningful name, include the template statement and include the p2mp statement. Also enable link protection and configure the optimize timer to periodically reoptimize the LSP path.
    [edit protocols]
    mpls {label-switched-path vpls-GOLD-p2mp-template {template;  # identify as a templateoptimize-timer 50;link-protection;  # link protection is enabled on point-to-multipoint LSPsp2mp;}}
  2. In this step, you configure static point-to-multipoint LSPs. Creating static point-to-multipoint LSPs is similar to creating point-to-point LSPs, except you can also configure other RSVP parameters under each point-to-multipoint LSP.

    To create static point-to-multipoint LSPs, include the label-switched-path statement, give the LSP a meaningful name, include the to statement, and specify the IP address of the PE router that is the endpoint of the LSP. Also include the p2mp statement and specify a pathname.

    [edit protocols]
    mpls {label-switched-path to-pe2 {to 2.2.2.2;p2mp vpls-GOLD;}label-switched-path to-pe3 {to 3.3.3.3;p2mp vpls-GOLD;}label-switched-path to-pe1 {to 1.1.1.1;p2mp vpls-GOLD;}}

Configuring Point-to-Multipoint Link Protection

Step-by-Step Procedure

Point-to-multipoint LSPs only support RSVP link protection for traffic engineering. Node protection is not supported. Link protection is optional, but it is the recommended configuration for most networks.

  1. To enable link protection on the core-facing interfaces, include the link-protection statement at the [edit protocols rsvp interface interface-name] hierarchy level.
    [edit protocols]
    rsvp {interface all;interface fxp0.0 {disable;}interface xe-0/3/0.0 {link-protection;}interface xe-0/2/0.0 {link-protection;}interface xe-0/1/0.0 {link-protection;}}
  2. Enable the point-to-multipoint LSP to use the RSVP link protection feature. Link-protection can be configured for both static point-to-multipoint and dynamic point-to-multipoint LSPs that use a template.

    For static point-to-multipoint LSPs, configure each branch sub-LSP. To enable link protection, include the link-protection statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level.

    [edit protocols mpls label-switched-path]
    label-switched-path to-pe2 {to 2.2.2.2;link-protection;p2mp vpls-GOLD;}
    label-switched-path to-pe3 {to 3.3.3.3;link-protection;p2mp vpls-GOLD;}
    label-switched-path to-pe1 {to 1.1.1.1;link-protection;p2mp vpls-GOLD;}
  3. For dynamic point-to-multipoint LSPs using a template, only the template needs to have link protection configured. All the point-to-multipoint branch LSPs that use the template inherit this configuration.

    To enable link protection for dynamic point-to-multipoint LSPs, include the link-protection statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level.

    [edit protocols mpls label-switched-path]
    label-switched-path vpls-GOLD-p2mp-template {template;optimize-timer 50;link-protection;p2mp;}

Configuring a BGP-Based VPLS Routing Instance for NG-VPLS

Step-by-Step Procedure

For NG-VPLS, the routing-instance configuration is similar to that for a regular VPLS routing instance. The routing instance defines the VPLS site and creates the VPLS connection. The following parameters are configured.

  • Instance Type – VPLS.
  • Interface – The interface connecting to the CE router.
  • Route Distinguisher – Each routing instance you configure on a PE router must have a unique route distinguisher. The route distinguisher is used by BGP to distinguish between potentially identical network reachability information (NLRI) messages received from different VPNs. If you use a unique route distinguisher for each routing instance on each PE, you can determine which PE originated the route.
  • VRF Target – Configuring a VRF target community using the vrf-target statement causes default VRF import and export policies to be generated that accept imported routes and tag exported routes with the specified target community.
  • Protocols – Configure the VPLS protocol as described in the following procedure.
  1. To configure the NG-VPLS routing instance, include the routing-instances statement and specify the instance name. Also include the instance-type statement and specify vpls as the type. Include the route-distinguisher statement and specify a route distinguisher that is unique throughout all VPNs configured on the router. Configure a VRF route target by including the vrf-target statement and specify the route target. The route target exported by one router must match the route target imported by another router for the same VPLS.
    [edit]
    routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;vrf-target target:65000:1;}}
  2. To use a point-to-multipoint LSP for VPLS flooding, configure an LSP under the VPLS routing instance.

    To configure the point-to-multipoint LSP for VPLS flooding, include the label-switched-path-template statement and specify the name of the LSP template at the [edit routing-instances routing-instances-name provider-tunnel rsvp-te] hierarchy level.

    [edit]
    routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;}}
  3. Configuring the VPLS protocol enables the VPLS between different sites in the VPLS domain. Multiple sites can be configured under a single VPLS routing instance, but note that the lowest site ID is used to build the VPLS pseudowire to the other PE routers, and the label block associated with the lowest site ID is advertised. The following parameters are configured for the VPLS protocol:
    • Site – Name of the VPLS site.
    • Site Range – Maximum site ID allowed in the VPLS. The site range specifies the highest-value site ID allowed within the VPLS, not the number of sites in the VPLS.
    • Site Identifier – Any number between 1 and 65,534 that uniquely identifies the VPLS site. This is also referred as the VE-ID in the relevant RFC.
    • PE-CE Interface – The interface participating in this site.
    • Tunnel services for VPLS – If you do not configure any tunnel interface at the [edit protocol vpls tunnel-services] hierarchy, the router uses any tunnel interface available on the router for VPLS.
    • No-tunnel-services – If you include the no-tunnel-services statement, the router uses a label-switched interface (LSI) for the tunnel services for that VPLS instance.
    • Mac Table Size – The size of the VPLS media access control (MAC) address table. The default is 512 addresses and the maximum is 65,536. When the table is full, new MAC addresses are no longer added to the table.

    To configure the VPLS protocol, include the vpls statement at the [edit routing-instances routing-instance-name protocols] hierarchy level. To configure the site range, include the site-range statement and specify the highest-value site ID allowed within the VPLS. To cause the router to use an LSI interface, include the no-tunnel-services statement. To create a VPLS site, include the site statement and specify a site name. Also include the site-identifier statement and specify the site ID. Then include the interface statement and specify the interface name for the interface connected to the CE device.

    [edit]
    routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;protocols {vpls {site-range 8;no-tunnel-services;site CE1 {site-identifier 1;interface ge-1/0/0.1;}site Direct {site-identifier 2;interface ge-1/1/0.1;}}}}}

Configuring Tunnel Services for VPLS

Step-by-Step Procedure

A tunnel interface is needed for VPLS configuration to encapsulate the originating traffic, and to de-encapsulate the traffic coming from a remote site. If the tunnel interface is not configured, the router selects one of the available tunnel interfaces on the router by default. There are three methods available in Junos OS to configure this tunnel interface.

  • To specify a virtual tunnel interface to be used as the primary device for tunneling, include the primary statement, and specify the virtual tunnel interface to be used at the [edit routing-instances routing-instance-name protocols vpls tunnel-services] hierarchy level.
    [edit routing-instances routing-instance-name]
    protocols {vpls {site-range 8;tunnel-services {primary vt-1/2/10;}}}
  • To configure the router to use an LSI interface for tunnel services rather than a virtual tunnel interface, include the no-tunnel-services statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy level.
    [edit routing-instances routing-instance-name]
    protocols {vpls {site-range 8;no-tunnel-services;}}
  • In an MX Series router you must create the tunnel services interface to be used for tunnel services. To create the tunnel service interface, include the bandwidth statement and specify the amount of bandwidth to reserve for tunnel services in gigabits per second at the [edit chassis fpc slot-number pic slot-number tunnel-services] hierarchy level.
    [edit chassis]
    fpc 1 {pic 3 {tunnel-services {bandwidth 1g;}}}

Verifying the Control Plane

Step-by-Step Procedure

This section describes show command outputs you can use to validate the control plane. It also provides methodologies for troubleshooting. Note the following:

  • In this example there are six sites. Router PE1 and Router PE2 have two sites each. Router PE3 and Router PE4 have one site each. All sites are in the GOLD VPLS instance.
  • In VPLS if you have multiple sites configured under a single VPLS routing instance, the label block from the site with the lowest site ID is used to establish pseudowires between remote PEs. Note that the data traffic is still sent to those PE router interfaces connected to CE devices that are in one of the following states:
    • LM – Local site ID is not the minimum designated. The local site ID is not the lowest. Therefore the local site ID is not being used to establish pseudowires or distribute VPLS label blocks.
    • RM – Remote site ID is not the minimum designated. The remote site ID is not the lowest. Therefore, the remote site ID is not being used to establish pseudowires or distribute VPLS label blocks.
  • For more information about how VPLS label blocks are allocated and used, see Understanding VPLS Label Blocks Operation.
  1. After the entire configuration is done, you can verify the VPLS connections state.

    In the following output, the VPLS connections show the Up state for certain sites, and the remaining sites show either the RM or LM state. This is the expected state in a VPLS implementation on multihoming sites.

    In this example, Router PE1 has site CE1 configured with site ID 1 and site Direct configured with site ID 2. The label block for site CE1 is advertised to the remote PE routers and used for receiving the data packets from the remote PE routers. In the show command output, notice the following:

    • Router PE1 uses its lowest site ID, which is site ID 1. Site ID 1 is used for Device CE1.
    • Router PE2 uses its lowest site ID, which is site ID 3. Site ID 3 is used for Device CE2.
    • Router PE3 and Router PE4 each have a single site configured.

      For site CE1, connection site 3 is in the Up state and connection site 4 is in the RM state.

    • For site Direct, all the connections are in the LM state.
    • Site Direct has a higher site ID than site 1 on this router.

    On Router PE1, use the show vpls connections command to verify the VPLS connections state .

    user@PE1> show vpls connections
    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 availble
BK -- Backup connection          ST -- Standby connection

Legend for interface status 
Up -- operational           
Dn -- down

Instance: GOLD
  Local site: CE1 (1)
    connection-site           Type  St     Time last up       # Up trans
    3                         rmt   Up    Oct  6 16:27:23 2009        1
      Remote PE: 2.2.2.2, Negotiated control-word: No
      Incoming label: 262171, Outgoing label: 262145
      Local interface: lsi.1049353, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 1 remote site 3
    4                         rmt   RM   
    5                         rmt   Up     Oct  6 16:27:27 2009        1
      Remote PE: 3.3.3.3, Negotiated control-word: No
      Incoming label: 262173, Outgoing label: 262145
      Local interface: lsi.1049354, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 1 remote site 5
    6                         rmt   Up     Oct  6 16:27:31 2009        1
      Remote PE: 4.4.4.4, Negotiated control-word: No
      Incoming label: 262174, Outgoing label: 800000
      Local interface: lsi.1049355, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 1 remote site 6
  Local site: Direct (2)
    connection-site           Type  St     Time last up       # Up trans
    3                         rmt   LM   
    4                         rmt   LM   
    5                         rmt   LM   
    6                         rmt   LM
  2. On Router PE4, use the show vpls connections command to verify the VPLS connections state.

    Verify that site 2 and site 4 are in the RM state. This state tells you that the sites are configured with the highest site ID on Router PE1 and Router PE2. Because Router PE4 has only one site configured, it does not have any sites in the LM states.

    user@PE4> show vpls connections
    ...
Instance: GOLD
  Local site: Direct (6)
    connection-site           Type  St     Time last up      # Up trans
    1                         rmt   Up     Oct  6 16:28:35 2009       1
      Remote PE: 1.1.1.1, Negotiated control-word: No
      Incoming label: 800000, Outgoing label: 262174
      Local interface: vt-1/2/10.1048576, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 6 remote site 1
    2                         rmt   RM   
    3                         rmt   Up     Oct  6 16:28:35 2009       1
      Remote PE: 2.2.2.2, Negotiated control-word: No
      Incoming label: 800002, Outgoing label: 262150
      Local interface: vt-1/2/10.1048577, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 6 remote site 3
    4                         rmt   RM   
    5                         rmt   Up     Oct  6 16:28:35 2009       1
      Remote PE: 3.3.3.3, Negotiated control-word: No
      Incoming label: 800004, Outgoing label: 262150
      Local interface: vt-1/2/10.1048578, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 6 remote site 5
  3. On each PE router, use the show bgp summary command to verify that the IBGP sessions between the PE routers or between the PE router and the route reflector have been established. The sessions must be operational before the PE routers can exchange any Layer 2 VPN routes. In the example below, also notice that the output from Router PE1 shows that the bgp.l2vpn.0 and GOLD.l2vpn.0 routing tables have been created.
    user@PE1> show bgp summary
    Groups: 1 Peers: 1 Down peers: 0
Table    Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l2vpn.0      4          4          0         0          0          0
Peer            AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State
7.7.7.7      65000         40         39       0       1       15:45 Establ
  bgp.l2vpn.0: 4/4/4/0
  GOLD.l2vpn.0: 4/4/4/0

admin@PE2# run show bgp summary 
Groups: 1 Peers: 1 Down peers: 0
Table    Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l2vpn.0      4          4          0         0          0          0
inet6.0          0          0          0         0          0          0
inet.0           0          0          0         0          0          0
Peer          AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State
7.7.7.7    65000         43         42       0       0       17:25 Establ
  bgp.l2vpn.0: 4/4/4/0
  GOLD.l2vpn.0: 4/4/4/0
  4. On Router PE4, use the show route table command to verify that there is one Layer 2 VPN route to each of the other PE routers. Router PE3 should have a similar show command output.
    user@PE4> show route table bgp.l2vpn.0
    bgp.l2vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1:1:1:1/96                
                   *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7
                      AS path: I
                    > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE1
1.1.1.1:1:2:1/96                
                   *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7
                      AS path: I
                    > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE1
2.2.2.2:10:3:1/96                
                   *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7
                      AS path: I
                    > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE2
2.2.2.2:10:4:1/96                
                   *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7
                      AS path: I
                    > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE2
3.3.3.3:10:5:1/96                
                   *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7
                      AS path: I
                    > to 10.10.8.1 via xe-0/1/0.0, label-switched-path to-PE3
  5. On the route reflector, use the show bgp summary command to verify that the router has an IBGP peer session with each of the PE routers.
    user@RR> show bgp summary
    Groups: 2 Peers: 5 Down peers: 1
Table    Tot Paths  Act Paths Suppressed    History Damp State  Pending
bgp.l2vpn.0      6          6          0          0          0        0
inet.0           0          0          0          0          0        0
Peer             AS     InPkt     OutPkt  OutQ   Flaps Last Up/Dwn State
1.1.1.1       65000        44        46      0       0       18:27 Establ
  bgp.l2vpn.0: 2/2/2/0
2.2.2.2       65000        43        45      0       0       18:22 Establ
  bgp.l2vpn.0: 2/2/2/0
3.3.3.3       65000        42        45      0       0       18:19 Establ
  bgp.l2vpn.0: 1/1/1/0
4.4.4.4       65000        43        45      0       0       18:15 Establ
  bgp.l2vpn.0: 1/1/1/0
  6. In NG-VPLS, point-to-multipoint LSPs carry only unknown unicast, broadcast, and multicast packets. A full mesh of point-to-point LSPs is needed between the PE routers for NG-VPLS. The point-to-point LSPs create routes in the inet.3 routing table. These entries are used to resolve the Layer 2 VPN routes received from the BGP peers. All other data traffic is sent over point-to-point LSPs.

    A point-to-point LSP is also created for the route reflector. This LSP creates a route in the inet.3 routing table for BGP next-hop resolution.

    On Router PE1, use the show mpls lsp command to verify that the to-PE2, to-PE3, to-PE4, and to-RR LSPs are in the Up state.

    user@PE1> show mpls lsp ingress unidirectional
    Ingress LSP: 7 sessions
To              From            State Rt P     ActivePath       LSPname
2.2.2.2         1.1.1.1         Up     0 *                      to-PE2
3.3.3.3         1.1.1.1         Up     0 *                      to-PE3
4.4.4.4         1.1.1.1         Up     0 *                      to-PE4
7.7.7.7         1.1.1.1         Up     0 *                      to-RR
Total 4 displayed, Up 4, Down 0
admin@PE2# run show mpls lsp ingress unidirectional 
Ingress LSP: 7 sessions
To              From            State Rt P     ActivePath       LSPname
1.1.1.1         2.2.2.2         Up     0 *                      to-PE1
3.3.3.3         2.2.2.2         Up     0 *                      to-PE3
4.4.4.4         2.2.2.2         Up     0 *                      to-PE4
7.7.7.7         2.2.2.2         Up     0 *                      to-RR
Total 4 displayed, Up 4, Down 0
admin@PE3# run show mpls lsp ingress unidirectional 
Ingress LSP: 7 sessions
To              From            State Rt P     ActivePath       LSPname
1.1.1.1         3.3.3.3         Up     0 *                      to-PE1
2.2.2.2         3.3.3.3         Up     0 *                      to-PE2
4.4.4.4         3.3.3.3         Up     0 *                      to-PE4
7.7.7.7         3.3.3.3         Up     0 *                      to-RR
Total 4 displayed, Up 4, Down 0
admin@PE4# run show mpls lsp ingress unidirectional 
Ingress LSP: 7 sessions
To              From            State Rt P     ActivePath       LSPname
1.1.1.1         4.4.4.4         Up     0 *                      to-PE1
2.2.2.2         4.4.4.4         Up     0 *                      to-PE2
3.3.3.3         4.4.4.4         Up     0 *                      to-PE3
7.7.7.7         4.4.4.4         Up     0 *                      to-RR
Total 4 displayed, Up 4, Down 0
  7. For each VPLS instance, a PE router creates a dedicated point-to-multipoint LSP. In this example, Router PE1 and Router PE2 are configured to use a point-to-multipoint dynamic template.

    For dynamic point-to-multipoint LSPs, whenever VPLS discovers a new Layer 2 VPN neighbor through BGP, a source-to-leaf sub-LSP is added in the VPLS instance for this neighbor PE router.

    On Router PE1, use the show mpls lsp command to verify that three source-to-leaf sub-LSPs are created.

    user@PE1> show mpls lsp ingress p2mp
    Ingress LSP: 1 sessions
P2MP name: 1.1.1.1:1:vpls:GOLD, P2MP branch count: 3
To            From          State Rt P   ActivePath     LSPname
4.4.4.4       1.1.1.1       Up     0 *       4.4.4.4:1.1.1.1:1:vpls:GOLD
3.3.3.3       1.1.1.1       Up     0 *       3.3.3.3:1.1.1.1:1:vpls:GOLD
2.2.2.2       1.1.1.1       Up     0 *       2.2.2.2:1.1.1.1:1:vpls:GOLD
Total 3 displayed, Up 3, Down 0
  8. On Router PE2, use the show mpls lsp command to verify that three source-to-leaf sub-LSPs are created.
    user@PE2> show mpls lsp p2mp ingress
    Ingress LSP: 1 sessions
P2MP name: 2.2.2.2:10:vpls:GOLD, P2MP branch count: 3
To            From          State Rt P     ActivePath       LSPname
4.4.4.4       2.2.2.2       Up     0 *        4.4.4.4:2.2.2.2:10:vpls:GOLD
3.3.3.3       2.2.2.2       Up     0 *        3.3.3.3:2.2.2.2:10:vpls:GOLD
1.1.1.1       2.2.2.2       Up     0 *        1.1.1.1:2.2.2.2:10:vpls:GOLD
Total 3 displayed, Up 3, Down 0
  9. In this step, Router PE3 and Router PE4 are using static point-to-multipoint LSPs. For static point-to-multipoint LSPs, the source-to-leaf sub-LSPs to all the PE routers are manually configured.

    On Router PE3, use the show mpls lsp command to verify that three source-to-leaf sub-LSPs have been configured.

    user@PE3> show mpls lsp p2mp ingress
    Ingress LSP: 1 sessions
P2MP name: vpls-GOLD, P2MP branch count: 3
To            From          State Rt P     ActivePath       LSPname
1.1.1.1       3.3.3.3       Up     0 *                      to-pe1
4.4.4.4       3.3.3.3       Up     0 *                      to-pe4
2.2.2.2       3.3.3.3       Up     0 *                      to-pe2
Total 3 displayed, Up 3, Down 0
  10. On Router PE4, use the show mpls lsp command to verify that three source-to-leaf sub-LSPs are configured.
    user@PE4> show mpls lsp ingress p2mp
    Ingress LSP: 1 sessions
P2MP name: vpls-GOLD, P2MP branch count: 3
To            From          State Rt P     ActivePath       LSPname
1.1.1.1       4.4.4.4       Up     0 *                      to-pe1
3.3.3.3       4.4.4.4       Up     0 *                      to-pe3
2.2.2.2       4.4.4.4       Up     0 *                      to-pe2
Total 3 displayed, Up 3, Down 0
  11. Each point-to-multipoint LSP created by the PE router can be identified using an RSVP-TE point-to-multipoint session object. The session object is passed as a PMSI tunnel attribute by BGP when it advertises VPLS routes. Using this tunnel attribute, an incoming source-to-leaf sub LSP add request (RSVP-Path message) supports label allocation in such a way that when traffic arrives on this source-to-leaf sub-LSP the router terminates the message in the right VPLS instance and also identifies the originating PE. This supports source MAC address learning.

    On Router PE1, use the show rsvp session command to verify that the RSVP session for the dynamic point-to-multipoint LSP is Up and that link protection is configured as desired. Notice that the point-to-multipoint session object to be sent in BGP is 54337.

    user@PE1> show rsvp session detail p2mp ingress
    Ingress RSVP: 7 sessions
P2MP name: 1.1.1.1:1:vpls:GOLD, P2MP branch count: 3

2.2.2.2
  From: 1.1.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: 2.2.2.2:1.1.1.1:1:vpls:GOLD, LSPpath: Primary
  P2MP LSPname: 1.1.1.1:1:vpls:GOLD
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 262145
  Resv style: 1 SE, Label in: -, Label out: 262145
  Time left:    -, Since: Tue Oct  6 16:27:23 2009
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 2 receiver 54337 protocol 0    
  Link protection desired
  Type: Protection down
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 10.10.2.2 (xe-0/1/0.0) 371 pkts
  RESV rcvfrom: 10.10.2.2 (xe-0/1/0.0) 370 pkts
  Explct route: 10.10.2.2 
  Record route: <self> 10.10.2.2
  12. Router PE4 is configured for static point-to-multipoint LSPs. Link protection is not configured for these LSPs. Use the show rsvp session command to verify that the point-to-multipoint session object to be sent in BGP is 42873.
    user@PE4> show rsvp session detail p2mp ingress
    Ingress RSVP: 7 sessions
P2MP name: vpls-GOLD, P2MP branch count: 3

1.1.1.1
  From: 4.4.4.4, LSPstate: Up, ActiveRoute: 0
  LSPname: to-pe1, LSPpath: Primary
  P2MP LSPname: vpls-GOLD
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 390416
  Resv style: 1 SE, Label in: -, Label out: 390416
  Time left:    -, Since: Tue Oct  6 15:28:33 2009
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 10 receiver 42873 protocol 0 
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 10.10.9.1 (xe-0/0/0.0) 524 pkts
  RESV rcvfrom: 10.10.9.1 (xe-0/0/0.0) 447 pkts
  Explct route: 10.10.9.1 10.10.3.1 
  Record route: <self> 10.10.9.1 10.10.3.1
  13. On Router PE1, use the show route table command to verify that Router PE1 received a Layer 2 VPN route to Router PE2 from the router reflector and the route includes a PMSI object that contains the point-to-multipoint tunnel identifier of 20361.
    user@PE1> show route table GOLD.l2vpn.0 detail
    GOLD.l2vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
!
!
2.2.2.2:10:3:1/96 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 2.2.2.2:10
                PMSI: Flags 0:RSVP-TE:label[0:0:0]:Session_13[2.2.2.2:0:20361:2.2.2.2]  
                Next hop type: Indirect
                Next-hop reference count: 7
                Source: 7.7.7.7
                Protocol next hop: 2.2.2.2
                Indirect next hop: 2 no-forward
                State: <Secondary Active Int Ext>
                Local AS: 65000 Peer AS: 65000
                Age: 4:25:25    Metric2: 1 
                Task: BGP_65000.7.7.7.7+63544
                Announcement bits (1): 0-GOLD-l2vpn 
                AS path: I (Originator) Cluster list:  7.7.7.7
                AS path:  Originator ID: 2.2.2.2
                Communities: target:65000:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Import Accepted 
                Label-base: 262145, range: 8
                Localpref: 100
                Router ID: 7.7.7.7
                Primary Routing Table bgp.l2vpn.0
PMSI: Flags 0:RSVP-TE:label[0:0:0]:Session_13[2.2.2.2:0:20361:2.2.2.2]
  14. On Router PE2, use the show rsvp session command to verify that the PMSI tunnel identifier object of 20361 matches the PMSI tunnel identifier object displayed on Router PE1.
    user@PE2> show rsvp session p2mp detail
    Ingress RSVP: 7 sessions
P2MP name: 2.2.2.2:10:vpls:GOLD, P2MP branch count: 3

1.1.1.1
  From: 2.2.2.2, LSPstate: Up, ActiveRoute: 0
  LSPname: 1.1.1.1:2.2.2.2:10:vpls:GOLD, LSPpath: Primary
  P2MP LSPname: 2.2.2.2:10:vpls:GOLD
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 262171
  Resv style: 1 SE, Label in: -, Label out: 262171
  Time left:    -, Since: Tue Oct  6 16:31:47 2009
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 20361 protocol 0 
  Link protection desired
  Type: Protection down
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 10.10.2.1 (xe-0/1/0.0) 379 pkts
  RESV rcvfrom: 10.10.2.1 (xe-0/1/0.0) 379 pkts
  Explct route: 10.10.2.1 
  Record route: <self> 10.10.2.1

Verifying the Data Plane

Step-by-Step Procedure

After the control plane is verified using the previous steps, you can verify the data plane. This section describes show command outputs you can use to validate the data plane.

  1. On Router PE1, use the show vpls connections extensive | match Flood command to verify the point-to-multipoint LSP name and status of all the sites. Notice the flood next-hop identifier of 600 for the 1.1.1.1:1:vpls:GOLD LSP.
    user@PE1> show vpls connections extensive | match Flood
    Ingress RSVP-TE P2MP LSP: 1.1.1.1:1:vpls:GOLD, Flood next-hop ID: 600
  2. On Router PE1, use the show vpls connections extensive command to verify the point-to-multipoint LSP name and status of all the sites.
    user@PE1> show vpls connections extensive
    Instance: GOLD
  Local site: CE1 (1)
    Number of local interfaces: 1
    Number of local interfaces up: 1
    IRB interface present: no
    ge-1/0/0.1         
    lsi.1049353     3       Intf - vpls GOLD local site 1 remote site 3
    lsi.1049346     4       Intf - vpls GOLD local site 1 remote site 4
        Interface flags: VC-Down
    lsi.1049354     5       Intf - vpls GOLD local site 1 remote site 5
    lsi.1049355     6       Intf - vpls GOLD local site 1 remote site 6
    Label-base        Offset     Range     Preference
    262169            1          8         100   
    connection-site           Type  St     Time last up      # Up trans
    3                         rmt   Up     Oct  6 16:27:23 2009       1
      Remote PE: 2.2.2.2, Negotiated control-word: No
      Incoming label: 262171, Outgoing label: 262145
      Local interface: lsi.1049353, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 1 remote site 3
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up
        Egress branch LSP:  1.1.1.1:2.2.2.2:10:vpls:GOLD, State: Up
    Connection History:
        Oct  6 16:27:23 2009  status update timer  
        Oct  6 16:27:23 2009  PE route changed     
        Oct  6 16:27:23 2009  Out lbl Update                    262145
        Oct  6 16:27:23 2009  In lbl Update                     262171
        Oct  6 16:27:23 2009  loc intf up                  lsi.1049353
    4                         rmt   RM   
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up
    5                         rmt   Up     Oct  6 16:27:27 2009          1
      Remote PE: 3.3.3.3, Negotiated control-word: No
      Incoming label: 262173, Outgoing label: 262145
      Local interface: lsi.1049354, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 1 remote site 5
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 3.3.3.3:1.1.1.1:1:vpls:GOLD, State: Up
        Egress branch LSP:  to-pe1, State: Up
    Connection History:
        Oct  6 16:27:27 2009  status update timer  
        Oct  6 16:27:27 2009  PE route changed     
        Oct  6 16:27:27 2009  Out lbl Update                    262145
        Oct  6 16:27:27 2009  In lbl Update                     262173
        Oct  6 16:27:27 2009  loc intf up                  lsi.1049354
    6                         rmt   Up     Oct  6 16:27:31 2009          1
      Remote PE: 4.4.4.4, Negotiated control-word: No
      Incoming label: 262174, Outgoing label: 800000
      Local interface: lsi.1049355, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls GOLD local site 1 remote site 6
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 4.4.4.4:1.1.1.1:1:vpls:GOLD, State: Up
        Egress branch LSP:  to-pe1, State: Up
    Connection History:
        Oct  6 16:27:31 2009  status update timer  
        Oct  6 16:27:31 2009  PE route changed     
        Oct  6 16:27:31 2009  Out lbl Update                    800000
        Oct  6 16:27:31 2009  In lbl Update                     262174
        Oct  6 16:27:31 2009  loc intf up                  lsi.1049355
  Local site: Direct (2)
    Number of local interfaces: 1
    Number of local interfaces up: 1
    IRB interface present: no
  Interface name  Remote site ID  Description
    ge-1/1/0.1         
    lsi.1049347     3       Intf - vpls GOLD local site 2 remote site 3
        Interface flags: VC-Down
    lsi.1049348     4       Intf - vpls GOLD local site 2 remote site 4
        Interface flags: VC-Down
    lsi.1049350     5       Intf - vpls GOLD local site 2 remote site 5
        Interface flags: VC-Down
    lsi.1049352     6       Intf - vpls GOLD local site 2 remote site 6
        Interface flags: VC-Down
    Label-base        Offset     Range     Preference
    262177            1          8         100   
    connection-site           Type  St     Time last up      
    3                         rmt   LM   
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up
    4                         rmt   LM   
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up
    5                         rmt   LM   
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 3.3.3.3:1.1.1.1:1:vpls:GOLD, State: Up
    6                         rmt   LM   
      RSVP-TE P2MP lsp:
        Ingress branch LSP: 4.4.4.4:1.1.1.1:1:vpls:GOLD, State: Up
  Ingress RSVP-TE P2MP LSP: 1.1.1.1:1:vpls:GOLD, Flood next-hop ID: 600
  3. Junos OS Release 9.0 and later identifies the flood next-hop route as a composite next hop. On Router PE1, use the show route forwarding-table family vpls vpn GOLD detail command to verify that three composite flood next-hop routes are installed in the Packet Forwarding Engine.
    user@PE1> show route forwarding-table family vpls vpn GOLD detail
    Routing table: GOLD.vpls
VPLS:
Destination        Type RtRef Next hop       Type Index NhRef Netif
default            perm     0                dscd   518     1
00:00:28:28:28:02/48
                   user     0                ucst   617     4 ge-1/1/0.1
00:00:28:28:28:06/48
                   user     0                indr 1048576     4
                              10.10.3.2     Push 800000, Push 390384(top)   621     2 xe-0/2/0.0
lsi.1049353        intf     0                indr 1048574     3
                              10.10.2.2     Push 262145   598     2 xe-0/1/0.0
lsi.1049354        intf     0                indr 1048575     4
                              10.10.1.2     Push 262145, Push 302272(top)   602     2 xe-0/3/0.0
lsi.1049355        intf     0                indr 1048576     4
                              10.10.3.2     Push 800000, Push 390384(top)   621     2 xe-0/2/0.0
00:14:f6:75:78:00/48
                   user     0                indr 1048575     4
                              10.10.1.2     Push 262145, Push 302272(top)   602     2 xe-0/3/0.0
00:19:e2:57:e7:c0/48
                   user     0                ucst   604     4 ge-1/0/0.1
0x30003/51         user     0                comp   613     2
0x30002/51         user     0                comp   615     2
0x30001/51         user     0                comp   582     2
ge-1/0/0.1         intf     0                ucst   604     4 ge-1/0/0.1
ge-1/1/0.1         intf     0                ucst   617     4 ge-1/1/0.1

    You can also use the use the show route forwarding-table family vpls extensive command to match the flood identifier and note the flood label. To match the label out corresponding to the point-to-multipoint LSP, use the show rsvp session ingress p2mp command.

  4. On Router PE1, use the show route forwarding-table family vpls vpn GOLD extensive | find 0x30003/51 command to get more details about the composite next-hop route and the associated point-to-multipoint LSP labels.
    user@PE1> show route forwarding-table family vpls vpn GOLD extensive | find 0x30003/51
    Destination:  0x30003/51
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Flags: sent to PFE 
  Nexthop:  	
  Next-hop type: composite             Index: 613      Reference: 2    
  Nexthop:  
  Next-hop type: composite             Index: 556      Reference: 4    
  Next-hop type: unicast               Index: 604      Reference: 4    
  Next-hop interface: ge-1/0/0.1   
  Next-hop type: unicast               Index: 617      Reference: 4    
  Next-hop interface: ge-1/1/0.1   
    
Destination:  0x30002/51
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Flags: sent to PFE 
  Nexthop:  
  Next-hop type: composite             Index: 615      Reference: 2    
  Nexthop:  
  Next-hop type: composite             Index: 556      Reference: 4    
  Next-hop type: unicast               Index: 604      Reference: 4    
  Next-hop interface: ge-1/0/0.1   
  Next-hop type: unicast               Index: 617      Reference: 4    
  Next-hop interface: ge-1/1/0.1   
  Nexthop:  
  Next-hop type: composite             Index: 603      Reference: 3    
  Next-hop type: flood                 Index: 600      Reference: 2    
  Nexthop: 10.10.2.2
  Next-hop type: Push 262145           Index: 599      Reference: 1    
  Next-hop interface: xe-0/1/0.0   
  Nexthop: 10.10.3.2
  Next-hop type: Push 390496           Index: 622      Reference: 1    
  Next-hop interface: xe-0/2/0.0   
  Nexthop: 10.10.1.2
  Next-hop type: Push 302416           Index: 618      Reference: 1    
  Next-hop interface: xe-0/3/0.0   
    
Destination:  0x30001/51
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Flags: sent to PFE 
  Nexthop:  
  Next-hop type: composite             Index: 582      Reference: 2    
  Nexthop:  
  Next-hop type: composite             Index: 556      Reference: 4    
  Next-hop type: unicast               Index: 604      Reference: 4    
  Next-hop interface: ge-1/0/0.1   
  Next-hop type: unicast               Index: 617      Reference: 4    
  Next-hop interface: ge-1/1/0.1   
  Nexthop:  
  Next-hop type: composite             Index: 603      Reference: 3    
  Next-hop type: flood                 Index: 600      Reference: 2    
  Nexthop: 10.10.2.2
  Next-hop type: Push 262145           Index: 599      Reference: 1    
  Next-hop interface: xe-0/1/0.0   
  Nexthop: 10.10.3.2
  Next-hop type: Push 390496           Index: 622      Reference: 1    
  Next-hop interface: xe-0/2/0.0   
  Nexthop: 10.10.1.2
  Next-hop type: Push 302416           Index: 618      Reference: 1    
  Next-hop interface: xe-0/3/0.0   
    
Destination:  ge-1/0/0.1
  Route type: interface             
  Route reference: 0                   Route interface-index: 84  
  Flags: sent to PFE 
  Next-hop type: unicast               Index: 604      Reference: 4    
  Next-hop interface: ge-1/0/0.1   
    
Destination:  ge-1/1/0.1
  Route type: interface             
  Route reference: 0                   Route interface-index: 86  
  Flags: sent to PFE 
  Next-hop type: unicast               Index: 617      Reference: 4    
  Next-hop interface: ge-1/1/0.1
  5. On Router PE1, use the show vpls mac-table instance GOLD command to verify the learned MAC addresses of CE routers connected to the VPLS domain.
    user@PE1> show vpls mac-table instance GOLD
    MAC flags (S -static MAC, D -dynamic MAC,
           SE -Statistics enabled, NM -Non configured MAC)

Routing instance : GOLD
 Bridging domain : __GOLD__, VLAN : NA
   MAC                 MAC      Logical
   address             flags    interface 
   00:00:28:28:28:02   D        ge-1/1/0.1           
   00:00:28:28:28:04   D        lsi.1049353          
   00:14:f6:75:78:00   D        lsi.1049354          
   00:19:e2:51:7f:c0   D        lsi.1049353          
   00:19:e2:57:e7:c0   D        ge-1/0/0.1
  6. On Router PE1, use the show vpls statistics command to verify the broadcast, multicast, and unicast traffic flow using the packet statistics for the VPLS instance.
    user@PE1> show vpls statistics
    VPLS statistics:

Instance: GOLD
   Local interface: lsi.1049347, Index: 72
     Current MAC count:                     0
   Local interface: lsi.1049348, Index: 73
     Current MAC count:                     0
   Local interface: lsi.1049346, Index: 82
     Current MAC count:                     0
   Local interface: lsi.1049353, Index: 83
   Remote PE: 2.2.2.2
     Current MAC count:                     2
   Local interface: ge-1/0/0.1, Index: 84
     Broadcast packets:                   421
     Broadcast bytes  :                 26944
     Multicast packets:                  3520
     Multicast bytes  :                261906
     Flooded packets  :             509043345
     Flooded bytes    :          130315095486
     Unicast packets  :             393836428
     Unicast bytes    :          100822118854
     Current MAC count:                     1 (Limit 1024)
   Local interface: ge-1/1/0.1, Index: 86
     Broadcast packets:                     0
     Broadcast bytes  :                     0
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :              22889544
     Flooded bytes    :            5859702144
     Unicast packets  :                   472
     Unicast bytes    :                 30838
     Current MAC count:                     1 (Limit 1024)
   Local interface: lsi.1049354, Index: 88
   Remote PE: 3.3.3.3
     Current MAC count:                     1
   Local interface: lsi.1049350, Index: 89
     Current MAC count:                     0
   Local interface: lsi.1049355, Index: 90
   Remote PE: 4.4.4.4
     Current MAC count:                     0
   Local interface: lsi.1049352, Index: 91
     Current MAC count:                     0

Results

The configuration, verification, and testing part of this example has been completed. The following section is for your reference.

The relevant sample configuration for Router PE1 follows.

PE1 Configuration

chassis {dump-on-panic;fpc 1 {pic 3 {tunnel-services {bandwidth 1g;}}}network-services ethernet;}
interfaces {xe-0/1/0 {unit 0 {family inet {address 10.10.2.1/30;}family mpls;}}xe-0/2/0 {unit 0 {family inet {address 10.10.3.1/30;}family mpls;}}xe-0/3/0 {unit 0 {family inet {address 10.10.1.1/30;}family mpls;}}ge-1/0/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}ge-1/1/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}lo0 {unit 0 {family inet {address 1.1.1.1/32;}}}}
routing-options {static {route 172.0.0.0/8 next-hop 172.19.59.1;}autonomous-system 65000;}
protocols {rsvp {interface all;interface fxp0.0 {disable;}}mpls {label-switched-path to-RR {to 7.7.7.7;}label-switched-path vpls-GOLD-p2mp-template {template;optimize-timer 50;link-protection;p2mp;}label-switched-path to-PE2 {to 2.2.2.2;}label-switched-path to-PE3 {to 3.3.3.3;}label-switched-path to-PE4 {to 4.4.4.4;}interface all;interface fxp0.0 {disable;}}bgp {group to-RR {type internal;local-address 1.1.1.1;family l2vpn {signaling;}neighbor 7.7.7.7;}}ospf {traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}}}
routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;protocols {vpls {site-range 8;no-tunnel-services;site CE1 {site-identifier 1;interface ge-1/0/0.1;}site Direct {site-identifier 2;interface ge-1/1/0.1;}}}}}

The relevant sample configuration for Router PE2 follows.

PE2 Configuration

chassis {dump-on-panic;aggregated-devices {ethernet {device-count 1;}}fpc 1 {pic 3 {tunnel-services {bandwidth 1g;}}}}
interfaces {xe-0/1/0 {unit 0 {family inet {address 10.10.2.2/30;}family mpls;}}xe-0/2/0 {unit 0 {family inet {address 10.10.5.1/30;}family mpls;}}xe-0/3/0 {unit 0 {family inet {address 10.10.4.1/30;}family mpls;}}ge-1/0/1 {gigether-options {802.3ad ae0;}}ge-1/0/2 {gigether-options {802.3ad ae0;}}ge-1/1/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}ae0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}fxp0 {apply-groups [ re0 re1 ];}lo0 {unit 0 {family inet {address 2.2.2.2/32;}}}}
routing-options {static {route 172.0.0.0/8 next-hop 172.19.59.1;}autonomous-system 65000;}
protocols {rsvp {interface all;interface fxp0.0 {disable;}}mpls {label-switched-path to-RR {to 7.7.7.7;}label-switched-path vpls-GOLD-p2mp-template {template;optimize-timer 50;link-protection;p2mp;}label-switched-path to-PE1 {to 1.1.1.1;}label-switched-path to-PE3 {to 3.3.3.3;}label-switched-path to-PE4 {to 4.4.4.4;}interface all;interface fxp0.0 {disable;}}bgp {group to-RR {type internal;local-address 2.2.2.2;family l2vpn {signaling;}neighbor 7.7.7.7;}}ospf {traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}}}
routing-instances {GOLD {instance-type vpls;interface ge-1/1/0.1;interface ae0.1;route-distinguisher 2.2.2.2:10;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;protocols {vpls {site-range 8;site CE1 {site-identifier 3;interface ae0.1;}site Direct {site-identifier 4;interface ge-1/1/0.1;}}}}}
 

Related Documentation

 

Published: 2013-08-13

Previous Page Next Page