Tuesday, May 14, 2013

Getting to know MPLS


By Jeremy Stretch

I've been reasonably familiar with MPLS ever since studying for the CCNP ISCW exam, but haven't bothered to lab it out until today. I set up a modest lab containing two each of CE, PE, and P routers, with an IS-IS core, IBGP between the PEs and EBGP to the CEs.
mpls_lab.png
My goal wasn't to become more familiar with MPLS itself, but rather to examine what benefits (if any) it provides to vanilla routing. Obviously MPLS is popular for its ability to implement VPNs and for traffic engineering, but implementing MPLS for plain IP routing alone seemed unnecessary. Why add labels when prefix-based packet switching works just fine?
Take another look at the lab topology. Notice that although IS-IS is running on all P and PE routers, IBGP is only running between the two PE routers. Traffic between the BGP routers must traverse a non-BGP router. This presents a problem: the P routers (which ultimately provide transit between the CE routers) have no knowledge of the customer routes (192.168.*.0/24).
P1# show ip route
...
 10.0.0.0/30 is subnetted, 6 subnets
i L2    10.0.0.8 [115/20] via 10.0.0.1, FastEthernet0/0
i L2    10.0.0.12 [115/20] via 10.0.0.5, FastEthernet0/1
i L2    10.0.2.0 [115/20] via 10.0.0.5, FastEthernet0/1
C       10.0.0.0 is directly connected, FastEthernet0/0
i L2    10.0.1.0 [115/20] via 10.0.0.1, FastEthernet0/0
C       10.0.0.4 is directly connected, FastEthernet0/1
Although disabling synchronization and using next-hop-self allows the IBGP routers to successfully peer and exchange customer routes, the P routers will not know how to forward packets destined for a customer network. Even after verifying full route convergence, a ping from 192.168.10.1 on CE1 to 192.168.40.1 on CE2 fails.
CE1# ping 192.168.40.1 source 192.168.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.40.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1 
.....
Success rate is 0 percent (0/5)
To remedy this situation, we could redistribute customer routes into our IGP, but that's messy. Another option is to include the P routers in BGP, but that might not be workable. Alternatively, we can implement MPLS to provide a wrapper for the IP traffic.
MPLS assigns labels to forwarding equivalence classes (FECs) based on IP prefixes, and attaches one or more tangible labels to each packet. This gives the P routers an alternate destination address to work with, eliminating the need to maintain IP routes for destinations outside the MPLS domain. This point should become clearer after an example.
Configuring MPLS is simply a matter of choosing a distribution protocol (Label Distribution Protocol (LDP) in modern configurations) and designating MPLS interfaces:
PE1(config)# mpls label protocol ldp
PE1(config)# int <interface>
PE1(config-if)# mpls ip
After MPLS has been enabled on all P and PE routers, labels will be dynamically assigned for all internal (10...*) prefixes. The LFIB entries can be examined on MPLS routers with show mpls forwarding-table:
P1# show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     10.0.0.8/30       0          Fa0/0      10.0.0.1     
17     Pop tag     10.0.0.12/30      0          Fa0/1      10.0.0.5     
18     Pop tag     10.0.2.0/30       9452       Fa0/1      10.0.0.5     
19     Pop tag     10.0.1.0/30       0          Fa0/0      10.0.0.1     
After deploying MPLS, we can try the ping from CE1 to CE2 again. Here's a rundown of the process from end to end:
  1. PE1 receives the packet and performs a CEF lookup for 192.168.40.1. The route (learned via IBGP) indicates 10.0.2.1 as the next hop. CEF also indicates an MPLS label should be added, since the outbound interface is MPLS enabled.
  2. PE1 inserts an MPLS header with the appropriate label between the layer 2 and layer 3 headers of the packet and sends it toward the next hop.
  3. Depending on the load balancing in use, the next hop will be either P1 or P2; for demonstration purposes we'll assume P1 is chosen.
  4. P1 receives the packet and performs a lookup on the label instead of the destination IP address. As the P routers have labels for all IGP-learned routes, P1 is able to make an intelligent decision on how to forward the packet.
  5. P1 consults its LFIB and determines that the label should be popped because the next hop is the end of the label-switched path (LSP); this is known as penultimate hop popping (PHP). If there were additional hops in the LSP, the label would instead be swapped for another.
  6. PE2 receives the unlabeled packet and normal IP routing occurs to route the packet to CE2.
To recap, MPLS enables P routers to bear transit traffic between IBGP peers not directly connected. Instead of relying on the destination IP address to determine a next hop, an intermediate label is used within the MPLS domain to designate a label-switched path (LSP) between the IBGP peers.

Sunday, February 10, 2013

GNS3: Add Qemu Host (MicroCore)

This write-up will explain Qemu Image use in GNS3 . Qemu Host image can be either CLI ( Microcore ) or GUI (Tinycore).Its basically a small linux image which can be used for performing some basic connectivity tasks e.g telnet, ssh, iptables, route, tcpdump and IPv6 support.
This tutorial will walk you through step by step for setting up Qemu Host image in GNS3
MicroCore Setup Instructions:


1.Set Qemu Host in GNS3 Preferences.
Edit -> Preferences -> Qemu -> Qemu Host
Set Qemu Host in GNS3 Preferences.
2.Setup Network Topology
Setup Network Topology
3. Start & Configure R1 for Basic Connectivity (IP address etc.)
Start & Configure R1 for Basic Connectivity
4. Start & Configure Qemu Host for Basic Connectivity (IP address etc.)
Start & Configure Qemu Host for Basic Connectivity
5. Test Connectivity between R1 & Qemu1
Test Connectivity between R1 & Qemu1
6. Enable R1 for telnet & ssh connections:
Enable R1 for telnet & ssh connections
7. Remotely manage Router from Qemu Host :
Remotely manage Router from Qemu Host
8. Add Default Route / Gateway to  Qemu Host :
Add Default Route / Gateway to  Qemu Hos
9. Use Qemu Host built-in tools e.g tcpdump & iptables for advanced testing:
tcpdump
Use Qemu Host built-in tools e.g tcpdump & iptables for advanced testing
IPtables
10. Finally , save all your configs  :
Save Qemu Configs
In order to make your configuration changes persistent so that they get automatically loaded upon reboot, use following commands:
vi /opt/bootlocal.sh
Add your configuration line by line & save the file (:wq!)
hostname Qemu1
ifconfig eth0 192.1.12.2 netmask 255.255.255.0 up
route add default gw 192.1.12.1
iptables -A INPUT -p tcp –dport telnet -j ACCEPT
iptables -A INPUT -j DROP
/usr/bin/filetool.sh backup
That’s all !
Software Version Used:
  • GNS3 Version : v 0.7.3
  • Microcore Version : 2.11.5
  • Tinycore Version : 2.11.5
  • IOS Image : c3745-adventerprisek9-mz.124-15.T13.bin
->For help using IPtables , refer to this guide
->Download Qemu Microcore / Tinycore Linux binary images from the following link: http://www.gns3.net/download