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