{"id":1202,"date":"2016-12-15T10:19:52","date_gmt":"2016-12-15T02:19:52","guid":{"rendered":"https:\/\/networkingnotesblog.wordpress.com\/?p=1202"},"modified":"2016-12-15T10:19:52","modified_gmt":"2016-12-15T02:19:52","slug":"mpls-check-the-label-switching-path-with-juniper-junos-and-cisco-ios","status":"publish","type":"post","link":"http:\/\/notes4it.com\/?p=1202","title":{"rendered":"MPLS – check the label switching path with Juniper Junos and Cisco IOS"},"content":{"rendered":"

How yall doing guys. It has been some times putting anything new to my blog. I think I will put some more materials that focus on troubleshooting wise stuffs. This time, I will present the way to check the label switching path or routing path of the MPLS VPN traffic that run on top of\u00a0the OSPF and LDP protocols.
\nHere is the Topology. The lab is build with both Cisco IOS (C1000v) and JunOS. There is 2 subnets in the VRF which are 192.168.104.0\/24 and 192.168.109.0\/24 and they are located in the R3 and R10 respectively.
\n\"20161215-mpls-lab\"<\/a>
\n 
\n
\nIf there is traffic sending from 192.168.104.2 to 192.168.109.10, the packet will send from the vASA-F14 and pass to R03 s VRF instance, and the packet will traffic all the way via the MPLS cloud and pass it to R09 and route to the Workstation.
\nSo when the packet with destination of 192.168.109.10\/32 reach to R06 the MPLS VPN ingress router, how do we know where does the packet route via? So, we could check the route table of the VRF in router 06 as listed below.
\nR06:
\nnetuser@net-AS5052-vMX-R06> show route table 1060010010.inet | find 192.168.109.0\/24
\n192.168.109.0\/24 *[BGP\/170] 17:47:02, MED 0, localpref 100, from 10.50.0.8
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.14 via ge-0\/0\/1.3993, Push 42, Push 420720(top)
\nWhen the packet reach to the ingress router, this packet will add 2 different LABELS on top of the packet. The first one is called the inner label; and the second label is called outer label , which is a Label stack on top of the inner label. In this case, the packet will be encapsulated with inner label of 42 and the outer label of 420720.
\nAfter the packet is being encapsulated, it will be routed to the next hop of 10.50.1.14 (R05) via ge-0\/0\/1.3993.
\n 
\n
\nSo in Router 05, we will be checking the packet switching path or routing path in the label table now.
\nR05:
\nnetuser@net-AS5052-vMX-R05> show route table mpls.0 | find 420720
\n420720 *[LDP\/9] 00:00:05, metric 1
\n> to 10.50.1.6 via ge-0\/0\/1.3997, Swap 404432
\nIn the label switching table, we can observe the reaction of how the router 05 handle the packet with the label of 420720 passed from the router 03. We can see the router 05 would “SWAP” the outer label from 420720 to 404432. After the outer laber of the packet is being SWAPPED, the packet will be passed to 10.50.1.6 (R01) via ge-0\/0\/1.3997.
\n 
\n
\nIn router 01, the reaction of handling the labeled packet is a bit different than router 05 since router 01 is the second last hop of the egress router. It will remove (POP) the outer label of 404432 from the packet and pass it to 10.50.1.35 (R10) via ge-0\/0\/1.3982. This is what the default behavior of the penultimate router and penultimate router are usually the second last hop of the egress router. At this time, the packet is still having the inner label of 42 attached in the packet.
\nnetuser@net-AS5052-vMX-R01> show route table mpls.0 | find 404432
\n404432 *[LDP\/9] 17:50:02, metric 1
\n> to 10.50.1.35 via ge-0\/0\/1.3982, Pop
\n404432(S=0) *[LDP\/9] 17:50:02, metric 1
\n> to 10.50.1.35 via ge-0\/0\/1.3982, Pop
\n 
\n
\nWhen the packet with inner laber pass to router 10 (running with IOS), R10 will remove all labels (NO Label) from the packet and pass it to 10.50.2.5 via gi3.3981 (the VRF interface). Once the packet are stripped out all the labels, it will route to Router 09 as regular packet based on the routing table.
\nnet-AS5052-c1kv-R10#sho mpls forwarding-table | begin 42
\n42 No Label 192.168.109.0\/24[V] \\
\n19863792 Gi3.3981 10.50.2.5
\nSo what about the path for the returning packets from 192.168.109.10 to 192.168.104.2??
\nIn this time, we will do the similar in router 10 and check the reaction when R 10 receive packet with destination to 192.168.104.2.
\n
\nR10:
\nnet-AS5052-c1kv-R10#sho ip cef vrf 1100010010 detail | be 192.168.104.0\/24
\n192.168.104.0\/24, epoch 0, flags [rib defined all labels]
\nrecursive via 10.50.0.3 label 16
\nnexthop 10.50.1.34 GigabitEthernet2.3982 label 384720-(local:23)
\nThe router 10 will put the inner label of 16 and outter label of 384720 on top of the received packet, and pass it to 10.50.1.34 (R01) via Gi2.3982.
\nWhen it reaches to router 01, the outter label will swap from 384720 to 362096 and pass to 10.50.1.7 (R05).
\nR01:
\nnetuser@net-AS5052-vMX-R01> show route table mpls.0 | find 384720
\n384720 *[LDP\/9] 00:48:15, metric 1
\n> to 10.50.1.7 via ge-0\/0\/1.3997, Swap 362096
\nIn router 05, it removes (POP) the outter label of 362096 and pass to 10.50.1.16 (R03).
\nR05:
\nnetuser@net-AS5052-vMX-R05> show route table mpls | find 362096
\n362096 *[LDP\/9] 00:32:22, metric 1
\n> to 10.50.1.16 via ge-0\/0\/1.3992, Pop
\n362096(S=0) *[LDP\/9] 00:32:22, metric 1
\n> to 10.50.1.16 via ge-0\/0\/1.3992, Pop
\nIn the router 03 (penultimate router), it removes (POP) the inner label of 16 and pass the packet to VRF 1030010010, and based on the route table of VRF, it will pass to the 10.50.2.10 (vASA)
\nnetuser@net-AS5052-vMX-R03> show route table mpls.0 | find 16
\n16 *[VPN\/0] 00:52:41
\nto table 1030010010.inet.0, Pop
\nnetuser@net-AS5052-vMX-R03> show route table 1030010010.inet.0 | find 192.168.104
\n192.168.104.0\/24 *[Static\/5] 00:54:36
\n> to 10.50.2.10 via ge-0\/0\/2.3979<\/p>\n","protected":false},"excerpt":{"rendered":"

How yall doing guys. It has been some times putting anything new to my blog. I think I will put some more materials that focus on troubleshooting wise stuffs. This time, I will present the way to check the label switching path or routing path of the MPLS VPN traffic that run on top of\u00a0the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[24,53,75,92,94,99,102,111,152,155,161,183,208],"class_list":["post-1202","post","type-post","status-publish","format-standard","hentry","category-networking","tag-c1000v-en","tag-forwarding-table-en","tag-ios-en","tag-juniper-vmx-en","tag-junos-en","tag-labels-en","tag-ldp-en","tag-mpls-en","tag-shos-mpls-forwarding-table-en","tag-show-ip-cef-vrf-en","tag-show-route-table-en","tag-troubleshoot-en","tag-vrf-en"],"_links":{"self":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/posts\/1202","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1202"}],"version-history":[{"count":0,"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/posts\/1202\/revisions"}],"wp:attachment":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1202"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1202"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}