We are proud to say, Mr. Khalid Raza is from Pakistan.

Meet the First Two Cisco Certified Architects Part 1

Meet the First Two Cisco Certified Architects Part 2

Meet the First Two Cisco Certified Architects Part 3

As a techie, i always wish to have my hands dig deep into every technology & vendors. In the current Service Provider & Enterprise market Juniper & Cisco are leading, but there are many other small/medium size vendors making their impacts and some are both reliable & cost effective, Maipu Communications is amongst the one of the emerging vendor of Switching, Routing & VoIP products.

As a Service Provider, what i always look for is to have a device that can do everything (thats why i rated Juniper as one of the Best). Although my wish is always not feasible to put the lots of service load on a single box, but its good not to go for another product for that special feature. We were working on Metro Ethernet Services and in start we evaluate Cisco ME solution having ME3400 & ME4500 products. We evaluate Cisco, base on our requirements and features that help us to offer scalable & manageable metro services in long term. But there come a-lot of features that support in one product but not in the other, some has power redundancy some not….so many factor comes in consideration.

From some resources we hear about Metro Ethernet Switches provider named Maipu. Initially we think, they will be same as Huawei i.e. Cheap but will cause alot of support related issue. Than on one day, Maipu offer us to test their products in our own facility. They offered us Maipu MP3400 (SM3400-8FET16FEF4GEF8E1-AC) for testing. This box is full of all sort of interfaces you can ever dream of in ME Switches. It has Eight 10/100M electric ports, 16 10/100M optical ports, eight E1/T1 interfaces supporting PWE3, four 1000M optical ports with the option of Dual Power supply support.

Features Highlight:

• Switching Capacity: 12.5Gbps to 56Gbps
• MEF9 & MEF14 Certifications
• Multi-service Ethernet switch with highest integrity
• Supports dual power supply
• Supports perfect OAM protocols (802.1ag, 802.3ah, E-LMI)
• Supports VPN services defined by MEF9
• 50ms Ethernet service protection
• Supports VLAN Translation
• Supports QinQ and selective QinQ
• Supports UDLD and improves operation and maintenance capabilities
• Supports rich L2 and L3 protocols
• Supports PoE for IP Phone and wireless AP connection
• Supports PWE3 protocols for TDMoIP applications
• Supports perfect multicast protocol
• Hard QoS including two-rate three color mode (trTCM)

Initially we feels that, we gonna face lots & lots of trouble in configuring and specially in support during testing as Maipu is not present locally in Pakistan. But thanks to Maipu Product Manager – Peter Hu, to offer us to provide 24/7 online support with their highly technical support team and established a direct link with their R&D team. This box support every feature we want to look in any ME boxes and may be even more than that. We usually use TDM over IP boxes on existing Cisco Metro network to provide PWE3 support to carry E1 over Packet network. This small MS3400 support 8 E1s to carry both channelize & unchannelize E1 using MEF standards. Even Layer 3 routing features are supported in it (Not like Cisco to select SDM feature, where you always not happy with the lacking of many important feature support).

I must comment about their online support & R&D. Its simply ………awesome. Initially their engineer Leon (Jingweili) support us in any of the technical guidance we required. We only need to highlight our requirements and Maipu come up with the complete solution in their boxes. They have introduce a-lot of new features on our request only. One of the most amazing occasion was when we have requested Maipu to integrate their proprietary Protocol EIPS (previously EAPS) with the Cisco proprietary REP. Ofcourse Maipu didn't support REP, but their R&D prepare the solution for us to integrate Maipu MS3400 on Cisco ME aggregation switch. Isn't really amazing.

During our 1 month extensive testing, we rated them as good as Cisco higher class ME switches in both reliability & feature support. Although Technical support is not available locally but remote support is as strong to make no difference for good Service Provider. Special thanks to Peter, Mark & Dan for their support.

For Higher end, we have tested Maipu 6800 10G Carrier Class Routing Switch (MLS). That is an another awesome box.

For complete product line: Maipu Communication

They are same good in low cost CPEs. Their MP 800, 1700 & 1800 are considerably the best choice for low cost & best CPEs for enterprise market.

I am amongst one of the most satisfied customer of Maipu Communication and wish Maipu continue to provide same level of support & services to their customers in future.

VPN – Virtual Private Network is growing demand of all the corporate business communication. They usually need to run their Business critical application along with Real time Voice & Video communication between their globally present offices. Their is usually two approaches to reach Global businesses i.e. using Tunnel Techniques or MPLS VPNs [For detail check blog: MPLS L3VPN (RFC 2547/ RFC4364)]. But guarantee QoS for Tunnel traffic over IP (Internet) Cloud is hard to claim. So what will be happen to Mission Critical applications? Do they provide the required performance? What is the solution?

Answer is MPLS VPN with the extensibility to expand over multiple IP/MPLS Service Provider clouds, virtually visible as the single QoS aware IP Cloud. This standards are present in the RFC 2547 / RFC 4364, in section 9 & 10. Option 9 is about Carrier of Carriers model and Option 10 is Inter-AS approach. Lets discuss each,

Carrier of Carrier Model

In CoC model, MPLS VPN Carrier help other Carrier to get connected their geographically dispersed PoPs over its own IP/MPLS VPN cloud. Here two options might be arise,

1 – Customer Carrier is only running IP cloud without carrying IP/MPLS VPN over this connection.

2 – Customer Carrier is also IP/MPLS VPN service provider & will provide global connectivity to its customer connected to it through some middle transport carrier.

Inter-AS Model

In Inter-AS model, Two different MPLS VPN provider agreed to serve each other customers through their Access & will handed over to them via ASBR-PE neighborship. This is one of the mostly used example of Global MPLS VPN exchange contract model. In Pakistan CYEBRNET is one of the initiator to provide International IP/MPLS L3VPN services to the global reach with Inter-AS connect model with SingTel.

RFC 2547 / RFC 4364, provides three possible way to design Inter-AS Model,

Option 10-A – In this model, a PE router in one AS is directly connected to a PE router in the other AS. Each of the PE routers also functions as an AS border router (ASBR). The PE routers are connected by multiple sub-interfaces, where each of the VPNs that are required to exchange routes across the AS boundary is assigned to at least one of these sub-interfaces. This
approach is also referred to as VRF-to-VRF approach.

Option 10-B – In the second approach, the PE routers within an AS use MP-IBGP to distribute labeled VPN-IPv4 routes to a PE (ASBR) or a route reflector of which the PE (ASBR) is a client. The PE (ASBR) then uses MP-EBGP to distribute the labeled VPN-IPv4 routes to its peer PE (ASBR) in the neighboring AS. Finally, the peer PE (ASBR) use MP-IBGP to distribute labeled VPN-IPv4 routes to PE routers or to a route reflector of which the PE routers are a client.

Option 10-C – While the previous two proposals provide workable solutions for inter-AS operations, the long-term applicability of these approaches is limited because their scalability is determined by the amount of VPN routing information carried by the individual BGP/MPLS VPN service providers. Ultimately, service providers will want to deploy the multi-hop MP-EBGP approach because it does not require that VPN-IPv4 routes be maintained and distributed by ASBRs. Multi-hop MP-EBGP is required because the EBGP peers are not directly connected. This approach significantly enhances the solution’s scalability because the load on the ASBRs is independent of the amount of VPN routing information carried by BGP/MPLS VPN service providers.

Google is one of the Internet Giant who take initiative to bring Live services on IPv6 Internet. In March 2008, they began offering Google search over IPv6 on IPv6-only websites like ipv6.google.com (IPv6 connection required), but other Google products were not generally available over IPv6.Till today most of the services are now IPv6 enabled, including Google Search Engine (ipv6.google.com), Docs, Mail, Calender etc…..but the most awaited service is Youtube [reference: Presentation @ RIPE58: IPv6 at Google].

Today, i have heard from sources i.e IPv6 mailing list @ LINK, that Youtube Contents are also IPv6 enable (not the youtube web page). This is one of the biggest service addition & milestone for IPv6 Internet. Google has also arranged Google IPv6 Summit in 2008 where number of sessions has been conducted, including one by Mr. Vint Cerf himself. Following are the video sessions from that summit,

What will the IPv6 Internet look like?

IPv6 on Windows

IPv6 and the DNS

Planning for the IPv6 Integration

IPv6, Nokia, and Google

I have discussed IP/MPLS concepts in my first blog [MPLS L3VPN (RFC-4364 / RFC-2547)], now we will look at the configuration example of MPLS L3VPN in the multi-vendor environment. My targets will be of Cisco &  Juniper products for this blog.

Here is example scenario,

Service Provider network is consist of three Routers R0 (CN-ISB), R1(CN-KHI) & R2 (CN-LHR). These are connected back to back on serial interfaces. OSPF is used as the IGP between SP domain.

Before configuring MPLS L3VPN service, first we have enable MPLS on our Core network. Here is the configuration,

Configuring MPLS on Core Routers:

Router R0

interface Loopback0
 ip address 1.1.1.1 255.255.255.255

interface Serial1/0
 description ISB-LHR Core MPLS Connection
 ip address 192.168.0.5 255.255.255.252
 mpls ip

interface Serial1/2
 description ISB-KHI Core MPLS Connection
 ip address 192.168.0.1 255.255.255.252
 mpls ip

router ospf 10
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.0.0 0.0.0.255 area 0

Router R1

interface Loopback0
 ip address 3.3.3.3 255.255.255.255

interface Serial1/1
 description KHI-LHR Core MPLS Connection
 ip address 192.168.0.9 255.255.255.252
 mpls ip

interface Serial1/2
 description KHI-ISB Core MPLS Connection
 ip address 192.168.0.2 255.255.255.252
 mpls ip

router ospf 10
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.0.0 0.0.0.255 area 0

Router R2

interface Loopback0
 ip address 2.2.2.2 255.255.255.255

interface Serial1/0
 description LHR-ISB Core MPLS Connection
 ip address 192.168.0.6 255.255.255.252
 mpls ip

interface Serial1/1
 description LHR-KHI Core MPLS Connection
 ip address 192.168.0.10 255.255.255.252
 mpls ip

router ospf 10
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.0.0 0.0.0.255 area 0

Check MPLS Status:

Now, our Core Network is IP MPLS enbled, here are the few outputs @ CN-ISB router AKA R0,

Check OSPF Neighbor details

CN-ISB#sh ip ospf nei
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2                0   FULL/  -        00:00:33    192.168.0.2     Serial1/2
3.3.3.3                0   FULL/  -        00:00:32    192.168.0.6     Serial1/0

Check LDP bindings

CN-ISB#sh mpls ldp bindings
  lib entry: 1.1.1.1/32, rev 2
        local binding:  label: imp-null
        remote binding: lsr: 3.3.3.3:0, label: 19
        remote binding: lsr: 2.2.2.2:0, label: 19
  lib entry: 2.2.2.2/32, rev 8
        local binding:  label: 17
        remote binding: lsr: 3.3.3.3:0, label: 18
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 3.3.3.3/32, rev 6
        local binding:  label: 16
        remote binding: lsr: 3.3.3.3:0, label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 17
  lib entry: 192.168.0.0/30, rev 15
        local binding:  label: imp-null
        remote binding: lsr: 3.3.3.3:0, label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 16
  lib entry: 192.168.0.4/30, rev 4
        local binding:  label: imp-null
        remote binding: lsr: 3.3.3.3:0, label: 20
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 192.168.0.8/30, rev 10
        local binding:  label: 18
        remote binding: lsr: 3.3.3.3:0, label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: imp-null

Note: In latest IOS, when MPLS is enabled, there is no need to configure LDP neighbors as its enabled by default & discover neighbor using Multicast discovery mechanism. Where as advance parameters or directed neighbors (using unicast instead of multicast) need to be configured on global level.

Configuration template of MPLS on Juniper Routers:

interfaces lo0
unit 0 {
    family inet {
         address 1.1.1.1/32;
    }
}

se-2/0/0 {
    description "KHI-LHR Core MPLS Connection";
    encapsulation cisco-hdlc;
    unit 0 {
        family inet {
             address 192.168.0.9/30;
    }
        family mpls;
}

protocols ospf         
area 0.0.0.0 {
    interface lo0.0 {
        passive;
    }
    interface se-2/0/0.0
 }

protocols ldp {
transport-address router-id;
interface lo0.0;
interface se-2/0/0.0;
}

Steps for configuring MPLS L3VPNs

1) Configure Full Mesh iBGP neighbors amongst PEs - BGP is the only protocol that can share the VPN-V4 AFIs amongst MPLS PE routers. Since our model network is small, we can start with Full Mesh iBGP neighborship, but scalability Route Reflector can be deployed to save number of iBGP sessions. [blog for RR Model for MPLS L3VPN will come soon]. Following is the configuration,

Router R0

router bgp 9541
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 9541
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 9541
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
 exit-address-family

Router R1

router bgp 9541
 no synchronization
 no bgp default route-target filter
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 9541
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 2.2.2.2 remote-as 9541
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 172.16.0.13 remote-as 100
 no auto-summary
!
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family

Configuration template of iBGP neighborship on Juniper Routers

protocols bgp
group IBGP {
    type internal;
    local-address 1.1.1.1;
    family inet {
        unicast;
    }
    family inet-vpn {
        unicast;
    }
    local-as 9541;
    neighbor 2.2.2.2 {
        description " *** iBGP KHI-LHR *** ";
    }
    neighbor 3.3.3.3 {
        description " *** iBGP KHI-PSW *** ";
    }

2) Configure VRF (Virtual Routing & Forwarding) – VRF is the per customer private routing table maintain by SP at MPLS PE network.  For configuring VRF, there are 2 mandatory elements are Route Target & Route Distinguisher. Following configuration will be done on all three PE MPLS routers, R0 & R1.

ip vrf test
 rd 100:1
 route-target export 100:1
 route-target import 100:1

3) Configuration of PE-CE Interface – After VRF has been created, the next step is to configure the PE-CE interface and assign membership of this interface with the customer VRF. membership is an interface-configuration mode command and run only where CE is attached to PE.

Router R0

interface FastEthernet0/0
 description MPLS L3VPN PE-CE1 Connection
 ip vrf forwarding test
 ip address 10.0.0.1 255.255.255.252

Router R1

interface FastEthernet0/0
 description MPLS L3VPN PE-CE2 Connection
 ip address 10.0.0.5 255.255.255.252

Configuration of VRF & PE-CE Interface configuration on Juniper Routers

routing-instances
Test {
    instance-type vrf;
    interface fe-0/3/2.0;
    route-distinguisher 100:1;
    vrf-target {
        import target:100:1;
        export target:100:1;
    }
}
fe-0/3/2 {
    description "Customer for VRF Test";
    unit 0 {
        family inet {
             address 10.0.0.1/30;
    }
}

4) Configuration of Customer VRF routes redistribution in iBGP – This is the last step, where customer routes are placed in the local VRF routing table, are advertised to other PE via iBGP session we created earlier. If PE-CE routing protocol is not configured or configured other than eBGP and routes redistribution need to configured in the VRF that we have to redistribute routes to iBGP session under VRF Test. If eBGP was the routing protocol between PE-CE, than customer advertised routes will automatically redistributed to iBGP and only connected networks will be redistributed under this configuration.

Router R0

router bgp 9541
 address-family ipv4 vrf test
  no synchronization
  redistribute connected
  neighbor 10.0.0.2 remote-as 10
  neighbor 10.0.0.2 activate
 exit-address-family

Router R1

router bgp 9541
 address-family ipv4 vrf test
  no synchronization
  redistribute connected
  neighbor 10.0.0.6 remote-as 20
  neighbor 10.0.0.6 activate
 exit-address-family

Check MPLS L3VPN routing information:

This will end the configuration of MPLS L3VPN. lets see….we have succeed or not,

Check iBGP VPN-V4 routes:

CN-ISB#sh ip bgp vpnv4 all
BGP table version is 68, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf test)
*> 10.0.0.0/30      0.0.0.0                  0         32768 ?
*>i10.0.0.4/30      3.3.3.3                  0    100      0 100 ?
*> 10.10.10.10/32   10.0.0.2                 0             0 10 i
*>i20.20.20.20/32   3.3.3.3                  0    100      0 100 200 i

Check VPN labels:

CN-ISB#sh ip bgp vpnv4 all labels
   Network               Next Hop      In label/Out label
Route Distinguisher: 100:1 (test)
   10.0.0.0/30           0.0.0.0         20/nolabel(test)
   10.0.0.4/30           3.3.3.3          nolabel/24
   10.10.10.10/32   10.0.0.2        21/nolabel
   20.20.20.20/32    3.3.3.3          nolabel/25

Check VRF routing table:

CN-ISB# sh ip route vrf test
Routing Table: test
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
       E1 – OSPF external type 1, E2 – OSPF external type 2
       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
       ia – IS-IS inter area, * – candidate default, U – per-user static route
       o – ODR, P – periodic downloaded static route, + – replicated route
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.0.0/30 is directly connected, FastEthernet0/0
L        10.0.0.1/32 is directly connected, FastEthernet0/0
B        10.0.0.4/30 [200/0] via 3.3.3.3, 00:05:49
B        10.10.10.10/32 [20/0] via 10.0.0.2, 00:38:11
      20.0.0.0/32 is subnetted, 1 subnets
B        20.20.20.20 [200/0] via 3.3.3.3, 00:05:49

We are hearing from numerous sources, that soon IPv4 address will be exhausted as the growth in the demand of public IP enabled services in increasing day by day. Specially residential users (broadband) are the one of the main drivers for the adaptation of IPv6 amongst the World.

But where the Technical World is moving….in totally different directions. And this is,we are almost ready for IPv6 good feature supports in Core & Distribution part of the networks, but if we take a look at the residential gateway vendors, how many of them fully support IPv6?

As we discuss about the Future of PnP devices in our last blog [Future of PnP in Communication World – IPv6 StateLess AutoConfiguration (SLAC)], how can the residential CPE vendors are lacking in this situation. Specially Triple Play Services, where STB & home automation electronic appliances need IP communication, IPv6 is the only survival hope.

I will soon published the essential IPv6 features list that must be needed in Network nodes (including User machines & CPE and also Service Provider Core nodes), from the platform of Pakistan IPv6 Task Force [Pkv6TF].

This is for my friends, going for CCIE SP track. This is from Cisco website, the list of Books recommended for the successful preparation for Written & Lab exam. I have almost 80% of the listed books…

I remember, many years back there was a block buster Oscar Winning SciFi/Futuristic movie release in 1985. Micheal J Fox starer "Back to the Future". We all usually saw that on local TV channel and was a great hit amongst all generation. They show many Futuristic gadgets and shows the Power of wireless communication & internet. At that age we take as the imaginary movie but as we saw the current era of wireless & Internet boom, one can match the ideology of great thinkers of that time that Communication will play the most critical part of daily life.

Mobile communication is the world most fastest growing form of communication. According to the stats, year-on-year growth is around 24% between 2000 & 2008. In 2000 mobile penetration stood at only 12%, it has surpassed the 50% mark by early 2008. China surpassed 600 Millions mark by the mid-2008, representing by far the world's largest mobile market. India had some 296 Million mobile subscribers by the end of July 2008. Pakistan is also amongst the emerging market of the World. Now a days if we can see mobile is in the use of every person from the Elite class to normal person (Dhabay wala/Dhobi etc). Internet is Global network (the World largest network) and is growing day by day, specially by the addition of 3G & 4G services.

Every communicating device now need IP address, to be the part of this Global communication World and its variant are amongst the most demanding VAS in Mobile services. In this was every device want to be on Internet, so they need IP address, but we don't have many – as only few Millions are left and we are talking about Billions of Mobile devices plus new emerging market of sensors network, RFIDs and other controllable electronic devices. IPv6 is the only answer and provide 340 Trillions Trillions Trillions IP addresses which make the huge room for all the current need of devices & surely for the future needs. I have read the case study of Japanese electronics market, where they have embed this IP technology in all possible electronic gadget and one of the most successful story is of Microwave Ovens & Refrigerators. Why one can use IP base communication in these devices? they have the answer: Still having so much educated, we are not taking maximum benefits of technology in our social life. Why we still maintaining inventories of items in refrigerators manually (many of us even didn't do it) and when any item was short, we have to go to the shops and having purchase them. Cant this be automated? Cant we monitor or communicate directly to it?

Consider a scenario, when most of the item are bar-coded or using RFIDs and Refrigerator works as the intelligent Inventory management and communication device. You can configure the min threshold of each item and whenever it cross that threshold it place the online order to the Shopping Mart like Macros/Metros etc and also generate alerts on the user's Mobile. These refrigerators & shopping marts are connected to single communication world. Items will be delivered in few minutes & bill will sent to the Mobile device through SMS or any specific cash payment software. Once it placed in the refrigerator, it updates its inventory & inform the user again. After verification mobile user can pay the bill, using e-Payment mechanisms. This whole scenario just need few minutes to complete the transaction cycle & tasks that we do in hours will be done in minutes. There are also many examples of other devices.

Now we have IPv6 with us, vendors like LG, Hitachi, Mistobishi etc have established the IP enabled refrigerators etc but the biggest challenge is to configure & manage the devices, specially IP address which is 128 bits long – represented in complex 32 Hex digits, How the normal/non-educated or non-techincal person will gonna configure the devices like these or configure the mobile devices or all other Plug n Play devices we can think of? One can answer the World mostly used IP management protocol DHCP (DHCPv6 for IPv6
). Yes can be! but if one needed to manage the home devices through mobile handset or other remote management tools and IP of these devices changes continuously (not fixed – basic concept of DHCP), it will be hard to identify the destination or needed some sort of Device Discovery mechanism. Why not to have a mechanism that every device generate its IP address by itself (dynamically) and it will remain fixed whenever it generate. This is the ICMPv6 feature called StateLess AutoConfiguration (SLAC)of IPv6 addresses.

The Challenges & Requirements

• Users devices like Mobile phones, Laptops, TV, Refrigerator, DVD & Music players, Microwave Over, IP Phone, IP cameras, most probably other home appliances like home security system, IPTV STBs etc need to have fixed IP address but w/o any user intervention.
• Users devices IP address should be Universally unique (work for Global/Site local/Link Local Unicast address).
• Duplicate Address Detection mechanism should be there to maintain the uniqueness.
• User devices should retain its IP address whenever it is alive & it will never be reuse by other devices.
• This all should be done dynamically and should be scalable.

Solution

StateLess AutoConfiguration (SLAC) help devices to generate Universally unique IPv6 address from its Universally unique MAC address. MAC is 48bits HEX address & is hard coded in NICs, even mobile technologies use MAC layer to communicate at DLL. ICMPv6 4 new messages are utilized to provide the functionality of Address Auto-configuration & Duplicate Address detection. Those are,

1. ICMPv6    Message Type-133    Router Solicitation (RS)
2. ICMPv6    Message Type-134    Router Advertisement (RA)
3. ICMPv6    Message Type-135    Neighbor Solicitation (NS)
4. ICMPv6    Message Type-136    Neighbor Advertisement (NA)

Lets discuss the functionality of each message & how can it provide help in SLAC based on the following scenario,

In the scenario, Router is connected to the switch configured with the IPv6 prefix on interface i.e. FEC0:0:0:1::/64. Over this segment number of machines are connected, which will used IPv6 SLAC to configure their IPv6 address from the same network address configured on router and also verify the duplicity check via DAD mechanism. Than they can able communicate with other destinations. Note: Routers cannot assign their IPv6 addresses to interfaces using stateless autoconfiguration. Stateless autoconfiguration is designed for nodes only. 

The whole scenario need routers to inform the machine about its presence (Gateway discovery) and the prefix running on that segment (Prefix advertisement). Than machine need to configure the unique IPv6 address from that known prefix. To maintain the high level of uniqueness there should be some mechanism to generate unique host address to get connected to network address provided by router. For that purpose SLAC use Universally unique MAC address to make the unique Host address for individual machine. Consider if Machine has the MAC address of 00:B0:4A:5C:F0:38 than this 48bits MAC address will convert into 64 bits host address by inserting FFFE in between OUI & Vendor Assigned Number. Than finally flip the 7th Bit.

This 64 bits interface ID combines with prefix information provided by router, the Universally unique IPv6 is generated. Lets dig down to the message flows,

Once the router configure with IPv6 prefix address in EUI-64 format, its automatically start send Router Advertisement messages over the segment containing,

• One or more onlink IPv6 prefixes that nodes on the local link can use to automatically configure their IPv6 addresses
• Lifetime information for each prefix included in the advertisement
• Default router information (whether the router sending the advertisement should be used as a default router and, if so, the amount of time (in seconds) the router should be used as a default router)
• Additional information for hosts, such as the hop limit and MTU a host should use in packets that it originates

This Router Advertisement message is sent to All-Node Multicast Address [FF01::1]. When ever the machine with IPv6 protocol stack comes UP, it will become the part of few special multicast addresses including All-Node Multicast address and Solicited Node Multicast Address. So this message will be intercept by all the nodes on the segment and get the information about the prefix information running on that link.

Consider IPv6 machines boots UP and miss the RA message by second, now it has to wait for another RA message which will be few minutes away (Default is 200 secs on Cisco Routers). There is no need to wait, Machine can solicit the router for request the RA message. These messages are called Router Solicitation (RS), which is send to All-Router Multicast address [FF02::2]. In reply Router send RA message containing prefix information.

Now machine combines prefix information [FEC0:0:0:1/64] with interface ID [02B0:4AFF:FE5C:F038], forming unique IPv6 address i.e. FEC0:0:0:1:2B0:4AFF:FF5C:F038/64.

It is important for node to check for Duplicate Address through DAD before configuring the IP address. DAD is another ICMPv6 feature. The above IP address formed is initially called Tentative IPv6 Address. Machine send Neighbor Solicitation (NS) message on the segment with Unspecified Address [::] as the Source address and Solicited node Multicast address generated from Tentative IPv6 address [FF02::1:FF5C:F038] as the destination address.

If another machine over the same segment replies NS message, it means this IP address is already in use by any other machine. So source machine will drop the tentative IP address and wait for the manual IP configuration. If not than source machine is ready to go on the network with the IPv6 address [FEC0:0:0:1:2B0:4AFF:FF5C:F038].

Multi-Protocol Label Switching – as the name suggest, provide the way to switch the packets/frames across MPLS cloud using Label switching methodology. This is the one we can say the heart of MPLS to perform its operation. The end result of this operation is to provide the end to end Label Switch Path (LSP) between PEs to send traffic from CEs. There are many ways to distribute labels & establish LSP, this blog is the discussion about these protocols i.e. TDP, LDP, RSVP and BGP. Before going into the detail of each one, first take a quick view on Label format itself.

MPLS Label is 20bits in length and placed in between Layer 2 & 3, thats why its called MPLS SHIM header. MPLS Shim header is look like this one,

Some important fields of MPLS shim headers are,

• Label - 20 bits Label assign to FEC (Forwarding Equivalence Class)
• EXP – 3 bits Experimental bits, used for CoS (usually mapped from IP Precedence, DSCP or 802.1p)
• S – Bottom of the stack bit, to identify that this Label is the Bottom of the Label stack or there are further more Label present under this label stack.
• TTL – Time To Live, normally copied from IP packet and has the same purpose.

Some of these labels are reserved for special purpose like Label "0" is called Explicit NULL or Label "3" called Implicit NULL.

Now look at different Label assignment procedures and LSP establishment. Their are two methods for LSP establishment each has two steps i.e. Label Assignment & Label Distribution.

Independent Control

Label Assignment:
In independent control operation, Label assignment is the independent operation of all the MPLS enabled router in domain, also label significance is local to the router, means multiple LSRs can have same label for same/different FECs. This label assignment is usually done by identifying the FEC entry present in the RIB (Routing Information Base).  Each LSR assign Label from their pools of label and store them in LIB (Label Information Base).

Label Distribution:
LSRs after building their LIB with local labels, they advertise to their neighbors. This advertisement is independent of each LSR i.e. there is not a single LSR that manage Label distribution, but every LSR done it as independent identity. When an adjacent LSR receives label-binding information from a neighbor, it checks for the presence of a local binding in its LFIB. If the local binding is present, it updates the outgoing label for that entry with the newly received label value. The LSR now has a fully populated LFIB entry and is ready for packet forwarding.

Ordered Control

Label Assignment:
In independent control operation, Label switch path established in the ordered manner i.e. LSP establishment initiate either by ingress or egress LSR. Label assignment is controlled in an orderly manner from the egress to the ingress of the LSP. LSP setup may be initiated from either end, the ingress or the egress. The initiator of the LSP makes the selection of FECs, and all LSRs along the LSP use the same FECs.

Label Distribution:
In independent control operation, initiator LSR propagate the local binding to all other LSRs. The ordered control of LSP establishment requires that the label bindings propagate over all LSRs before an LSP can be established. This results in slower convergence times than the independent control. 

Label Distribution Protocols

The concept of Label switching over IP cloud is originally provided by Cisco systems by their legendary protocol Tag Distribution Protocol (TDP). But its Cisco proprietary, so incompatibility was the issue. As this was the very successful attempt from Cisco to provide great technology concept, IETF start working with Cisco to develop open standard version of TDP named LDP.

Label Distribution Protocol (LDP):
Label Distribution Protocol (LDP) was defined in RFC-5036 (previously RFC 3036). LDP defines the dynamic way to distribute label following IGP paths to establish LSP. LDP implementation is very much flexible b/c of its TLV (Type, Length, Value) structure, which help LDP to extend its services from basic MPLS LSP switching to VPN services like Martini L2circuit & VPLS. LDP works by either discovering the neighbors using Multicast UDP Hello messages or via Unicast targeted Hellos. Once the neighbor has been discovered, TCP session has been established over port 646 between the neighbors and negotiate Mode of operation (Independent or Ordered Control) & other features. After session setup they also exchange Label information (against FECs) over TCP session as incremental updates. Multicast/Unicast Hellos are used to check the health of neighbor. 

LDP is quite easy to implement, but as the core implementation its highly dependent on underlying IGP. Which means its Traffic Engineering capabilities are not more than the TE capabilities of IGP. Also IGP loops can cause LSP to form loops, and IGP synchronization is very important, as LDP will synchronize after the IGP populates the routes & compute their best path.

Finally LDP scope is limited to the local AS i.e. Inter-AS LSP cannot be created using LDP. For that, RSVP & BGP extensions are used as mentioned by IETF.

Configuring LDP on Cisco Routers

mpls label protocol ldp (optional for new IOS)
interface GigabitEthernet0/3
mpls ip

Targeted Hellos
mpls ldp neighbor 10.0.0.1 targeted ldp
mpls ldp neighbor 10.0.0.1 password MD5-password

Configuring LDP on Juniper Routers

protocols ldp {
  strict-targeted-hellos;
  transport-address router-id;
  interface ge-0/3/1;
  session 10.0.0.1 {
      authentication-key MD5-password
  }
}

Resource Reservation Protocol (RSVP):
Resource Reservation Protocol (RSVP) was originally designed QoS model Integrated Services with the idea to reserve the resources for each flow of communication. Its extension to MPLS is just to distribute label to form the LSP & reserve specific bandwidth per LSP [RFC 3029]. RSVP was designed specially to provide the feature of Traffic Engineering which is the shortcoming of LDP. Traffic Engineering means, its not necessary that LSP will follow IGP dictated path, whereas number of other parameter can be consider to establish RSVP LSP, including link coloring, available/total/used bandwidth, explicit hops etc.

RSVP session is initiated by LSP head-end PE router. Ingress LSR send path reservation message with the bandwidth requirements and explicit hop with the destination IP of the LSP tail-end PE router.

Path Message may include,

• Label Request Object (LRO) which is the request for MPLS label
• Explicit Route Object (ERO) which direct the hop which need to traverse for LSP
• Record Route Object (RRO) which tracks the path followed by LSP
• Sender TSpec which is request for reservation of bandwidth

In response to Path message, egress PE router send the Resv Message, to its upstream LSR and than intermediate LSR send Resv Message to next until reach the ingress LSR.

RSVP TE capabilities help it to establish LSP between different AS.

Configuring RSVP on Cisco Routers

interface GigabitEthernet0/3
 ip rsvp bandwidth
 mpls traffic-eng tunnels
 mpls ip

ip explicit-path name LSP-path1
 next-address 11.0.0.2
 next-address 10.0.0.2
 next-address 2.2.2.2

ip explicit-path name LSP-path2
 next-address 12.0.0.2
 next-address 13.0.0.2
 next-address 2.2.2.2

interface Tunnel1
 description *** LSP-1***
 ip unnumbered Loopback0
 tunnel destination 2.2.2.2
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 1 explicit name LSP-path1
 tunnel mpls traffic-eng path-option 1 explicit name LSP-path2
 tunnel mpls traffic-eng path-selection metric te

Configuring RSVP on Juniper Routers

protocols rsvp {
  interface ge-0/3/1 {
      authentication-key MD5-password
  }
}

protocols mpls {
  label-switched-path LSP-1 {
      from 1.1.1.1;
      to 2.2.2.2;
      primary LSP-path1;
      secondary LSP-path2 {
       }
    }
  path LSP-path1 {
      11.0.0.2 strict;
      10.0.0.2 strict;
      2.2.2.2 strict;
  }
  path LSP-path2 {
      12.0.0.2 strict;
      13.0.0.2 strict;
      2.2.2.2 strict;
  }
interface ge-0/3/1
}

Border Gateway Protocol (MP-BGP):
Border Gateway Protocol (BGP) has been extended to support many address families, including VPN-V4, discussed in previous Blog [MPLS L3VPN (RFC-4364 / RFC-2547)], so BGP has been extended to send label along with the advertised prefixes. The main application for BGP to send labels is in the Inter-AS MPLS L3VPN model or 6PE. I will discuss Inter-AS MPLS L3VPN & 6PE in the later post.

Conclusion

Now which protocol to use, is the one of the important decision for any MPLS network designer. In best practices, TE is some times not required for all sort of MPLS based traffic, but its required for some specialized VPN based applications. So merger of all three is possible in real time environment, where LDP is used to provide basic traffic switching for normal IGP based traffic. For VPN TE is preferred (but only when needed), If MPLS Core provide symmetric bandwidth opportunity with equal usage ratio than load of RSVP based is not needed. But if Core or its usage is un-symmetric than Service Provider might use TE to optimize use of its Core. For Inter-AS & 6PE BGP is the option to established end-to-end MPLS based model.

Its my immense pleasure to announce that, today my blog has been certified with "The IPv6 Enabled WWW Logo" by IPv6 Forum [www.ipv6forum.org]. It is now listed amongst other 280 International IPv6 enabled web server in the World and first in Pakistan.

Lets have some Technical background of IPv6 & Dual stack:

IPv6 is the name of new Internet Protocol (IP). Current Internet is based on IPv4, which can address max of 2^32 (~4B) hosts. But if we look at the current scenario, where every device now becoming a part of Internet Globe, this capacity seems to be end soon. Specially boom in wireless broadband technologies like 3G, WiMAX and later LTE, all those Billions of mobile users will need IP address. If we check the current situation there are only few Millions IPv4 addresses are left. Here is the IPv4 Exhaustion Counter,

This counter points out the direction of next few years, may be 2010 to 2012, when there will be no more public IPv4 address remain. This will be the alarming conditions for the World of Communication, where everyone want to expand, serve more & more customers, introducing latest services (ofcourse most of them are on IP)….and that day no one has the single IP address to communicate with this Global World. I can call this a Dooms Day for those who still not believe the end is near.  Because most of the world (not talking about consumer market), the Corporate world really need to have it tested on their infrastructure, services & scenarios, which they haven't realize till now.

During my communication with number of professionals around the globe (mostly Corporates not SPs), they always said, we have alot of time and we are hearing this exhaustion since decades, so no worries. When the time comes, we will tackle it. I can agree with them that yes we are hearing of IPv6 since long time and still its limited to few parts of Internet. But my advice for all of them is to be prepare themselves for the migration strategy if they wait for the last moment. According to my observations, following may be the hurdles in IPv6 propagation specially in Corporate world,

• Hesitation to bring the CHANGE in smooth running network/services
• Fear of Service unavailability / unforeseen problems due to IPv6
• Fear of additional Cost (Hardware/Software/OS)
• Fear of Training Cost for their Team
• Lack of IPv4 Exhaustion & IPv6 awareness

What is Dual Stack?

Dual Stack machines are running both IPv4 & IPv6 protocol stacks. This is one of the most recommended method for transition to enable IPv6 in any network. Dual stack machines/networks has the smart way of communicating between both of the worlds. For destination having v6 only address, they establish connection through v6 stack and for v4 destination, through v4 stack. communication between two dual stack machines gave you the best result that communication always preferred first IPv6 stack, and if communication channel unable to establish , it tries for IPv4 stack.

Wait for my new blogs about IPv6 technical details, it will cover more in-depth technical design & implementation.