Interop IP infusion and MikroTik: part 2 – VPLS

VPLS is a pretty common technology in ISPs to either sell layer 2 services or backhaul traffic to a centralized aggregation point to conserve IPv4 space; check out more on that here.

How can I take advantage of segment routing but still deliver the same services? We already looked at how to setup the label switched paths utilizing IP Infusion as a segment routing mapping server in this interop post. Now let’s see how we can deliver a VPLS service over this with mikrotik as a provider edge router.

Delivering a service with a L2VPN

After setting up the IGP and label distribution between the PEs we will start building the L2VPN.

Why a BGP signaled VPLS session instead of LDP signaled VPLS?

In the segment-routing domain there is no LDP running. However, some vendors support static pseudowires or other methods to bring up a targeted LDP session for VPLS. I did some basic testing here couldn’t easily identify the right combination of knobs to make this work. Don’t worry; I’ll come back to it.

BGP signaled VPLS is a standards based technology that both vendors support.

First thing we need to do after having loopback reachability is to build the BGP sessions.

ipi-1.lab.jan1.us.ipa.net:

router bgp 65000
 neighbor 100.127.2.0 remote-as 65000
 neighbor 100.127.2.0 update-source lo
 !
 address-family l2vpn vpls
 neighbor 100.127.2.0 activate
!
MikroTik-1:

/routing bgp peer
add address-families=l2vpn name=OCNOS1 nexthop-choice=force-self \
    remote-address=100.127.0.1 remote-as=65000 update-source=Lo0

After establishing the BGP peering we need to build the vpls instance.

ipi-1.lab.jan1.us.ipa.net:

mpls vpls TEST 10
 signaling bgp
  ve-id 10
  exit-signaling
 exit-vpls
!
MikroTik-1:

/interface vpls bgp-vpls
add bridge=VPLS-TEST export-route-targets=65000:10 import-route-targets=\
    65000:10 name=TEST route-distinguisher=100.127.2.0:10 site-id=2 \
    use-control-word=no

On OcNOS the route-target and route distinguisher is automatically derived from the vpls instance creation. While you explicitly set it on MikroTik.

ipi-1.lab.jan1.us.ipa.net# show mpls vpls TEST
Virtual Private LAN Service Instance: TEST, ID: 10
 SIG-Protocol: BGP
  Route-Distinguisher :65000:10
  Route-Target :65000:10
  VE-ID :10

The site-id (Tik) or VE-ID (OcNOS) are the vpls endpoint identifiers which uniquely identify each PE.

The final step before we can start to test is to setup the attachment circuit. On OcNOS we will have to setup a service template to pair with the vpls instance on attachment circuit. Then you can assign the vpls instance and the service template to a switchport. We will match vlan tag 10 on our service template. Anything coming in with dot1q 10 from the CCR2004 will enter the VPLS tunnel.

ipi-1.lab.jan1.us.ipa.net:

service-template TEST
 match outer-vlan 10
!
interface xe2
 switchport
 mpls-vpls TEST service-template TEST
  exit-if-vpls
!

On the MikroTik side we need to setup a bridge for the autocreation of the tunnels and assign appropriate interfaces to it. Again, we will match on dot1q 10.

MikroTik-1:

/interface bridge
add name=Lo0
add name=LoVOICE
add mtu=1500 name=VPLS-TEST protocol-mode=none

/interface bridge port
add bridge=VPLS-TEST interface=ether10 pvid=10

/interface bridge vlan
add bridge=VPLS-TEST tagged=VPLS-TEST untagged=vlan10,ether10 vlan-ids=10

Finally, we can do testing and verification. We want to look for the mesh peer which is the autodiscovered PE also in this vpls instance.

ipi-1.lab.jan1.us.ipa.net#show mpls vpls TEST
Virtual Private LAN Service Instance: TEST, ID: 10
 SIG-Protocol: BGP
  Route-Distinguisher :65000:10
  Route-Target :65000:10
  VE-ID :10
 Attachment-Circuit :UP
 Learning: Enabled
 Control-Word: Disabled
 Group ID: 0, Configured MTU: 1500
 Description: none
 service-tpid: dot1.q
 Operating mode: Raw
 Configured interfaces:
  Interface: xe2
 Service-template : TEST
  Match criteria : 10

 Mesh Peers:
   100.127.2.0 (Up)

Then we want to make sure we are learning mac-addresses. As you can see the MACs not learned from the attached device are learned from the BGP peer at 100.127.2.0.

ipi-1.lab.jan1.us.ipa.net#show mpls vpls mac-address
VPLS-ID     MAC address       Learned from   Vlan-Id          Peer address   Tim
e-out
10          027b.6866.7831    xe48           -                100.127.2.0    300

10          488f.5a00.4f87    xe2            10               -              300


10          4c5e.0c6f.4476    xe48           -                100.127.2.0    300

Next we can test reachability. I did have a strange issue where if the AC went down on the MikroTik-1 the mesh wouldn’t form on reattachment. This was resolvable with the following command on IPI-1: clear bgp 100.127.2.0 l2vpn vpls

This image has an empty alt attribute; its file name is IPA-Blog-ad-template-network.jpg
https://iparchitechs.com/contact

I’ll be doing more testing on interop here. Let us know in the comments what you’d like to see next.

Interop LDP and Segment Routing with IP infusion and MikroTik

Introduction

During networking field day service provider 1 there was a ton of talk about segment routing (SR) and ethernet virtual private networks (EVPN). One of the biggest questions was “how do we get there?” and while we won’t examine EVPN in this post (it’s coming in a future post don’t worry) we will look at how you can take advantage of SR while still having large portions of LDP in your network.

The team here at IP architechs works on a lot of MikroTik and whitebox gear so we’ll focus on a deployment using MikroTik and IP infusion.

MPLS and IGP setup

The first thing to accomplish is end to end reachability between the provider edge (PE) routers. MikroTik doesn’t support IS-IS so we will have to perform redistribution between the IS-IS segment and the OSPF segment as seen above.

MPLS only requires the /32s of the loopbacks for functionality so redistribution is limited to the /32 loopbacks of the PE routers.

ip prefix-list LDP-PE-LOOPBACKS
 seq 10 permit 100.127.2.0/24 eq 32
!
ip prefix-list SR-PE-LOOPBACKS
 seq 10 permit 100.127.0.0/24 eq 32
!
route-map REDIS-OSPF-TO-ISIS permit 10
 match ip address prefix-list LDP-PE-LOOPBACKS
!
route-map REDIS-ISIS-TO-OSPF permit 10
 match ip address prefix-list SR-PE-LOOPBACKS
!
router ospf 1
 ospf router-id 100.127.0.2
 redistribute isis IPv4-UNDERLAY route-map REDIS-ISIS-TO-OSPF
 network 100.126.2.0/29 area 0.0.0.0
!
router isis IPv4-UNDERLAY
 is-type level-1-2
 metric-style wide
 mpls traffic-eng router-id 100.127.0.2
 mpls traffic-eng level-1
 mpls traffic-eng level-2
 capability cspf
 dynamic-hostname
 fast-reroute ti-lfa level-1 proto ipv4
 fast-reroute ti-lfa level-2 proto ipv4
 net 49.0015.1001.2700.0002.00
 redistribute ospf level-1-2 route-map REDIS-OSPF-TO-ISIS
 isis segment-routing global block 16000 23999
 segment-routing mpls
ipi-1.lab.jan1.us.ipa.net#ping 100.127.2.0 source-ip 100.127.0.1
Press CTRL+C to exit
PING 100.127.2.0 (100.127.2.0) from 100.127.0.1 : 56(84) bytes of data.
64 bytes from 100.127.2.0: icmp_seq=1 ttl=63 time=0.332 ms
64 bytes from 100.127.2.0: icmp_seq=2 ttl=63 time=0.304 ms

Now that we have reachability between the loopbacks we can work on signaling for exchanging labels. Since MikroTik only runs LDP we will have to “stitch” the LDP and segment routing domains together. This is done with a segment routing – LDP mapping server.

This will assign labels to the routes in the LDP label space and distribute them to through the SR domain so we can have an end to end label switched path enabling the use of MPLS services.

segment-routing
 mapping-server
  srms preference 100
  prefix-sid-map address-family ipv4
   100.127.2.0/32 4000 range 256
  exit-ms-af
 exit-ms
!

This will start with prefix 100.127.2.0/32 add 4000 to the segment routing global block starting point (16000 as defined) and be able to label the next 256 routes in order. i.e. 100.127.2.1/32 gets the node sid 20001. IPI-2 shows the stitching in action.

ipi-2.lab.jan1.us.ipa.net#show mpls ilm-table
Codes: > - installed ILM, * - selected ILM, p - stale ILM
        K - CLI ILM, T - MPLS-TP, s - Stitched ILM
       S - SNMP, L - LDP, R - RSVP, C - CRLDP
       B - BGP , K - CLI , V - LDP_VC, I - IGP_SHORTCUT
       O - OSPF/OSPF6 SR, i - ISIS SR, k - SR CLI
       P - SR Policy, U - unknown

Code    FEC/VRF/L2CKT    ILM-ID      In-Label    Out-Label   In-Intf    Out-Intf
/VRF       Nexthop                   LSP-Type
   i>   100.127.0.2/32     1           16102       Nolabel     N/A        N/A
           127.0.0.1                 LSP_DEFAULT
   i>   100.127.0.1/32     2           16101       3           N/A        xe48
           100.126.0.1               LSP_DEFAULT
   B>   evpn:2             7           16          Nolabel     N/A        N/A
           127.0.0.1                 LSP_DEFAULT
   i>   100.126.0.1/32     4           24320       3           N/A        xe48
           100.126.0.1               LSP_DEFAULT
 s i>   100.127.2.0/32     8           20000       3           N/A        xe1.2
           100.126.2.2               LSP_DEFAULT
 s L>   100.127.0.1/32     3           25600       3           N/A        xe48
           100.126.0.1               LSP_DEFAULT
   i>   fe80::3e2c:99ff:fec2:2aa/128
                           5           24321       3           N/A        xe48
           fe80::3e2c:99ff:fec2:2aa  LSP_DEFAULT

And on IPI-1 we can see that this doesn’t appear “stitched” as it only runs IS-IS SR and not LDP as well as IS-IS SR. Tracing the label-switched path to 100.127.2.0/32 would take us via IPI-2 which does the stitching as seen above.

ipi-1.lab.jan1.us.ipa.net#show mpls ilm-table
Codes: > - installed ILM, * - selected ILM, p - stale ILM
        K - CLI ILM, T - MPLS-TP, s - Stitched ILM
       S - SNMP, L - LDP, R - RSVP, C - CRLDP
       B - BGP , K - CLI , V - LDP_VC, I - IGP_SHORTCUT
       O - OSPF/OSPF6 SR, i - ISIS SR, k - SR CLI
       P - SR Policy, U - unknown

Code    FEC/VRF/L2CKT    ILM-ID      In-Label    Out-Label   In-Intf    Out-Intf
/VRF       Nexthop                   LSP-Type
   i>   100.127.0.2/32     4           16102       3           N/A        xe48
           100.126.0.2               LSP_DEFAULT
   i>   100.127.0.1/32     1           16101       Nolabel     N/A        N/A
           127.0.0.1                 LSP_DEFAULT
   B>   evpn:100           5           16          Nolabel     N/A        N/A
           127.0.0.1                 LSP_DEFAULT
   i>   100.126.0.2/32     3           24320       3           N/A        xe48
           100.126.0.2               LSP_DEFAULT
   i>   100.127.2.0/32     6           20000       20000       N/A        xe48
           100.126.0.2               LSP_DEFAULT
   B>   VOICE              2           25024       Nolabel     N/A        VOICE
           N/A                       LSP_DEFAULT
   i>   fe80::3e2c:99ff:fec0:aa/128
                           7           24321       3           N/A        xe48
           fe80::3e2c:99ff:fec0:aa   LSP_DEFAULT

Here is what the label space looks like from the perspective of the MikroTik-1 as well.

[[email protected]] > mpls remote-bindings print                     
Flags: X - disabled, A - active, D - dynamic 
 #    DST-ADDRESS        NEXTHOP         LABEL         PEER                      
 0 AD 100.127.0.1/32     100.126.2.1     25600         100.127.0.2:0             
 1 AD 100.127.0.2/32     100.126.2.1     impl-null     100.127.0.2:0             
 2  D 100.126.0.0/29                     impl-null     100.127.0.2:0             
 3  D 100.126.2.0/29                     impl-null     100.127.0.2:0 
This image has an empty alt attribute; its file name is IPA-Blog-ad-template-network.jpg
https://iparchitechs.com/contact


Delivering a service with an L3VPN

Now that there is an end to end label switched path a L3VPN is built between IPI-1 and MikroTik-1. A common service to put in a L3VPN is voice which is the name of the vrf above.

router bgp 65000
 neighbor 100.127.2.0 remote-as 65000
 neighbor 100.127.2.0 update-source lo
 !
 address-family vpnv4 unicast
 neighbor 100.127.2.0 activate
 exit-address-family
 !
 address-family ipv4 vrf VOICE
 redistribute connected
 exit-address-family
!
/routing bgp peer
add address-families=vpnv4 name=OCNOS1 nexthop-choice=force-self \
    remote-address=100.127.0.1 remote-as=65000 update-source=Lo0
ipi-1.lab.jan1.us.ipa.net# ping 192.168.2.1 vrf VOICE
Press CTRL+C to exit
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.577 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.287 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.278 ms

If it were not for the SR-LDP mapping server this functionality would not be possible. This can jumpstart your transition to segment routing.

Be sure to check back soon for more on segment routing and EVPN in the future. If you noticed there are already labels for EVPN in the ilm-table output.