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

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.

   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.

   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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. We recommend that you use a unique route distinguisher for each routing instance on each PE so that 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.

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.

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.

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.

• 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.

• 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.

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 .

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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 192.0.2.1:1:vpls:GOLD LSP.

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.

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.

   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.

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.

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.