MPLS Explicit and Implicit null Label

I have often seen that people often confuses between MPLS explicit null and Implicit null label value (I was among those) so in this post will try to ease your confusion on this 🙂

Before starting with these label values, I hope you are aware of MPLS PHP (Penultimate Hop Popping) feature. If you are not let me explain….

Take a look at the below picture, Ingress LSR and Egress LSR are routers which have customer connections on each side and LSRs in figure are inner MPLS routers.

MPLS Label

In Normal MPLS operation, IPv4 packet when comes to Egress LSR, will have MPLS Label on the top of IP Header. Egress LSR will do 2 operations and 2 look ups. One in MPLS table and other in IP Routing Table to send the packet to appropriate Customer interface. However these 2 operations increases the memory and CPU consumption on the Egress LSR. To avoid these 2 lookups on Egress, Egress LSR initially send a special label value of 3 to “next-to-last LSR” (called the penultimate LSR). This label 3 is called the IPv4 Implicit Null label. When an LSR receives an MPLS header in which the label is set to 3, it always POPs the header i.e., it removes the top label.

This procedure  is called Penultimate Hop Popping (PHP).

So what is Explicit Null?

Ok, when a packet or Ethernet frame is encapsulated in MPLS, you have the option of copying the IP precedence or 802.1p bits to the three CoS bits of the MPLS header i.e. EXP Bits.

If a POP is performed at the penultimate LSR, the EXP bits in the MPLS header are no longer available as a reference for queuing and the packet is queued on the outgoing interface according to the CoS behavior of the underlying payload (in Ipv4 packet, it will be ToS field). An explicit null (Label Value 0 for IPv4), on the other hand, leaves the MPLS header in place until it reaches the egress, preserving the LSP CoS behavior across the entire LSP.

So that’s all for these reserved label values. If you still have any queries, please let me know.




Juniper Northstar — WAN-SDN Controller

Biggest misconception I think currently with SDN is that in order to run SDN we need to have OpenvSwitch equivalent switch supporting Openflow protocol between Controller and Switch. Most software vendors are promoting their software under this category however Hardware vendors who have spent considerable money on building hardware platforms are not just selling switches supporting Openflow. They are using SDN to come up with other applications which are centrally controlling the network and influencing the network from single point but not using Openflow protocol.

Juniper has one of the similar product under WAN–SDN controller category named Northstar. I just happen to assess it recently for my Telco.

Northstar comes in two flavours, Controller and Planner. Controller enables granular visibility and control of IP/MPLS tunnels in large service provider and enterprise networks.

Northstar Planner is more of modelling tool which can help you in understanding the behaviour of new LSP addition, deletion, failure of node/link etc. on your network before you actually provision the network.

The NorthStar Controller relies on PCEP (Path Computation Element Protocol) to deploy a path between the PCC routers. The path setup itself is performed through RSVP-TE signaling, which is enabled in the network and allows labels to be assigned from an ingress router to the egress router. Signaling is triggered by ingress routers in the core of the network. The PCE client runs on the routers by using a version of the Junos that supports PCEP.

The NorthStar Controller provisions PCEP in all PE devices (PCCs) and uses PCEP to retrieve the current status of the existing tunnels (LSPs) that run in the network. By providing a view of the whole network state and bandwidth demand in your network, the NorthStar Controller is able to compute optimal paths and provide the attributes that the PCC uses to signal the LSP.

Example Topology

Northstar Controller Topology

If your network supports Point to Multipoint LSPs, then you need minimum of 15.1F6 version on your ingress PE to view P2MP LSPs on Northstar controller however Egress PE can be on any version. Northstar initiates an iBGP-Link state session between itself and Ingress PE and PCEP attributes are shared over this session.

Home Page:

Northstar Controller_Home Page

With Northstar, we can view all the LSPs in network from the point of view of Ingress PE supporting PCEP and from there on we can initiate an LSP and delegate LSP from PE to Controller to manage it.

Northstar lets you create single LSP, multiple LSPs at once and even diverse LSP by site or link which could be very useful in case of primary backup paths in order to protect against single source of failure.

Diverse LSP Provisioning

Northstar Controller_Provision Diverse LSPs

There are three types of TE LSPs used with PCEP

  • CLI-controlled LSPs—The LSPs that do not have the lsp-external-controller pccd statement configured are called CLI-controlled LSPs. Although these LSPs are under local router control, the PCC updates the connected PCE with information about the CLI-controlled LSPs during the initial LSP synchronization process.
  • PCE-controlled LSPs—The LSPs that have the lsp-external-controller pccd statement configured are called PCE-controlled LSPs or delegated LSPs. The PCC delegates the PCC-initiated LSPs to the main PCE for external path computation.
  • Externally-provisioned LSPs (or PCE-initiated LSPs)—The LSPs that have the lsp-provisioning statement configured are called PCE-initiated LSPs. A PCE-initiated LSP is dynamically created by an external PCE; as a result, there is no LSP configuration present on the PCC.

In its current version, Northstar is really impressive and only thing lacking at the moment in its in-ability to create P2MP LSPs which is must for broadcast applications in NG-MVPN environment and Juniper has plans to include this in their coming releases by end of 2017.

I am sure Service providers will surely think of using Northstar in their IP/MPLS Network where they are using Traffic Engineering LSPs in order to give them more flexibility and control over there traffic bandwidth demands.

Let me know your views on it and would you be interested to deploy this onto your network 🙂


Mohit Mittal





Software Defined Networking – SDN

SDN as I mentioned in previous discussion is to separate out the Control Plane from Router or any network component and provide the centralized place to control the whole Network Topology. You know in any Network device, we have Control Plane, Mgmt Plane and Data plane doing their own set of work (e.g in Cisco 6509 you have Line cards acting as Dataplane, Route Processor as Control Plane and Mgmt plane is how you are accessing the device via SSH/Telnet etc) and in SDN you are separating out the Control plane from these Network devices to make them only works as pure Forwarding devices.

All the routing protocols and control data is taken care by Centralized location which in SDN terminology is called “SDN Controller”. SDN Controller talks to Infrastructure (Forwarding Network devices) via Southbound APIs and Controller can talk to Applications above it via Northbound APIs as you can see in image below.



So you will build Applications like any software on your desktop which talks to Controller and Controller then talks to Forwarding devices via Southbound APIs. In this way you will have centralized way of communicating with Forwarding Network devices and Network devices only work will be to send the traffic from one source to destination as fast as possible without worrying about Control protocols like OSPF, BGP, ISIS etc.

Most common Southbound interface is Openflow which is Open source protocol developed by ONF (Open Networking Foundation). Network devices can be specialized hardware switches from companies like Cisco, Brocade, Juniper etc. or they can be Virtual devices (VMs) for which they are called Open vSwitch. Only requirement for Hardware switches to use with Openflow is that those switches should be able to support Openflow. There are several products in market from various hardware vendors which supports Openflow i.e. Juniper EX9200 Ethernet Switches, MX960 Router, Big Switch Networks – Big Virtual Switch and many many more.

Openflow is not the only protocol which you use for Controller to talk to Network devices; instead other protocols like SNMP, NetConfig, OVSDB are also there but most common protocol in use is Openflow only and all the companies who are currently building the Openflow support are members of ONF as I explained above.

There are various pre-built VM packages you can get today from Internet which you can run from VMware or Virtual Box and they will open the Interface from where you can create your own topologies to work with. Topologies like 1 Virtual Controller, 3 OpenvSwitches with 3 Hosts. Those VM Images will come pre-built with SDN Controllers, Open vSwitch with support for Openflow, Mininet to create and run example topologies, Wireshark, JDK 1.8, Eclipse Luna etc etc.

In next blogs, i will try to give more from hands on perspective from one of these VM Packages and will also talk about how some projects are currently using this.

Please let me know if you have any queries.

Mohit Mittal


As we are faced with more n more SDN and NFV terms in Telecom Networking these days, i thought of discussing same here and give you my understanding of what i think of these technologies.

Currently Communication service providers (CSPs) like BT, ATnT are facing numerous challenges from OTT (Over the Top) players like Netflix, Youtube, Hulu etc. CSP doesn’t get any revenues while subscribers like us use these OTT services. Still however, the infrastructure needed to handle all this growing data traffic needs to grow more to meet the expanding capacity and customer requirements. As a result, infrastructure costs are growing faster than customer/subscriber revenue growth.

Network functions Virtualization (NFV) offers a new way to design, deploy and manage networking services. NFV decouples the network functions, such as network address translation (NAT), firewall, domain name service (DNS), caching, etc., from proprietary hardware appliances, so they can run in software. (Think of GNS3 software if you have used it on your laptop). NFV is just much more that. You must have heard that Cisco or Juniper or any vendor’s hardware are some hundred thousand pounds. You can’t use Juniper Line card in Alcatel or Cisco or vice versa. This is a challenge for Service Providers. Previously Cisco or any Hardware vendor for that matter used to sell their products based upon traffic capacity they can handle like Gig, 10G per seconds however now the Dell, HP servers can meet those requirements without you having to buy the proprietary hardware from vendors like Cisco. All you need to do is take any server and run custom software on top of it which can acts as Firewall, DNS etc. etc.  NFV utilizes standard IT virtualization technologies that run on high-volume service, switch and storage hardware to virtualize network functions.

This will surely put a dent in hardware vendors profit but if they have to keep up with client expectations they have to take this turn. Offcourse there are limitations because of using server instead of dedicated vendor router but then Service providers are not going to replace their Core MPLS routers with NFV. NFV is still new to market and is in very nascent stage to understand its various usecases.


PIC Courtesy :

SDN (Software-Defined Networking) on the other hand is a concept related to NFV, but they refer to different domains. If you are aware of how any router works, you will be able to understand it very quickly. Every Router has 3 different planes. One is Management Plan, 2nd Control Plane and 3rd Forwarding Plane. Using Management Plane Router delivers Management Functions like SSH, TACACs etc. Control Plane is where all routing protocols is processed Like OSPF, BGP, RIP, etc etc. Forwarding Plane is using which Router sends/receive the Actual traffic out/in from its interfaces.

Now work of SDN is to separate out this Control Plane from Router or any network component and provide the centralized place to control the whole Network Topology. In this way the areas like Internal Data Centres of organizations where nothing much changes happens in Control Plane you can separate out this functionality from servers/network components and use servers purely for forwarding traffic as fast as possible. There are number of tools which helps in providing this functionality and with time I think we would be able to get more on that.

However SDN as a concept is not just using Openflow switches using open flow protocol.. Other vendors are implementing it as an Automatic provisioning tool using totally different concepts but still calling it as SDN as that what it is, you are using software to influence networks.

As you can see above, NFV and SDN are somewhat different concepts and can operate independently however they are generally implemented together and can act as powerful tool in today’s network environments.

That’s all for this blog. I will discuss more on these topics in later blogs. Do let me know your comments or feedback and what you think of these technologies!



Mohit Mittal


Service providers these days are continuously facing a challenge and that challenge is someone intruding their network…Suspicious access from unknows IPs, hacking etc.. put pressure on service provider’s environment, their customer’s network and put a dent in their resources and revenues.

On the other hand, companies also spend quite a money in understanding user’s traffic patterns, monitoring network bandwidth utilization and WAN traffic, and performance monitoring. Whatever is their motive, some sort of protocol is needed to do all this as traditional method of monitoring via SNMP is just not enough and this give rise to Network protocol by Cisco called “Netflow”.

“NetFlow” is a network protocol developed by Cisco for collecting IP traffic information and monitoring network traffic. By analyzing flow data, a picture of network traffic flow and volume can be built. Using a NetFlow collector and analyzer, you can see where network traffic is coming from and going to and how much traffic is being generated.

While the term NetFlow was mostly used by Cisco, many other network hardware manufacturers support alternative flow technologies:

  • Juniper (Jflow)
  • 3Com/HP , Dell (s-flow)
  • Huawei (NetStream)
  • Alcatel-Lucent (Cflow)

Routers and switches that support NetFlow collect IP traffic statistics on all interfaces where NetFlow is enabled, and later export those statistics as NetFlow records, toward at least one NetFlow collector. Network collector is typically a server that does the actual traffic analysis. The NetFlow collector then processes the data to perform the traffic analysis and presentation in a user-friendly format. NetFlow collectors can take the form of hardware based collectors or software based collectors.

Netflow picture 1


NetFlow_Picture 2


NetFlow v1 was originally introduced in 1990 and has since evolved to NetFlow version 9. Today, the most common versions are v5 and v9. Major difference between v5 and v9 version is that v5 is restricted to IPv4 flows however v9 can be used to report flows like IPv6, MPLS, or even plain IPv4 with BGP nexthop.

Monitoring IP traffic flows ensures that resources are used appropriately in support of organizational goals. It helps IT determine where to apply Quality of Service (QoS), plays a vital role in network security to detect Denial-of-Service (DoS) attacks, and other undesirable network events.

One last thing is, Netflow is not a standardized version of protocol and it was developed by Cisco however other vendors uses the same concept for their routers/switches. IETF took the Netflow v9 and standardized this protocol into “IP-FIX” (IP Flow Information Export) with some additional changes which vendors are implementing these days to have a consistent view and avoiding any inter-operability issues.

We can go through the IP-FIX in other blogs but for now I hope you have understood the usage of Netflow :).


Mohit Mittal


OSPF Special Area Types!!

The topic which I have chosen for today is special area types in OSPF. I have seen that people ((I was one of them ;)) find it hard to grasp these area types.

We know that OSPF is Link State Interior Gateway Protocol which works by advertising Link State Advertisements (LSA) to its neighbours. LSA are nothing but state of router Interface. More neighbors in Autonomous System means more LSA you need to share with your neighbours and more processing in terms of Power, Memory, CPU is needed on routers to process those incoming LSAs.

What is the solution?

To divide the whole autonomous system into different Areas with Area 0 or Back bone area being at the centre or you can say all other areas connects to Area 0.

What is the Benefit?

With division of whole autonomous system into different Areas, routers have to send the LSAs only to its neighbors inside that particular area and not with all OSPF routers of autonomous system.

Then how the information flows outside the Area?

This is with the help of OSPF Area Border Routers (ABRs) which summarizes the LSAs from One area and send it to another area in Type 3 LSA which is also called Summary LSA.

Till this point we have not introduced any special area types. Everything I have mentioned till now is mostly about Area 0 (Backbone Area) and any other area which is connected to Area 0. Let’s say that another area as Area 1 and common point among both of these areas is ABR which is at the border between these 2 areas.

Before learning Special area types you have to understand one type of LSA which is called “External LSAs or Type 5 LSAs”. These LSAs advertises external connectivity. External connectivity could be from some other Autonomous system or if redistribution is happening from any other IGP, Static protocol into OSPF.

Now, Special Areas are listed as:

1) Stub Area

2) Totally Stubby Area

3) Not-so-Stubby Area

4) Totally Not-so Stubby Area

:S… What is this all about?    Ok, I will try to explain in simple terms  😀

As I discussed above that we have divided the Autonomous systems into Areas to restrict the flow of LSAs however there can be situations that you have some router in your network which is of very low memory or very old legacy router which can’t take all the routes in its routing table but instead of replacing it you want to keep it in your network and serve customers via it. You don’t want to bombard that router will extern LSAs to reach those external prefixes instead you can configure that router as Stub router.

With Stub router configuration all External LSA gets suppressed. But then how that router reaches External prefixes. That is via Default route. As soon as you configure Stub ABR router and other Internal routers as stub router, ABR will automatically advertises a default route towards Internal stub routers which is only information Internal stub routers needs in order to reach External prefixes.

Now in Stub routing, routers will still have Type 3 Summary LSAs, Type 1 Router LSA and default route in their database however why you even want Type 3 Summary LSA when you have default route. This is achieved via configuring the router as Totally Stubby Area where summary LSA even will be suppressed.

People think that apart from Stub area, all other area types are Cisco proprietary however if you look at the original OSPF RFC, Not so Stubby Area has been defined over there so it’s not exactly a Cisco Proprietary feature and has been implemented by other Vendors. Totally Stub Area and Totally Not-so Stubby Area are not defined in RFC.

There are many instances in which companies want to connect to another company or 2 companies gets merged and they want to share any information with each other but in limited fashion. This can be achieved by NSSA (Not-So-Stuby Area) in which router which connects to other’s company network becomes NSSA ASBR (Autonomous System Boundary Router) and router which is connected to Backbone Area 0 Router becomes NSSA ABR.

Redistribution into an NSSA area creates a special type of link-state advertisement (LSA) known as Type 7 LSA, which can only exist in an NSSA area. An NSSA autonomous system boundary router (ASBR) generates this LSA and an NSSA area border router (ABR) translates it into a type 5 LSA, which gets propagated into the OSPF domain i.e Area 0. However one thing to note is that External routes i.e. Type 5 LSAs coming via NSSA ABR is still not allowed into NSSA as normal Stub area rules still apply.

Like for Stub area we have Totally Stubby Area, for NSSA we have Totally NSSA which is same as before that NSSA doesn’t allow Type 5 LSA however it allow Type 3 Summary LSA’s , with Totally NSSA, we are suppressing this summary LSA even.. 🙂

Note: When you configure an area as NSSA, by default the NSSA ABR does not generate a default summary route. In the case of a stub area or an NSSA totally stub area, the NSSA ABR does generate a default summary route.

I know text has become lengthy but I didn’t want to stop abruptly to add to more confusion 🙂 . If you have any doubts, please let me know.