CCIE Routing & Switching Advanced Technologies Class

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	In our next section for IPv6 we're going to look at the
0:00:17	different types of tunneling mechanisms that can either be
0:00:21	used to transport IPv6 over an IPv4 only network
0:00:26	or the reverse of transporting IPv4 over an IPv6 only network.
0:00:33	Now we'll see that there's a bunch of different encapsulation options
0:00:37	for going in either direction. We could use the default
0:00:41	tunnel type that is an IPv4 GRE tunnel
0:00:44	similar to we saw before for doing basic tunneling of IPv4
0:00:50	or any other protocol stack where we simply define
0:00:53	the IPv4 tunnel source, the IPv4 tunnel destination
0:00:56	then specify an IPv6 address on the link.
0:01:02	Now the advantage of doing a GRE tunnel is that it is a
0:01:06	multiprotocol encapsulation which means that not only
0:01:09	can we run IPv6, but any other protocol stacks we have
0:01:13	at the same time whether we're using CLNS for IS-to-IS routing
0:01:17	maybe we have some legacy protocols like IPX or SNA that
0:01:21	need to be bridged over the link, then GRE would also be able
0:01:25	to encapsulate those.
0:01:27	The disadvantage is that GRE is a little bit more overhead
0:01:31	than the specific tunnel encapsulation that is designed for IPv6 over IP
0:01:37	which is IP protocol number 41, the IPv6 IP tunnel.
0:01:43	Configuration wise, they're very similar, the GRE tunnel
0:01:47	and the IPv6 IP tunnel. We still specify simply the source
0:01:51	the destination as IPv4 unicast addresses that we have
0:01:56	reachability to and specify a static IPv6 address over the link.
0:02:03	One of the differences is going to be the transport protocol
0:02:06	number where GRE is using protocol number 47
0:02:09	IPv6 IP is using protocol number 41
0:02:12	and for IPv6 IP, it cannot support other payloads
0:02:18	in the tunnel.
0:02:20	So in reality, there's only one thing that this is going to
0:02:23	affect is that if you are using IS-to-IS to route
0:02:27	IPv6, you would not be able to do that over an IPv6 IP tunnel
0:02:32	because IS-to-IS doesn't use IP as transport, it uses CLNS
0:02:38	which is not supported over that specific IP tunnel type.
0:02:43	The other tunnel type that is common is called a teredo tunnel.
0:02:47	This is basically a transparent IPv6 tunnel over UDP
0:02:51	in IPv4
0:02:52	this is what you get when you go onto the internet and
0:02:55	sign up for the tunnel broker, it's basically a transparent
0:02:59	way for your end host to be able to connect out onto the
0:03:03	IPv6 network.
0:03:05	Now the key with teredo is that it doesn't really run on
0:03:08	the router per se, we're simply transparently passing it
0:03:12	through with UDP
0:03:13	so this is kind of just a temporary transition
0:03:18	type of tunnel because it's not meant to be used as a
0:03:21	site-to-site tunnel, it's an end host-to-end host tunnel
0:03:27	which is also similar to the ISATAP tunnel
0:03:29	which is part of the IPv6 IP tunneling stack.
0:03:35	Then in the opposite direction we could be using IPv6
0:03:38	as the transport instead of the payload
0:03:40	where we have the GRE IPv6 protocol
0:03:46	so this would be the case where we have IPv6 everywhere
0:03:49	in the network, then we're trying to run IPv4 over
0:03:53	the IPv6 only network
0:03:56	so this again would be the reverse transition mechanism
0:04:00	where 10, 20 years down the road IPv4 is considered the
0:04:03	legacy protocol and IPv6 is the majority of the transport.
0:04:09	We'll also see that there's a couple different types of
0:04:11	automatic tunnels that go along with the IPv6
0:04:15	IP tunneling stack, the main two are called 6 to 4
0:04:20	and ISATAP where 6 to 4 is used for site-to-site
0:04:24	tunnels so between the border routers that are connecting to the
0:04:28	IPv4 only network, so this is one of the simplest ways
0:04:32	to tunnel between your networks over the
0:04:35	public internet.
0:04:38	So even if you're running MPLS service if you don't want to
0:04:41	get the service provider involved with your IPv6
0:04:43	routing, you can configure an automatic 6 to 4 tunnel
0:04:47	which is a multipoint IPv6 IP site-to-site tunnel.
0:04:53	So we'll see one of the configuration advantages for
0:04:56	this is that the routing is very straightforward
0:04:59	because there's a special address format that is used
0:05:02	specific for the automatic 6 to 4 tunnel.
0:05:05	The disadvantage of doing this
0:05:08	is that it limits what your actual addressing of the network is
0:05:12	supposed to be, so it means that you would need to use the
0:05:15	temporary 6 to 4 addressing where if you wanted to get
0:05:19	actual global routable address base as an
0:05:22	allocation, you essentially would have to run dual
0:05:25	addressing in the entire network.
0:05:27	So again, it's kind of a temporary stop gap for
0:05:31	transitioning from IPv4 to IPv6, but it wouldn't be a
0:05:35	good solution if you were trying to run globally routable
0:05:38	address base.
0:05:40	Then the last one, the ISATAP tunnel
0:05:43	this is an intra-site automatic tunneling mechanism
0:05:47	as opposed to the inter-site tunneling, so this is used for the
0:05:52	host-to-host tunnels.
0:05:56	So let's say that you have a local area network that is
0:05:59	spanning multiple office buildings, some of the end hosts are
0:06:03	running IPv6, but the transit network is still IPv4
0:06:07	you can turn on the ISATAP protocol stack in your
0:06:11	Windows 7 or your Mac OS
0:06:13	and then the end host would be able to encapsulate their
0:06:16	IPv6 packets over IPv4
0:06:21	Now IOS does support the ISATAP tunnels, but typically
0:06:25	you wouldn't use this on the router because
0:06:27	it is a host-to-host tunneling protocol, not a router-to-router
0:06:31	tunneling protocol.
0:06:33	Typically it would be more appropriate to use either just
0:06:36	the static GRE or IPv6 IP tunnel
0:06:39	or the automatic 6 to 4 tunnel.
0:06:43	So we're going to look at examples of the first three
0:06:45	the GRE, the static IPv6 IP, then the automatic 6 to 4
0:06:50	IPv6 IP tunnel in our particular topology.
0:06:54	So what we have set up here is RIPNG routing
0:07:01	behind Router 6
0:07:04	and RIPNG routing behind Router 5
0:07:09	Previously Router 1 was routing IPv6
0:07:13	but now we're going to say that this is the
0:07:14	IPv4 only network.
0:07:18	So we're trying to tunnel the traffic as it leaves the IPv6
0:07:21	network on Router 6 and it goes out to the IPv4
0:07:25	only network.
0:07:28	As long as Router 5 and Router 6 have IPv4 reachability
0:07:31	to each other, they should be able to use any of these
0:07:34	tunneling mechanisms in order to exchange traffic
0:07:37	between their IPv6 enabled networks.
0:07:43	So first let's look at the basic static tunnel configuration
0:07:47	and on Router 5 and Router 6 first I'm going to disable
0:07:52	the IPv6 processing that's going out to Router 1
0:07:56	so on Router 5 on the frame relay interface,
0:07:58	I'll simply say no ipv6 address
0:08:03	On Router 6 this is going to be on Fast Ethernet 0/0.146
0:08:08	no ipv6 address
0:08:15	If we look at the show ipv6 route
0:08:21	Router 6 is learning some RIP routes
0:08:23	in from Switch 1
0:08:28	Now we still have a BGP peering with Router 1
0:08:30	let me remove that as well.
0:08:31	We'll say no router bgp 6
0:08:36	and on Router 5 no router bgp 5
0:08:42	so at this point we should have just IPv6 routes
0:08:46	from our own local LANs
0:08:49	Router 5 should have RIP routes that are coming in
0:08:51	from Switch 2, then Router 6 has the RIP routes that are coming
0:08:55	in from Switch 1
0:08:57	so the ultimate goal here is that once the tunnels are
0:08:59	complete, we should be able to send traffic from the
0:09:03	VLAN 7 interface to Switch 1
0:09:05	and get it to reach the VLAN 8 interface to Switch 2
0:09:08	so this would be where our end hosts are attached
0:09:12	they are IPv6 enabled and it's completely
0:09:15	transparent to them that their traffic is actually being
0:09:17	sent over the IP version 4 network.
0:09:21	So our next step is on the border routers which are
0:09:23	Router 5 and 6, we're going to create our tunnel interfaces
0:09:27	so we'll say interface tunnel 0
0:09:32	The tunnel source is any IPv4 address
0:09:35	that Router 5 will have reachability to
0:09:38	so we'll say the loopback 0
0:09:41	and the tunnel destination is going to be the loopback of Router 5
0:09:45	which is 150.28.5.5
0:09:50	so assuming that Router 6 can send packets to the
0:09:53	address 150.28.5.5
0:09:56	when it is sourcing traffic from 150.28.6.6
0:10:01	then it means we should be able to establish the tunnel.
0:10:03	We don't have any filtering in the middle of the network
0:10:06	so we shouldn't have to worry about the GRE
0:10:09	tunnel or the IPv6 IP tunnel being dropped.
0:10:15	If we were going through any type of active firewall
0:10:20	most of them do not support the inspection of the
0:10:24	IPv6 IP tunnels or the GRE tunnels
0:10:27	so generally you would have to manually allow that
0:10:29	through your firewall filtering rules.
0:10:33	The reason that I mentioned this is that when you create
0:10:36	an access list, on Router 6 if I were to say access list 100
0:10:40	permit and look at the protocol numbers
0:10:46	it does not give us a shortcut here for the
0:10:49	IPv6 IP tunnel.
0:10:52	So I would have to say access list 100 permit
0:10:55	41 which is IPv6 IP
0:10:59	Now we'll look at a way that we can figure out what the
0:11:02	protocol number is if you don't want to memorize
0:11:04	this, we can look at the debugs in the transit path
0:11:07	of the IPv4 network and figure out the difference in the
0:11:11	protocol numbers whether we're running GRE or
0:11:13	whether we're running IPv6 IP
0:11:17	so next on Router 6 let's go back to the tunnel interface
0:11:19	and we're going to configure an IPv6 address.
0:11:22	We'll say ipv6 address
0:11:25	it could be anything here, we'll say 2001:56::6/64
0:11:37	Now since this is a manual point-to-point tunnel
0:11:42	I will enable routing on it so we'll simply say ipv6 rip 1 enable
0:11:48	we're already running the RIP process
0:11:50	then we'll basically do the same thing on Router 5
0:11:57	so Router 5 is interface tunnel 0, the tunnel source is
0:12:00	loopback 0
0:12:07	The tunnel destination is Router 6's loopback
0:12:13	we have an IPv6 address
0:12:18	and we have ipv6 rip 1 enable
0:12:24	so again, the process number for RIP doesn't matter
0:12:26	it's only locally significant. The only thing is that on Router 5
0:12:30	I would want to make sure whatever the name or number
0:12:32	of the process is on the tunnel is matching what I'm
0:12:36	running on the LAN interfaces.
0:12:38	So for Fast Ethernet 0/0 this is running RIP 1
0:12:43	If I were to put RIP 2 on the tunnel, then there's separate routing databases.
0:12:48	So same as like multiple EIGRP As numbers or multiple
0:12:52	OSPF process IDs
0:12:54	but it's important to remember this because with regular IPv4
0:12:57	routing, you can only have one RIP process
0:13:01	with IPv6 you can have multiple ones.
0:13:08	So now to test the basic tunnel reachability
0:13:10	we should be able to send traffic to the remote end of the tunnel
0:13:14	if we ping 2001:56::6
0:13:22	we see we do have connectivity to Router 6
0:13:25	If we show ipv6 route rip
0:13:28	we see that now we have updates coming in the tunnel.
0:13:34	So it's a pretty straightforward configuration. It's not different than
0:13:38	any other IPv4 over GRE configuration
0:13:42	the only change is that we're putting an IPV6 address
0:13:45	as opposed to an IPv4 address.
0:13:50	If we look at the show interface tunnel 0
0:13:52	it tells us that the default encapsulation is GRE
0:13:59	over IP version 4
0:14:02	so it's a generic routing encapsulation, but the
0:14:04	key is that the transport protocol is IP version 4
0:14:09	This is different than if we were to create a different tunnel
0:14:12	let's say tunnel 1
0:14:13	and set the tunnel mode to GRE IPv6
0:14:27	This means now that for tunnel 1, we're still using
0:14:30	generic routing encapsulation as the tunnel protocol
0:14:34	but now the transport is an IPv6 address.
0:14:40	So this would then mean whatever the tunnel source is
0:14:42	and whatever the tunnel destination is
0:14:44	those would be IPv6 addresses.
0:14:46	So this would then be used for tunneling IPv4 over IPv6
0:14:52	or technically you could tunnel IPv6 over IPv6
0:15:00	but for the vast majority of designs today
0:15:02	it's going to be the first variation where we're tunneling
0:15:06	IPv6 over IPv4
0:15:10	Now if we look in the transit path, let's say
0:15:12	from Router 5 I want to trace to figure out
0:15:15	how am I getting out to the loopback of Router 6
0:15:23	and it says actually there's three different ways I could
0:15:25	go. I could go two different ways out the frame relay
0:15:29	or I could go to the point-to-point interface of Router 4
0:15:34	What I'm going to do here on Router 5 to simplify this a
0:15:36	little bit is simply shut this link down
0:15:41	so I know that the traffic then only has this one
0:15:43	way to route, so the traffic is always going to go through Router 4
0:15:48	The reason I want to do this is that we're going to look at
0:15:50	some of the debugs of the transit flows and I want to
0:15:54	make sure I can predict what both the inbound
0:15:56	and the outbound flow is going to be.
0:15:59	So on Router 5, to change the route the only thing
0:16:02	I'm going to do is simply just shut this link down.
0:16:08	If I look at the trace route to the tunnel destination
0:16:11	we see that we almost immediately re-routed just
0:16:14	to that point-to-point link.
0:16:17	So now I could go to Router 4
0:16:20	and if we look at the interfaces here
0:16:24	the two transit links are going to be this serial 0/1/0
0:16:28	which is the PPP link that goes to Router 5
0:16:33	and Fast Ethernet 0/1 which is the LAN interface
0:16:36	that goes to Router 6
0:16:38	so to see the debugs of the flow, I need to go to these
0:16:41	links and say no ip route cache
0:16:44	which is going to turn off the Cef process
0:16:47	because remember on the router, you can only debug
0:16:51	the process switched traffic.
0:16:53	That means that anything that is locally originated by the
0:16:56	router or that is destined to the router would be seen
0:17:01	by the debugs by default.
0:17:03	If I want to debug any of the transit traffic, then I need to
0:17:06	turn Cef off.
0:17:08	Next on Router 4, I know that my routing protocol
0:17:11	underneath is EIGRP
0:17:14	so when I do the debugs, I don't want to see the EIGRP packets there.
0:17:17	So I'm going to create an access list
0:17:20	access list 100
0:17:23	that says deny eigrp any any
0:17:27	access list 100 says permit ip any any so anything else
0:17:33	then Router 4 is going to debug ip packet detail 100
0:17:40	and also one last step I'm going to turn time stamping off
0:17:43	no logging time stamps
0:17:51	or actually no service time stamps
0:17:56	We can see from the debug that we're also receiving
0:17:59	UDP port 520 and TCP 179
0:18:06	these are the routing updates that are coming from the backbone router.
0:18:12	So to get these out of the debug, I'm simply just going to
0:18:14	shut that link down.
0:18:20	So essentially the only debug output that we should see now
0:18:23	is going to be the routing of the IPv6 over IPv4 traffic
0:18:30	that's going between Router 5 and Router 6
0:18:33	Now we can see here we do have traffic coming from the
0:18:35	loopback of 6 going to 5
0:18:38	and the key point about this is that it says the protocol is
0:18:41	number 47 which means that this is GRE.
0:18:47	From Router 4's perspective it does not know that IPv6 is
0:18:51	in the payload so it's only looking at the GRE header
0:18:55	which is just saying to route traffic between the loopback of 5
0:18:57	and the loopback of 6
0:19:02	Now if we were to go to Router 5 and 6
0:19:05	and on interface tunnel 0 I'm going to change the tunnel
0:19:08	mode to IPv6 IP
0:19:14	and the neighbors will need to agree on this because it's a
0:19:16	different protocol format we'll say tunnel mode ipv6ip
0:19:24	Now if we look at the change on Router 4 in the transit path
0:19:30	we see the protocol number is 41
0:19:36	so this is the IPv6 IP header
0:19:38	which is using 41 as opposed to the GRE header
0:19:42	which is using number 47
0:19:50	and again, the reason that this is significant is that if
0:19:52	we were doing some sort of access list filtering, let's say
0:19:55	that on Router 4 we're doing the zone based policy firewall
0:20:02	and we're saying that this is my incoming interface
0:20:06	maybe these are my outgoing interfaces
0:20:08	this is my DMZ
0:20:11	if I then wanted to allow the IPv6 IP tunnel
0:20:14	between Router 5 and Router 6
0:20:16	I would need to make an exception for IP protocol
0:20:19	number 41
0:20:23	so to match on this simply when we define an access list
0:20:26	if we were to say access list 101
0:20:30	permit 41 from Router 5's loopback going to Router 6's loopback
0:20:40	and then vice versa.
0:20:52	So let's leave the debug running on 4, we'll debug
0:20:54	ip packet detail 100
0:20:57	If we look at the end result of this
0:21:00	there's basically going to be no change from the end host's
0:21:02	point of view. On Switch 2 if we ping
0:21:06	2001:155:28:7::7 and we source this from our
0:21:15	VLAN 8
0:21:21	This traffic should be routed over the tunnel.
0:21:23	If we do a trace route to this destination
0:21:28	it should go up to five over the tunnel
0:21:31	to 6 and then from 6 to Switch 1
0:21:34	which it is.
0:21:36	So here hop number 2 that's the tunnel between
0:21:39	Router 5 and Router 6
0:21:42	So from the end host perspective, they don't really care whether
0:21:45	it's an IPv6 IP tunnel or a GRE tunnel.
0:21:48	If you're doing large scale bandwidth over the tunnel
0:21:52	you would probably want to pick the IPv6 IP
0:21:55	because it's a little bit less overhead in the
0:21:58	encapsulation of IPv6 IP versus the GRE tunnel.
0:22:04	Now the real advantage for this is going to come in
0:22:07	with the automatic tunnels
0:22:09	so with the static GRE and the static IPv6 IP tunnel
0:22:13	the issue is that if there's a lot of sites in the network
0:22:17	it becomes a little bit unmanageable in order to
0:22:20	configure all of the tunnels between the different destinations.
0:22:25	Now for GRE, the solution for that is a multipoint
0:22:29	GRE tunnel that is used with the dynamic multipoint
0:22:34	VPN or the DMVPN feature.
0:22:38	So DMVPN is basically a multipoint GRE tunnel
0:22:43	that allows you to do site to site tunnels
0:22:47	over GRE automatically. It allows dynamic routing
0:22:50	over the links.
0:22:52	Typically this is also used with IPSec for encryption
0:22:55	but technically it doesn't have to be. You could run
0:22:58	DMVPN without IPSec
0:23:00	You would just have your traffic going over clear text
0:23:02	GRE tunnels.
0:23:05	Now I believe in the newer versions this is also supported for
0:23:08	IPv6 so if you look in the 12.4 T configuration guides
0:23:14	IPv6 configuration
0:23:20	and dynamic multipoint VPN
0:23:25	so if we look at the configuration examples here
0:23:30	first the router is configuring an IPSec profile
0:23:34	that is essentially going to say that for whatever
0:23:38	interface this profile is applied to
0:23:41	it's always going to get the transform set examples
0:23:44	set have this timeout for the security association lifetime
0:23:50	this basically means how often we need to re-key
0:23:54	the phase 1 and the phase 2 of the actual tunnel
0:23:56	then set perfect group secrecy group 2 this makes
0:23:59	the re-keying a little bit more secure
0:24:02	but technically we could skip this part. You don't
0:24:05	have to apply IPSec in order to get the DMVPN to work.
0:24:09	The key is that on the tunnel itself so this tunnel
0:24:14	zero this is the multipoint
0:24:18	GRE tunnel
0:24:20	where when we look at the tunnel mode
0:24:23	it's a GRE tunnel, but it's multipoint GRE.
0:24:29	So the key then with this would be
0:24:38	this feature, so in the newer versions they
0:24:41	added support for the next hop resolution protocol which
0:24:44	is NHRP
0:24:46	they added IPv6 next hop resolutions to that protocol.
0:24:52	So basically what it's saying is that we have
0:24:53	some tunnel destination that is going to do
0:24:58	the mapping for us
0:25:00	so there's a -- there's the hubs and then there's the
0:25:03	they're the hub and then there's the spokes
0:25:09	so this said what? This was the
0:25:12	example configuring the hub for DMVPN
0:25:15	so the hub basically says that it's going to do the
0:25:17	mappings on the tunnels, if we look at the spokes configuration
0:25:23	on the tunnel it says if I'm trying to get to this
0:25:28	IPv6 next hop value
0:25:33	then you should use that particular IP address.
0:25:39	10.11.11.99
0:25:41	so we would then need to know what's 10.11.11.99
0:25:49	and it's kind of hard to see without their overall
0:25:54	topology. Let me see if I can find this 10.11.11.99
0:26:02	This is the -- this should be the address of the hub which it is.
0:26:08	So basically what happens is that the spokes register
0:26:10	with the hub telling them what the association between
0:26:13	their IPv6 address and their IPv4 address on the GRE tunnel is
0:26:19	then it allows the spokes to set up the tunnels on
0:26:22	demand between the different sites.
0:26:24	So the key for this is that generally you would be
0:26:27	running EIGRP routing over the tunnel in order to accomplish it.
0:26:32	So this would work, this technically is now supported
0:26:34	as a multipoint tunnel
0:26:36	it would be a multipoint GRE tunnel
0:26:41	but the configuration design is going to be much more
0:26:44	complicated to do DMVPN just versus automatic
0:26:48	6 to 4 or the ISATAP tunnels.
0:26:51	So generally if you were running IPv6 over DMVPN
0:26:56	it's probably because you already have DMVPN
0:26:59	set up and then you just want to add the IPv6 support.
0:27:04	The real advantage for DMVPN is that it supports encryptions.
0:27:07	If you're doing automatic 6 to 4, that's not going to
0:27:10	support encryption.
0:27:13	So the key with 6 to 4
0:27:16	is that we need to figure out what is the destination of
0:27:19	the tunnel if the tunnel is going to point to different
0:27:23	neighbors at the same time.
0:27:25	Now with our static configuration, this is really easy to figure out
0:27:29	because if we look at Router 5 or Router 6
0:27:31	We're simply telling them manually that any time
0:27:35	I route packets out the tunnel
0:27:38	use this as the destination address in the actual GRE packet.
0:27:42	So in the IP header that goes on top of the GRE packet.
0:27:47	But with the automatic tunnel, we don't necessarily
0:27:50	know where the traffic is going to until the traffic
0:27:54	is actually routed out the link in the data plane
0:28:00	so what they did is came up with a conversion between
0:28:03	the IPv4 address that is already globally routable
0:28:07	and the IPv4 prefix that is going to be assigned to a specific
0:28:12	site, so the way that this works is that with automatic
0:28:17	6 to 4, everyone is allocated the prefix 2002
0:28:21	followed by the IPv4 address denoted in hex.
0:28:28	So let's say in our particular case that we have just two
0:28:31	end points of the tunnel, the tunnel is going to be
0:28:34	on Router 6 and Router 5
0:28:36	Router 6's address is 150.28.6.6
0:28:42	Router 5's address is 150.28.5.5
0:28:50	so this then means my first step would be to take these
0:28:53	decimal IPv4 addresses and convert them into hex.
0:29:04	So our first octet is 150
0:29:07	that's going to be 96
0:29:11	96 in hex
0:29:16	then 28 in decimal
0:29:19	is 1C
0:29:24	then 5 is 05
0:29:26	and 5 is 05
0:29:28	this then would mean that Router 6's address is going to be
0:29:31	96:1C:06:06
0:29:43	so I now know what their IPv4 destination is
0:29:47	converted into hex and I'm going prepend
0:29:50	the prefix 2002 onto this.
0:29:55	So for Router 6's site, this is going to be 2002
0:30:00	961C
0:30:02	961C
0:30:11	this is a /48
0:30:13	because it's 1, 2, 3, 4, 5, 6 bytes long
0:30:22	For Router 5's site, so that's for 6
0:30:29	Router 5's site is going to be 2002
0:30:33	960 -- or 961C
0:30:38	0505::/48
0:30:46	so these are now the prefixes that allocated
0:30:49	to every host that is behind Router 6
0:30:53	and every host that is behind Router 5
0:30:59	There's a question here, "Do you have to use the
0:31:01	2002 prefix? If you tried a different prefix like 2009
0:31:05	would that work for 6 to 4?"
0:31:07	I've never actually tried it before. It's possible
0:31:10	that the IOS would allow you to do that. The only thing
0:31:14	is that 2002 is specifically reserved for automatic 6 to 4
0:31:20	so basically it depends on when the router is doing the
0:31:22	encapsulation. Does it actually look at the first
0:31:25	two bytes to see what the address is or does it
0:31:28	just look at the next four bytes after that.
0:31:31	If it only looks at these four, then it's not going to
0:31:34	matter what the first two bytes are
0:31:36	but you'd have to double check that on the command line
0:31:38	whether it's actually going to work or not.
0:31:40	But normally it's going to start with 2002 because
0:31:43	that's what IANA said it's allocated specifically for
0:31:46	automatic 6 to 4
0:31:54	so now in order to implement this, it basically means that
0:31:56	we need to renumber the network.
0:31:59	So anyone who is behind Router 6
0:32:03	is now going to get a subnet that is inside
0:32:05	2002:961C:0606
0:32:11	We'll say that the link between Router 6 and Switch 1
0:32:14	is going to be the 67 subnet and then
0:32:18	the VLAN 7
0:32:20	on Switch 1 is going to be the 7
0:32:24	then on Router 5 between Router 5 and Switch 2
0:32:26	this will be 58
0:32:28	then on Switch 2's VLAN 8, that'll just be 8
0:32:33	so this is going to be the 9th and 10th byte
0:32:39	that I'm setting.
0:32:42	because the prefix generally should be /64
0:32:48	for the network and then 64 bits for the host as well.
0:32:58	So basically this means that if you take your
0:33:00	/48 you were to generate all /64
0:33:07	subnets out of it
0:33:12	that would mean that we have 16 bits
0:33:16	for the subnets so if we were to say 2 to the 16
0:33:21	it means that you could have 65 thousand subnets.
0:33:25	So if you wanted more technically you don't have to
0:33:27	assign /64 even if we went just one bit further
0:33:32	so instead of doing 16 for the 16 that's for the subnets
0:33:38	let's say that we said 2 to the 17th
0:33:41	so then you get a 130 thousand.
0:33:44	A lot of times allocations will go to /96
0:33:52	because if we look at a 128 bits
0:33:54	minus 96 for the network
0:33:57	which is 32 bits
0:34:00	and 2 to the 32
0:34:04	is 4.2 4.3 billion
0:34:09	that would means the amount of hosts on the segment
0:34:12	so even if your route is to a /96
0:34:17	you're still never going to have that many
0:34:20	you're never going to have that many hosts on the segment.
0:34:24	So if out of this /48 I say that I'm going to allocate
0:34:28	always /96 subnets
0:34:32	this means that the amount of bits that I have
0:34:34	now for creating subnets is going to be
0:34:38	96 minus 48
0:34:40	which is 48 bits
0:34:42	if I took 2 to the 48th
0:34:45	that's how many subnets I could have.
0:34:50	So if 65 thousand is a problem, then you could go
0:34:53	larger than /64, it doesn't really matter because
0:34:57	the RFC is just a recommendation, the IOS implementation you can
0:35:01	configure it to be whatever you want and it's just going to
0:35:04	use the routing table to figure out what is the
0:35:05	longest match.
0:35:07	Now whether that's going to be an issue with vendor
0:35:10	interoperability really depends how strictly the other vendors are
0:35:13	interpreting the RFC
0:35:18	you could potentially run into a problem where your end host
0:35:21	won't be allocated something that is not /64
0:35:25	and I don't have a lot of experience with the desktops
0:35:29	running IPv6 so it would be an issue of like the Microsoft
0:35:33	IPv6 stack would it accept a /96 allocation from the router.
0:35:39	And if it doesn't, if it's only going to accept /64
0:35:43	then that would be an issue.
0:35:44	So that's more of the actual protocol stack implementation
0:35:48	on the end application versus the network's point of view.
0:36:01	Ok, so let's look back at the command line. We know
0:36:03	what the address formats are going to be, so
0:36:05	now behind Router 6
0:36:08	I would need to say on the link that goes to
0:36:11	Switch 1
0:36:13	this now needs to be in the subnet
0:36:17	2002:961C:0606
0:36:26	I'll say this is 67::6/64
0:36:36	then Switch 1 is going to do the same thing.
0:36:38	Now technically you can have multiple addresses on the interface.
0:36:43	So if you wanted to run both global routing and automatic
0:36:47	6 to 4 at the same time
0:36:49	you could just configure both of them.
0:36:52	The problem is that if you're doing this in a real implementation
0:36:55	it's kind of a pain to number your whole network for automatic
0:36:58	6 to 4 and then do a migration to the global addressing.
0:37:05	There's a question here, "How am I working out the
0:37:08	base values to the powers?"
0:37:10	Because the mask's notation is talking about
0:37:16	how many bits it is.
0:37:18	So even though the address is denoted in hex
0:37:21	it's....
0:37:28	it's a 128 bits long
0:37:35	because each of these digits and let me go back to
0:37:40	the...
0:37:45	slide that talks about that so the address itself
0:37:48	is made up of eight groupings
0:37:51	of 2 bytes.
0:37:55	Eight groupings of 2 bytes it means that the whole
0:37:58	the whole address is 16 bytes long.
0:38:02	So if we took 16 bytes multiply this by 8
0:38:06	it means it's a 128 bits long.
0:38:09	So each of these groupings that are between the colons
0:38:16	these are 2 bytes long so it means 2 times 8
0:38:19	these are 16 bits each.
0:38:23	So when you're looking at how many hosts or
0:38:25	how many networks you have, it's always going to be
0:38:28	based on 2 to that power
0:38:31	because we're looking at it in binary.
0:38:34	So this means that if the prefix is a /64
0:38:41	it means that you have 64 bits in the host
0:38:47	and then you have -- excuse me, not the host
0:38:51	you have 64 bits in the network
0:38:56	so 64 bits of the address is denoting the network
0:38:59	64 bits is denoting the host.
0:39:05	So if you look at the number of combinations that you could have
0:39:09	for the network numbers or the host numbers
0:39:13	since the number is really a binary number because
0:39:17	the hex notation is only for us to look at visually.
0:39:20	When the router is processing this, it's always looking at it in
0:39:22	binary, so if I want to know how many hosts
0:39:27	could I have on the /64
0:39:31	it's going to be 2 to whatever that number is.
0:39:34	So 2 to the 64, that's the number of hosts
0:39:39	and also 2 to the 64 is the number of networks
0:39:43	because that's what my prefix length is.
0:39:49	So if I'm trying to figure out if I am allocated
0:39:52	a /48 prefix
0:39:56	so let's say theoretically IANA allocates me
0:39:59	the number 2001:1234:5678::/48
0:40:10	this is a /48 because that's 1 byte, that's 2, 3, 4, 5, 6
0:40:20	it's 6 bytes so 6 bytes times 8 bits
0:40:26	is 48 bits long, that's the prefix that they're giving me.
0:40:29	So now I have to figure out when I actually subnet this
0:40:32	and assign it to the hosts, what's the length of the
0:40:35	subnets that I want to use. Now you could use variably
0:40:38	lengths it doesn't really matter, we could go as far as
0:40:40	and say that between two routers let's say Router 1 to Router 2
0:40:45	we could use as long as a /127 here
0:40:49	a 127 in IPv6
0:40:53	this would be the equivalent of a /31 in IPv4
0:40:58	so it's exactly two numbers.
0:41:01	It would be Router 1's address so this would be like a
0:41:04	0 and Router 2's address would be a 1
0:41:09	If I were to say this was a /126 I could say
0:41:13	Router 1's a .1 and then -- well actually, not a .1
0:41:16	it would be :1
0:41:18	and then Router 2 could be :2
0:41:22	so if I have a /48 and let's say that I want to make this
0:41:26	into /64 subnets
0:41:30	so I need to look at what is the difference between
0:41:34	what I have as the /48 to the 64
0:41:39	so if you take 64 minus 48
0:41:43	and bear with me here because I'm horrible at math
0:41:45	64 minus 48 it means you have 16 bits
0:41:50	for the networks.
0:41:54	So therefore if I took 2
0:41:57	to the 16th, that's how many networks I would have
0:42:01	if I were to subdivide my /48 into all equal /64s
0:42:09	but you don't necessarily have to do that, you can allocate it
0:42:12	however you want. I could say maybe half of it I'm going to
0:42:15	dedicate to /64s because I know that maybe I'm not going to
0:42:19	have more than 32 thousand LANs where my hosts are located.
0:42:25	So if I took the first portion of the /64 and I'm going to
0:42:30	allocate that to the end hosts and then the rest
0:42:35	of it I'm going to allocate to longer matches
0:42:38	/96 or I'll say 96 plus 8 so
0:42:44	/104
0:42:46	so if I wanted to know how many /104s could I get
0:42:51	out of the /48
0:42:53	If I took 104 minus 48 is 56
0:42:58	2 to the 56 it's some insane number.
0:43:01	So this would be the number of networks, not the number of
0:43:05	hosts, so realistically it's basically infinite addressing
0:43:12	because you're never going to need these many networks or
0:43:14	hosts to begin with. The only problem is that if you start
0:43:18	allocating the subnets too big to begin with
0:43:21	then you could potentially run into a problem.
0:43:25	So let's say that like I'm an ISP an I get blocks of
0:43:28	/48 if I start allocating /64s everywhere
0:43:33	then it's pretty feasible that I'm going to have more than
0:43:36	65 thousand end networks that I need to route to.
0:43:41	So let's say like a cell phone network, there may be
0:43:43	10 million phones on the network that need IPv6 addresses.
0:43:49	So that means that they're going to have -- they're going to need
0:43:51	separate prefixes in order to be assigned those, so
0:43:55	if I did /64, that's not going to be feasible, it's going to have to be
0:43:57	something much much smaller to make sure I have a number
0:44:01	enough networks in order to deal with the amount of end hosts.
0:44:07	So it's going to be pretty interesting to see exactly
0:44:10	how the migration goes. One interesting site that you can
0:44:13	look at this is the statistics of the current BGP table
0:44:18	growth of IPv4 versus IPv6
0:44:22	and if you look for just the BGP table statistics
0:44:26	there's this site bgp.potaroo.net
0:44:33	so this is the current graph of the IPv4 table
0:44:37	and these are a couple different views that they're
0:44:39	looking at for, so it's almost around 400 thousand routes
0:44:43	but they also have a view of IPv6 versus IPv4
0:44:49	so the IPv6 to IPv4 comparative report here.
0:44:55	It says right now into the BGP table there's
0:45:00	219 thousand prefixes that being advertised
0:45:06	for IPv4
0:45:09	so even though there's a lot -- or actually no, that's the
0:45:12	yeah, that's the number of prefixes
0:45:16	where IPv6 there's only 850 routes.
0:45:19	So in the entire BGP table there's only 850 routes now for
0:45:23	IPv6 which is this percentage of the address base, it's
0:45:28	.0008 percent of the address base
0:45:31	but IPv4 40 percent of it is already advertised.
0:45:35	So basically it means that there's like another 30-40 percent somewhere
0:45:40	that people are not advertising into BGP.
0:45:43	So the addresses are already allocated
0:45:47	almost all of the IPv4 addresses are gone, but a lot of them
0:45:50	aren't advertised into the BGP table.
0:45:54	So it's going to be an interesting problem to see because
0:45:56	using IPv6 it doesn't really solve the problem
0:46:00	it just makes the problem bigger because the issue is
0:46:04	not really that we don't have enough addresses
0:46:06	it's that the table size is going to get out of control
0:46:10	because right now at 400 thousand routes
0:46:12	when you look at this from a BGP forwarding point of view
0:46:15	not only do you need to install this in the
0:46:18	the general route processor to build the routing table
0:46:23	when the router goes to forward, you need to put
0:46:25	the BGP table at the line card level at the FIB
0:46:30	so it means that in IPv6 let's say 5-10 years from now
0:46:34	it might be feasible that there could be 10 million
0:46:37	routes in the table, so not only would we have to
0:46:41	maintain the routing table of 10 million routes
0:46:43	but that's going to have to go down to the line card level
0:46:46	in order to do the hardware forwarding to those particular destinations.
0:46:50	So there are proposals about how to fix this problem
0:46:56	the common response is about the summarization
0:46:59	the problem is with the IPv6 design
0:47:01	there's no hierarchy to it.
0:47:04	So even though technically the addresses are hierarchical
0:47:08	that you could do allocations that summarize nicely together
0:47:14	the problem is that when you look at a graph of the internet
0:47:17	there really is no hierarchy to it.
0:47:19	So the structure of the interconnections is too complex
0:47:23	in order to say that well I'll put one level of aggregation
0:47:26	here and then another level of aggregation over here.
0:47:30	So for my network let's say I have ten upstream peers if I'm
0:47:33	well connected maybe I'm going to AT&T, Level 3
0:47:37	British telecom, Hurricane electric etc.
0:47:41	then it means that just based on my connectivity really there's
0:47:44	no good aggregation point because to figure out how to
0:47:47	route out to all of those peers, I'm going to have to have longer
0:47:51	matches than something very small like /16, it's not really going to be
0:47:55	feasible for IPv6 because there's so many different prefixes
0:47:59	that are going to fall into that, that's the reason
0:48:02	why the BGP table is so like disjointed now
0:48:09	so that's the key, the question is how does IPv6 solve the problem?
0:48:12	It doesn't solve the problem, it actually makes the problem worse.
0:48:15	So there are some proposals out there for new routing protocols
0:48:20	that do kind of like a geographical addressing
0:48:25	to basically enforce aggregation because you can go to IANA
0:48:30	right now and you can basically get whatever
0:48:34	IPv6 address base that you want to, so pretty much you
0:48:37	just need to fill out some paperwork for whatever the
0:48:41	internet registry is here like if you go to request resources
0:48:46	there's somewhere in here where you fill out a form to
0:48:47	get IPv6 addresses.
0:48:50	LISP if one of them, right so LISP is one of the ways that
0:48:53	you can do hierarchy and addresses based on the
0:48:56	the geography of the network, but it'll be kind of interesting to
0:48:59	see because we're still in the phase where IPv6
0:49:04	is still almost kind of like a research topic because there's
0:49:07	really not that many people implementing it
0:49:10	so we haven't really gotten to any of the scalability problems of
0:49:14	the protocol.
0:49:18	So kind of outside of the scope of the class here
0:49:21	but it's definitely going to be interesting to see what
0:49:24	what eventually happens with this.
0:49:26	Ok, so let's get back to the topic that I was talking about
0:49:29	here which is the automatic 6 to 4 tunnel.
0:49:33	The key for this again is that you need to figure out
0:49:37	what's the /48 prefix
0:49:41	that the router's site is going to be assigned.
0:49:43	So in the case of Router 6 it was 2002:961C:0606
0:49:51	If we go back to the command line here
0:49:54	it means that out of this /48 I'm going to allocate
0:49:57	some subnet. It doesn't really matter what it is
0:50:00	as long as it's encompassed by this /48
0:50:04	then at the VLAN 7 interface of Switch 1 here
0:50:10	I have another subnet
0:50:15	and these links they're still running RIPNG so if we look at
0:50:18	Router 6 and look at the show ipv6 route
0:50:22	we should see that both of these addresses are
0:50:25	going to be advertised
0:50:28	whereas in IPv4, we have the notion of the primary
0:50:32	address and the secondary address. There are some
0:50:35	limitations for advertising the secondary address into your
0:50:39	IGP where RIP is going to treat this differently than
0:50:42	EIGRP and OSPF does, most of the time for IPv4
0:50:46	it's not a good idea to have the secondary addressing to begin with.
0:50:50	But with IPv6 there's no limitation for it.
0:50:53	The main goal behind this is for anycast
0:50:56	where you can have duplicate addresses assigned to the same
0:50:58	routers and then you route to whichever one is geographically
0:51:02	closer to you or closer based on the metric
0:51:05	in the network.
0:51:07	So here we see that Router 6 is receiving that
0:51:11	particular prefix from Switch 1
0:51:16	so now I need to do the same thing on the
0:51:21	the other end of the network, if we show run on this interface
0:51:26	I'm going to have the same type of prefix on Router 5
0:51:32	which is going to be on I'll say do show run interface
0:51:35	Fast Ethernet 0/0
0:51:40	The difference is that this is going to be 505
0:51:46	505:58::5
0:51:54	then on Switch 2
0:52:00	on VLAN 58
0:52:03	similar address
0:52:06	and then on the VLAN 8 as well.
0:52:11	So now we have the addresses allocated
0:52:13	the issue then becomes how do we route the traffic between
0:52:17	the network edge.
0:52:19	Now with using just two sites in the network
0:52:22	it's pretty straightforward because we know from
0:52:24	Router 5 the only possible destination is going to be Router 6
0:52:28	because there's only two sites that are participating
0:52:30	in the IPv6 network.
0:52:34	However, the ultimate goal of automatic 6 to 4
0:52:37	is that you could be routing to any site over the internet
0:52:40	and it doesn't really matter where it's located as long as
0:52:44	we know the IPv4 address of the border router.
0:52:48	So in order to actually properly implement this
0:52:52	you need some sort of correlation between the
0:52:54	IPv6 destinations and then the IPv4 router you need to go to reach it.
0:53:00	So you would use something like DNS to do the resolution
0:53:03	from the whatever resource you're trying to reach to figure out
0:53:07	who is the router that actually is going to be advertising that.
0:53:12	So now on Router 5 and 6 we're going to change their
0:53:15	tunnel configurations so that first off they have an address
0:53:21	that's part of this allocated space so Router 5 we'll say that
0:53:27	it has the -- let's say it has the first subnet there
0:53:32	and Router 6 is going to do the same thing.
0:53:36	So on the tunnel this is part of the /48
0:53:42	so notice that Router 5 and 6 they're not on the same subnet here.
0:53:49	Next we're going to remove the tunnel destination
0:53:56	no tunnel destination and we're going to change the
0:53:59	tunnel mode to ipv6 ipv6ip
0:54:08	but this is an automatic 6 to 4 tunnel.
0:54:21	Likewise on Router 6, we're going to say no tunnel destination
0:54:24	the tunnel mode is ipv6 ip
0:54:28	6 to 4
0:54:31	Now since we know that every device
0:54:36	that is participating in the 6 to 4 addressing
0:54:39	is going to start with 2002
0:54:41	the easy way then to solve the routing is simply to say
0:54:45	on the border router ipv6 route 2002::/16 is via tunnel 0
0:54:55	so essentially when the host sends traffic to any destination
0:55:00	out via 2002, then it's going to point towards the
0:55:06	the tunnel.
0:55:15	So let's test this out. Now from Switch 2
0:55:19	we should be able to send traffic to the address of Switch 1
0:55:26	which is this
0:55:31	when we are sourcing traffic from our own local interface.
0:55:37	Now right now -- let's see show ipv6 route
0:55:44	let's see how did we learn those destinations?
0:55:47	It says that we have -- Switch 2 is receiving these via RIP
0:55:54	but I didn't actually tell it to
0:56:02	advertise that, so let's see I should not hear
0:56:09	that's actually kind of strange. In Router 6 let's say
0:56:12	show ipv6 route
0:56:17	how did we learn those destinations? Actually
0:56:19	you know what that is? It's old information that's
0:56:22	aging out of the table.
0:56:23	So I need to refresh the routing table here. Let's say
0:56:26	clear ipv6 rip
0:56:33	and Switch 2 should not be learning those particular subnets
0:56:39	so if we show ipv6 route rip
0:56:44	Ok, right now we don't have a route to the other side of the network
0:56:46	which is correct.
0:56:48	So if we ping the other side, right now we simply can't
0:56:53	reach them because we don't have any routing information.
0:56:56	Now on the network edge which is Router 5 and Router 6
0:56:59	they have static routes that are pointing out the tunnel
0:57:02	that are going to 2002/16
0:57:08	so typically what you would do in this design is either
0:57:10	just tell Router 5 to send a default route so send 0::/0
0:57:17	and do the same thing on Router 6 or we could take this
0:57:21	static route that's pointing out the tunnel and then
0:57:23	redistribute into our IGP
0:57:26	so on 5 we could go to the RIP process.
0:57:31	We'll say ipv6 router rip 1
0:57:35	redistribute static with the metric of 1
0:57:40	so now Switch 2 when we look at the routing table
0:57:44	it has that 2002/16
0:57:49	then likewise Router 6 is going to do the same thing
0:57:52	so ipv6 router rip 1
0:57:57	redistribute static
0:57:59	and we set a metric value so just like in RIP version 2
0:58:03	you do need to set the metric as you're going into
0:58:05	either RIP or EIGRP
0:58:09	For EIGRP unless you're going between two process two EIGRP ASs
0:58:12	you need to set the metric.
0:58:14	For OSPF it will have a default seed metric.
0:58:19	So now on Switch 1 if we look at the show ipv6 route rip
0:58:29	we have that route to the 2002::/16
0:58:38	If we look at the trace route to the destination
0:58:42	the key is that when this gets to the network edge
0:58:45	on Router 5, Router 5 figures out automatically who is the
0:58:50	tunnel destination based on the fact that Router 6's IPv4
0:58:55	address is encoded inside the IPv6 destination.
0:59:05	So in order for this to work, the first important point is
0:59:09	that you need to do the conversion of the addresses correctly.
0:59:12	So whatever is the tunnel source on Router 5 and Router 6
0:59:17	now it doesn't necessarily have to be the loopback interface
0:59:21	but typically in most configurations that's what it is
0:59:24	because it's going to be -- it could be your outgoing interface
0:59:28	towards the public network like on Router 5 if we are
0:59:32	routing out to the network via -- if we're going via this interface
0:59:40	then we could say the tunnel source is serial 0/1/0
0:59:45	so whatever IPv4 address is assigned on that link
0:59:51	that's where the 2002: then the IPv4
0:59:58	address /48 is going to be assigned from.
1:00:04	Then assuming that Router 5 and Router 6 already have
1:00:07	IPv4 reachability to each other, then they should automatically
1:00:11	be able to route the traffic out the tunnel.
1:00:18	So when we look at this on the transit path if we were to
1:00:21	go to Router 4
1:00:31	and we look at the trace route that's coming from Switch 2
1:00:34	going to Switch 1
1:00:37	the transport protocol is the same type of encapsulation.
1:00:48	So the actual IPv6 IP tunnel it has multiple functionalities.
1:00:51	We could use it as the static tunnel where
1:00:54	we simply say on the tunnel mode ipv6 ip
1:00:57	then we manually configure what the tunnel source and tunnel
1:01:00	destination is or in this case where we have the
1:01:04	automatic 6 to 4 tunnel we're saying the tunnel mode is
1:01:07	IPv6 IP 6 to 4
1:01:11	so it infers based on the 2002 address and the next
1:01:15	32 bits where the tunnel destination is.
1:01:24	But again, then the two disadvantages of this solution
1:01:27	the first is that you need to renumber your addresses
1:01:31	internally, so I would need everyone on my side of the network
1:01:36	to run 2002:961C:505
1:01:40	then additionally you cannot run dynamic routing.
1:01:46	If you wanted to run dynamic routing, then you would
1:01:48	have to run the -- this feature, the dynamic multipoint VPN.
1:01:54	So this is a GRE tunnel that is multipoint
1:01:58	and it's basically using the hub of the network
1:02:02	to build the control plane for routing and then the spokes can
1:02:10	set up tunnels directly between each other.
1:02:15	There's a question here, "What if you have NAT?"
1:02:17	It really depends on the individual NAT implementation.
1:02:22	I'm pretty sure that Cisco's translation is not going to
1:02:28	break the 6 to 4 because the key is that the
1:02:36	protocol number 41 is destined for the router itself.
1:02:41	So you may have -- so are you saying that the translation
1:02:44	is on the router that's doing the tunnel or it's in front of the
1:02:47	router that's doing the tunnel
1:02:49	because that's going to make a difference, so if we look at the design
1:02:51	and we say that -- so Router 6 was the tunnel source
1:02:57	Router 5 was one of the tunnel sources.
1:03:00	If 4 is in the middle
1:03:04	and then 4 is doing NAT
1:03:06	where this is the outside, this is the inside
1:03:10	this is going to cause a problem
1:03:13	because I don't believe that you can do port translations
1:03:17	for protocol number 41
1:03:20	What you could do is just a static mapping
1:03:24	so I could say for whatever this outside interface here
1:03:27	I could do a manual mapping to redirect this to Router 5
1:03:31	at protocol 41
1:03:33	but then the problem is you would have a mismatch between
1:03:36	what the public and the private addresses are
1:03:43	so when you assign the 2002 prefix -- I'm not a 100 percent
1:03:48	sure if that's going to work then
1:03:51	because the border router is controlled by the
1:03:56	the border router is controlled by the address that's embedded in the
1:04:00	destination.
1:04:02	So most likely if you're doing the NAT on the router that
1:04:06	terminates the tunnel, that should be fine, but probably
1:04:09	this example where there's a NAT in between, most likely
1:04:12	this is going to break it.
1:04:14	So if you do need to go through the network address translation
1:04:17	this is generally what the teredo tunnel is for
1:04:20	if you just search for teredo
1:04:29	teredo tunneling is a transition technology for IPv6 connectivity
1:04:34	over the IPv4 internet.
1:04:37	Compared to other protocols the distinguishing feature is
1:04:41	that it's able to perform its function even behind NAT.
1:04:43	Ok, the reason why this works is that IPv6 is encapsulated
1:04:48	inside of UDP.
1:04:50	So you're assuming that if your inspection engine already
1:04:53	supports UDP translations, then it's going to support teredo as well.
1:04:57	But the problem is this is not really designed to be
1:05:00	a site to site tunnel, it's really an end host to end host tunnel
1:05:05	where you have the teredo relays which is like the tunnel broker.
1:05:11	It says they have access to IPv6 network, they receive the
1:05:14	packets, unencapsulate them and route them on.
1:05:23	There's a question, "If you hide the networks behind 6 and 5
1:05:27	so you should not need to renumber the network?"
1:05:30	So if you did 6 to 6 NAT you mean?
1:05:39	I guess you could do 6 to 6 NAT
1:05:46	I'm not sure if IOS even supports that yet though
1:05:49	let's look under
1:05:54	IPv6 configuration
1:05:59	there's NAT protocol translation
1:06:03	and I think that's called -- is it called NAT6?
1:06:12	NAT for IPv6 only hosts
1:06:15	so it says this is on standards track May, 2009
1:06:22	that's version 1, this may not be implemented yet.
1:06:30	Let's see here.
1:06:31	site:www.cisco.com nat6
1:06:35	and a part of the problem with these IPV6 features
1:06:39	is that a lot of them are brand new in the implementation.
1:06:43	So you'll see that when you look at some of the feature guides
1:06:48	so this says
1:06:55	let's see, it doesn't look like it does
1:06:58	let's try this in quotes.
1:06:59	You'll see that some of the features it'll say like 15.0 T or
1:07:03	15.1 where basically you need the very latest enterprise versions
1:07:09	in order to support this stuff so that's probably not going to
1:07:12	work -- eventually that would work, but it's kind of going out of the way
1:07:16	it's probably easier just to do the renumbering
1:07:19	as opposed to doing the 6 to 6 solution.
1:07:24	But then the key is you would still need some
1:07:28	sort of mapping mechanism for the actual application
1:07:31	which generally is going to be done by DNS.
1:07:35	Now I'm not sure if the router supports the DNS V6 server
1:07:40	I don't believe it does.
1:07:46	Let's see, well we can check this on the router -- this type of
1:07:49	stuff, we are going to talk about in services
1:07:53	not really necessarily a lot of the configurations because
1:07:55	once you try this stuff out, it's pretty self-explanatory how
1:07:58	it works, but the -- let's see ip
1:08:03	can we say ipv6 host
1:08:06	and then a.b.com
1:08:15	the address 2001::1
1:08:25	I don't believe it supports it. If you...
1:08:30	let's search for DNS aaaa
1:08:38	Use domain name services and IPv6
1:08:47	probably not because if it did support it, I think this would be
1:08:51	under IPv6 configuration as opposed to the DNS.
1:08:55	So some of these other minor features like the
1:08:57	DHCP, the NetFlow, NTP,
1:09:02	network address translation we are going to talk about
1:09:04	this stuff in services
1:09:05	but once you understand again how it works for IP version 4
1:09:09	there's really not that much of a stretch for it to go out to
1:09:13	IP version 6
1:09:20	There's a question, "Earlier when I advertised IPv6 prefixes with
1:09:22	BGP version 4 as the transport, how did you resolve the next hop
1:09:27	issue? I know you use a route map and set the local IPv4 address
1:09:30	but where do you apply it?"
1:09:33	Now the way that I did I applied it inbound
1:09:36	and I think the configuration is still on there. If we look at
1:09:39	Router 6 and show run section route map
1:09:51	so this is the next hop value of the IPv6 neighbor
1:09:56	essentially what I would have done is under the
1:10:00	IPv6 address family
1:10:05	so we have the route map here
1:10:08	where we said router bgp 6
1:10:10	neighbor whatever their address is 1.2.3.4 remote-as 1
1:10:15	then under the address family
1:10:18	ipv6 unicast
1:10:21	this neighbor would be activated
1:10:24	then we would have the route map
1:10:29	from Router 1 in
1:10:32	so basically this says that when we're receiving
1:10:35	IPv6 updates, change the next hop value
1:10:39	so it's actually an IPv6 address
1:10:41	because the problem is it's coming from an IPv4 neighbor.
1:10:46	So I'm setting the IPv6 next hop.
1:10:49	Now you could also do it the other way around.
1:10:52	I also did it where the transport was IPv6
1:10:56	but the address family was IPv4
1:10:59	in which case for that
1:11:02	it would look like this. Let's say that this is the
1:11:06	neighbor's address
1:11:11	so that's the neighbor's address, but we're trying to set them to be
1:11:16	to have an IPv4 next hop
1:11:21	so now it would be this neighbor's address
1:11:28	but now they are under IPv4 unicast.
1:11:35	So it's going to work either way.
1:11:37	The key is that the transport of BGP is separate from the
1:11:42	actual advertisement of the network layer reachability information.
1:11:46	So we can advertise IPv4 routes, IPv6 routes
1:11:50	IPv4 multicast, IPv6 multicast
1:11:53	all over the same transport session
1:11:55	because the logic behind this is that if I have two
1:11:58	routers that already have the TCP session
1:12:01	why do I need to establish another TCP session
1:12:03	just to advertise more updates.
1:12:06	So if they're already running both address families
1:12:09	then there's no reason to increase the load on the control plane
1:12:13	and manage two separate TCP sessions.
1:12:15	We can just have one session that they're exchanging
1:12:17	different types of updates over.

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

IPv6 Tunneling

Create Bookmark