CCIE R&S Advanced Technologies Class v4.5 - MPLS Layer 3 VPNs and VPNv4 BGP

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 06m
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 17m
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 02m

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	In our next section here for MPLS,
0:00:16	we're gonna look at the details of the PE to CE routing configurations.
0:00:20	Look at how to configure the different VRF aware routing processes
0:00:25	to ultimately then exchange the customer-learned routes into the MPLS networks
0:00:30	and get end-to-end reachability over the Layer 3 VPNs.
0:00:36	Now, as we can see based on the diagram here,
0:00:38	we have four different VPNs we're gonna be defining.
0:00:42	We have VRFs A through D,
0:00:44	where the different provider edge routers, routers 4, 5 and 6
0:00:48	are gonna have separate customers respectively.
0:00:52	Now, again, for the different variations of the routing protocols,
0:00:56	we essentially can use any of the protocols as a VRF aware process.
0:01:01	We could simply do static routing, we could run any of the IGPs,
0:01:04	we could run BGP or we could do policy routing.
0:01:07	We'll see that there are some separate caveats for OSPF versus EIGRP versus RIP and BGP.
0:01:15	So, not only do you need to be aware of the regular global routing issues with the IGPs and BGP.
0:01:22	But also what's going on with the VRF aware process.
0:01:27	So, first, let's start on router 4,
0:01:30	and our first step would then be to define the VRFs.
0:01:33	Assign them to the interfaces.
0:01:35	And then enable the VRF aware routing process.
0:01:39	On router 4, we're gonna have three different VPNs.
0:01:42	One of them is VRF A.
0:01:45	One of them is VRF B. The other one is VRF D.
0:01:50	For each of these separate routing tables, I need to specify the route distinguisher,
0:01:56	which again once I export the routes into the MPLS network,
0:02:00	this is gonna make sure that they are unique even if the customers have overlapping address space.
0:02:07	Now, again, the format of the route distinguisher, it can be two ways.
0:02:12	It can either be the AS number followed by a locally significant number.
0:02:16	Or it could be in the IP addressing format.
0:02:21	Now, which one is gonna be used as really just a preference of the service provider?
0:02:26	If my AS number is 200 here,
0:02:29	maybe I wanna say 200 and this is VPN 1.
0:02:34	Or I could specify that the route distinguisher is based on my router ID.
0:02:41	So, my loopback address, and on router 4, this is the first VPN.
0:02:47	So, again, as long as it makes the prefix unique throughout the entire MPLS network,
0:02:52	that's what the goal of the route distinguisher is.
0:02:55	It's not used to denote what is the VPN membership of the route.
0:03:01	That'll be a separate attribute that we're gonna talk about here shortly.
0:03:04	So, for these different VRFs, we need the separate route distinguishers.
0:03:08	We'll say for VRF B, this will have the second distinguisher.
0:03:14	And then VRFD, this will have the fourth one.
0:03:19	But again, technically, this is only gonna make sure that the route is unique throughout the network.
0:03:25	Next step is that we're going to apply the VRF to the interface.
0:03:29	So, before we do this, let's look at the Show Run Include Interface or IP Address.
0:03:35	Because I wanna know what are the currently assigned addresses before I actually apply the VRFs.
0:03:42	Now, there's three diffrerent customers router 4's gonna be servicing.
0:03:46	The connection to switch 3 is using VRF B.
0:03:50	The connection to switch 4 is using VRF A and then the connection to BB2 is gonna be in VRF D.
0:03:56	So, our first one, which is Fast Ethernet 0/0.49, this is going to switch 3.
0:04:02	Again, this is gonna be in IP VRF Forwarding B.
0:04:07	So, if we make a mistake on the configuration in this portion, then ultimately,
0:04:11	the customer routes would not have reachability to each other.
0:04:16	Fast Ethernet 0/0.104, this is gonna be in VRF A.
0:04:24	Then I re-issue the IP address.
0:04:28	Then lastly, Fast Ethernet 0/0.192, this is gonna be in VRF D.
0:04:35	And then again, we re-apply the address.
0:04:40	So, now, at this point, if we look at the Show IP Route VRF*,
0:04:45	this is gonna show us the separation fron the global routing table
0:04:49	to the individual customer tables.
0:04:52	Inside my global routing table, I have the IGP routes to my internal network.
0:04:59	In table A, I have the link that's going to switch 4.
0:05:03	In table B, I have the link that's going to switch 3.
0:05:05	And then finally, in table D, I have the link that's going to BB2.
0:05:11	So, let's do this on router 5 and 6 as well.
0:05:15	Router 5 is going to have two separte VRFs.
0:05:19	Specifically, these are A and C.
0:05:28	We'll say IP VRF A.
0:05:30	I'll give it to route distinguisher of 200:1
0:05:37	Okay, so again, it doesn't really matter, as long as it makes the end result that the route is unique.
0:05:41	I could use whatever numbering format that I want.
0:05:45	Then for VRF C, we'll say Route Distinguisher 200:3,
0:05:52	it's gonna be our third VPN.
0:05:54	Then at the individual link levels, if we Show Run Include Interface or IP Address,
0:06:05	the link to...
0:06:08	BB3, that's gonna be on VRF A.
0:06:11	So, IP VRF Forwarding A.
0:06:15	Then again, apply the IP address.
0:06:21	Then the link to switch 2, Fast Ethernet 0/0.58, this is gonna be in VRF C.
0:06:29	Now, if I type the wrong name here,
0:06:31	it's gonna simply tell us that that VRF is not configured.
0:06:34	Okay, likewise, this is case sensitive, if I put a lower case c, it's gonna say "That's not valid."
0:06:38	It has to be in the correct case.
0:06:43	Then lastly, re-apply the address.
0:06:49	So, for clarity, this could be one of the configurations that you may want to do a notepad.
0:06:53	Just to make sure that the correect interfaces are matching up.
0:06:56	That you're using the correct route distinguisher values.
0:06:59	And then ultimately, the route targets.
0:07:02	Where we'll see later, the route targets are more significant than the route distinguishers
0:07:06	because that's gonna control where the routes are going to belong to on a per VPN basis.
0:07:14	So then again, lastly on router 6, we have two VPNs.
0:07:18	We have IP VRF...
0:07:22	B.
0:07:25	We'll say this is again 200:2.
0:07:30	Then VRF C is 200:3.
0:07:34	So generally, you would stick with one naming convention but within the scope of the lab exam,
0:07:38	if they don't tell you what to use, then technically, you gonna use anything here.
0:07:44	Then let's look at the Show Run Include Interface or IP Address.
0:07:54	The link to switch 1, this is gonna be IP Forwarding or IP VRF Forwarding...
0:08:00	C.
0:08:03	Then the link to BB1, this is gonna be IP...
0:08:08	VRF Forwarding B.
0:08:12	So, one way that we could do this would be to go to all the links.
0:08:16	Assign the VRFs and then simply take the same ouput from before
0:08:20	and paste it back into the router.
0:08:23	So, now, all the interface addresses, they're gonna be reassigned.
0:08:26	But the key is if you don't check this to begin with,
0:08:29	you might not know what was the actual address and mask that was assigned to that particular interface.
0:08:35	If you do accidentally do that, you assigned the VRF and you didn't know what the address was,
0:08:40	on we thing you could potentially do would be to look at the startup config.
0:08:44	So, if your config was already saved from before,
0:08:48	you could do the comparisson between these two and see what was previously assigned.
0:08:57	But ideally, you're not gonna run into that case because you would
0:09:00	check the running configuration before you make the changes for the VRFs.
0:09:06	So, before we move on, next step would be to do a basic verification.
0:09:10	To make sure that the interfaces are in the correct VRFs and we do have connectivity to the other side.
0:09:15	From router 6, we're gonna ping inside VRF B, 54.28.1.254.
0:09:26	So, I have connectivity to BB1 and it's in the correct VRF.
0:09:30	And VRF C, this should be the link...
0:09:34	to switch 1.
0:09:41	Which I do have connectivity.
0:09:46	Then for router 4 and router 5, we're basically gonna be able to tell whether this configuration is correct
0:09:50	once we configure the router.
0:09:54	So, from router 4, there's gonna be three different protocols that we are running.
0:09:59	We're running VRF aware instances of RIP, EIGRP and BGP.
0:10:04	Now, for both the RIP and the EIGRP process,
0:10:08	they both will use one single global RIP or EIGRP process.
0:10:14	Then the individual VRFs are gonna be defined based on the address family.
0:10:20	So, this means, first on router 4,
0:10:22	I would need to define the global RIP process.
0:10:27	Then I'm gonna specify a sub-address family for the IPv4 VRF.
0:10:34	And specify what the particular VRF instances.
0:10:36	In this case, I wanna run RIP for VRF A.
0:10:41	So, address family IPv4 VRF A.
0:10:44	Once I'm in the subconfiguration mode, all of the syntaxes are gonna be the same as the global RIP process.
0:10:51	So, if I were to look at Show IP VRF A Detail,
0:10:57	or actually, just Show IP VRF Detail.
0:11:02	For VRF A, it tells me what are the interfaces that are aassigned.
0:11:07	What is the route distinguisher.
0:11:10	Right now, I don't have any of the import or export route targets configured.
0:11:14	So, we'll have to come back and do that.
0:11:17	But eventually, I just wanna make sure that this particular link is running the RIP process.
0:11:21	So, if I do Show Run Interface Fast Ethernet 0/0.104,
0:11:28	I need to make sure that I have a network statement that overlaps with this.
0:11:34	So, as we know with RIP, we can only put a classful network statement.
0:11:38	But since this is related to the address family VRF A,
0:11:44	so again, under the RIP process, we said address family IPv4 VRF A.
0:11:49	Eventhough the network statement is overlapping with the other interfaces,
0:11:54	so, for example, this is matching with what's in the global routing table.
0:12:00	Since this particular link is not assigned to VRF A,
0:12:06	it means that the VRF A routing process is not gonna have any effect on that.
0:12:11	So, I don't need to say Passive Interface Fast Ethernet 0/0.24.
0:12:15	It's only gonna be related to interfaces that are in that particular routing table.
0:12:21	Then other standard options, I probably wanna say Version 2 No Autosummary.
0:12:28	On the other end of the link, which is switch 4,
0:12:31	from there perspective, this is just a normal RIP process.
0:12:34	So, if I were to go to switch 4, I'll say Turn RIP On.
0:12:40	Network 10.
0:12:42	Version 2 No Auto Summary.
0:12:45	So, from the customer's point of view, they do not need to run the VRF aware process.
0:12:50	This is becasue when they look at the routing table,
0:12:54	their links are in the global table.
0:12:58	If the customer were also running a VRF, in the case that they're running VRF light,
0:13:03	then, we might need to run the VRF aware routing process.
0:13:07	But in this case so far, we're not
0:13:08	doing any multi-VRF in the customer, just on the provider edge.
0:13:16	Now, on router 4, if we look at the Show IP Route VRF B,
0:13:23	actually, this is VRF A.
0:13:28	We see that we are learning the loopback address that's assigned to switch 4.
0:13:35	So, this is telling us the VRF aware RIP process is working.
0:13:38	If I were to ping this, Ping Inside VRF A
0:13:42	10.1.10.10,
0:13:47	we'll ping VRF A.
0:13:50	We see that we do have connectivity.
0:13:55	Next, we have the EIGRP process that is for VRF B.
0:14:00	Specifically, that's EIGRP AS 10.
0:14:02	So, from switch 3's perspective,
0:14:04	who is the customer, there's no special configuration for this here.
0:14:08	We just have EIGRP AS number 10.
0:14:10	The network statement that's matching whatever interfaces we want to run the protocol on,
0:14:15	and then, No...
0:14:18	No Auto Summary.
0:14:20	From router 4's perspective, I technically could use the same network statement,
0:14:24	I could match everything.
0:14:27	Because ultimately, this is only going to match
0:14:29	any routes that are in VRF B.
0:14:35	Now, a common mistake for this
0:14:38	is that once we enable the EIGRP process globally,
0:14:42	if we were to be using EIGRP for our internal routing,
0:14:47	we would need to specify what's the AS number for the global process.
0:14:52	So, if I'm already running EIGRP 100,
0:14:55	then, I would say, Router EIGRP 100.
0:14:58	Okay, if I'm not running this for the global table, then, I could put anything here.
0:15:01	I'll say, Router EIGRP 65535.
0:15:05	Next, once we go into the address family for the IPv4 VRF B,
0:15:12	I need to again specify what is the autonomous system,
0:15:16	because it is specific to that individual routing table.
0:15:21	The VRFs for the separate customers, they could be running same autonomous system,
0:15:25	or they could be running separate ones.
0:15:29	That's why we need to specify it on a per-VRF basis.
0:15:33	If I do not specify the autonomous system here,
0:15:35	it means I'm not gonna be able to establish the EIGRP adjacency.
0:15:43	From this point on, the rest of the configuration is gonna be the same.
0:15:46	So, I need a network statement that's gonna match the interface.
0:15:49	And most likely, I wanna disable auto-summary.
0:15:55	We could see now, the adjacency came up. If I Show IP EIGRP...
0:16:01	VRF.
0:16:03	VRF's name is B.
0:16:05	I wanna check the adjacencies.
0:16:10	And I could see that I am adjacent with switch 3, and the queue count is zero.
0:16:16	So again, the only configuration really that's significant about the EIGRP aware process.
0:16:21	If we Show Run Begin, or Section Router EIGRP
0:16:24	is that under the particular VRF, we need to specify what the autonomous system is.
0:16:30	It does not automatically inherit to the global process number.
0:16:37	And as we know that the EIGRP number is significant for the adjacency.
0:16:41	So, it would need to match between the provider and the customer.
0:16:45	Basically, whatever the customer's value is, that's what the...
0:16:49	the provider's gonna specify under the VRF.
0:17:02	Okay, there's a question here, why didn't you put the interface in VRF
0:17:09	on router 4 for the RIP process.
0:17:12	If we look at the, lets look at the full routing config.
0:17:15	Show Run Section Router,
0:17:17	right now, both the RIP process and the EIGRP process are VRF aware.
0:17:23	So, the RIP process is specific to VRF table A.
0:17:27	The EIGRP process is specific to VRF table B.
0:17:32	Even though technically the network statements are overlapping,
0:17:35	it's not gonna make a difference because they're in separate routing tables.
0:17:39	This means the network statement for VRF A is not gonna affect B, and vice versa.
0:17:45	Now, if we were to look at the Show IP Route VRF Star (*),
0:17:49	we should see routes in both tables A and B.
0:17:54	So, for table A, we see the RIP route coming from switch 4.
0:17:59	For table B, we see the EIGRP route that's coming from switch 3.
0:18:04	In table D, right now, we're not learning anything because we didn't establish a BGP peering with BB2.
0:18:15	So next, we need to enable BGP VRF aware process.
0:18:22	Now, this portion gets a little bit confusing for some people,
0:18:26	because there's a difference in the address family VPNv4
0:18:30	versus the address family IPv4 VRF.
0:18:35	And depending on which one that you are referencing
0:18:38	whether the peer is in the global routing table versus a VRF table,
0:18:44	that's gonna control where the neighbor statement is supposed to go,
0:18:46	and where the particular attributes for that peer are gonna be located.
0:18:55	Now, on router 4, specifically in this case,
0:18:57	the link that's connecting to BB2 is assigned inside VRF D.
0:19:05	We can see this because we looked at the Show IP Route VRF Star (*),
0:19:08	and the last one, routing table D, it says that Fast Ethernet 0/0.192 is directly connected.
0:19:15	What this means is that once we run the BGP process,
0:19:19	if I were to put the neighbor statement for BB2 under the global process,
0:19:27	it means that the BGP process is gonna say, Show IP Route 192.10.28.254
0:19:36	in order to figure out what interface I need to forward the control plane message about BGP.
0:19:44	The problem is though that particular address, it's not in the global table.
0:19:48	It's in the VRF table.
0:19:51	So, what this means is that if the neighbor's address
0:19:54	that you're trying to peer with is already in the VRF,
0:19:58	the neighbor statement should not go under the global process.
0:20:03	It should go under the address family IPv4 VRF.
0:20:09	We'll see that this is different than the VPNv4 address family,
0:20:14	because a VPNv4 peering is for someone that is in the global table.
0:20:23	So, we'll come back to this in a little bit when we actually get into the routing exchange from the PE to the CE,
0:20:29	or the CE PE, and then, into the MPLS network.
0:20:32	Right now, we're just enabling the VRF aware routing processes.
0:20:37	Then again, this particular neighbor is pre-configured for authentication.
0:20:41	So, any options that we would want to apply on to them,
0:20:45	the password, a route map,
0:20:48	any other attributes on the BGP,
0:20:51	it means they're gonna go under this particular process.
0:20:55	Now, we could see, I got a BGP notification message back.
0:20:57	It says that the peer is in the wrong AS.
0:21:01	This basically means I configured the...
0:21:06	remote AS wrong. This should be not 200, this should be 254.
0:21:18	So, we should see here shortly that we get a log message that the peering to BB2 is up.
0:21:24	But it says specifically, this is inside the VPN
0:21:29	that is defined by VRF D.
0:21:32	Now, the reason that this is significant is that again, it's gonna change our verification for the neighbor.
0:21:38	We now need to use the VRF aware BGP show commands.
0:21:44	Now, this can get a little bit complicated depending on whether we're trying to look at the global routing table,
0:21:49	the VRF table, or the VPNv4's specific information.
0:21:55	Whereas in the newer IOS versions, the syntax of the show commands for BGP has now changed.
0:22:01	Instead of saying, Show IP BGP, or Show IP BGP Summary,
0:22:06	instead, we now say Show BGP followed by the address family identifier,
0:22:12	the sub-address family identifier,
0:22:14	and then, the particular options.
0:22:18	In this case, we would want to say, the VPNv4 Unicast VRF D Summary."
0:22:31	This is verifying the specific peering that's happening inside the VRF table D.
0:22:37	If I were to simply say, Show IP BGP Summary,
0:22:41	the peer does not exist there.
0:22:44	Because the peer is not in the global routing table, the peer is in the VRF specific table.
0:22:53	Likewise, if I was then to look at the Show BGP VPNv4 Unicast VRF D,
0:23:00	this is the equivalent of the Show IP BGP specifically for that routing table.
0:23:06	Then, if I wanted to see more specific information about one of the routes,
0:23:11	Show BGP VPNv4 Unicast VRF D 222.22.2.0.
0:23:20	Now, we'll see that when we have multiple VRF tables
0:23:24	under the BGP process, we could also sort them by the route distinguisher
0:23:28	or just say for All VRFs.
0:23:31	So, if I said Show BGP VPNv4 Unicast All,
0:23:35	this is gonna be for any VPNv4 neighbor
0:23:40	regardless of whether they're in the global table or whether they're coming in from a VRF table.
0:23:47	So now, at this point on router 4, we know that the exchange from the customer to the provider is working.
0:23:53	Now, we hadn't done any distribution into the BGP network.
0:23:57	So, we're technically not running anything that's related to MPLS.
0:24:01	This is still considered just VRF light,
0:24:04	because we're not running the VPNv4 address family under the BGP.
0:24:10	Now, if I had another interface here on router 4, let's say that goes to router 7.
0:24:15	If I were to configure this in VRF A,
0:24:19	and put the RIP process on this,
0:24:21	then, I would be able to exchange routes from switch 4 down to router 7.
0:24:28	This would then be considered a VRF light configuration,
0:24:32	because I'm simply separating the router into multiple virtual routers
0:24:36	based on the VRF assignment that goes on into the interface level.
0:24:41	So next, let's do the same thing on router 5 and router 6.
0:24:46	Again, a lot of these configuration gets pretty repetitive.
0:24:49	So, you may be better off doing this in Notepad to make sure that your configurations are matching up
0:24:53	on one side versus the other.
0:24:56	So, I could go to router 4,
0:24:59	and let's say, Show Run Section Router,
0:25:04	where the RIP and the EIGRP configuration is basically gonna be the same thing that I need on the other side.
0:25:11	The only difference is that one of them is gonna be on router 5,
0:25:14	one of them is gonna be on router 6.
0:25:18	So router 6 is running the EIGRP process,
0:25:23	but that's gonna be going to BB1. So, it has a different network statement.
0:25:29	Then, the RIP process is gonna be on router 5.
0:25:33	So, that syntax should be fine.
0:25:43	Where this actually is...
0:25:48	not network 10, this would be network...
0:25:52	So, No Network 10.
0:25:56	This is network 204.12.28.0.
0:26:07	Then, on router 6, we have the...
0:26:10	VRF aware EIGRP process.
0:26:18	We should then see the adjacency with BB1.
0:26:22	Again, if we ping VRF B 54.28.1.254,
0:26:28	we see we do have connectivity there.
0:26:33	If we look at the interface level,
0:26:38	this also, on the other end, they're pre-configured for MD-5 authentication for EIGRP.
0:26:43	So, I need to say...
0:26:45	IP Authentication Mode EIGRP AS 10
0:26:52	is running MD-5 authentication.
0:26:55	The IP authentication key chain for EIGRP 10, I have named this capital "EIGRP".
0:27:03	So, within the scope of the lab exam, if you're doing authentication with the backbone routers,
0:27:06	then, obviously, they're gonna have to tell you that.
0:27:09	Okay, there's no way we can just guess what the password is here.
0:27:12	But now, once the adjacency is up,
0:27:13	if we look at the Show IP Route VRF B,
0:27:17	we see now that the EIGRP information is being installed in the VRF table.
0:27:22	Likewise, on router 5, if we look at the...
0:27:25	Show IP Route VRF A,
0:27:28	we have the RIP routes coming in from that particular customer.
0:27:33	Then, the OSPF configuration on router 5 and router 6,
0:27:36	we're gonna come back to this in a little bit.
0:27:40	So, now that we have the routing process configured
0:27:43	from the provider down to the customer,
0:27:46	we need to figure out how can we get this information to be exchanged between the PE routers.
0:27:51	And the way again we're gonna do this is by encoding the information inside a VPNv4 BGP update.
0:27:58	Now, this is essentially the same logic as normal BGP
0:28:03	except we're doing an extension for it,
0:28:05	which is defined in RC-4364, which is the BGP MPLS IP VPNs.
0:28:11	So, it's specific interaction for BGP and Layer 3 MPLS VPNs.
0:28:18	What this is defining is a new address family identifier and the sub-address family identifier
0:28:23	that are specific for VPN IPv4, or VPNv4.
0:28:30	There is one layer that's specific for VPNv6,
0:28:33	which is for IPV6 routing.
0:28:35	That's not gonna be within the scope of the current routing and switching lab exam.
0:28:43	So again, the first thing that the VPNv4 address family is gonna define
0:28:47	is how do we take the customer's routing information and make it unique inside the MPLS network?
0:28:55	So, to do this, we're gonna take that route distinguisher,
0:28:57	and encode it inside of the update.
0:29:02	So now, the actual VPNv4 route becomes the IP prefix
0:29:07	with the route distinguisher in front.
0:29:09	We can see this on router 4,
0:29:12	when we look at the Show IP BGP for that particular VRF.
0:29:17	Specifically, we say, Show BGP VPNv4 Unicast All.
0:29:22	It says, "This particular table has the route distinguisher 10.0.4.4:4."
0:29:29	So, if I were to Show BGP VPNv4 Unicast All
0:29:33	for the prefix 205.90.31.0/24,
0:29:43	we see that this particular route
0:29:46	now has been tagged with the route distinguisher 10.0.4.4:4:205.90.31.0/24.
0:29:59	So, this entire string now makes up the VPNv4 route.
0:30:05	Again, this is where the route distinguisher is making the prefix unique.
0:30:11	The routers do not yet know what VPN the route belongs to.
0:30:17	This is what the route target value is gonna be for.
0:30:22	So, once we take the route from the customer,
0:30:26	then, we advertise it to the MPLS network,
0:30:29	we need an additional route tag
0:30:33	to figure out what particular VPN do we wanted to go into on the other side.
0:30:39	Now, syntax-wise, the IOS takes this as the route target export, and the route target import.
0:30:47	The key point to remember here
0:30:49	is that we are importing or exporting from the perspective of the VRF itself.
0:30:56	This means that if the route target is export,
0:31:02	we are exporting the route from the VRF out to BGP.
0:31:06	So, out to the MPLS network.
0:31:08	When we are importing the route,
0:31:11	we're taking it in from MPLS,
0:31:14	and then, sending it back into the VRF.
0:31:18	So, this value, the route target,
0:31:22	this is ultimately what is controlling what VRF the route is gonna belong to.
0:31:28	Because the VRF name is not encoded anywhere in the update.
0:31:30	It's just this particular value that we are manually defining.
0:31:35	Now, we'll also see that the route targets
0:31:37	for the particular prefix, there can be multiples,
0:31:41	which is going to allow us to have to have different complex policies
0:31:46	for the VPNv4 routes.
0:31:54	Now, configuration-wise, this is gonna be under the address family VPNv4 Unicast,
0:32:01	but the control plane peering is still gonna happen inside of the global routing table.
0:32:08	So, what this means is that between the PE routers,
0:32:12	who is specifically in this case again are router 6, router 5 and router 4,
0:32:17	we need to configure regular BGP peerings inside of the global routing table.
0:32:24	Since we already know each other's loopback zero addresses through IGP,
0:32:29	we should not have any problems with the transport.
0:32:33	So, first portion is just we're gonna do a normal BGP peering.
0:32:39	So, we'll say, router BGP 200
0:32:42	Neighbor 10.0.4.4 Remote AS 200.
0:32:50	This neighbor, the update source is loopback zero.
0:32:58	Then, this is gonna be the same for routers 5 and 6.
0:33:02	So, I can take the same template to the configuration,
0:33:06	and put it on all three of the routers.
0:33:08	Whichever one has that local loopback
0:33:10	is automatically going to ignore that particular option.
0:33:17	So again, it's just another quick way to make sure we're not leaving out a key piece as syntax.
0:33:22	So, on router 4,
0:33:25	we can see, the first two commands, it's ignoring me because that's the local system.
0:33:29	That's router 4's own local address.
0:33:36	Router 5 is peering with 4 and 6,
0:33:40	and then, 6 is peering with 4 and 5.
0:33:50	Now again, we could have had a different BGP peering design.
0:33:54	Just like we can in the normal global routing table.
0:33:57	VPNv4 does support a full mesh or route reflection, or confederation,
0:34:01	we can configure it however we want.
0:34:04	But the basic route advertisement loop prevention and attributes
0:34:08	is gonna be the same as the normal global BGP process.
0:34:13	The only thing that we're doing is taking an additional type of route,
0:34:17	and encoding it inside new extended communities.
0:34:21	Now, from any three of these routers, if we look at the log output, we should see, all the peerings are up.
0:34:26	If we look at the Show IP BGP Neighbors,
0:34:31	we should see that by default,
0:34:33	these devices are peering with IPv4 Unicast address family.
0:34:38	So, this is for our regular IP routing.
0:34:42	If I want these devices also to exchange the MPLS routes,
0:34:45	I need to tell them in the capabilities exchange
0:34:48	that they need to negotiate VPNv4 Unicast.
0:34:53	This is now what under the address family
0:34:57	is gonna be used for when we activate the neighbors.
0:35:01	So, under BGP 200, I need to say, Address Family VPNv4
0:35:06	for these three neighbors.
0:35:10	And again, the one that has the local system number, this one is gonna be ignored.
0:35:15	For these three neighbors, I want to activate
0:35:18	the capability that is VPNv4.
0:35:26	So, the key point here is that we're using the normal TCP control plane
0:35:31	that is established in the global routing table.
0:35:35	So, this peer is not configured under the VPN, or the IPv4 VRF.
0:35:41	Because from router 4,
0:35:43	when I look at the route to router 5,
0:35:48	and to router 6,
0:35:50	this is in the global table.
0:35:52	So, this means that the peering statement needs to be in the global BGP process.
0:36:00	Okay, next, if we...
0:36:02	do the same thing on router 4,
0:36:07	once the neighbors come back up, if we look at the Show IP BGP Neighbors,
0:36:12	we should see now in addition to IPv4 Unicast,
0:36:17	they have now negotiated the VPNv4 address family.
0:36:24	Now, the capabilities exchange is part of the adjacency negotiation,
0:36:28	which means that if one router supports a different address family than the other ones,
0:36:32	they're not gonna be able to establish the peerings.
0:36:35	So, we need to make sure that all of the routers agree exactly what type of routes that are going to be exchanged.
0:36:42	By default, we're always be running IPv4 Unicast.
0:36:46	We could disable this
0:36:49	under the process globally
0:36:51	if we were to say, No BGP Default IPv4 Unicast.
0:36:57	So, this turns off the automatic negotiation of IPv4 Unicast,
0:37:03	or we could go to address family IPv4 Unicast
0:37:08	and say, "For this particular neighbor,
0:37:10	where they are normally activated, I do not want to activate them."
0:37:16	Now, whether you need to deactivate them or not,
0:37:20	it really depends on whether you're gonna be exchanging those type of routes.
0:37:24	In our particular case here,
0:37:26	if routers 4, 5, and 6 are not routing the global BGP table,
0:37:30	they don't necessarily need to be exchanging the IPv4 Unicast address family.
0:37:36	So, I could deactivate this and it's not going to affect any of the MPLS configuration.
0:37:41	The only reason I would want that is if they were exchanging normal routes in the global BGP table.
0:37:49	So, in a real world design with this MPLS VPNs,
0:37:52	typically, the service providers will have different physical boxes
0:37:56	that are for VPNv4 peerings versus the IPv4 Unicast peerings.
0:38:02	Especially in very large scale designs,
0:38:05	when we need to use route reflection for VPNv4,
0:38:08	typically, the VPNv4 route reflectors will be different physical routers
0:38:12	than the IPv4 route reflectors.
0:38:16	Because the VPNv4, this is for the private customer routes,
0:38:20	where the IPv4, that would be for the normal global Internet BGP table.
0:38:25	So now, we have two out of the three steps configured.
0:38:29	We have the routing between the customer and the provider.
0:38:32	And we have the multi-protocol BGP peerings between the PE routers.
0:38:37	Our last step is that we need to take the routes from the customer,
0:38:41	and advertise them into the MPLS network.
0:38:46	Now, in order to do this,
0:38:48	we need to agree on what the route target policy is going to be.
0:38:53	So, on a per-VPN basis,
0:38:56	we need to figure out for whatever route target
0:39:00	that router 4 is exporting...
0:39:05	for VRF A,
0:39:08	this should be the route target that router 5 is importing.
0:39:14	Then, on the reverse path, whatever route target of router 5 is exporting,
0:39:20	this should then be the value that router 4 is importing.
0:39:27	So, remember, this is from the perspective of the BGP table.
0:39:32	The export route target is what is going from the customer out to the MPLS network.
0:39:39	The import route target is what is coming from BGP and then being advertised down to the customer.
0:39:45	Now, we'll also see,
0:39:47	there's an additional loop prevention mechanism that goes along the VPNv4 updates
0:39:53	that the router will filter out any updates it receives
0:39:57	if it's not actually using that route target value.
0:40:01	So, this is configured by the command that is on by default, which is BGP route target filter.
0:40:08	There's basically only two cases that you would need to turn this off
0:40:13	is that if you are a VPNv4 route reflector,
0:40:17	which means, you don't actually have the VRF configured locally, but you want to advertise the route on,
0:40:23	or you're doing some sort of inter-AS VPN exchange,
0:40:28	where the edge routers are advertising the VPN routes, but they don't actually have the VRF configured.
0:40:34	But the key point we'll see when we look at the Debug IP BGP VPNv4 updates.
0:40:40	For routers that don't have the particular VRFs configured,
0:40:44	they're automatically going to filter those routes out.
0:40:49	So, from router 4's perspective, there's three different VRFs that are gonna be advertising, A, B, and D.
0:40:56	These updates are gonna go both to 5 and 6.
0:41:00	Since 5 is using A but not B,
0:41:04	and router 6 is using B but not A,
0:41:07	it means that they're automatically gonna filter the ones that they don't want when the update comes in.
0:41:14	So, it's basically an automatic optimization of the size of the VPNv4 routing table.
0:41:22	Now, we could tell the router not to do the filtering.
0:41:26	We could say, No BGP Default Route Target Filter,
0:41:28	but really, there's no reason that you would need to do that
0:41:31	unless you're using the router to advertise
0:41:35	prefixes that it doesn't actually have the VRF configured on.
0:41:39	So again, usually, that's two cases: one that it would be a VPNv4 route reflector.
0:41:44	The other one that you're doing some sort of inter-AS Layer 3 MPLS VPNs,
0:41:51	which is gonna be outside of the scope of the routing and switching exam.
0:41:56	So, the next thing we then need to do
0:41:59	is to define what is our route target policy gonna be.
0:42:03	Now, the actual numbers are going to be arbitrary.
0:42:05	As long as the routers are going to agree on what is being imported and exported.
0:42:11	And there's a bunch of different ways that we could do this.
0:42:14	If we were to import and export the same values everywhere.
0:42:19	Okay, same values everywhere within that particular VRF.
0:42:23	It essentially means that we're gonna have a full mesh
0:42:26	of reachability between the different customer size.
0:42:30	So, let's say theoretically, I have 10 different sites for customer A.
0:42:35	If I import and export the same value
0:42:38	on each of those 10 PE routers for that particular VRF,
0:42:43	it means that automatically, I'm gonna have a full mesh of the routing.
0:42:49	We could manually define some sort of hub and spoke design
0:42:52	where the hub is importing...
0:42:55	all of the spoke's routes.
0:42:58	It's exporting to the spokes and then, the spokes are importing the hub, not the spoke's routes.
0:43:04	This is typically used if you're trying to do some sort of centralized filtering policy.
0:43:10	Like you have a firewall that you wanna go through in one central site before you
0:43:13	send traffic out to the other remote locations.
0:43:18	Another common design for this is called "Central Services VPNs",
0:43:22	where service provider is offering a managed service down to the customer
0:43:28	whether this is something like Voice over IP, or maybe e-mailed or hosting exchange for the customer,
0:43:34	or hosting call manager for the customer.
0:43:37	In that case, we may want multiple VPNs to import the same route target.
0:43:44	So, they can reach one particular resource.
0:43:48	Now, we're gonna do this in the example here by using VRF D as the central service
0:43:55	that is going to be imported into A, B and C on the remote ends.
0:44:02	Now, one thing you cannot do is...
0:44:05	locally leak the traffic between the VRFs on the router itself.
0:44:11	So, we cannot go to the VRF table A on router 4 and say, Redistribute VRF D.
0:44:16	What you would have to do is advertise the routes out,
0:44:20	and then loop them back around.
0:44:23	So, it's kind of a hack on this thing what I've seen it used in production before
0:44:27	is that you can configure a physical loopback
0:44:31	on the router.
0:44:33	So, let's say you have 2 Ethernet ports you could figure a cable
0:44:37	between the same 2 ports on the router.
0:44:40	On one end, you configure it in one VRF.
0:44:43	On the other end, you configure it as a separate VRF.
0:44:46	Then, the router is essentially peering back with itself.
0:44:50	But since they're 2 separate routing tables,
0:44:52	it basically doesn't know
0:44:54	that it's running a routing protocol between its own process.
0:45:01	So again, key point for this is that...
0:45:04	for the VRF D routes, I could get them to go into the BB3, to switch 2, to switch 1, and to BB1.
0:45:14	But I cannot locally get them to go from BB2 to 4 to switch 3.
0:45:20	Without a physical loopback, the only way I could do that
0:45:22	would be to put them in the same VRF to begin with.
0:45:26	So, next, let's define what is gonna be the import and export policy.
0:45:32	To keep this simple, I'm gonna use the same values for A, B, and C
0:45:36	on the different PE routers.
0:45:38	We'll say that A will be 1:1,
0:45:43	B will be 2:2,
0:45:45	and then, C will be 3:3.
0:45:48	If I wanted to, I could make them separate on the individual PE routers
0:45:52	It just depends on the individual policy that I want to define it as.
0:45:57	So again, the easy way to this is to put it in Notepad.
0:46:01	Make sure that you're not gonna miss a route distinguisher or router target value on any of the PE routers.
0:46:07	Under IP VRF A,
0:46:11	the route target for export,
0:46:15	so again, this is from the VRF out to BGP is 1:1.
0:46:20	The route target for import is the same value.
0:46:25	This would be the same as saying Route Target...
0:46:31	Both,
0:46:33	and then, the value.
0:46:37	Where Route Target Both is basically a keyword shortcut for export and import at the same time.
0:46:44	So, we're gonna configure this on router 4 this 4.
0:46:48	Because 4 has both A and B.
0:46:51	On router 6 and router 5, those are gonna be separate,
0:46:53	because they don't have both of those VRFs.
0:46:57	So, on router 4, we're saying VRFs A and B.
0:47:03	On the other end,
0:47:05	router 5 has A.
0:47:11	So, this means that 5 is importing what 4 is exporting,
0:47:16	and 4 is importing what 5 is exporting.
0:47:24	Then, the same type of logic for VRF B.
0:47:28	So, as long as these values match between the different PEs,
0:47:32	then, the routes should be exchanged between the different tables.
0:47:41	Now, at this point, I have not done redistribution
0:47:45	from the IP process to the BGP process.
0:47:48	So, none of these customer learned routes are actually gonna be advertised into the MPLS network.
0:47:54	So, this is our very last step. We're gonna redistribute
0:47:57	from the IGP into MPLS. So, from router 4, I need to go to RIP to BGP,
0:48:04	I need to go from EIGRP to BGP.
0:48:07	And then, back on the other side.
0:48:11	Now, when we do this, we'll see that for RIP and EIGRP,
0:48:15	there are specific ways that the BGP extended communities
0:48:19	will encode the IGP learned information.
0:48:23	So, in the case of EIGRP, one of them is known as the "EIGRP Cost Community."
0:48:28	It allows us to continue to prevent loops over the MPLS network
0:48:33	by encoding the metric value of EIGRP
0:48:37	inside separate attributes of the BGP update.
0:48:42	So, we don't need to do any type of filtering when we redistribute between the sites.
0:48:46	Generally, the routing protocol is gonna prevent that itself.
0:48:50	We'll see when we get to OSPF, it gets a little bit more complicated,
0:48:54	because there's some advance traffic engineering designs that we can get into with OSPF
0:48:58	that are different than the other IGPs.
0:49:02	So, next let's go back to router 4.
0:49:08	If we look at the Show Run Section Router,
0:49:18	I have the VRF aware EIGRP process.
0:49:22	I have the VRF aware RIP process.
0:49:24	And then, I have BGP, where I have the VPNv4 neighbors.
0:49:30	So, the key is I need to get these RIP routes,
0:49:33	and turn them into VPNv4 routes.
0:49:37	The same thing with EIGRP
0:49:39	that on the other end of the network, I need to send them back.
0:49:45	So now, under the BGP process,
0:49:48	Router BGP 200.
0:49:51	Address Family IPv4 VRF A.
0:49:55	This is where we are redistributing RIP.
0:50:00	Under...
0:50:02	the RIP process, for address family IPv4 VRF A,
0:50:08	we will redistribute BGP 200.
0:50:12	Now, when we do this, we still need to set the metric into the RIP process.
0:50:18	We could give it a specific hop count.
0:50:19	I could say give it a metric of 1.
0:50:22	Or we could say, Metric Transparent.
0:50:25	This would be to pass the RIP hop count into the BGP med
0:50:30	and then come back out the other side as RIP hop count again.
0:50:36	So, if I say the same thing on both sides, Redistribute BGP 200 Metric Transparent,
0:50:40	then, the end-to-end RIP metric is gonna be maintained over the MPLS network.
0:50:53	Then next, under the process for address family IPv4 VRF B,
0:50:58	we need to Redistribute EIGRP 10.
0:51:03	Then, under the global EIGRP process, which is 65535,
0:51:09	address family IPv4 VRF B.
0:51:12	I need to Redistribute BGP 200.
0:51:18	So now, we're doing a redistribution mutually on router 4.
0:51:22	At this point, without going anywhere else further into the MPLS network,
0:51:27	I should be able to look at the BGP table for VRF A,
0:51:31	and the BGP table for VRF B,
0:51:34	and see that the customer routes were originated into the VPNv4 process.
0:51:41	So now, on router 4, if I were to look at the Show BGP VPNv4 Unicast for VRF A,
0:51:51	I can see that the RIP learned routes are now being advertised into BGP.
0:51:58	So, if I were to look at this for VRF B,
0:52:01	likewise, I see the EIGRP learned routes are now being advertised into BGP.
0:52:08	Notice some of the attributes,
0:52:10	the RIP hop count was encoded at the BGP med
0:52:13	as was the EIGRP metric.
0:52:16	If I look at the specifics behind some of these prefixes,
0:52:19	we Show BGP VPNv4 Unicast
0:52:22	VRF B 10.2.9.9/32,
0:52:30	we have the route distinguisher
0:52:33	plus the prefix, this is making up the actual VPNv4 route.
0:52:40	Then, we have the route target,
0:52:43	which is gonna control a route's VPN membership.
0:52:48	This now means on any other provider edge router,
0:52:52	if they were to import the route target 2:2,
0:52:58	it means that this particular prefix would then go into their VRF table.
0:53:04	Because inside this update, there is no way to distinguish this from table B,
0:53:08	and table A, C, and D on the other side.
0:53:13	The VRF name, and the VRF membership, it's only locally significant.
0:53:18	The way that we're getting it the global significance
0:53:20	is by doing that additional route target.
0:53:26	We can also see that there is now an MPLS label
0:53:30	that is generated for this specific route.
0:53:34	This is now the VPN label.
0:53:39	What this means is that if router 4 were to receive traffic inbound
0:53:44	that has label number 31,
0:53:47	it knows that the packet is really destined
0:53:50	into VRF B for the particular destination 10.2.9.9/32.
0:53:57	So next, let's look at the other side.
0:53:59	If we were to go to router 5 or 6,
0:54:02	ideally we should see these routes now being learned.
0:54:06	On router 5, let's look at the Show BGP VPNv4...
0:54:14	Unicast All.
0:54:18	If we do the same thing on router 6,
0:54:22	what we should see....
0:54:24	is that router 5 and router 6 are gonna have different views of the BGP table.
0:54:29	The reason why is that the process is automatically gonna filter out
0:54:33	the route targets that are not being used.
0:54:38	So, on router 6, if we look at the Show IP VRF Detail,
0:54:43	for VRF B, we are importing 2:2.
0:54:50	For VRF C, we have it configured, but we don't have any import route targets configured.
0:54:56	So essentially, what this means is that if we received a VPNv4 update,
0:55:01	and it has a route target that is not 2:2,
0:55:06	we're automatically gonna filter that route out.
0:55:10	Now, we can specifically see this occur in the process
0:55:13	if we were to look at the Debug...
0:55:16	IP BGP VPNv4...
0:55:20	Unicast Updates.
0:55:24	Then we were to ask for a route refresh from 6 into 4,
0:55:30	we'll say, Clear IP BGP...
0:55:33	VPNv4 Unicast.
0:55:38	The autonomous system, which is 200,
0:55:41	and inbound.
0:55:51	Router 6 says, "I'm receiving other routes.
0:55:55	Like the 222, the route to switch 4's loopback,
0:56:00	but these are automatically being filtered out
0:56:02	due to the extended community not being supported.
0:56:07	Specifically, the extended community is the route target 1:1.
0:56:18	So again, there's nothing that we manually need to do here.
0:56:20	The router is automatically gonna figure out which routes it wants and which ones it doesn't
0:56:25	based on the route target import and export policy.
0:56:29	This is why it's so important to make sure that the PEs that are servicing the same customer
0:56:34	agree on what the route target values are supposed to be.
0:56:38	The route distinguisher does really matter.
0:56:39	As long as the prefix is unique based on the distinguisher,
0:56:43	that's the only job that the RD has.
0:56:47	But the RT, the route target,
0:56:50	again that is what is defining the VPN membership.
0:57:00	So now, let's add the final step on router 5 and router 6.
0:57:04	Router 5 is running RIP in VRF A.
0:57:09	So, I need to do redistribution between RIP and BGP.
0:57:13	On router 6, we're running EIGRP.
0:57:15	So, I need to do redistribution between EIGRP and BGP.
0:57:20	Basically, the same that type of syntax that I have on router 4.
0:57:23	So, on router 4, I could say Show Run.
0:57:27	Show Run Include Router,
0:57:30	or Address Family,
0:57:32	or Redistribute.
0:57:36	And I can pretty much take what I have here,
0:57:40	and edit it to match what I need on routers 5 and 6.
0:57:44	Now, router 6 is the one that's running the EIGRP process.
0:57:49	And in that portion, this is gonna be for router 6.
0:57:54	Router 5 is the one running the RIP process.
0:57:59	Then for router 5,
0:58:02	we have VRF A.
0:58:08	For router 6, we have VRF B.
0:58:17	So again, a lot of this configuration is pretty repetitive so you can...
0:58:21	just filter it through real quick like this.
0:58:23	So, this first portion, this is gonna to router 6.
0:58:27	Then, the next one is gonna go to router 5.
0:58:32	We could see, since router 6 still has the debug on,
0:58:36	it's not generating the new updates
0:58:39	for those routes that we are redistributing.
0:58:44	If I look at the Show IP BGP on router 5,
0:58:47	this is not gonna affect router 5's table,
0:58:51	because what 6 is exporting
0:58:54	is not the same as what 5 is importing.
0:58:59	So technically, even though router 5 is receiving these prefixes,
0:59:05	it's not actually gonna use them, because the route target is automatically being filtered out.
0:59:08	So now, let's look router 4 for our final verification.
0:59:19	If we Show IP Route VRF A,
0:59:23	we see that we do have the BGP routes that are coming from router 5.
0:59:30	If we Show IP Route VRF B,
0:59:34	we see we have the BGP routes that are coming from router 6.
0:59:41	If we go to the customer edge,
0:59:43	which in this case to switch 3 and switch 4,
0:59:46	ideally, we should see the BB1 and the BB3 routes respectively
0:59:50	on switch 3 and switch 4.
0:59:56	We go to switch 3 and look at the Show IP Route EIGRP,
1:00:05	right now, we're not receiving anything.
1:00:07	Okay, so it basically could mean a couple things.
1:00:10	Either the redistribution is not correct on router 4,
1:00:14	or the process simply hasn't updated yet.
1:00:18	So before doing any additional troubleshooting what I probably wanted on router 4 is just clear out the routing table.
1:00:23	Sometimes, when you do the initial exchange,
1:00:26	the prefixes don't actually get populated down into the VRF.
1:00:30	So let's say,
1:00:33	Clear IP Route VRF Star (*),
1:00:37	or VRF A Star () and VRF B Star ().
1:00:45	Now, on switch 3, we are receiving them.
1:00:50	Likewise, on switch 4, if we look at the Show IP Route RIP,
1:00:54	now, I can see that I'm receiving the prefixes from the other end.
1:01:01	Lastly, if I try to send traffic to these, we'll ping 30.0.0.1,
1:01:05	source the packets from my loopback,
1:01:08	we can see that I do a connectivity.
1:01:13	From switch 3, if we ping 200.0.0.1,
1:01:17	source this from loopback zero.
1:01:26	We do not have connectivity.
1:01:31	So now, we need to look at...
1:01:33	what's going on on the other side
1:01:37	with the exchange of switch 3's routes.
1:01:43	Switch 3's routes, they're going out to BB1.
1:01:49	Because again, remember that the routing process
1:01:53	is always asynchronous.
1:01:55	Just because I have a route to you,
1:01:56	doesn't necessarily mean that you have a route back to me.
1:02:00	So, at this point, switch 3 has a route to the remote destination,
1:02:04	but we don't necessarily know that they have the route back.
1:02:08	So, the first point that I probably wanna look at this is on router 6.
1:02:11	Is router 6 actually receiving the updates in from router 4 via VPNv4 BGP?
1:02:18	then, did it properly perform the redistribution into the process?
1:02:24	The process being the EIGRP process.
1:02:26	So now, let's go to router 6.
1:02:39	We'll look at the Show BGP VPNv4 Unicast All.
1:02:45	We can see that we are receiving
1:02:48	the loopback interface of switch 3
1:02:52	It says, "It's in the correct table, which is for VRF B."
1:02:56	Now, I wanna know, did actually make it to that routing table?"
1:02:59	Let's say, Show IP Route VRF B.
1:03:03	It is in the table.
1:03:05	But this doesn't necessarily tell me that it was redistributed into EIGRP.
1:03:10	So, next thing I probably wanna check is the EIGRP topology.
1:03:14	If we Show IP EIGRP VRF B topology,
1:03:21	we can see, the redistribution did not happen.
1:03:25	So, two possible problems here. Either something in the syntax is wrong with the redistribution,
1:03:31	or the process is just not converged yet on router 6.
1:03:35	So, before doing any other troubleshooting, I probably wanted to just clear the routing table.
1:03:39	We'll say, Clear IP Route VRF B Star (*).
1:03:46	If I look back at the topology, and the subnets come in,
1:03:51	that's exactly what it was. So, the process was just hung
1:03:54	clearing it out is gonna refresh which routes are supposed to be redistributed.
1:03:59	So now, on switch 3, let's do the ping.
1:04:01	And we do have connectivity.
1:04:05	So now, this telling me that all of the pieces, the puzzle are working together.
1:04:09	If we were to look at a trace route
1:04:12	that goes to 200.0.0.1.
1:04:16	Sourced from my own local loopback,
1:04:21	we see that we are going over the MPLS network,
1:04:25	but what's kind of interesting is that these neighbors,
1:04:27	they don't even have a route back to switch 3.
1:04:34	So, there's a specific behavior
1:04:37	that occurs with MPLS Layer 3 VPNs and trace route,
1:04:41	where it's not really very helpful for a troubleshooting,
1:04:45	because it's gonna work for a 100% of the hops, or none of the hops.
1:04:51	Now, I know in this case, the network is working, because the pings were going through.
1:04:54	So, the traceroute is gonna show me what the...
1:04:58	what the exact neighbors that I'm going through over the process are.
1:05:01	There is some specific documentation about how this works.
1:05:05	If you just search for...
1:05:07	MPLS traceroute,
1:05:09	there's a couple different documents that's on Cisco's website.
1:05:13	So, this would be worth the time to read over.
1:05:15	Also, it talks about how the service provider can hide the topology
1:05:20	of the internal MPLS network from the customers
1:05:24	to make sure that they don't see the intermediary hops.
1:05:29	Which is more of the common application because we would really want
1:05:33	switch 3 as the customer to know what the addresses are
1:05:37	on these particular links that were transiting through.

Now Viewing

CCIE R&S Advanced Technologies Class v4.5
Title:	CCIE R&S Advanced Technologies Class v4.5
Duration:	81h 02m
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!
	Sign Up
Download this Course
$299.00	Add to Cart

MPLS Layer 3 VPNs and VPNv4 BGP

Create Bookmark