Manual:Cisco VPLS

Overview

Since version 3.20 RouterOS implements features that provide compatibility with Cisco VPLS features:

• Cisco style static VPLS pseudowires (RFC 4447 FEC type 0x80)
• Cisco VPLS BGP-based auto-discovery (draft-ietf-l2vpn-signaling-08)

When signaling static VPLS tunnels (pseudowires) using LDP, Cisco does not use pseudowire endpoint identification as specified in RFC 4762 (FEC type 0x81), but uses other method - from RFC 4447 (FEC type 0x80). Such pseudowires can be configured in RouterOS by means of cisco-style and cisco-style-id settings.

Cisco does not implement BGP-based auto-discovery and signaling according to RFC 4671. Instead, Cisco implements BGP based auto-discovery (draft-ietf-l2vpn-signaling-08). This method specifies use of BGP only to auto-discover other peers that participate in VPLS. VPLS pseudowire signaling is done by LDP.

This document focuses on RouterOS configuration that is related to Cisco compatibility features, for general information on VPLS see MPLSVPLS, for information on RFC 4671 compatible BGP based VPLS, see BGP based VPLS.

Example network

The example network used throughout this document is the same as in MPLSVPLS.

The requirements of customers A and B are the same - ethernet segments must be transparently connected. Taking into account simplicity of given network topology Service Provider has decided to use R5 as route reflector and to have no backup route reflector. Consider that MPLS switching is configured and running, as discussed in MPLSVPLS, but no any VPLS configuration has been applied yet. the rest of this document deals with specifics that are introduced by using Cisco compatible VPLS features.

Customer's B networks are to be connected using static VPLS pseudowire, Customer's A networks are to be connected using VPLS BGP-based autodiscovery.

Configuring Cisco style static VPLS interface

Cisco compatible static VPLS interface is created by specifying appropriate settings: cisco-style=yes specifies that VPLS interface should use Cisco-like endpoint identification, parameter cisco-style-id specifies pseudowire ID to use. On R1:

[admin@R1] /interface vpls> add disabled=no cisco-style=yes cisco-style-id=666 remote-peer=9.9.9.5

and on R5:

[admin@R5] /interface vpls> add disabled=no cisco-style=yes cisco-style-id=666 remote-peer=9.9.9.1

This should result in establishment of targeted LDP session between R1 and R5 and VPLS interface becoming active:

[admin@R1] > mpls ldp neighbor print
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls
 #      TRANSPORT       LOCAL-TRANSPORT PEER                       SEND-TARGETED ADDRESSES
 0 DO   9.9.9.2         9.9.9.1         9.9.9.2:0                  no            1.1.1.2
                                                                                 2.2.2.2
                                                                                 9.9.9.2
 1 DOTV 9.9.9.5         9.9.9.1         9.9.9.5:0                  yes           4.4.4.5
                                                                                 5.5.5.5
                                                                                 9.9.9.5
[admin@R1] > /interface vpls print
Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
 0 R   name="vpls1" mtu=1500 mac-address=02:94:02:DB:60:6E arp=enabled disable-running-check=no
remote-peer=9.9.9.5 cisco-style=yes cisco-style-id=666
[admin@R1] > /interface vpls monitor vpls1 once
       remote-label: 29
        local-label: 31
      remote-status:
          transport: 9.9.9.5/32
  transport-nexthop: 1.1.1.2
     imposed-labels: 24,29

The rest of configuration to enable transparent bridging of Customer B networks (configuring bridging) is the same as described in MPLSVPLS

Configuring BGP for Cisco compatible VPLS

Configuring Cisco compatible BGP VPLS instance makes router advertise VPLS NLRI according to draft-ietf-l2vpn-signaling-08. Note that this NLRI uses the same BGP AFI/SAFI values as RFC 4762 compatible BGP VPLS. Therefore only one of those specifications (configured as BGP peer address-families) can be supported at a time.

In order to avoid configuring full mesh of BGP sessions between routers acting as attachment points for customer A networks (R1,R4,R5), R5 will be used as route reflector - the same as in BGP based VPLS.

On R5, make sure that client-to-client-reflection is enabled:

[admin@R5] /routing bgp instance> pr
Flags: X - disabled
 0   name="default" as=65530 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no redistribute-rip=no
     redistribute-ospf=no redistribute-other-bgp=no out-filter="" client-to-client-reflection=yes ignore-as-path-len=no

Create BGP peers with support for l2vpn-cisco in peers address-families, on R5 configure route reflection:

[admin@R5] /routing bgp peer> add remote-as=65530 update-source=lobridge instance=default remote-address=9.9.9.1
address-families=l2vpn-cisco route-reflect=yes
[admin@R5] /routing bgp peer> add remote-as=65530 update-source=lobridge instance=default remote-address=9.9.9.4
address-families=l2vpn-cisco route-reflect=yes

[admin@R1] /routing bgp peer> add remote-as=65530 update-source=lobridge instance=default remote-address=9.9.9.5
address-families=l2vpn-cisco

[admin@R4] /routing bgp peer> add remote-as=65530 update-source=lobridge instance=default remote-address=9.9.9.5
address-families=l2vpn-cisco

Configuring Cisco compatible BGP VPLS instance

In order for full mesh of VPLS pseudowires to get established, appropriate Cisco compatible VPLS instance must be created. Creating such instance makes router to inject VPLS BGP NLRI in BGP network:

[admin@R1] /interface vpls cisco-bgp-vpls> add bridge=A bridge-horizon=1 export-route-targets=1:1 import-route-targets=1:1
l2router-id=9.9.9.1 route-distinguisher=1:1 vpls-id=1:1

[admin@R4] /interface vpls cisco-bgp-vpls> add bridge=A bridge-horizon=1 export-route-targets=1:1 import-route-targets=1:1
l2router-id=9.9.9.4 route-distinguisher=1:1 vpls-id=1:1

[admin@R5] /interface vpls cisco-bgp-vpls> add bridge=A bridge-horizon=1 export-route-targets=1:1 import-route-targets=1:1
l2router-id=9.9.9.5 route-distinguisher=1:1 vpls-id=1:1

This causes full mesh of targeted LDP sessions to get established and appropriate VPLS interfaces created, e.g. on R4:

[admin@R4] > /mpls ldp neighbor print
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls
 ...
 1 DOTV 9.9.9.5         9.9.9.4         9.9.9.5:0                  no            4.4.4.5
                                                                                 5.5.5.5
                                                                                 9.9.9.5
 2 DOTV 9.9.9.1         9.9.9.4         9.9.9.1:0                  yes           1.1.1.1
                                                                                 9.9.9.1
[admin@R4] > /interface vpls print
Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
 0 RDC name="vpls1" mtu=1500 mac-address=02:62:65:24:4C:FD arp=enabled disable-running-check=no remote-peer=9.9.9.1
       vpls-id=1:1 cisco-style=no cisco-style-id=0 vpls=cisco-bgp-vpls1

 1 RDC name="vpls2" mtu=1500 mac-address=02:58:9F:80:EB:94 arp=enabled disable-running-check=no remote-peer=9.9.9.5
       vpls-id=1:1 cisco-style=no cisco-style-id=0 vpls=cisco-bgp-vpls1