CCIE Routing & Switching Advanced Technologies Class - MPLS Layer 3 VPN Verification & Troubleshooting

Transcript

1	Introduction	0h 43m
2	Using the Cisco Documentation	0h 52m
3	Ethernet Overview, Layer 2 Switchports, Trunking, ISL, 802.1q, DTP	0h 47m
4	VTP, VTP Authentication, VTP Pruning	1h 02m
5	VTP Prune Eligible List, VTP Transparent, VTP Troubleshooting, Trunk Allowed List, Extended VLANs	0h 48m
6	VLAN and VTP Review	0h 19m
7	SVIs, Native Routed Interfaces, Router-on-a-Stick	0h 46m
8	Layer 2 EtherChannel, EtherChannel Load Balancing, Layer 3 EtherChannel	0h 57m
9	802.1q Tunneling, Layer 2 Protocol Tunneling, EtherChannel over 802.1q Tunneling	1h 03m
10	STP Root Bridge Election, STP Root Port Election, STP Designated Port Election, STP Priority, STP Cost, STP Port-Priority	1h 46m
11	STP Review	0h 12m
12	STP Timers, STP PortFast	0h 34m
13	STP UplinkFast	0h 11m
14	STP BackboneFast	0h 12m
15	STP BPDU Filter	0h 13m
16	STP BPDU Guard	0h 11m
17	STP Root Guard	0h 11m
18	STP Loop Guard, Unidirectional Link Detection (UDLD)	0h 11m
19	Multiple Spanning-Tree Protocol (MST)	0h 40m
20	Rapid Spanning-Tree Protocol (RSTP), Rapid-PVST	0h 18m
21	MST with Multiple Regions	0h 33m
22	Flex Links	0h 16m
23	Frame Relay	0h 39m
24	Frame Relay Configuration Part 1	0h 34m
25	Frame Relay Configuration Part 2	0h 41m
26	Frame Relay Switching	0h 27m
27	Back-to-Back Frame Relay	0h 08m
28	Frame-Relay End-to-End Keepalives	0h 18m
29	PPP, PPP PAP Authentication, PPP CHAP Authentication	0h 59m
30	PPPoFR, PPPoE	0h 40m
31	Transparent Bridging, IRB	0h 32m
32	Fallback Bridging	0h 14m
33	IP Routing Overview, Switching Paths, Static Routing	0h 42m
34	Static Routing Examples	0h 25m
35	IP Default-Gateway, IP Default-Network	0h 14m
36	On-Demand Routing (ODR)	0h 07m
37	Floating Static Routes	0h 10m
38	Backup Interface	0h 29m
39	Enhanced Object Tracking, IP SLA, Reliable Static Routing	0h 21m
40	Policy Routing	0h 43m
41	GRE Tunneling, GRE Recursive Routing Errors	0h 27m
42	Reliable Backup Interface with GRE	0h 25m
43	RIP Overview, RIP Versions, RIP Auto-Summary	0h 48m
44	RIP Split-Horizon, RIP Timers	0h 22m
45	RIP Broadcast Updates, IP Directed Broadcast, IP Broadcast-Address, Smurf Attacks, Fraggle Attacks	0h 16m
46	RIP Unicast Updates	0h 03m
47	RIP Offset-List	0h 18m
48	RIP Authentication	0h 11m
49	RIP Summarization	0h 10m
50	Prefix-Lists, RIP Distribute-List Filtering, RIP Administrative Distance Filtering	0h 48m
51	RIP Default Routing, RIP Conditional Default Routing	0h 18m
52	RIP Triggered, RIP Validate Update Source,	0h 12m
53	EIGRP Overview	0h 29m
54	EIGRP Auto-Summary	0h 07m
55	EIGRP Split-Horizon	0h 11m
56	EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface	0h 24m
57	EIGRP Hello-Interval, EIGRP Hold-Time	0h 05m
58	EIGRP Authentication	0h 11m
59	EIGRP Time Based Authentication	0h 25m
60	EIGRP Path Selection, EIGRP Metric Weights, EIGRP Traffic Engineering	0h 47m
61	EIGRP Unequal Cost Load Balancing, EIGRP Variance	0h 19m
62	EIGRP QUERY, EIGRP Summarization, EIGRP Leak-Map	0h 28m
63	EIGRP Stub Router Advertisement	0h 22m
64	EIGRP Default Routing	0h 13m
65	EIGRP Route Filtering	0h 11m
66	EIGRP Router-ID	0h 07m
67	Miscellaneous EIGRP Features	0h 02m
68	OSPF Overview	0h 27m
69	Establishing OSPF Adjacencies, Understanding the OSPF Database	0h 43m
70	OSPF Network Type Broadcast, OSPF DR/BDR Election, OSPF over NBMA, OSPF Network Type Non-Broadcast and Point-to-Multipoint	0h 56m
71	OSPF Network Type Point-to-Point, OSPF Network Type Mismatch	0h 13m
72	OSPF Network Type Point-to-Multipoint Non-Broadcast, OSPF Per Neighbor Cost	0h 17m
73	OSPF Network Type Loopback	0h 02m
74	OSPF Path Selection	0h 27m
75	OSPF Convergence Timers	0h 09m
76	OSPF Authentication	0h 12m
77	OSPF Summarization	0h 32m
78	OSPF Stub Areas, OSPF Totally Stubby Areas, OSPF NSSAs, OSPF Totally NSSAs	0h 40m
79	Controlling OSPF NSSA Redistribution	0h 02m
80	OSPF Type 7 to 5 Translator Election, OSPF LSA Type 3 Filter, OSPF Forwarding Address Suppression	0h 24m
81	Route Redistribution Overview	0h 36m
82	Route Redistribution Configuration & Verification, Connected Redistribution	0h 22m
83	OSPF External Path Selection, TCL PING Scripting	0h 33m
84	Routing Loops Overview, EIGRP Route Loop Prevention	0h 55m
85	Metric Based Routing Loops, Route Tagging	0h 46m
86	Administrative Distance Based Routing Loops, Debug IP Routing, IP Route Profile	0h 58m
87	BGP Overview, BGP Peering Types	0h 51m
88	Establishing BGP Peerings, EBGP Multihop, BGP Neighbor Disable Connected Check, BGP TTL Security	0h 49m
89	BGP 4-Byte ASNs	0h 20m
90	BGP Local AS, BGP Peer Groups	0h 30m
91	BGP Next-Hop Self, BGP Next-Hop Processing	0h 30m
92	BGP Route Reflectors	0h 37m
93	Large Scale BGP Route Reflectors with Clusters	0h 34m
94	BGP Confederation	0h 37m
95	BGP NLRI Advertisements, BGP Network Statement, BGP Redistribution	0h 43m
96	BGP Aggregation, BGP Aggregation & Summary-Only, BGP Aggregation & Unsuppress-Map	0h 46m
97	BGP Origin, BGP Aggregation & AS-Set, BGP Aggregation & Advertise-Map	0h 22m
98	BGP Conditional Route Injection	0h 21m
99	BGP Bestpath Selection, BGP Multipath, BGP Weight	0h 53m
100	BGP Local Preference, BGP Local Preference and Communities, BGP AS-Path Prepending,	0h 30m
101	BGP MED, BGP MED Missing As Worst, BGP Deterministic MED	0h 34m
102	BGP Communites, BGP Regular Expressions	0h 43m
103	BGP Filtering, BGP Convergence Timers, BGP Default Routing, Miscellaneous BGP Features	0h 24m
104	MPLS Overview, MPLS Label Distribution Protocol (LDP)	1h 05m
105	MPLS Tunnels, MPLS Penultimate Hop Popping (PHP)	0h 40m
106	MPLS Layer 3 VPNs Overview, VRF Lite	0h 36m
107	MPLS Layer 3 VPNs and VPNv4 BGP	1h 08m
108	MPLS Layer 3 VPN Verification & Troubleshooting	0h 49m
109	MPLS Layer 3 VPN OSPF PE-CE Routing Overview	0h 06m
110	MPLS Layer 3 VPN OSPF PE-CE Routing Path Selection & Sham-Links	2h 01m
111	MPLS Layer 3 VPN OSPF PE-CE Routing Loop Prevention & Down-Bit, OSPF Capability VRF-Lite	0h 40m
112	IPv6 Overview, IPv6 ICMPv6 ND, IPv6 over NBMA	0h 44m
113	IPv6 Routing Overview, IPv6 Static Routing	0h 28m
114	IPv6 RIPng	0h 20m
115	IPv6 EIGRPv6	0h 09m
116	IPv6 OSPFv3	0h 31m
117	MP-BGP for IPv6	0h 26m
118	IPv6 Tunneling	1h 13m
119	Multicast Overview, IGMP	0h 34m
120	PIM Overview	0h 18m
121	PIM Dense Mode	1h 03m
122	PIM Sparse Mode	0h 30m
123	PIM Sparse Mode Configuration	0h 36m
124	PIM Sparse Mode RPF & RP Troubleshooting	0h 27m
125	Auto-RP, Multicast over GRE Tunnels	0h 53m
126	Bootstrap Router (BSR), Bidirectional PIM, Source Specific Multicast (SSM)	0h 40m
127	MSDP, Anycast RP	0h 27m
128	IPv6 Multicast Routing	0h 24m
129	QoS Overview, IntServ QoS, DiffServ QoS, IP Precedence, DSCP, MQC, HQF	0h 41m
130	MQC Classification	0h 44m
131	FIFO, FQ, WFQ, CBWFQ, HQF	0h 50m
132	LLQ	0h 23m
133	WRED	0h 31m
134	Traffic Shaping, Traffic Policing	0h 40m
135	Frame Relay Traffic Shaping (FRTS)	0h 33m
136	RSVP	0h 07m
137	Catalyst 3560 QoS	1h 00m
138	IOS Security Overview, Access Lists (ACLs)	0h 58m
139	Time Based ACLs, Dynamic ACLs	0h 33m
140	Reflexive ACLs	0h 21m
141	TCP Intercept, Content Based Access Control (CBAC)	0h 34m
142	Zone Based Policy Firewall (ZBPF)	1h 09m
143	AAA, Local Authentication, Local Authorization, Role Based CLI Access	0h 43m
144	Port Security, Static CAM Entries, Storm Control, 802.1X Authentication, PACLs, RACLs, VLAN Access Maps (VACLs)	0h 48m
145	DHCP Snooping, Dynamic ARP Inspection (DAI), IP Source Guard	0h 12m
146	Protected Ports, Private VLANs	0h 25m
147	IP Services Overview, HSRP	1h 10m
148	VRRP, GLBP	0h 28m
149	NAT	0h 42m
150	DHCP, DNS	0h 30m
151	NetFlow	0h 09m
152	WCCP, Miscellaneous IP Services	0h 06m
153	System Management Overview, NTP, NTP Authentication	0h 24m
154	SNMP, RMON	0h 38m
155	Syslog, Telnet, SSH, Banners	0h 21m
156	EEM Scripting, Miscellaneous System Management	0h 26m
Total Duration		81h 59m

Slides - Diagrams

Slides - Introduction

Slides - Ethernet Switching

Slides - Advanced Ethernet Switching

Slides - Frame Relay

Slides - PPP

Slides - Transport Bridging

Slides - Redistribution

Slides - IOS Security

Slides - Layer 2 Security

Slides - IP Services

Slides - System Management

0:00:14	So, continuing with the Layer 3 MPLS VPNs,
0:00:18	what we have up to this point is router 4 running the two different VRFs,
0:00:22	we have VRF A and VRF B,
0:00:26	router 4 is running the RIP process for VRF A,
0:00:30	and redistributing this routes into BGP.
0:00:33	Likewise, we have VRF were EIGRP process,
0:00:36	this is being redistributed into BGP.
0:00:40	There's two separate route target values that router 4 is using,
0:00:45	for VRF A, it is exporting 1:1, for VRF B it is exporting 2:2.
0:00:53	These again means that these are the values that router 5 and router 6 import respectively.
0:01:01	We also saw from the Debug IP BGP VPNv4 Updates on router 6,
0:01:06	that it was actually receiving both of the sets of routes, the once from VRF A and the once from VRF B,
0:01:13	but it was automatically filtering out the ones that came in for VRF A,
0:01:18	because router 6 did not have that particular route target configured.
0:01:24	So, with the default operation in any VPNv4 update that the router receives,
0:01:29	and it doesn't actually have that route target configured in the VRF,
0:01:33	it's automatically donna filter that out.
0:01:36	The only exception would be if the in a VPNv4 route reflector,
0:01:40	Therefore, we're manually disabling the filter with the No BGP default route target filter command under the global BGP process.
0:01:50	So, we know now at this point that the control plane is working and the end to end data forwarding is working,
0:01:56	but now the issue was that if there is a problem somewhere in the network,
0:02:01	it can be very hard to troubleshoot a Layer 3 MPLS VPN configuration,
0:02:05	a must we know what are the exact pieces that go together and in what order in order to get the network to work.
0:02:13	So now, let's go back to the verification, we're gonna start on router 4,
0:02:17	look at the configuration verification in the control plane,
0:02:22	which is gonna be the routing advertisement,
0:02:24	then the actual date plane which is where the traffic is forwarded using the labels.
0:02:30	So again, from router 4, the first step was that we have the two different VRFs.
0:02:36	If we Show IP VRF, we have VRF A and B, they're assigned in separate local interfaces,
0:02:45	and they have separate route distinguishers.
0:02:48	This means that one routes were learned in the VRF,
0:02:50	and they're exported to BGP,
0:02:54	routes exported from VRF A are gonna get distinguisher 10.0.4.4:1,
0:03:01	from VRF B they'll get 10.0.4.4:2.
0:03:05	Again this field here is used just to keep the route unique it doesn't control the membership.
0:03:11	If we look at the detail for the VRFs, says for VRF A, we're exporting 1:1, we're importing 1:1.
0:03:22	Means that this value here that we're exporting,
0:03:24	this should match what router 5 is importing.
0:03:28	Then likewise, what we're exporting for B should be what router 6 is importing for B.
0:03:36	Next, we would wanna know are we actually learning the routes from the customer in that VRF.
0:03:41	So, if we Show IP Route VRF A, we see that there are RIP routes coming in from switch 4.
0:03:53	Next, would be to see can we redistribute this locally into the VPNv4 process.
0:03:59	So, if we look at the Show BGP, VPNv4 unicast for the VRF A,
0:04:08	we should see locally that we have then redistributing our connected interface cause this is a part of the RIP process,
0:04:16	and then also the route that's being learned in from switch 4.
0:04:23	We look at the detail attributes here from 10.1.10.10,
0:04:28	we see that the route distinguisher 10.0.4.4:1: followed by the actual prefix,
0:04:36	so this is the VPNv4 route,
0:04:40	the route also includes the route target, which is 1:1,
0:04:45	and then it includes the MPLS label.
0:04:48	Which in this case router 4 is allocating label number 29.
0:04:53	So, essentially what is means, is that when this update advertise to the other end of the network,
0:05:00	which in this case where table A, should go from switch 4 to router 4,
0:05:05	router 4 to router 5, then 5 to BB3, router 4 inside of the VPNv4 update.
0:05:17	Not only is it telling router 5 what the route is,
0:05:21	but it's telling it inside of the date plane, when you send me the traffic for that particular destination,
0:05:28	I want it to have label number 29.
0:05:32	This is now what we consider the VPN label.
0:05:37	So, if we were to look at the packet format,
0:05:40	we would have our underlying IP packet that we're transitting,
0:05:44	so let's say it's in ICMP packet we're doing a basic ping.
0:05:48	So, the ICMP packet is then gonna have its basic IP header,
0:05:54	On top of this, there's gonna be two separate labels.
0:05:58	The inner label is the VPN label, that's what router 4 said you should use value 26.
0:06:07	Then we have the transport label, which is going to change on a hop-by-hop basis inside the MPLS transit network.
0:06:18	The key is that this outer transport label, should be going to where?
0:06:23	From router 5's prospective the trasport label, to get to 10.0.4.4:1:10.1.10.10/32, should be to where?
0:06:40	Let's look at this from router 5's prospective,
0:06:44	we look at the same output in the BGP table,
0:06:49	it says, I know what the label is that I'm suppose to be using,
0:06:55	the out going label number is 29.
0:07:00	Which actually is not what, actually it's 29.
0:07:03	So, I wrote 26 that should be 29 there.
0:07:09	Router 4 sees this is the in coming label, which means that router 5 sees it as the out going label.
0:07:19	Router 5 says that next hop is what for this particular prefix?
0:07:24	The next hop is 10.0.4.4.
0:07:28	Now, the way that the route recursion logic is gonna work here,
0:07:32	is that the VPNv4 route, when we look in the VRF table,
0:07:37	so we Show IP Route VRF A, the next hop value for the BGP learned destinations,
0:07:47	is gonna point to a next hop that's not actually in that VRF table.
0:07:52	So, notice on router 5, it says, to get to 10.1.10.10/32,
0:07:57	we need to use the next hop 10.0.4.4.
0:08:01	But if we Show IP Route VRF A 10.0.4.4,
0:08:07	we don't actually have that next hop.
0:08:11	So, internally to the CEF process, the router knows that when a VPNv4 update comes in,
0:08:18	the next hop value is gonna point to an address that's in the global routing table.
0:08:25	So, router 5 does not do the route recursion in the VRF, it actually does it in the global table.
0:08:30	Says do I have an IGP route to 10.0.4.4, in this case I do.
0:08:35	It's going out towards the next hop 10.0.35.3,
0:08:40	which is really directly connected on my Fast Ethernet 0/0.35.
0:08:46	If router 5 looks at the Show MPLS Interfaces, and it finds that Fast Ethernet 0/0.35 is running MPLS,
0:08:57	it's then gonna look up in the LFIB, to figure out do I have a label value that's associated with 10.0.4.4.
0:09:08	So, now router 5 says, internally Show MPLS Forwarding Table for 10.0.4.4.
0:09:15	Says, I do have a label associated with that,
0:09:18	because the IGP route is learned on an interface that is running LDP.
0:09:23	So, whoever my IGP neighbor is out that link, they should also be allocating the A label through LDP.
0:09:31	The out going label is 22.
0:09:35	Through the VPNv4 update, router 5 already knew what the VPN label was supposed to be.
0:09:45	Says, the VPN label is 29.
0:09:47	So, now what we should see, is that when router 5 actually forwards the packet for this particular destination,
0:09:56	the packet is gonna be received in from BB3, the final destination is down here.
0:10:03	Router 5 says, this actually recurses towards router 3, with the trasport label of 22.
0:10:13	So, this means that 22 is gonna be in the outer header.
0:10:17	I know what the VPN label is, the VPN label is 29,
0:10:21	then we have the actual payload, which is gonna be the ping.
0:10:26	Now, when router 3 receives this in, since 3 is a P router,
0:10:32	3 should be doing the swap operation, saying that 22 is coming in,
0:10:37	I need to figure out what is the out going label for that particular value.
0:10:43	So, in router 3 if we look at the Show MPLS Forwarding Table,
0:10:47	says the label coming in is 22, for that we're gonna change it to 16,
0:10:55	and we're gonna forward it out Fast Ethernet 0/0.23, towards router 2.
0:11:01	So, now between router 3 and router 2 the label value is changed.
0:11:05	Router 3 performs a swap, exchanging 22 to 16.
0:11:10	What it is not doing though is modifying the VPN label.
0:11:14	So, the VPN label is staying as 29, the ICMP payload is not being looked at.
0:11:19	Now, the packet gets to router 2.
0:11:22	2 needs to say, what do I do when I receive the in coming label 16?
0:11:29	Ideally in coming label 16 should be pointing towards the loopback of router 4.
0:11:34	We Show MPLS Forwarding Table, says for in coming 16,
0:11:39	that's actually going to a destination that is directly connecting to my connected neighbor,
0:11:46	so I am the Pen ultimate hop for this destination,
0:11:50	so I'm not gonna swap the label, I'm actually gonna remove the top most label from the stock, which is the pop tag.
0:11:58	Now, again as I mention before, this is different than saying, no label.
0:12:05	So, router 2 now removes label number 16, and it sends the packet down to router 4,
0:12:13	just with label number 29.
0:12:18	When router 4 receives this in, it says, the packet is MPLS so I need to look up in the LFIB.
0:12:25	We Show MPLS Forwarding Table, says, label number 29 is actually for one of my VRF interfaces.
0:12:34	It's going out Fast Ethernet 0/0.104, specifiically the destination is 10.1.10.10,
0:12:41	but since this is not an MPLS interface, I'm gonna remove the entire stock.
0:12:50	So, now the labels are removed, it's exposing the normal IPv4 destination,
0:12:56	and then the packet is switch towards this particular neighbor.
0:12:59	Which is 10.1.104.10.
0:13:05	So, the key for the end and date plane, is that to begin with,
0:13:11	the in comig PE needs to know what is VPN label that the remote PE has allocated.
0:13:19	So, router 4 is the one that's advertising to router 5,
0:13:22	what is the VPN label that's supposed to be used to that particular destination.
0:13:27	That's what should come inside the VPNv4 update.
0:13:33	Then router 5 would need to know what is the transport label, that's used to get towards the PE.
0:13:40	Because remember the outer label which is the trasport label,
0:13:44	this one is saying, which PE, where the inner label, which is the VPN label,
0:13:53	is saying, which customer?
0:13:59	So, based on the fact that router 4 is allocating separate label values,
0:14:03	for each of the end customer routes,
0:14:06	it's essentially signaling inside of the data plane to router 5,
0:14:11	how the traffic should be received back in the reverse way.
0:14:18	Now, if we actually look at the packet flow for this,
0:14:20	let's go to router 2 and router 3, and look at the Debug MPLS Packets,
0:14:27	Debug MPLS Packets, on both of these neighbors,
0:14:31	then from switch 4, I'm gonna ping basically the same thing I did before ping 30.0.0.1,
0:14:41	source from lopback 0, I'm just gonna send one packet.
0:14:47	Router 3 says, the label came in, as 22, with the inner label of 29.
0:14:57	This is what we would expect when 3 receives the packet.
0:15:03	Router 3 is then doing a swap, it says, I'm changing 22 to 16,
0:15:07	when i'm leaving 29 alone cause that's the under, that's the inner VPN label.
0:15:23	Next to packet is switch to router 2,
0:15:26	router 2 receives it in 16, with an inner label of 29,
0:15:32	so 29 is still the VPN label, it's removing the topmost one,
0:15:37	so it's doing the pop operation, and then trasmitting this out towards router 4.
0:15:43	When router 4 gets this in, if we were to look at the Debug MPLS Packets,
0:15:49	what we should see is that router 4 receives the MPLS packet in,
0:15:54	but then doesn't send a label back out,
0:16:00	because this is where the full label stock is being removed.
0:16:05	So, the packet is coming in as MPLS but then it's going out as regular IPv4.
0:16:13	Now, where this could potentially be a problem in the actual data plane,
0:16:17	is if somewhere along the trasfer path,
0:16:20	the routers do not agree on what the transport label is supposed to be,
0:16:25	or if the VPN label is exposed to soon before we get to the PE.
0:16:33	Now, that would be the similar case to where we saw before,
0:16:36	that if router 5 was peering with router 4 via the connected interface,
0:16:43	as supposed to the loopback, so 5 peers with 4's Ethernet,
0:16:49	instead of the loopback, it would mean that the next hop value is gonna be on this .24 address,
0:16:55	as the update goes out to router 5.
0:17:00	Now, we could change this without having to mess too much up with the actual peering,
0:17:06	because what I could do is on router 4 can figure a route map,
0:17:12	that says, to router 5, that it's going to set the IP next hop to 10.0.24.4,
0:17:22	then under BGP this is gonna be applied under address family VPNv4.
0:17:30	Because the key is that this next hop attribute is part of the VPNv4 route.
0:17:36	So, if I were to say as I sent update out to 10.0.5.5,
0:17:40	used the route map to R5,
0:17:48	to R5 out,
0:17:53	then we send them a route refresh,
0:17:54	we would say, Clear IP BGP VPNv4 unicast the As number,
0:18:09	and we're Clearing this outbound, we're sending them a new route refresh out.
0:18:14	If we now look at the change on router 5, look at the Show IP BGP VPNv4 Unicast,
0:18:20	we should see that this 10.0.4.4 is gonna change to 10.0.24.4,
0:18:29	so it's 10.0.4.4 and now it's 10.0.24.4,
0:18:35	the end result is now that the traffic is gonna be lost in the data plane.
0:18:42	Because now we're using the incorrect transport label,
0:18:47	in order to get to router 4.
0:18:49	In this case we're now using the transport label that points at the link between 2 and 4,
0:18:55	which means that the PHP process, what happened on router 3,
0:18:58	as supposed to happening on router 2.
0:19:02	so, essentially router 2 is gonna be exposed to the VPN label,
0:19:06	and it does not know what to do with that value.
0:19:12	We could see this if we were to go to router 2 and look at the Debug MPLS Packets,
0:19:17	we see that the wrong number is basically coming in,
0:19:21	so if we send a bunch of these pings again, it says the packet is coming in with label 29,
0:19:36	so it's coming in from router 3 with label 29,
0:19:41	when we Show MPLS Forwarding Table, we don't have that label 29 allocated.
0:19:48	So, router 2 is simply dropping the traffic as it doesn't know what to do with that number.
0:19:56	So, again in order to prevent this, we need to make sure that the VPNv4 peering,
0:20:01	ends up with a next hop value, that is to the loopback addresses that are advertised into IGP.
0:20:12	Now, normally the way that this is gonna happened when we look at router 4's configuration,
0:20:15	and we could see it, it actually does give that error message.
0:20:18	So, it's next hop may not be reachable from the neighbor because it's not a loopback.
0:20:23	If we Show Run Section Router BGP,
0:20:32	simply based on the fact that we are peering from our loopback 0,
0:20:38	out to router 5, we should not need to change the next hop value.
0:20:44	So, automatically under the VPNv4 address family,
0:20:47	whatever is our update source is gonna be what the next hop value is.
0:20:54	Now, even in the case where the PE to CE protocol is BGP.
0:20:58	So, let's now say in addition to the normal VRF A routes,
0:21:08	I also wanna get the VRF D routes into the RIP process of BB3.
0:21:16	So, if we to actually go to BB3, and look at the Show IP Route RIP,
0:21:26	we could see right now we have the routes to switch 4.
0:21:35	What I wanna do here is change the topology, so in addition to having the switch 4 routes,
0:21:41	it also has the routes that are coming in from BB2.
0:21:47	Now, there's a couple different ways that we could do this.
0:21:50	The ultimate key again, is that the VPN memebership is controlled by what?
0:21:58	Not the route distinguisher, but the route target.
0:22:04	So, this means that when the routes from VRF D are exported out to BGP,
0:22:12	is the route target value that is created matches the import policy of router 5,
0:22:19	then router 5 should allow those into the VRF table.
0:22:24	So, we could do this two different ways.
0:22:26	We could export a new value, on router 4 in the VRF D,
0:22:31	and import a new value on router 5,
0:22:34	or on router 4 we could export a value that router 5 is already importing.
0:22:42	Now, really there's no advantage of using one over the other,
0:22:45	it's just more of a management technique for the service provider
0:22:48	how they wanna keep track of what the route target values are,
0:22:52	so, if I wanna say that for every site inside VRF A,
0:22:56	I want them to get the VRF D routes,
0:22:58	then I can simply export it as a particular value that they are using.
0:23:03	So, let's take a look at this on router 4.
0:23:07	If we were to go to the IP VRF D, and say the route target export is 1:1,
0:23:22	and let's remove that route map that is under the BGP process
0:23:25	because we know that's gonna cost the actual data plane to fail.
0:23:33	So, under router BGP 200, I remove the route map,
0:23:45	then we'll send a new route refresh out to router 5,
0:23:50	So, we'll say, Clear IP BGP VPNv4 Unicast 200 Out,
0:24:00	on router 5 we should now see the next hop is gonna change from the 24.4 to the 4.4,
0:24:07	so it should change from the physical interface to the loopback, which it does,
0:24:11	and result to this is now that the data plane should be fixed,.
0:24:15	So, now we have connectivity.
0:24:18	But if we now look at the updates of router 5,
0:24:20	and just say Show BGP VPNv4 Unicast All,
0:24:31	we see now in addition to the routes that are already inside VRF A,
0:24:39	we're now learning the routes that came from BB2.
0:24:41	Because these particular prefixes even though they have different route distinguisher,
0:24:49	they're imported into VRF A, because they have a route target,
0:24:55	that matches my import policy.
0:24:59	So, if I Show BGP VPNv4 Unicast 222.22.2.0/24 Unicast All,
0:25:16	it says that for table A, the route target is 1:1, and this is what I already imported.
0:25:25	So, now if I were to go to BB3, and look at the Show IP Route RIP,
0:25:31	we could see now those additional routes are being installed.
0:25:35	Now, on the way back BB2 is not yet gonna have the routes to BB3,
0:25:41	because on VRF D of router 4, we did not import what router 5 is exporting.
0:25:52	So, if we Show Run Section IP VRF, under VRF D we're doing an export policy,
0:26:02	that is for 1:1, but we are not importing anything.
0:26:08	I could configure a new import value, let's say route target import is 5:5,
0:26:15	then on router 5, under VRF A, IP VRF A,
0:26:22	I could now define a new route target export policy, that matches 5:5,
0:26:29	with the key point being here that I'm allowed to export multiple values at the same time.
0:26:38	So, when we look at VRF A, we're not only exporting 1:1 but also 5:5.
0:26:45	So, there's really no effective limit as to how many values you can export and how many values you can import.
0:26:51	Now, eventually you're gonna hit some hard limit based on the software, but it's effectively unlimited.
0:27:01	So, this would allow us to do that central services type VPN,
0:27:06	where the service provider is hosting some sort of application possibly for the customer,
0:27:11	like hosted mail or hosted DNS or also network management,
0:27:17	where maybe the service provider is running SNMP pooling or the net flow collection,
0:27:23	on behalf of the customer, it means that they would have to have reachablility to some particular address.
0:27:30	So, you'll also see under the VRF, if we say IP VRF A,
0:27:34	we can configure on export map, or an import map,
0:27:41	that is effectively just a route map that matches different criteria that we can define.
0:27:47	So, we can match not only on the route target but we can match on a specific prefix,
0:27:51	or match on other community values for BGP.
0:27:53	Now, one of the problem I want to show here, for troubleshooting the data plane of MPLS,
0:28:07	is what would happenif between router 2 and router 3,
0:28:13	that either MPLS was not in enabled on the link,
0:28:18	or for some reason, we don't have the correct label binding value,
0:28:25	for the next hop value in BGP.
0:28:28	So, let's say we were to go to router 2, and first we'll just disable MPLS.
0:28:34	Now, up to this point we know that there is connectivity.
0:28:36	There is no problem between the VPN A sites.
0:28:43	So, now on router 2, I'm gonna go to interface Fast Ethernet 0/0.23,
0:28:47	and simply say No MPLS IP.
0:28:53	This means that this is going to remove the peering between router 2 and router 3.
0:29:01	So, ultimately we should see that this is gonna cost the data plane to fail.
0:29:07	But the problem in troubleshooting something like this,
0:29:09	is it, it's not necessarily reflected in the control plane exactly what the problem is.
0:29:16	So, if I were to go to switch 4, and look at the Show IP Route RIP,
0:29:22	I do have those routes, so I have the routes of the 30.0.0.0 network,
0:29:31	but when I actually send the packets into the network, they're getting drop to the data plane.
0:29:36	Now the place that we would see this, what again we would have to track down on a hop-by-hop basis,
0:29:42	what are the actual label values that are used for the VPN label, versus the transport label.
0:29:51	So, again let's look at what is the VPN label that router 4 is allocating, for the loopback of switch 4.
0:30:00	We could see this either on router 4 if we were to look at the Show BGP VPNv4 Unicast All 10.2.10.10 or 10.1,
0:30:18	10.1.10.10, again this is label number 29.
0:30:27	So, from router 5's perspective it should be using label number 29 as the VPN label,
0:30:32	then is we Show MPLS Forwarding Table, it says,
0:30:36	"To get to the loopback of router 4 I'm gonna use label number 22."
0:30:40	So, this now means from router 5's perspective, when I sent packets out towards this destination,
0:30:46	the full label stock is gonna be 22 for the transport label, and 29 for the VPN label.
0:30:53	That is followed by the actual IP payload.
0:30:57	When this gets to router 3, if we look at the Show MPLS Forwarding Table,
0:31:07	it says for the in coming label 22, the out going label is untagged.
0:31:16	So, again for some versions this will say no label for some version this will say "untagged".
0:31:22	Basically what this means is that router 3 failed to receive a label binding about 10.0.4.4/32.
0:31:33	So, either it's because that's on a non-MPLS enabled interface,
0:31:38	if we Show MPLS Interfaces, we can see that Fast Ethernet 0/0.23 is running LDP,
0:31:46	so that's not the case around router 3.
0:31:48	It could be that there's something wrong with the LDP adjacency,
0:31:53	which in this case we know that's what it is, because I disabled the protocol on router 2,
0:31:58	or it could have to do with some sort of filtering of the actual labels that are being advertised.
0:32:05	So, we can specify a manual policy under the MPLS LDP advertised labels for,
0:32:13	and specify an access list that matches the particular prefixes that we want to advertised labels for,
0:32:21	then we could say no MPLS LPD advertised labels and withdraw the prefixes that we do not wanna do bindings for.
0:32:32	But again, the key point is that when we look at the Show MPLS Forwarding Table,
0:32:36	it should never say untagged or no label, out in interface that supposed to be running MPLS.
0:32:44	Now, it can say Pop Tag. If it say Pop Tag,
0:32:47	it would mean that we are the next to last hop for that particular destination.
0:32:52	So, Pop Tag is the indication of the PHP process happened which is normal.
0:32:57	But untagged means that for some reason the label binding failed.
0:33:05	So, if we were to go to router 2, and re-enable MPLS IP,
0:33:13	and we should see now that we do have a label value,
0:33:17	for 10.0.4.4 so once the LDP adjacency comes back,
0:33:24	okay, now we have the label 16.
0:33:27	If we now check the data plane, now we see the transport is fine.
0:33:34	But the key is that this is not affecting any of the advertisements that are related to BGP,
0:33:40	or related to the PE to CE routing protocol.
0:33:43	It was a problem in the underlying transfer path of the MPLS network,
0:33:47	because they didn't agree on what the trasport label was.
0:33:52	Now, another case that this could happen,
0:33:54	is that for some reason the label binding doesn't match the actual IP routes that's in the routing table,
0:34:02	and the case that this can occur in is that if we're doing any type of summarization in IGP,
0:34:09	or for some reason we have a mismatched in the length of the prefixes.
0:34:14	Now, in this particular case, one reason this could happen,
0:34:19	is that if the loopback of router4, was not a /32 interface,
0:34:26	so if I changed this to 10.0.4.4 let's say /30,
0:34:36	actually that's not balanced so let's say,
0:34:42	let's use 25 valid, okay, so 25, if we Show IP Route Connected,
0:34:50	we could see that prefix is no longer a /32.
0:34:54	However, since this is being advertised in to OSPF,
0:34:59	with the default network type of loopback,
0:35:03	the remote routers are gonna received this as what?
0:35:08	They're gonna received this as /32.
0:35:11	Okay, the IGP advertisement is gonna be /32.
0:35:13	So, if I were to go to router 5, and say, Show IP Route for 10.0.4.4,
0:35:20	we still see this as the /32 host route.
0:35:24	Now, the change on the advertisement it's not gonna affect our transit there.
0:35:28	So, if I ping 10.0.4.4, there's still no problem with router 5 reaching that.
0:35:34	We'll see what the issue is now, that there will be a difference in the label allocation,
0:35:41	versus what the router says that the actual network is connected.
0:35:46	So, what I may need to do in order to refresh this,
0:35:56	let's say, Clear MPLS LDP Neighbor Star (*),
0:36:08	and we'll say this on everyone on the trasfer path,
0:36:12	so, some of the versions support this,
0:36:15	again the versions that on the router 1, 2 and 3, these are the older 12.3 Mainlines.
0:36:21	So, now what we should see if we were to go to router 2,
0:36:25	and look at the Show MPLS Forwarding Table,
0:36:33	it says that, for the prefix 10.0.4.4/32, we are supposed to pop the tag,
0:36:43	which is correct because we are the next to last hop.
0:36:53	Then router 2 is gonna advertised to 3, on 3 let's say Show MPLS Forwarding Table,
0:37:02	we see router 3 does have a label value assigned,
0:37:07	3 should then be advertising this to router 5,
0:37:11	on router 5, if we Show MPLS Forwarding Table,
0:37:18	okay, we do have the label for router 4's loopback and if we look at this on router 4,
0:37:22	let's say, Show MPLS Forwarding Table, notice that on the output of the LFIB here,
0:37:30	it's not gonna show you your connected interfaces.
0:37:33	So, to figure out what your own local label values are,
0:37:37	you'd need to go to the other side what they allocated.
0:37:41	You could look at this on the debug, you could say, Debug MPLS LDP Bindings,
0:37:47	but it's a pretty noisy debug, it's gonna show a lot of information,
0:37:51	and usually it's too hard to sort through what are the actual label values that are being advertised.
0:37:56	But, let's try on router 4 here,
0:37:58	let's say, Clear MPLS LDP Neighbors,
0:38:11	then let's look at this on router 2,
0:38:14	and it may not actually have this problem in this particular version,
0:38:19	but the probelm you could run into, is that when there is a descrepency between the IGP route that you're learning,
0:38:27	and the label value that is being allocated,
0:38:30	or actually the address that the label is allocated for,
0:38:37	then the router's not actually gonna install the particular label value.
0:38:41	Now, what I mean by this, if we look at the configuration change I made on router 4,
0:38:46	the loopback interface is now configured as 10.0.4.4/25.
0:38:55	But this is being advertised in the IGP 10.0.4.4/32.
0:39:02	So, normally what happens with LDP, is that for every IGP route you have,
0:39:14	for every IGP route you have there's gonnabe a corresponding label value advertised.
0:39:19	So, if router 4 locally has the /25 address,
0:39:24	it's gonna advertised the label to router 2 for that particular prefix, for this /25.
0:39:32	The problem is router 2 doesn't have the route to that particular destination.
0:39:37	It has the /32.
0:39:40	So, the end result is that you're trying to do a label binding for a route that the remote neighbor doesn't actually have.
0:39:47	So,usually this is only gonna happen when you're doing summarization,
0:39:51	if you're taking a longer matched, that should be the exact route to the end point that is to BGP peering,
0:39:59	and then you are summarizing the prefix,
0:40:02	So, let's say we did it that way in on router 4.
0:40:06	Let's do it the opposite way.
0:40:08	Let's go to router 4, and we'll say on the loopback,
0:40:12	this actually is a /32.
0:40:15	So, let's say the address is 10.0.4.4/32,
0:40:20	this is not directly in area 0, so it's not on area 0,
0:40:27	what I'm gonna do instead is do redistribute connected,
0:40:33	so let's say, redistribute connected subnets, if we look at the route now on router 5,
0:40:38	router 5 should see this as an E2 route, which it does.
0:40:45	So, this is being advertises as an external route.
0:40:48	If router 4 were then to summarize this,
0:40:50	let's say summary address is 10.0.4.0.255.255.255.0,
0:41:04	this /32 now should be advertised as a /24.
0:41:10	So, if we look at the label binding, let's say, Show Forwarding Table for 10.0.4.4,
0:41:19	then we look at this on a hop-by-hop basis, so from 5 this should go to 3,
0:41:25	from 3 this should go to 2, from 2 this says, and the prefix is /24 and it's coming in from router 4,
0:41:36	this particular version is not gonna have the problem.
0:41:39	So, it may have actually be a bug that they fixed,
0:41:42	but the end result is that if the router doesn't agree on what the mask is,
0:41:47	of the prefix that is trying to do the label binding for,
0:41:50	you can see that the routers don't agree on what the transport label is supposed to be,
0:41:55	and ultimately it's a failure of the data plane.
0:41:59	So, it's kind of a tricky problem to troubleshoot because the label value is gonna be installed,
0:42:04	but it ends up being in the wrong number because they're talking about two different prefixes.
0:42:09	Because we know 10.0.4.4/32 is not the same route as 10.0.4.0/24.
0:42:16	So, if they're separate label number is associated with them,
0:42:18	then the router might not be agreeing what I'm supposed to used when the packet is actually sent outbound.
0:42:25	So, again when we're look at the final verification of these,
0:42:29	we need to look at all of the individual pieces that are making up the Layer 3 VPN.
0:42:34	So, the first would be the actual VRF configuration on the PE.
0:42:40	So, in the VRF do we have the route disinguisher configured,
0:42:45	this is gonna make sure that the prefix is unique through out the intire MPLS network,
0:42:51	do we have the correct route target import,
0:42:55	and the route target export policy.
0:43:00	Again, what's site 1 is exporting is what site 2 should import and vice versa.
0:43:07	If you use the same value as import-export everywhere on a particular VPN,
0:43:10	and then you're never gonna have that problem
0:43:12	It's pretty much only when you want a complex topology,
0:43:15	something like hub and spoke or central services, that you would change what the route target values are.
0:43:23	The next would be to assign the VRF,
0:43:28	so this is where we actually binding it to the interface,
0:43:31	again the potential issue here is that it's gonna remove the IP address once we do the assignment.
0:43:36	So, if we didn't know what the address was to begin with,
0:43:38	then that might be a problem.
0:43:43	Next step would be to enable the VRF aware routing process.
0:43:49	so, this would depend on what is the customer running.
0:43:52	Could be RIP, could be EIGRP, OSPF, static routing BGP policy run,
0:43:57	okay, so basically any other combinations are gonna be fine.
0:44:00	If we're using BGP,
0:44:02	remember that the peering is gonna be dependent on where that particular neighbor exist in the routing table.
0:44:10	If their address is on the global table,
0:44:12	it means the neighbor statement should be on the global BGP process.
0:44:16	If their address is inside of the VRF,
0:44:19	then the neighbor statement should be under the address family IPv4 VRF.
0:44:24	Now in few minutes we'll also see some problem with OSPF,
0:44:28	that we could get into, most of the time with RIP and EIGRP,
0:44:31	they're pretty full profest to the configuration of it.
0:44:37	Okay, just a thing about the normal redistribution rules,
0:44:39	that when we're redistributing into RIP, we need to set a metric value.
0:44:42	When we're redistributing in to EIGRP, we need to set a metric value.
0:44:46	The only exception for that would be if the cost where the hop count,
0:44:51	is automatically encoded inside of BGP.
0:44:55	So, ultimately that's gonna depend on the particular version that we're running.
0:44:59	So, if we were to look at, let's see who is running EIGRP here.
0:45:05	Switch 3 is running EIGRP, if we Show IP Route EIGRP,
0:45:13	these prefixes that came from the other end of the network,
0:45:17	notice that these are not EIGRP externals.
0:45:22	So, even though we redistributed from BGP into EIGRP,
0:45:26	we can look in the topology table, so Show IP EIGRP Topology for 200.0.0.0/24,
0:45:38	and the individual values that are making up the composite metric,
0:45:42	those were automatically encoded inside the BGP update.
0:45:48	So, the end and metric is still there.
0:45:49	This is configured automatically or enable automatically through the EIGRP cost community for BGP.
0:45:56	So, as long as the particular IOS version supports it,
0:45:58	there's no special configuration you need to do.
0:46:01	Just redistribute between EIGRP and BGP it's gonna be automatic.
0:46:05	But for previous versions that did not automatically encode this,
0:46:08	then you would need to set the metric value.
0:46:12	The othe key point is that when you're defining the VRF aware process,
0:46:18	the VRF aware EIGRP process is not automatically going to inherit the autonomous system number from the global process.
0:46:30	So, we have the global process 65535 basically that's used for nothing here.
0:46:35	Because we're not running EIGRP in the global routing table.
0:46:39	For table number, for table VRF B, we're running autonomous system number 10.
0:46:48	So, once we have the VRF routing work, that's gonna be the PE to CE routing,
0:46:53	and then we need the VPNv4 peerings.
0:46:59	So, this is under the address family VPNv4 unicast inside BGP,
0:47:03	this is where the PE routers are going to establish the peering
0:47:07	so that they can ultimately exchanged the routes that are redistributed,
0:47:12	from the VRF into the MPLS process.
0:47:17	Once the VPN peers are up, then we have the redistribution,
0:47:23	and ulitmately that should be our final step.
0:47:25	Now, again this is assuming that the MPLS network in the middle of the transfer path is already working to begin with.
0:47:32	So, if there's some sort of problem in the IGP reachability between the PE routers,
0:47:37	or some problem with the transport label between each other's loopbacks,
0:47:40	then that's going to affect the end-to-end connectivity for the Layer 3 VPN.
0:47:45	So, in reality there should be a couple steps before this,
0:47:48	Point 5 that says verify the MPLS network in the middle,
0:47:53	to make sure that you do have proper transport between the PE routers.
0:47:58	There is a question here, does the volume 1 workbook cover all that's needed for the lab exam?
0:48:04	I'm not a 100% sure of hand exactly which topics that it, does cover.
0:48:09	Really there's not that much that's within the scope of MPLS,
0:48:13	and it may seem like a lot that we're talking about here today,
0:48:15	but when you look at the other topics,
0:48:18	basically we're touching on just a very, very tip of how the MPLS works.
0:48:22	So, there's a lot of other topics in the Layer 2 MPLS VPNs, the inter-AS VPNs,
0:48:29	multi-cast over MPLS, QoS , traffic engineering,
0:48:34	so that's a much larger scope, that stuff is definately not gonna be included in routing and switching.
0:48:40	But if you're comfortable with everything that I've shown today,
0:48:43	then you should definately be prepared for what's gonna be within the scope of the lab exam.

Now Viewing

CCIE Routing & Switching Advanced Technologies Class
Title:	CCIE Routing & Switching Advanced Technologies Class
Duration:	81h 59m
The CCIE Routing & Switching Advanced Technologies Class is the first step in understanding CCIE level technologies and is a companion to the Advanced Technologies Lab Workbook. Each technology you need to know for the CCIE Routing & Switching lab will be described in detail using an instructor led hands on demonstration. The class consists of over 80 hours of in depth explanations and examples.
Get instant access to our entire library!
$159/month	Add to Cart
Download this Course
$299.00	Add to Cart

MPLS Layer 3 VPN Verification & Troubleshooti...

Create Bookmark