Continuing L2 across L3 topic started with post about L2TP.

Another easy-to-setup way to interconnect two Ethernet segments across Layer 3 network is EoMPLS, a particular case of AToM.

The diagram I used for my tests and the initial configuration are the same as in my previous post on L2TP.

 

R2	R3
interface FastEthernet0/0   description -= WAN =-   ip address 115.0.0.2 255.255.255.252 ip route 0.0.0.0 0.0.0.0 115.0.0.1	interface FastEthernet0/0  description -= WAN =-  ip address 116.0.0.2 255.255.255.252 ip route 0.0.0.0 0.0.0.0 116.0.0.1

To set up EoMPLS you need to have MPLS-enabled transport network in between the border routers. But if you don’t have this option, such as in case of interconnecting LAN segments across the internet you can just use GRE to make border routers look directly connected to each other across the tunnel. All the configurations are made for common Cisco IOS (not XE or XR).

Setting up GRE

GRE Tunnel uses outside physical interfaces IP addresses as source and destination:

R2	R3
interface Tunnel0  ip address 1.1.1.1 255.255.255.252  keepalive 1 3  tunnel source 115.0.0.2  tunnel destination 116.0.0.2	interface Tunnel0  ip address 1.1.1.2 255.255.255.252  keepalive 1 3  tunnel source 116.0.0.2  tunnel destination 115.0.0.2

Tunnel is up:

R3#sh ip int brief | inc Tunnel0 Tunnel0 1.1.1.2 YES manual up up

And we have R2 and R3 “directly connected”.

Setting up LDP

First, I have set up Loopback interfaces on both border routers:

R2

interface Loopback0  ip address 2.2.2.2 255.255.255.255

R3

interface Loopback0  ip address 3.3.3.3 255.255.255.255

To have connectivity between Loopback interfaces  I have set up OSPF (one might use static routing as well):

R2

interface Tunnel0  ip ospf 100 area 0 interface Loopback0  ip ospf 100 area 0

R3

interface Tunnel0  ip ospf 100 area 0 interface Loopback0  ip ospf 100 area 0

So now both Loopback interfaces see each other:

R2#sh ip route ospf Gateway of last resort is 115.0.0.1 to network 0.0.0.0 3.0.0.0/32 is subnetted, 1 subnets O 3.3.3.3 [110/1001] via 1.1.1.2, 00:01:48, Tunnel0 R3#sh ip route ospf 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1001] via 1.1.1.1, 00:01:20, Tunnel0 R3#ping 2.2.2.2 source 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 3.3.3.3 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 212/222/228 ms

Enforce the LDP router-ID on both routers:

R2

mpls ldp router-id loop0 force

R3

mpls ldp router-id loop0 force

Enable label exchange over GRE Tunnel:

R2

int tunnel0 mpls ip

R3

int tunnel0 mpls ip

Now the LDP neighborship is established:

R2#sh mpls ldp neighbor Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0 TCP connection: 3.3.3.3.64467 - 2.2.2.2.646 State: Oper; Msgs sent/rcvd: 8/8; Downstream Up time: 00:00:12 LDP discovery sources: Tunnel0, Src IP addr: 1.1.1.2 Addresses bound to peer LDP Ident: 116.0.0.2 3.3.3.3 1.1.1.2R2#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 3.3.3.3/32 0 Tu0 point2point

 

R3#sh mpls ldp nei Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0 TCP connection: 2.2.2.2.646 - 3.3.3.3.64467 State: Oper; Msgs sent/rcvd: 8/8; Downstream Up time: 00:00:32 LDP discovery sources: Tunnel0, Src IP addr: 1.1.1.1 Addresses bound to peer LDP Ident: 115.0.0.2 2.2.2.2 1.1.1.1R3#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 2.2.2.2/32 0 Tu0 point2point

We see some label (16) in show mpls forwarding-table command output, but it’s not the the label that will be used for tunneling traffic.  There will be a few words later in this post about MPLS labels use with EoMPLS.

Now we have the following:

Setting up the EoMPLS Interconnection

Similarly to L2TPv3 we now configure the interconnection (Virtual Circuit) using xconnect.

R2

interface fastethernet2/0 xconnect 3.3.3.3 2222 encapsulation mpls

R3

interface fastethernet2/0 xconnect 2.2.2.2 2222 encapsulation mpls

Verifying

Trying ping between hosts:

R4#ping 192.168.1.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 120/143/224 ms R5#ping 192.168.1.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/134/208 ms

And to the broadcast address:

R5#ping 255.255.255.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds: Reply to request 0 from 192.168.1.4, 152 ms Reply to request 1 from 192.168.1.4, 188 ms Reply to request 2 from 192.168.1.4, 180 ms Reply to request 3 from 192.168.1.4, 172 ms

Checking that the Virtual Circuit is established:

R2#show mpls l2transport vc detail Local interface: Fa2/0 up, line protocol up, Ethernet up Destination address: 3.3.3.3, VC ID: 2222, VC status: up Output interface: Tu0, imposed label stack {17} Preferred path: not configured Default path: active Next hop: point2point Create time: 03:38:36, last status change time: 01:26:33 Signaling protocol: LDP, peer 3.3.3.3:0 up Targeted Hello: 2.2.2.2(LDP Id) -> 3.3.3.3 Status TLV support (local/remote)   : enabled/supported Label/status state machine        : established, LruRru Last local dataplane   status rcvd: no fault Last local SSS circuit status rcvd: no fault Last local SSS circuit status sent: no fault Last local  LDP TLV    status sent: no fault Last remote LDP TLV    status rcvd: no fault MPLS VC labels: local 17, remote 17 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: -= LAN =- Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 1382, send 1394 byte totals:   receive 140659, send 185950 packet drops:  receive 0, seq error 0, send 3

R3#show mpls l2transport vc detail Local interface: Fa2/0 up, line protocol up, Ethernet up   Destination address: 2.2.2.2, VC ID: 2222, VC status: up     Output interface: Tu0, imposed label stack {17}     Preferred path: not configured     Default path: active     Next hop: point2point   Create time: 03:36:10, last status change time: 01:24:29   Signaling protocol: LDP, peer 2.2.2.2:0 up     Targeted Hello: 3.3.3.3(LDP Id) -> 2.2.2.2     Status TLV support (local/remote)   : enabled/supported       Label/status state machine        : established, LruRru       Last local dataplane   status rcvd: no fault       Last local SSS circuit status rcvd: no fault       Last local SSS circuit status sent: no fault       Last local  LDP TLV    status sent: no fault       Last remote LDP TLV    status rcvd: no fault     MPLS VC labels: local 17, remote 17     Group ID: local 0, remote 0     MTU: local 1500, remote 1500     Remote interface description: -= LAN =-   Sequencing: receive disabled, send disabled   VC statistics:     packet totals: receive 1374, send 658     byte totals:   receive 139272, send 88278     packet drops:  receive 0, seq error 0, send 1

In both commands output above we see Virtual Circuit ID that we have configured (2222), it’s status (Up), and the tunnel label (17). This is an actual label used in traffic “encapsulation/decapsulation”. The encapsulation itself consists in appending the label to the packet sent across the tunnel.

Looking at the ping capture between R4 and R5 we can see how the packet is formed:

Both captures show ICMP packet inside the Ethernet frame. Above that comes the Label 17 which we saw in show mpls l2transport vc detail command output. This is so-called VC Label that actually identifies Layer 2 interconnection. Above that comes GRE header and then IPv4 header used to deliver packet from one border router to another. This configuration theoretically can be used to establish EoMPLS interconnection across any sort of Layer 3 WAN, i.e. to perform the same task as L2TPv3 usually does.

Here are the final configurations for both routers:

R2

mpls ldp router-id Loopback0 force ! interface FastEthernet0/0   description -= WAN =-   ip address 115.0.0.2 255.255.255.252 ! interface Loopback0  ip address 2.2.2.2 255.255.255.25 ! interface Tunnel0  ip address 1.1.1.1 255.255.255.252  keepalive 1 3  tunnel source 115.0.0.2  tunnel destination 116.0.0.2  ip ospf 100 area 0  mpls ip ! interface Loopback0  ip ospf 100 area 0 ! interface fastethernet2/0  xconnect 3.3.3.3 2222 encapsulation mpls ! ip route 0.0.0.0 0.0.0.0 115.0.0.1

R3

mpls ldp router-id Loopback0 force ! interface FastEthernet0/0  description -= WAN =-  ip address 116.0.0.2 255.255.255.252 ! interface Loopback0  ip address 3.3.3.3 255.255.255.255 ! interface Tunnel0  ip address 1.1.1.2 255.255.255.252  keepalive 1 3  tunnel source 116.0.0.2  tunnel destination 115.0.0.2 ! interface fastethernet2/0  xconnect 2.2.2.2 2222 encapsulation mpls  ip ospf 100 area 0  mpls ip ! interface Loopback0  ip ospf 100 area 0 ! ip route 0.0.0.0 0.0.0.0 116.0.0.1

The general case

The more general use case for EoMPLS is when a service provider uses it to give Layer 2 interconnectivity to its customer. The EoMPLS VC starts at one PE router, crosses the MPLS-enabled service provider network (a number of P routers) and gets terminated at another PE router. In this case instead of GRE the MPLS transport is used. The series of labels gets attached and popped from the packet above the VC label. The network diagram I used to emulate this looks the following:

This is how ICMP echo request from R5 to R6 (192.168.1.5 to 192.168.1.6) travels across the MPLS WAN:

R1 → R2

R2 → R3

R3 → R4

The packet carries two labels: the inner one identifies the VC as in previous case and the outer one is used to transport packet across the MPLS network. The outer label gets discarded on R3, because of penultimate-hop-popping so we don’t see it on R3 → R4 segment.

The outer label can easily change on the way, because it is local for each MPLS router interface. The captures above just show the case where both R1 and R2 got the same label (23) assigned for packets that are being forwarded towards 4.4.4.4/32 prefix. However it’s not always the case. Here is an example with echo reply packet going back from R6 to R5:

R4 → R3

R3 → R2

R2 → R1

Outer label gets switched from 18 to 16 and then discarded on R2. The inner label stays the same.

Here is a diagram showing the packet flow for echo-request and echo-reply: