Ethernet VPN - Layer 2 Scalability

Introduction
MPLS (Multi-Protocol Label Switching) is matured technology & has widely been opted by most of the service providers across the globe. Initially it has been deployed for fast switching but due to its scalability, resiliency & protocol agnostic nature made it more successful across the network. MPLS not only provides the wan connectivity but also acts as a platform for service providers to offer different kind of services which can further be used for monetization purpose. VPLS (Virtual Private LAN Services) is one of the service offering in MPLS which helps to provide the extension of broadcast domain from one to multiple sites over the wan. VPLS became more popular after the outburst of data center interconnects. The utmost reason for the extension of layer 2 domains is workload mobility (Migration of Virtual machines from one data center to another), high availability clusters, and geographical redundancy.
Current Challenges with VPLS
1. Scaling of thousands of MAC addresses (Single VM requires single mac address):- Virtualization applications are fueling the need of the mac-address in the network. A single server which can host hundreds of virtual machines and every machine consume one mac address which clearly justifies the scaling requirement of mac-address tables.

2. Optimal forwarding of multicast:- Multicast LSP can be formed in conjunction with VPLS but limited to point to multipoint which consumes more network resources as there is no defined set of parameters in VPLS to create multipoint to multipoint multicast LSPs.

3. MultiHoming:- VPLS supports Active/standby BGP multi homing model. MultiHoming with all active attached circuits is not possible. In contract, customer can utilize only 50% of the links in lieu of 100% payment.

4. C-Mac (Customer Mac) Transparency:- Current VPLS solution doesn’t support the transparency of customer mac address.

5. Fast Convergence for C-Mac Flushing:- In case of failure of virtual machines or physical servers, network re-convergence will occur which may lead to the mac flushing problems.

Proposed Solution
Ethernet Virtual Private Network (E-VPN) is the proposed solution to overcome the issues highlighted by VPLS. E-VPN uses the existing MPLS/IP backbone to transport the layer 2 connectivity among the various data centers which are part of same VPN. Being layer-2 extension, the solution treats the mac addresses as routable addresses and uses the existing MP-iBGP protocol to carry the customer mac addresses. In E-VPN, mac learning at the edge routers doesn’t occur in data plane but in the control plane consequences more control could be applied in terms of the learning mechanism. The process is similar to the IPVPN as mentioned in RFC 4364. The policy attributes specified in E-VPN are almost similar in MPLS VPN. RD and RT remains the same, but instead of virtual routing forwarding instance we have now Ethernet VPN Instance. The information about Ethernet TAG of EVI is advertised by the new BGP NLRI which is E-VPN.

Figure 1
In EVPN, the mac learning could be of two types:- 1. Local Mac Learning 2. Remote Mac Learning In local mac learning process, MPLS Edge Switch (MES) must support the local mac learning process through standard protocols. Once the local learning process gets complete, MES can advertise the locally learn mac address to remote MES nodes via MP-iBGP. This process of receiving the remote mac addresses of attached customer via MP-iBGP is known as remote mac learning process.
Solution for MultiHoming and Avoiding Layer 2 Loops in EVPN
Ethernet Segment ID (ESI) is used when Customer Edge device is multi homed to different MPLS Edge Switches as shown in Figure 2. It has new MPLS BGP Label Extended community which is used for split horizon procedures in multi homing scenarios. As depicted in figure 2, host H1 has mac address of M1. It sends the broadcast request to MES-1 and MES2. MES-1 and MES-2 identified that the request is coming from Extended Segment ID-1, so before replicating the frames both MESs will append a split horizon label on the frames. Once it will be done, frames get exchanged among the MESs. All MESs check the SH label and if found the same ESI-1 is directly attached, the traffic is silently dropped because a frame originated by a segment must not be received by the same segment. This technique helps to avoid loops in multi homing scenarios.

Figure 2
Note:- Split horizon label is only used for unknown unicast, multicast and broadcast
Role of Designated Forwarder
As per figure 2, MES-3 and MES-4 will receive the multi destination frames via MP-iBGP for particular segment. How will it be decided which MES has to forward the frames to downstream segment? Only Designated Forwarder will forward the frames to particular segment and Designated forwarder election is performed by each PE advertising the ESI in BGP route. All the non-Designated Forwarder MES will block their respective port for that segment as shown in Figure 3.

Figure 3
Load Balancing
As per figure 3, MES-3 & MES-4 is receiving the update of host H1 with Mac M1 from MES-1 and MES-2 with Ethernet segment of ESI-1. So MES-3 and MES-4 install the two routes in the Forwarding Information Base. Once the traffic of M1 destination is received both the routers will do the load balancing during forwarding. The core will forward the traffic on the basics of next hop information for M1 which is MES-1 and MES-2.
Scaling by using Provider Backbone Bridge (PBB)
The EVPN scalability is achieved by using the existing technique of Provider Backbone Bridge aka PBB. Below are the advantages while using PBB in EVPN:-
1. Subnetting of C-MAC addresses is not possible. But by using PBB, B-MAC addresses can be subnetted easily which leads to mac address scalability.

2. In case of shifting of VM or local customer networks from one DC to another requires lot of mac flushing. But by using B-MAC that C-MAC flushing will become transparent which leads to fast convergence.

3. Per Site Policy Support by using B-MAC

4. Device MultiHoming

5. Network MultiHoming

6. C-MAC addresses need to be distributed in BGP but by using PBB-EVPN C-MAC advertisement could be limited by assigning multiple C-MAC addresses to single B-MAC address.

References
EVPN requirement
BGP/MPLS IP VPN
PBB-EVPN
VPLS
EVPN
Download Full Document
Click Here To Read Rest Of The Post...

Implementation of EoMPLS (Ethernet Over MPLS)

Introduction
Layer 2 vpn is being used by many of service providers. It can be configure in two ways, one way to use l2 vpn over ip cloud with the help of l2tpv3 and another way is to use over mpls backbone by using encapsulation mpls. In this simulation I will be covering how to configure l2 mpls vpn over mplsvpn cloud.

Figure 1

R0-CE and R4-CE is looking for l2 vpn so that the communication is possible between the both as
they are on same local area network.

How Layer2 MPLS Works
Service provider should use the mpls in the whole cloud to provision l2mpls vpn. The forwarding will be the same as it happens in the case of layer 3 vpn, the only difference is that in that case the customer pool is advertised via MP-iBGP which works as full mesh but in this scenario only point to point will work. If the customer is looking for point to multipoint in that case VPLS (Virtual Private Lan Services) need to be configured which requires minimum of 7600 series router with sip and spa card. In this scenario customer link is terminated on PE router and with the help of xconnect l2 vpn is configured. For every layer2 a unique vc (virtual circuit) is required and the label is generated for that vc only. In our example we are using 100 as vcid, which should be unique on both PEs. When ever the l2 session comes up a new ldp session is being established between the both PEs and the connection is virtually treated as directly connected connection. In simple ldp neighbourship, only directly connected peers can establish the LDP neighbourship but in l2 circuits we get the LDP neighbourship which are not directly connected.

The discovery mechanism is used by the directly connected LDP peers is known to basic discovery
and by l2 circuits is known as extended discovery. Both the peers exchange the targeted hello
messages with each other. TCP session is established by the peers but hellos are exchanged as udp packets over multicast address 224.0.0.2.

Session is always established on loopback address with the remote router and that loopback should be the ldp router id else it won’t work. (Never Perform Loopback Summarization in MPLS)

How The Labels Will Exchange
When the circuit comes up a local label is generated on the basics of vc id and is
exchanged with the remote end router and vice versa.

How The Forwarding Will Work
Labels are already exchanged in the service provider cloud for loopbacks. It means every router is having label information for reaching any other router in the cloud. That label will work as top label which is going to swap at each and every hop underneath that label a vc label is stored which will only come in picture when the packet will reach to its destination PE and that PE has the information of that label against that vc id consequence ip packet will forward towards the customer end.

In figure 1, label 17 is used for IGP and label 19 is used for vc 100. When the packet comes from R0-CE label 19 is imposed on packet against vc 100 and on that one more label is imposed which is 17. In the path only label 17 will be swapped. As in figure1, When label 17 is imposed and forwards to the outgoing interface which is connected to R2-P router. On R2-P router LFIB is checked for label 17 and the outgoing label is showing as pop label because R3-PE is advertising its directly connected interface as implicit null. So at R2-P the top most label is removed and packet is forwarded towards R3-PE with label 19. When the packet reached R3-PE label 19 is checked in local database and come to know that it is being generated for vc 100 consequence ip packet delivered to R4-CE.

How To Check The Status Of Circuit
R1#show mpls l2transport summary
Destination address: 30.30.30.30, total number of vc: 1
0 unknown, 1 up, 0 down, 0 admin down, 0 recovering
1 active vc on MPLS interface Fa0/0
Output 1

How To Check The Neighbourship
R1#show mpls ldp neighbor
Peer LDP Ident: 20.20.20.20:0; Local LDP Ident 10.10.10.10:0
TCP connection: 20.20.20.20.20465 - 10.10.10.10.646
State: Oper; Msgs sent/rcvd: 20/21; Downstream
Up time: 00:11:05
LDP discovery sources:
FastEthernet0/0, Src IP addr: 1.1.1.2
Addresses bound to peer LDP Ident:
1.1.1.2 20.20.20.20 2.2.2.2
Peer LDP Ident: 30.30.30.30:0; Local LDP Ident 10.10.10.10:0
TCP connection: 30.30.30.30.31666 - 10.10.10.10.646
State: Oper; Msgs sent/rcvd: 19/19; Downstream
Up time: 00:09:08
LDP discovery sources:
Targeted Hello 10.10.10.10 -> 30.30.30.30, active, passive
Addresses bound to peer LDP Ident:
2.2.2.1 30.30.30.30
Output 2

How to Check The Label Generated And Received
R1#sh mpls l2transport binding
Destination Address: 30.30.30.30, VC ID: 100
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
Output 3

Output 2 depicts that l2 session is established with peer 30.30.30.30 against VCID 100.
For this particular VCID local label 19 is generated and the 19 is receiving from the
30.30.30.30 peer. The label can be different also. The local label of R1-PE will become
the remote label on R3-PE. Below command depicts the same

R3#show mpls l2transport binding
Destination Address: 10.10.10.10, VC ID: 100
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Output 4

The output of Output 3 and 4 depicts that the label exchange information is going correct.
The same command can be used for troubleshooting also.

How To Check The MPLS Forwarding
R1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 20.20.20.20/32 0 Fa0/0 1.1.1.2
17 Pop tag 2.2.2.0/30 0 Fa0/0 1.1.1.2
18 17 30.30.30.30/32 0 Fa0/0 1.1.1.2
19 l2ckt(100) 9067 none point2point
Output 5

From Output 5 it is cleared that 17 label is used as outgoing label 19 label is used for vcid 100 which is point to point connection. Now check the output of MPLS forwarding on R2-P router where 17 should be the local label and pop label is used as outgoing label.

R2#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.10.10.10/32 0 Fa0/0 1.1.1.1
17 Pop Tag 30.30.30.30/32 4350 Fa0/1 2.2.2.1
Output 6

How To Check The Label Stack Which Is Depicted In Figure 1
R1#sh mpls l2transport vc 100 detail
Local interface: Fa0/1 up, line protocol up, Ethernet up
Destination address: 30.30.30.30, VC ID: 100, VC status: up
Next hop: 1.1.1.2
Output interface: Fa0/0, imposed label stack {17 19}
Create time: 00:06:10, last status change time: 00:05:37
Signaling protocol: LDP, peer 30.30.30.30:0 up
MPLS VC labels: local 19, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 70, send 70
byte totals: receive 7603, send 7603
packet drops: receive 0, seq error 0, send 0
Output 7

Check End To End Connectivity
R0#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 372/560/756 ms
Output 8

Configurations
R0-CE
interface FastEthernet0/1
Description ### Connected With Service Provider End ###
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto

R1-PE
mpls label protocol ldp
interface Loopback0
ip address 10.10.10.10 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
interface FastEthernet0/1
description ### CE Is Coming On This Interface ###
no ip address
duplex auto
speed auto
xconnect 30.30.30.30 100 encapsulation mpls
!
router ospf 1
log-adjacency-changes
mpls ldp router-id Loopback0 force

R2-P
mpls label protocol ldp
interface Loopback0
ip address 20.20.20.20 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
interface FastEthernet0/1
ip address 2.2.2.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
router ospf 1
!
mpls ldp router-id Loopback0 force


R3-PE
mpls label protocol ldp
interface Loopback0
ip address 30.30.30.30 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
xconnect 10.10.10.10 100 encapsulation mpls
!
interface FastEthernet0/1
ip address 2.2.2.1 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
router ospf 1
mpls ldp router-id Loopback0 force


R4-CE
interface FastEthernet0/0
Description ### Connected With Service Provider End ###
ip address 192.168.1.2 255.255.255.0
duplex auto
speed auto

Click Here To Read Rest Of The Post...

Types of PseudoWire

Pseudowire emulation aka PWE3 that emulates the attributes of service over packet switched network (PSN). Pseudo means no physical existence only virtual. By using pseudowire, service provider can emulate any circuit end to end. E.g. if customer is looking for TDM bandwidth end to end, but SP is having a packet core network but no TDM backhaul, in that case pseudowire help SP to deliver end to end circuit which uses packet core network and provide TDM drop to customers. This is the case where in both termination points are having same output but in case of different output like one side Ethernet and another side frame-relay or atm, the best is to provision inter network circuit.
Types of Pseudowire
1. CESoPSN:- Circuit Emulation over Packer Switched Network supports framed and channelized TDM services over packet switched network.
2. SAToP:- Structure Agnostic TDM over Packet, is a TDM Pseudowire technology which treats the TDM traffic as data traffic and ignore the framing bits. It supports unframed TDM services.

Advantages of SAToP:-
1. Flexible packet size.
2. Lowest end to end delay.
3. Low overhead.

Advantages of CESoPSN:-
1. Lower packetization delay.


Click Here To Read Rest Of The Post...

Modes Of Ethernet Over MPLS (EoMPLS)

Introduction
An Ethernet Pseudowire allows Ethernet packets to transport over MPLS cloud. By using this service customers simply extend their local area networks without loosing the information. The spanning tree will work and end to end connectivity will be on same subnet. Otherwords, we can say it a virtual leased circuit. Customer end to end connectivity is aka as Emulated Service which operates over Pseudowire which further operates over Packet Switched Network (MPLS Network). Entire end to end communication reference model is depicted below.

Figure 1

Modes Of Ethernet Pseudowire
An Ethernet Pseudowire operates in two modes: raw mode and tagged mode. In tagged mode, each frame must have 802.1q tag and that tag is meaningful to the local and end point router. It should be noted that if the VLAN identifier is modified by the egress PE, the Ethernet spanning tree protocol might fail to work properly. If this issue is of significance, the VLAN identifier MUST be selected in such a way that it matches on the attachment circuits at both ends of the PW. It means the identifier or vlan tag should be used same not different. This mode use Pseudowire type 0x0004. Every frame sent on the PW must have a service-delimiting VLAN tag (Different vlans for different customers). If the frame as received by the PE from the attachment circuit does not have a service-delimiting VLAN tag, the PE must prepend the frame with a dummy VLAN tag before sending the frame on the PW.


But in case of raw mode, tag may or may not be added in the frame and is not meaning to the end points. Though the frame is forwarded transparently. This service corresponds to PW type 0x0005. If an Ethernet PW is operating in raw mode, service-delimiting tags are NEVER sent over the PW. If a service-delimiting tag is present when the frame is received from the attachment circuit by the PE, it mUST be stripped from the frame before the frame is sent to the PW.

Why Customer Needs Extended Lan Services
1. In case of Data Center, customers having geographically seperated DC and want to replicate the storage over Fiber Channel IP aka FCIP. FCIP works only on same broadcast domain.
2. Need to run dynamic routing protocol between the sites.

Click Here To Read Rest Of The Post...

Fragmentation choke bandwidth

Link was working fine with ip traffic and getting the proper load. But as soon as the l2tpv3 traffic was added customer won't able to the add the more traffic on configured link. After deep analysis, we had seen the problem occured because of fragmentation issue which was being caused by l2tpv3 consequences router ip input was increasing drastically. The solution of the problem is either to set the path mtu or increase the mtu in the whole path.

Click Here To Read Rest Of The Post...

L2MPLS With Traffic Engineering

Service provider provision l2 circuits for the customers where customers need to extend the lan services to the remote offices. Provisioing of l2 circuits does in two ways; one over ip cloud and another is over mpls cloud. But sometimes customers wants to forward the jitter senstive traffic over the backbone and to fulfill the SLA service provider need to forward the l2 traffic over another path which is not best in IGP. For this traffic engineering plays a vital role with fallback mode. In the next post I will be posting how to configure MPLS TE for l2 circuits.

Click Here To Read Rest Of The Post...

L2TPv3 Not Coming Down

The team stuck up in imbroglio where the l2tpv3 tunnel never torn down even after shutting down of physical sub-interface. There after lot of test were made but all in vein. The problem came with the SB13 ios but the opposite side was using different vendor equipment. The problem states that when the interface was shut down, no stop ack was sent to the remote peer, it is same as keepalives used in gre tunnel to get it torn. Still we are not able to find exact RCA except the IOS bug.

Click Here To Read Rest Of The Post...

L2TPv3 Forces PIM Not Coming Up

The next time if you find that pim neighbourship is not coming up for a customer which is coming through l2tpv3 to MPLS enabled PE, might hit with the bug which is not listed in cisco bug tool kit. During the lab, we find the issue and look for the cisco site for bug but do not find any information. IOS used for l2tpv3 is entservices9 12.3(14)T5.The weird behavior which was seen is that PIM neighborship is coming up at CE end but not at PE end. If migrate the customer over GRE then it works fine because we were bypassing l2tpv3.

Click Here To Read Rest Of The Post...

Control Word In Pseudowire

Control word plays a vital role in AToM. It is 32 bit field which is inserted between VC label and transport layer in case of AToM. This is added by the ingress PE and removed by the egress PE.

Structure of control Word

Tunnel Lable/IGP Label
VC label
Control Word
Layer 2 Frame

regards
shivlu jain
Click Here To Read Rest Of The Post...

L2TPv3: Transport Header Overhead Used By Various Transport Types

In yesterday's post, I have explained how PMTU help to stop the reassembly of l2tpv3 packets over IP cloud consequence saves router CPU processes. In this post, I have transport header size with respect to the transport type which help to calculate the exact MTU size for CE.

MTU= 1500- (20 Bytes (IPv4 Header) + 4 Bytes (L2TPv3 Overhead) + 8 Bytes (Option Cookie Overhead) + Transport Header Size)


Transport Type Transport Header Size
Ethernet Port 14 Bytes
Ethernet Vlan 18 Bytes
HDLC 2 Bytes
PPP 4 Bytes
Frame Relay DLCI,CISCO 2 Bytes
Frame Relay DLCI,IETF 8 Bytes

E.g. If we want to calcute the overhead occured in case of Ethernet where dot1q is used. The calculation is given below

1500-(20+4+18) = 1462

1462 Bytes is the maximum MTU avail by CE. The same is depicted in previous post.


regards
shivlu jain
Click Here To Read Rest Of The Post...

MTU Problem In L2TPV3

Introduction
Layer 2 VPN is being used by many service providers. L2tpv3 is used to provide layer 2 services to the customer over IP/MPLS cloud. In this document, MTU issue has been simulated with its workaround.


How To Check The Status Of Circuit
R1#show l2tun session

L2TP Session Information Total tunnels 1 sessions 1

LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
50413 45422 23086 20, Fa0/0 est 00:00:46 4

R2#show l2tun session

L2TP Session Information Total tunnels 1 sessions 1

LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit
45423 50414 17633 20, Fa0/0 est 00:00:01 4

Check The Encapsulation Type
L2TP Session Information Total tunnels 1 sessions 1

Session id 20044 is up, tunnel id 59245
Remote session id is 50078, remote tunnel id 25237
Locally initiated session
Call serial number is 4048300002
Remote tunnel name is R2
Internet address is 20.20.20.20
Local tunnel name is R1
Internet address is 10.10.10.10
IP protocol 115
Session is L2TP signaled
Session state is established, time since change 00:00:10
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
UDP checksums are disabled
FS cached header information:
encap size = 24 bytes
45000014 00000000 FF737F3B 0A0A0A0A
14141414 0000C39E
1 Packets sent, 1 received
60 Bytes sent, 60 received

Encapsulation Type 24 means 20 bytes of IP Header and 4 Bytes of L2tpv3.

Initiate a Ping request of 1500 bytes with df-bit from R0 which is CPE. Before starting a ping check the two given outputs on R2 router.
R2#show interfaces fastEthernet 0/0 switching
FastEthernet0/0

Protocol Other
Switching path Pkts In Chars In Pkts Out Chars Out
Process 0 0 0 40878
Cache misses 0 - - -
Fast 170 52853 158 15680
Auton/SSE 0 0 0 0


R2#sh ip traffic | i fra
0 fragmented, 0 fragments, 0 couldn't fragment
Start the ping from R0 router
R0#ping 192.168.1.3 df-bit size 1500 repeat 10

Now check the outputs again
Show interfaces fa0/0 switching
Protocol Other
Switching path Pkts In Chars In Pkts Out Chars Out
Process 0 0 27 40878
Cache misses 0 - - -
Fast 197 52853 158 15680
Auton/SSE 0 0 0 0

R2#sh ip traffic | i fra
27 fragmented, 54 fragments, 0 couldn't fragment

Nice findings come here. You can R0 is sending packets with DF bit sent and when the packet comes at R1 interface it encapsulate the packet with l2tpv3 but the packet size becomes more than 1500 so the l2tpv3 packet fragments on R1 and sent over l2tpv3 to R2. At R2 again reassemble of fragment packet occurs which can be seen from the above output. Total 27 packets has been sent from R0 but due to fragmentation each packet is divided into two parts and reassemble at R2. This is reason we are getting 54 fragments which is double the sent packets. The main disadvantage of using this is that every time PE tail end router has to reassemble the packet consequence lot of CPU is required. From the “Show interfaces fa0/0 switching”, it is cleared that the packets received as fast switched and processed as process switch.

Solution Of The Problem
The problem can be overcome by using PMTU which is path MTU discovery. Now add ip pmtu command under pseudowire and initiate a ping request from R0 router.
R0#ping
Protocol [ip]:
Target IP address: 192.168.1.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: V
Loose, Strict, Record, Timestamp, Verbose[V]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1450
Sweep max size [18024]: 1470
Sweep interval [1]:
Type escape sequence to abort.
Sending 105, [1450..1470]-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
Packet sent with the DF bit set
Reply to request 0 (564 ms) (size 1450)
Reply to request 1 (564 ms) (size 1451)
Reply to request 2 (552 ms) (size 1452)
Reply to request 3 (564 ms) (size 1453)
Reply to request 4 (564 ms) (size 1454)
Reply to request 5 (344 ms) (size 1455)
Reply to request 6 (564 ms) (size 1455)
Reply to request 7 (392 ms) (size 1457)
Reply to request 8 (756 ms) (size 1458)
Reply to request 9 (708 ms) (size 1459)
Reply to request 10 (564 ms) (size 1460)
Reply to request 11 (320 ms) (size 1461)
Reply to request 0 (564 ms) (size 1462)
Unreachable from 192.168.1.3, maximum MTU 1462 (size 1463)
Request 13 timed out (size 1464)

From the above output the packets are being dropped after packet size 1462 and a message is appearing that maximum MTU is 1462.
How MTU becomes 1462? Here is the calculation for MTU
20 Bytes IP Header + 4 Bytes L2tpv3 + 14 Bytes Ethernet = 38 Bytes
1500 Bytes – 38 Bytes = 1462 Bytes
This is in case of Ethernet without dot1q, If dot1q is enabled then we need to add 4 bytes more in this consequence MTU will be reduced to 1458.

Click Here To Download Full Article


regards
shivlu jain
Click Here To Read Rest Of The Post...

Troubleshooting Layer 2 VPN

After long vacation, I continue with l2vpn series. In this post I would like to share about the disconnection of label switch path but xconnect session never terminates. The sesion establish because of ip reachability not of ldp. So if the ldp is broken anywhere in the path , it won't terminates the xconnect connection but the main problem is hpw to troubleshoot. The troubleshooting of the same is very easy with the help of ping mpls pseudosire . If the path is mpls enabled you would definately receive the ping acknowledgement else it will be dropped.

regards
shivlu jain
Click Here To Read Rest Of The Post...

Decrease The Label Database In Layer 2 MPLS

In my yesterday post I have covered how to provison a layer 2 mpls circuit. Today I am going to explain about implicit null label, a label which comes when the xconnect peer comes up. As per figure 1 check the mpls ldp binding table of PE-R1. A label for 30.30.30.30 will be coming with implicit null. Now the question arises why it is coming so? Answer is so simple because when the ldp between the xconnect peer up, both treat them as directly connected to each other and advertise the directly connected interface with implicit null the same as in the case of PHP happens. But the label is never ever used for forwarding because when the packet reaches on R1-PE and the destination is 30.30.30.30 for that it check the best IGP path and corresponding to that next hop is selected with outgoing label. So this implicit null will never be preferred in the case of layer 2 mpls vpn. These labels are only increasing the database and can be stopped by using acl.

step 1:- Create standard acl which will deny any thing
ip access-list 1 deny any

Step 2:- Bind the acl with the xconnect peer so that it won't accept any labels for IGP.
mpls ldp neighbor 30.30.30.30 labels accept 1

The same command need to be configured at remote end peer also.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Configuring Layer 2 MPLS VPN

Layer 2 vpn is being used by many of service providers. It can be configure in two ways, one way to use l2 vpn over ip cloud with the help of l2tpv3 and another way is to use over mpls backbone by using encapsulation mpls. In this document I will be covering how to configure l2 mpls vpn over service provider cloud.

Before moving ahead penultimate hop popping concept should be cleared.

Click here read the full story.


regards
shivlu jain
Click Here To Read Rest Of The Post...

L2VPN Over Metro Ethernet

In my previous post of http://shivlu.blogspot.com/2009/02/l2vpn-over-ipmpls.htmlL2VPN, I described the modes of L2VPN and its provisioning. In this post I am going to elaborate how to deploy point to point L2VPN over Metro Ethernet rings with Q-in-Q tagging. The deployment is very lucid and trouble-free. As per the diagram customer is terminated on ME switch with Q-in-Q functionality. The focal advantage of using Q-in-Q in Metro Ethernet circuits to make customer frames unique within L2 domain and preserves the customer vlans. The flow is given below:-
CPE will forward the frames to PE switch with vlan tagging, after receiving the frames PE switch will encapsulate a more vlan tag on the existing vlan tag (It is like label with in label of layer 3 vpn). There after a sub interface is created on router physical interface by taking the same vlan as sub interface and xconnect is created over Ethernet domain by taking remote PE loopback as destination. When the frame is received by remote PE it will tag the frame again by preserving the existing customer vlan and forward to the Metro Domain. Where ever the packet will get out form the access port the upper tag of service provider domain will be removed and customer will able to get the valn tag which was being originated.
Why this type connectivity is being asked by service provider? Really awesome question, every service provider don't want to loose the confidentiality of its esteemed customers and used to promise their customers that they are Omni. Whenever customer demands the circuit at some remote locations and SP is not feasible on that location at that time layer 2 vpn services comes mostly in picture. One SP asks the another SP to provide the layer 2 circuit which looks like to customer that the whole backbone is being used by their service provider.
Monitoring of L2 circuits are not possible.

regards

shivlu jain

Click Here To Read Rest Of The Post...

L2VPN Over IP/MPLS

Layer 2 circuits are becoming order of the day. Every service provider desires layer 2 circuits from the other service provider to provision its customers. It can be configured by two methods
a) Point to Point
b) Point To Multipoint
Currently ISR , 6500 and 7200 series supports point to point and 7600 supports point to multipoint. Point to multipoint is also known to VPLS (Virtual Private Lan Services). In this post I will explain about point to point circuit and its provisioning. Services offer on two type of cloud
a) IP Cloud
b) MPLS Cloud
If service provider is using IP cloud, L2 services offer by encapsulation l2tpv3 and if cloud is MPLS enabled then encapsulation mpls can be used. So the difference is lucid. In the given scenario customer is having l2 domain and want to use the l2 services across the service provider cloud. A simple l2 session will be created between Delhi PE and HYD PE over ip cloud on the basics of loopbacks. The provisioning is trouble-free and easy to configure.
Steps for Configuring Layer 2 Services across Service Provider IP Backbone
a) Configure basic IGP.
b) Create PSEUDOWIRE name SHIVLU & use the encapsulation L2TPv3 as source loopback of the router.
c) On Physical interface where the client is coming create a xconnect as destination address of loopback HYD PE & vice versa.
Commands For Creating L2 VPN
Pseudowire SHIVLU
Ip local interface loopback 0
Encapsulation l2tpv3

Interface Specific Command
Interface x/y
Xconnect 400 pw-class SHIVLU
Note:- 400 is the Virtual Circuit ID and it should be the same on the remote end also.

Verify L2 Circuit
After “Show l2 session circuit vcid 400” you can see the est state of l2 session. Now ping end to end laptop.

regards

shivlu jain

Click Here To Read Rest Of The Post...