Saturday, 25 February 2017

MPLS Fundamentals

MPLS Fundamentals


MPLS is Multiprotocol label switching, which is used to tunnel the multiple protocols like ipv4/ipv6/Ethernet/ATM/FRAME RELAY traffic by using tag or label. It is just like GRE tunneling where your private IP address is tunneled over the public IP address and travels in service provider core and reaches to a service provider destination router, which further de-encapsulates it and send it to the customer router.  MPLS core concept is same as GRE tunneling concept however instead of public IP scheme it uses labels in the service provider core.
How do they do it…
Let’s take an example of S1 and S2 which are 2 service provider edge routers and ready to provide service to any customer which wants to connect its two sites together. Service provider offers different type of services example T1/E1 leased lines, common Frame Relay infra, MPLS infra, ATM infra, Metro Ethernet infra etc. To understand which service should customer take depends upon the requirement of the customer for example if customer needs to send low bandwidth date like ATM transactions it can go with T1/E1 or ATM, however if the requirement is for more bandwidth and a large frame size packet then we have options available like Frame Relay/Metro Ethernet/MPLS. (differentiating between these technologies is outside the scope of this thread)
What MPLS offers….
1.      No more use of public IP address in VPN services offered by service provide, since it uses label.
2.      Small packet header size which leads to fast processing and less overhead in router infrastructure, since only 20-bit label is injected between the frame and IP header.
3.      Offers L3 VPN, L2 VPN, VPLS, MVPN, NG-MVPN and EVPN like tunneling service to customer.
4.      Provides redundancy and fast convergence in the core by using RSVP link protection/Node protection and Fast re-route and LDP loop free-alternate as well as to tunnel services like duel homed tunnel service environment.
5.      Free BGP CORE, this feature is of big use in service provider, since now it can segregate its internet backbone with services backbone where it does not need to run BGP on the core/P routers in services backbone.
6.      Traffic engineering by using RSVP constraints in service provider core.

We will discuss about these characteristics of MPLS in more details in next thread.


MPLS Terminology
Label edge router – performs push (adding label) and pop (removing label) operation depending upon the placement of MPLS router in the topology.
Label switch router – performs label swap operation and always called MPLS transit router.
Label switch path – The path between Ingress LER and Egress LER upon which packet is transported by using a label.
Label – It is numerical value bind with forwarding equivalence class to switch the traffic between service provider core network example 18, 20 etc.
Incoming Label – Self originated label for the destination prefix and distributed to neighbor. The packet is expected with the same label ie.it is called incoming label. (used as a transport label)
Outgoing Label – label received from the directly connected downstream LDP/RSVP neighbor when label exchanges happen. Push or Swap operation used and label is imposed on incoming packet and send it out to downstream neighbor in LSP path.
VPN Label – Label value any number. Identifies the correct VRF instance to export the MPLS data traffic. Always sent in label stack as a bottom label or inner label.
Label stack – set of Labels are used in different MPLS applications. Last label is called bottom VPN Label and top Label called transport Label. Denoted by S bit.  S=1, means last label in the stack, S=0 means stack has following labels.
PHP (penultimate HOP Popping) – Label value 3, when this label is received as control plan information from the downstream neighbor in LSP path, router removes the top label and send the data packet to downstream LER.
Operation performs in PHP (implicit null Label = 3)








                                                                                        


UHP (Ultimate HOP Popping) – Label value 0, UHP causes the PHP router to send the Labeled packet with a value of 0 to downstream LER. This helps in QOS functions.
Operation performs in UHP (explicit null Label = 0)





Label distribution Protocol – The protocol is used to distribute the labels, per hop basis between LDP enabled LER’s and LSR’S. It uses un-solicited label distribution method.
RSVP (resource reservation protocol) – Used to distribute the labels in downstream on demand fashion from egress to ingress router, also used from providing different services like link protection, node protection, traffic engineering etc.
RSVP FailoverRsvp provides an additional feature of failover from primary LSP to backup LSP in different ways. Node link protection, fast reroute, secondary LSP etc.
1.       LINK PROTECTIONIt is used to protect directly connected physical interface by creating bypass LSP on every router towards next-hop. Egress router does not create this link protection bypass LSP.
2.      NODE PROTECTION -  It is used to protect next-hop by creating bypass LSP on every router towards next-next-hop. Egress and PHP router do not create this node link bypass LSP.
3.      FAST RE-ROUTE It is another way for protecting the primary LSP by creating detour backup path on every router except Egress router. Detour means creating the bypass LSP on every router in the path of LSP to Egress router and every primary LSP has separate detour LSP which puts extra load on router to maintain extra states. Link coloring parameters are reflected from primary LSP to detour path while calculating.
4.      SECONDARY LSP – Static backup LSP is created for securing Primary LSP.
ERO (Explicit router object) -  Path provided by MPLS by using TED database or strictly defined without CSPF which includes all LSR and LER routers on which the LSP is built by RSVP and the result is reflected in record route.
RECORD ROUTE OBJECT -  This object is used to check if the actual LSP has been created on the ERO present in path messages or not. Record route and ERO output should be same after the LSP creation.
RA (Router Alert bit) – Alerts all the ERO routers in the LSP path to create soft session for creation of the LSP.


Test Topology 



Interface Information: ge-0/0/0.vlan-Id NO.
IP addressing: Vlan-Id prefix .1.1. Router no.


RSVP Fundamentals:
Resource reservation protocol was created to reserve a bandwidth to create virtual end to end path from source to destination address and reserve bandwidth on each hop which is required by data stream. MPLS uses this quality in MPLS traffic Engineering to ensure proper link utilization on all core routers, since by default IGP only selects best path and rest of the paths remains untouched.
How do they do it.
For this, we need information about the link available bandwidth and other constraints if you want more granularity in the TE. In order to get this available bandwidth information, we need link state protocol to provide this data in the intervals, we use ospf and isis as link state protocols.
Once you know the requirement about bandwidth which is provided by the user in the router configuration ingress router creates ERO (Explicit router object) and put this information in the path message (Please check top to know ERO) with RA bit set and send it to next hop in the ERO path. The path message travels hop by hop to the egress router and egress router create LSP by generating the Label for the LSP and passes on to the upstream router. Every router removes its own IP address from the ERO and creates an entry in RRO in the path message. Every router creates a soft state for the tunnel-id no. so when the Reservation message comes up from the egress router it can co-relate with assigning a label for the same LSP.
Fields include in Path message:                                                                                                            

S      1.    Session id/tunnel id: To identify the tunnel and maintain a soft state on every router in the path.
2.      Next hop- IP address of the next hop from ERO output.
3.      TIME: Time mentioned in MS
4.      ERO: Explicit route object
5.      Label request field: is used to request for a Label in downstream on demand fashion.
6.      Path Properties: If it a primary path or backup or secondary path.
7.      Session attributes: Name of the LSP to maintain soft-state on LSP path routers.
8.      Sender specification: LSP id no is mentioned in this.
9.      Tspec: bandwidth reservation on tunnel
10.  ADspec: MTU or other related information of the tunnel.
11.  Record route object: check top to understand this object. Sub-object is used to store labels as well       with next-hop information back to ingress router in record route.

Fields include in Reservation messages: (path message + additional fields)

1     Style: SE/FF
2.      Label: label number generated by downstream on demand method.
3.      Record route object: check on Top.

How to Configure MPLS RSVP signaled tunnel.
1    1.     Enable MPLS family on every core facing interface.
set interfaces ge-0/0/0 unit 12 family mpls
2.      Enable core facing interfaces under MPLS and RSVP
set protocols mpls interface ge-0/0/0.12
set protocols rsvp interface ge-0/0/0.12
3.      Create static MPLS/RSVP signaled tunnel on ingress router only. (ingress router R5 to R6 egress router)
set protocols mpls label-switched-path R5-to-R6-lsp to 6.6.6.6
4.      Enable ospf on all interfaces and Enable traffic engineering capabilities.
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface all

root@R5> show route 10.10.10.10

inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.10/32     *[BGP/170] 02:01:17, localpref 100, from 6.6.6.6
                      AS path: I
                    > to 51.1.1.1 via ge-0/0/0.51, label-switched-path R5-to-R6-lsp
                      to 53.1.1.3 via ge-0/0/0.53, label-switched-path R5-to-R6-lsp   (detour route created to backup primary LSP mentioned in the route)

root@R5> show route 10.10.10.10 extensive

inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
10.10.10.10/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.10.10.10/32 -> {indirect(262143)}
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x9350cb8
                Next-hop reference count: 12
                Source: 6.6.6.6
                Next hop type: Router, Next hop index: 262142
                Next hop: 51.1.1.1 via ge-0/0/0.51 weight 0x1, selected
                Label-switched-path R5-to-R6-lsp
                Label operation: Push 299776      (Downstream on demand label learned by next-hop router)
                Label TTL action: prop-ttl  (TTL Propagation is being done)
                Next hop: 53.1.1.3 via ge-0/0/0.53 weight 0x4001
                Label-switched-path R5-to-R6-lsp  (detour route created to backup primary LSP mentioned in the route)
                Label operation: Push 299792
                Label TTL action: prop-ttl
                Protocol next hop: 6.6.6.6
                Indirect next hop: 944e358 262143
                State: <Active Int Ext>
                Local AS:   100 Peer AS:   100
                Age: 2:01:21    Metric2: 3
                Task: BGP_100.6.6.6.6+179
                Announcement bits (2): 0-KRT 4-Resolve tree 1
                AS path: I
                Accepted
                Localpref: 100
                Router ID: 6.6.6.6
                Indirect next hops: 1
                        Protocol next hop: 6.6.6.6 Metric: 3
                        Indirect next hop: 944e358 262143
                        Indirect path forwarding next hops: 2
                                Next hop type: Router
                                Next hop: 51.1.1.1 via ge-0/0/0.51 weight 0x1
                                Next hop: 53.1.1.3 via ge-0/0/0.53 weight 0x4001
                        6.6.6.6/32 Originating RIB: inet.3
                          Metric: 3                       Node path count: 1
                          Forwarding nexthops: 2
                                Nexthop: 51.1.1.1 via ge-0/0/0.51
                                Nexthop: 53.1.1.3 via ge-0/0/0.53


root@R5> traceroute 10.10.10.10
traceroute to 10.10.10.10 (10.10.10.10), 30 hops max, 40 byte packets
 1  51.1.1.1 (51.1.1.1)  25.052 ms  31.922 ms  46.181 ms                                                                                      
     MPLS Label=299776 CoS=0 TTL=1 S=1
 2  12.1.1.2 (12.1.1.2)  64.494 ms  44.852 ms  28.115 ms
     MPLS Label=299776 CoS=0 TTL=1 S=1
 3  10.10.10.10 (10.10.10.10)  57.554 ms  56.659 ms  39.480 ms
    MPLS Label=0 CoS=0 TTL=1 S=1


What happens in background on R5 to R6 to create RSVP tunnel?



Resource reservation protocol was created to reserve a bandwidth to create virtual end to end path from source to destination address and reserve bandwidth on each hop which is required by data stream. MPLS uses this quality in MPLS traffic Engineering to ensure proper link utilization on all core routers, since by default IGP only selects best path and rest of the paths remains untouched.
How do they do it.
For this, we need information about the link available bandwidth and other constraints if you want more granularity in the TE. In order to get this available bandwidth information, we need link state protocol to provide this data in the intervals, we use ospf and isis as link state protocols.
Once you know the requirement about bandwidth which is provided by the user in the router configuration ingress router creates ERO (Explicit router object) and put this information in the path message (Please check top to know ERO) with RA bit set and send it to next hop in the ERO path. The path message travels hop by hop to the egress router and egress router create LSP by generating the Label for the LSP and passes on to the upstream router. Every router removes its own IP address from the ERO and creates an entry in RRO in the path message. Every router creates a soft state for the tunnel-id no. so when the Reservation message comes up from the egress router it can co-relate with assigning a label for the same LSP.
Fields include in Path message:
1.       Session id/tunnel id: To identify the tunnel and maintain a soft state on every LSP router in the path.
2.       Next hop- IP address of the next hop from ERO output.
3.       TIME: Time mentioned in MS
4.       ERO: Explicit route object
5.       Label request field: is used to request for a Label in downstream on demand fashion.
6.       Path Properties: If it a primary path or backup or secondary path.
7.       Session attributes: Name of the LSP to maintain soft-state on LSP path routers.
8.       Sender specification: LSP id no is mentioned in this.
9.       Tspec: bandwidth reservation on tunnel
10.   ADspec: MTU or other related information of the tunnel.
11.   Record route object: check top to understand this object. Sub-object is used to store labels as well with next-hop information back to ingress router in record route.

Fields include in Reservation messages: (path message + additional fields)
1.       Style: SE/FF
2.       Label: label number generated by downstream on demand method.
3.       Record route object: check on Top.

TE works
LSP Metrics
It is possible to manually assign a static metric to an RSVP LSP, in the same fashion that a metric can be assigned to an IGP interface. Once configured, the LSP cost is fixed and cannot change, regardless of the underlying IGP metrics of the interface along the LSP’s path. Keep this in mind, because even if the LSP activates a failover method such as link protection and is then re-signaled, the LSP metric remains fixed at the configured value. In this fashion, if multiple LSPs exist to a specific destination, it is possible to force all traffic onto one LSP or to load-share traffic between LSPs. It will always select lower metric and lower metric LSP will always be preferred.
Configuring LSP Metrics
Only need to configure on ingress router R5.
set protocols mpls label-switched-path R5-to-R6-lsp metric 20


                                                                                                                                                                                                                

Thanks for reading this blog, probably this would help you understand the mpls at a very fundamental level, next blogs will deep dive into more details of mpls and its applications.

                                                                                                                                                                    Regards,
Ankit Arora




No comments:

Post a Comment