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...

Split Horizon and Route Poisoning - Layer 3 Routing Loops

Most of the time, I always be a part of layer 2 routing loop discussion but never heard about the engineers talking about layer 3 routing loop problem. This is being experienced during my recent visit in some company where all engineers knows why to use Spanning Tree Protocol but none of them knew why to use split horizon and route poisoning.
In layer 3 networks, there might chance of routing loops and split horizon, hold down timers and route poisoning are the techniques which help to prevent the layer 3 routing loop. Below depicted Figure 1 is showing the converge network. Let’s assume in case of failure of 10.4.0.0 network, router C will forward the update to router B and router B will forward the update to router A and router C as well. By doing this the same kind of the update which is being generated by C is received and C might think that he is getting the information of 10.4.0.0 network from B but In fact, 10.4.0.0 network is directly attached to router C. This situation can arise in smaller networks too.

The first work around is the split horizon technique which says not to send the updates to the interfaces from it has been received. It looks like send update information (Number of interfaces – Receiving Interface Updates).
Next one is route poisoning, when the router detects link down, the attached router sends the update to its neighbors. But in this case, the receiving router can send back the received information to the same interface from where it received by setting the route metric to maximum. Definitely this is the violation of split horizon rule but it helps router to understand about that particular network is down or inaccessible which actually help the convergence of routing. Now 10.4.0.0 is poisoned route which is having the maximum metric assigned as the route is not reachable. When the neighbor send the route back to the originator, it becomes reverse poisoned.

What does route poisoning do?

1. Set the hop count to an unreachable state as soon as the failed network is detected
2. Route remains poisoned until the hold-down timer expires.
3. Hold timer depends on the routing protocol; Every protocol is having different hold-down timer.
4. Only uni direction traffic flow.
5. If the route is not back up during the hold down time period expires, that route is removed from the routing table and added in the garbage table.

The last one is Hold Down timers. What does hold-timers do?
1. A router receives an update from a neighbor indicating that a network that previously was accessible is now no longer accessible.

2. The receiving router marks that route possibly down and starts the hold-down timer.

3. If an update with a better metric for that network is received from any neighboring router during the hold-down period, the network is reinstated and the hold-down timer is removed.

4. If an update from any other neighbor is received during the hold-down period with the same or worse metric for that network, that update is ignored. Thus, more time is allowed for the information about the change to be propagated.

5. Routers still forward packets to destination networks that are marked as possibly down. This allows the router to overcome any issues associated with intermittent connectivity. If the destination network truly is unavailable and the packets are forwarded, black hole routing is created and lasts until the hold-down timer expires. (Very Important Point). This could be the reason, administrators look forward to reduce the hold-down timers to increase the convergence time. Definitely if the network is not stable these timers generates lot of messages.

As per section 2.2.2, RFC 1058 explicitly says that “Split horizon with poisoned reverse will prevent any routing loops that involve only two gateways. However, it is still possible to end up with patterns in which three gateways are engaged in mutual deception.” Definitely this could be the case of broadcast of multi-access networks.

Click Here To Read Rest Of The Post...

Aakash tablet retailing online

Datawind, the maker of the low cost tablet Aakash, has started selling the device online from today. Retailing at Rs. 2,500/-, it is currently the most reasonably priced tablet in the Indian market. What’s more, Datawind has made it extremely easy for users to get their hands on Aakash. The company promises to deliver the tablet to buyers within seven days and accepts cash on delivery. That way, users don’t have to pay online when they book the tablet on www.aakashtablet.com.

Aakash is powered by an Arm 11 – 366 MHz microprocessor and runs on Android’s 2.2 Froyo operating system. A 2100 mAh battery supports the tablet. Aakash weighs 350g and measures 7’’. It offers 256MB of RAM and has a resistive touch screen with a resolution of 800 x 480p. Its 2GB Flash internal storage is expandable externally up to 32GB. Connectivity wise, Aakash works on Wi-Fi networks. The tablet is perfect for those who desire everything a basic model offers but don’t want to spend too much on it.

For those looking for a slight more spruced up version of Aakash, there is the Ubislate 7. Manufactured by Datawind, this is Aakash’s big brother. Ubislate 7 will be available in January 2012 and will be powered by a Cortex A8 – 700MHz processor and a 3200 mAh battery. It will run on Android’s 2.3 operating system. Besides Wi-Fi, Ubislate will also work on GPRS networks. The best part about this tablet is that it is reasonably priced. Just slightly more expensive than Aakash, it will retail at Rs. 2999/-. 

Both these tablets by Datawind guarantee that very soon, technology will be within every Indian’s reach. In fact, when Aakash was launched, Telecom and Education Minister Kapil Sibal had promised, “The rich have access to the digital world, the poor and ordinary have been excluded.

Specifications:
Display: 7” colour LCD/TFT
Keyboard: Built in
RAM: 2GB
Hard Drive: 32GB
Connectivity: Wifi, USB 2.0 (2), Ethernet port.
Operating System: Android
Power: 2 watt
Processor: Unknown
Expandable Memory upto 8GB (SD Card)
VGA Port (For connecting to Projector)

Features:
Open Office
SciLab
Internet browsing
Video web conferencing facility,
Multimedia content in a variety of formats (pdf, docx, ods, adp, xls, jpeg, gif,png, bmp, odt, zip, AVCHD, AVI, AC3)
Inbuilt PDF reader
Internet browsing with flash plug-in, JavaScript.
It is enabled with a touch screen.
An in-built keyboard is attached with this laptop.
The laptop can store the data of up to 2 GB memory. It is a RAM memory.
Wifi connectivity and USB port are this laptop’s additional features.
2 watt system is used up by this laptop so that it can even perform in areas where power supply is low.
80% shock resistant
Source

Click Here To Read Rest Of The Post...

Difference Between MPLS and MPLS-TP

RFC 5654 is all about requirements of MPLS-TP. But what is the difference between MPLS and MPLS-TP and how operators can use MPLS-TP in lieu of legacy SDH/SONET networks.
1. MPLS requires a control plane protocol and but in case of MPLS-TP no control plane protocol is required. The reason for selecting no control plane protocol is only for the fast convergence and removing any kind of dependencies.
2. MPLS is uni directional where as MPLS-TP is bi-directional.
3. MPLS is having inband OAM where as in MPLS-TP out of band OAM is available.
4. No separation of control and data plane where as in MPLS-TP MUST support the logical separation of the control and management planes from the data plane
5. MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching ime within 50 ms from the moment of fault detection in a network with a 16-node ring with less than 1200 km of fiber but in MPLS all dependent of IGP.

Click Here To Read Rest Of The Post...