rms.koenig-solutions.comrms.koenig-solutions.com/.../Trainer/QMS/824-20191014… · Web viewIPV6 NOTES: Introduction to IPv6. In this lesson i’ll give you an introduction to IPv6

IPV6 NOTES:

Introduction to IPv6In this lesson i’ll give you an introduction to IPv6 and you will learn the differences between IPv4 and IPv6. Let’s start with a nice picture:

This picture is old already but it shows you the reason why we need IPv6…we are running out of IPv4 addresses!

So what happened to IPv4? What went wrong? We have 32-bits which gives us 4,294,467,295 IP addresses. Remember our Class A, B and C ranges? When the Internet started you would get a Class A, B or C network. Class C gives you a block of 256 IP addresses, a class B is 65.535 IP addresses and a class A even 16,777,216 IP addresses. Large companies like Apple, Microsoft, IBM and such got one or more Class A networks. Did they really need > 16 million IP addresses? Many IP addresses were just wasted.

We started using VLSM (Variable Length Subnet Mask) so we could use any subnet mask we like and create smaller subnets, we longer had to use the class A, B or C networks. We

also started using NAT and PAT so we can have many private IP addresses behind a single public IP addresses.

Nevertheless the Internet has grown in a way nobody expected 20 years ago. Despite all our cool tricks like VLSM and NAT/PAT we really need more IP addresses and that’s why we need IPv6.

What happened to IPv5? Good question…IP version 5 was used for an experimental project called “Internet Stream Protocol”. It’s defined in a RFC if you are interested:

http://www.faqs.org/rfcs/rfc1819.htmlIPv6 has 128 bit addresses and has a much larger address space than 32-bit IPv4 which offered us a bit more than 4 billion addresses. Keep in mind every additional bit doubles the number of IP addresses…so we go from 4 billion to 8 billion, 16,32,64, etc. Keep doubling until you reach 128 bit. With 128 bits this is the largest value you can create:

340,282,366,920,938,463,463,374,607,431,768,211,456Can we even pronounce this? Let’s try this:

340- undecillion 282- decillion 366- nonillion 920- octillion 938- septillion 463- sextillion 463- quintillion 374- quadrillion 607- trillion 431- billion 768- million 211- thousand 456That’s mind boggling… This gives us enough IP addresses for networks on earth, the moon, mars and the rest of the universe. To put this in perspective let’s put the entire IPv6 and IPv4 address space next to each other:

IPv6: 340282366920938463463374607431768211456 IPv4: 4294467295

Some other nice numbers: the entire IPv6 address space is 4294467295 times the size of the complete IPv4 address space. Or if you like percentages, the entire IPv4 address space is only 0.000000000000000000000000001.26% of the entire IPv6 address space.The main reason to start using IPv6 is that we need more addresses but it also offers some new features:

No Broadcast traffic: that’s right, we don’t use broadcasts anymore. We use multicast instead. This means some protocols like ARP are replaced with other solutions.

Stateless Autoconfiguration: this is like a “mini DHCP server”. Routers running IPv6 are able to advertise the IPv6 prefix and gateway address to hosts so that they can automatically configure themselves and get access outside of their own network.

Address Renumbering: renumbering static IPv4 addresses on your network is a pain. If you use stateless autoconfiguration for IPv6 then you can easily swap the current prefix with another one.

Mobility: IPv6 has built-in support for mobile devices. Hosts will be able to move from one network to another and keep their current IPv6 address.

No NAT / PAT: we have so much IPv6 addresses that we don’t need NAT or PAT anymore, every device in your network can have a public IPv6 address.

IPsec: IPv6 has native support for IPsec, you don’t have to use it but it’s built-in the protocol.

Improved header: the IPv6 header is simpler and doesn’t require checksums. It also has a flow label that is used to quickly see if certain packets belong to the same flow or not.

Migration Tools: IPv4 and IPv6 are not compatible so we need migration tools. There are multiple tunneling techniques that we can use to transport IPv6 over IPv4 networks (or the other way around). Running IPv4 and IPv6 simultaneously is called “dual stack”.

What does an IPv6 address look like? We use a different format than IPv4:

X:X:X:X:X:X:X:X where X is a 16-bit hexadecimal field

We don’t use decimal numbers like for IPv4, we are using hexadecimal now. Here’s an example of an actual IPv6 address:

2041:1234:140F:1122:AB91:564F:875B:131B

Now imagine you have to call one of your users or colleagues and ask him or her to ping this IPv6 address when you are trying to troubleshoot something…sounds like fun right?

To make things a bit more convenient it’s possible to shorten IPv6 addresses which I discuss in this lesson. Running a local DNS server is also a good idea. Remembering hostnames is easier than these IPv6 addresses.If you are unsure how hexadecimal numbers work, take a look here.

That’s all I have for now, I hope this introduction has given you an idea of why we need IPv6, what the address looks like and some of the new features. In the next lessons we will cover everything including addressing, routing protocols, tunneling and more.

That’s all for now! You should now have an idea of how IPv6 works. In future lessons I will show you how to configure routing for IPv6 and some other things. If you have any questions just leave a comment.

Shortening IPv6 AddressesIPv6 addresses are hexadecimal and since they are 128-bit, they are quite long. Imagine you have to call a friend and ask him/her to ping the following address:

2041:0000:140F:0000:0000:0000:875B:131B

To make our lives a bit better, IPv6 addresses can be shortened. Let’s take a look at some examples and I’ll show you how it works:

Original: 2041:0000:140F:0000:0000:0000:875B:131B Short: 2041:0000:140F::875B:131BIf there is a string of zeros then you can remove them once. In the example above I removed the entire 0000:0000:0000 part. You can only do this once, your IPv6 device will fill up the remaining space with zeros until it has a 128 bit address.There is more however, the address can be shortened even more:

Short: 2041:0000:140F::875B:131B Shorter: 2041:0:140F::875B:131BIf you have a “hextet” with 4 zeros then you can remove those and leave a single zero. Your IPv6 device will add the remaining 3 zeros.

When we talk about IPv4 addresses, we use the term “octet” to define a “block” of 8 bits. In IPv6, there is no official term (yet) and there is an IETF draft that discusses the names to be

used. The official term for 4 hexadecimal values is “hexadectet”, this is hard to remember / pronounce so the short form “hextet” will be used.

Leading zeros can also be removed, here’s another address to demonstrate this:

Original: 2001:0001:0002:0003:0004:0005:0006:0007 Short: 2001:1:2:3:4:5:6:7By removing these zeros we get a nice short IPv6 address.

To summarize these rules:

An entire string of zeros can be removed, you can only do this once. 4 zeros can be removed, leaving only a single zero. Leading zeros can be removed.I hope this helps! Feel free to leave a comment if you have any questions.

How to find IPv6 PrefixIPv4 addresses have a subnet mask but instead of typing something like 255.255.255.0 we use a prefix length for IPv6. Here is an example of an IPv6 prefix:2001:1111:2222:3333::/64This is pretty much the same as using 192.168.1.1 /24. The number behind the / are the number of bits that we use for the prefix. In the example above it means that 2001:1111:2222:3333 is the prefix (64 bits) and everything behind it can be used for hosts.

When calculating subnets for IPv4 we can use the subnet mask to determine the network address and for IPv6 we can do something alike. For any given IPv6 address we can calculate what the prefix is but it works a bit different.

Let me show you what I’m talking about, here’s an IPv6 address that could be assigned to a host:

2001:1234:5678:1234:5678:ABCD:EF12:1234/64What part from this IPv6 address is the prefix and what part identifies the host?

Since we use a /64 it means that the first 64 bits are the prefix. Each hexadecimal character represents 4 binary bits so that means that this part is the prefix:

2001:1234:5678:1234This part has 16 hexadecimal characters. 16 x 4 means 64 bits. So that’s the prefix right there. The rest of the IPv6 address identifies the host:

5678:ABCD:EF12:1234So we figured out that “2001:1234:5678:1234” is the prefix part but writing it down like this is not correct. To write down the prefix correctly we need to add zeros at the end of this prefix so that it is a 128 bit address again and add the prefix length:

2001:1234:5678:1234:0000:0000:0000:0000/64 is a valid prefix but we can shorten it. This string of zeros can be removed and replace by a single ::2001:1234:5678:1234::/64That’s the shortest way to write down the prefix. Let’s look at another example:

3211::1234:ABCD:5678:1010:CAFE/64Before we can see what the prefix is, we should write down the complete address as this one has been shortened (see the :: ). Just add the zeros until we have a full 128 bit address again:

3211:0000:0000:1234:ABCD:5678:1010:CAFE/64We still have a prefix length of 64 bits. A single hexadecimal character represents 4 binary bits, so the first 16 hexadecimal characters are the prefix:

3211:0000:0000:1234Now we can add zeros at the end to make it a 128 bit address again and add the prefix length:

3211:0000:0000:1234::/64That’s a good looking prefix but we can make it a little shorter:

3211:0:0:1234::/644 zeroes in a row can be replaced by a single one, so “3211:0:0:1234::/64” is the shortest we can make this prefix.

Depending on the prefix length it makes the calculations very easy or (very) difficult. In the examples I just showed you both prefixes had a length of 64. What if I had a prefix length of /53 or something?

Each hexadecimal character represents 4 binary bits. When your prefix length is a multiple of 16 then it’s easy to calculate because 16 binary bits represent 4 hexadecimal characters.

Here’s an illustration:

So with a prefix length of 64 we have 4 “blocks” with 4 hexadecimal characters each which makes it easy to calculate. When the prefix length is a multiple of 4 then it’s still not too bad because the boundary will be a single hexadecimal character.

When the prefix length is not a multiple of 16 or 4 it means we have to do some binary calculations. Let me give you an example!

2001:1234:abcd:5678:9877:3322:5541:aabb/53This is our IPv6 address and I would like to know the prefix for this address. Where do I start?

First I have to determine in what “block” my 53rd bit is located:

Somewhere in the blue block we will find the 53rd bit. To know what the prefix is we will have to calculate those hexadecimal characters to binary:

We now have the block that contains the 53rd, this is where the boundary is between “prefix” and “host”:

Now we will set the host bits to 0 so that only the prefix remains. Finally we calculate from binary back to hexadecimal:

Put this block back into place and set all the other host bits to 0 as well:

We have now found our prefix! 2001:1234:abcd:5000::/53 is the answer. It’s not that bad to calculate but you do have to get your hands dirty with binary…

Hopefully this lesson has been useful to you, if you have any questions feel free to leave a comment!

Pv6 Address Types

IPv6 looks different than IPv4 but there are some similarities. For example we have unicast addresses and we still have a “public” and “private” range. We use different names for these but the idea is the same. One of the differences is that IPv6 has some additional unicast address types.

We still have multicast, same idea but we use different addresses. There are also some reserved addresses that are similar to their IPv4 counterparts.

Something new is anycast, an address that can be assigned on multiple devices so that packets are always routed to the closest destination. Also, broadcast traffic doesn’t exist in IPv6 anymore.

In this lesson we’ll take a look at all the different address types and I’ll explain what they look like and how we use them.

Unicast

Unicast IPv6 addresses are similar to unicast IPv4 addresses. These are meant to configure on one interface so that you can send and receive IPv6 packets. There are a number of different unicast address types that we’ll discuss here.

Global Unicast

The global unicast IPv6 addresses are similar to IPv4 public addresses. These addresses can be used on the Internet. The big difference with IPv4 is that we have so much address space that we can use global unicast addresses on any device in the network.

Unique Local

Unique local addresses work like the IPv4 private addresses. You can use these addresses on your own network if you don’t intend to connect to the Internet or if you plan to use IPv6

NAT. The advantage of unique local addresses is that you don’t need to register at an authority to get some address space. The FC00::/7 prefix is reserved for unique local addresses, however when you implement this you have to set the L-bit to 1 which means that the first two digits will be FD. Here’s an example:

Let’s discuss all the fields of the unique local address. The first 7 bits indicate that we have a unique local address. 1111 110 in binary is FC in hexadecimal. However, the L bit (8th bit) has to be set to 1 so we end up with 1111 1101 which is FD in hexadecimal.

The global ID (40 bits) is something you can make up. Normally an ISP would choose a prefix but now it’s up to you to think of something. What’s left is 16 bits that we can use for different subnets. This gives us a 64-bit prefix, what’s left is 64 bits for the interface ID.

Let’s work on an example…let’s say that we have a LAN and we want to use unique local IPv6 addresses and we require 10 subnets:

The prefix starts with FD. We have 40 bits for the global ID, each hexadecimal character represents 4 bits so we

can pick 10 hexadecimal characters. Let’s use AB:1234:5678 as the global ID. Our first subnet will start with 0000.Here’s what we’ll end up with:

FDAB:1234:5678:0000::/64 will be our first subnet. The other subnets could look like this:

FDAB:1234:5678:0000::/64 FDAB:1234:5678:0001::/64 FDAB:1234:5678:0002::/64 FDAB:1234:5678:0003::/64 FDAB:1234:5678:0004::/64

FDAB:1234:5678:0005::/64 And so on…If you are just messing around with IPv6 then you could use a simple global ID like 00:0000:0000 which is nice because you can shorten it to ::. For production networks, it’s better to pick something that is truly unique. When you want to connect multiple sites that use unique local addresses then you want to make sure you don’t have overlapping global IDs.

Link-Local

Link-local addresses are something new in IPv6. As the wording implies, these addresses only work on the local link, we never route these addresses. These addresses are used to send and receive IPv6 packets on a single subnet.When you enable IPv6 on an interface then the device will automatically create a link-local address. We use the link-local address for things like neighbor discovery (the replacement for ARP) and as the next hop address for routes in your routing table. You will learn more about this when you work through the static route and OSPFv3 lessons.We use the FE80::/10 range for link-local addresses, this means that the first 10 bits are 1111 1110 10. Here’s what it looks like:

The first 10 bits are always 1111 1110 10 which means that we start with FE80. Technically the following are all valid link-local addresses:

FE8 - 1111 1110 1000 FE9 - 1111 1110 1001 FEA - 1111 1110 1010 FEB - 1111 1110 1011These link-local addresses however are automatically generated by the host which sets the 54 bits to zeroes. This means that normally you will only see link-local addresses that start with FE80.

https://networklessons.com/ipv6/how-to-configure-ipv6-ospfv3-on-cisco-ios-router/

https://networklessons.com/ipv6/how-to-configure-ipv6-static-route/

https://networklessons.com/ipv6/ipv6-neighbor-discovery-protocol-on-cisco-router/

Site-Local

The site local range was originally meant to be the "private range" for IPv6. It has been deprecated though and nowadays we use the unique local addresses instead. For these addresses we used the FEC0::/10 range (1111 1110 11 in binary)

If you are interested why they gave up on the site local addresses then you can read RFC 3879 for the full story.Unspecified

The 0:0:0:0:0:0:0:0 address is called the unspecified address, :: is the shortened version of this address. It should never be configured on a host and is used to indicate that the host doesn't have any address.

Loopback

the 0:0:0:0:0:0:0:1 address is called the loopback address, the short version is ::1. IPv6 devices can use this to send an IPv6 packet to themselves which is typically used for testing. It should never be assigned to any physical interfaces. This address is the equivalent of IPv4's 127.0.0.1 address.

Multicast

In IPv6 we use multicast for IPv6 (routing) protocols and for user traffic. We use the FF::/8 prefix for multicast traffic (1111 1111 in binary). Let's take a look what the addresses look like:

The first 8 bits indicates that we have a multicast address. The next 4 bits are used to set flags, these are used for some special things like embedded RP. The scope bits are used to tell the "scope" of this multicast traffic. You can use this to indicate that the multicast traffic should be restricted to link-local, organization local or global (Internet).Below you will find an overview with some of the most common IPv6 multicast addresses:

https://networklessons.com/multicast/embedded-rp-ipv6-multicast/

https://tools.ietf.org/html/rfc3879


FF02::1 - all nodes on local network segment. FF02::2 - all routers on local network segment. FF02::5 - all OSPFv3 routers. FF02::6 - all OSPFv3 DR routers. FF02::9 - RIPng routers FF02::A - EIGRP routersIf you look closely you can see some of these addresses are similar to their IPv4 multicast counterparts. For example, in IPv4 we use 224.0.0.05 and 224.0.0.6 for OSPF while we use FF02::5 and FF02::6 for ipv6. We use 224.0.0.9 for RIPv2 and FF02::9 for RIPng.

Anycast

The anycast address is new in IPv6. The same address can be assigned to multiple devices and advertised in a routing protocol. When you send a packet to an anycast address then it will be delivered to the closest interface. Something similar is possible in IPv4 but it was never "officially" possible. There is no specifix prefix for anycast addresses. Any unicast address that you use on more than one device is suddenly an anycast address. The only difference is that you have to configure the device and tell that the address will be used for anycast.

IPv6 Address Assignment ExampleIn this lesson we’ll take a look how you can create IPv6 prefixes and subnets so that you can configure your entire network with IPv6. We’ll start at the top where IANA (Internet Assigned Numbers Authority) is responsible for the global coordination of the IPv4 and IPv6 address space and move our way all the way to the bottom where we assign subnets and IPv6 addresses to our routers, switches and VLANs.IPv6 Global Unicast Prefix Assignments

IANA “owns” the entire IPv6 address space and they assign certain prefixes to the RIRs (Regional Internet Registry). There are 5 RIRs at the moment:

http://iana.org/

AFRINIC: Africa APNIC: Asia/Pacific ARIN: North America LACNIC: Latin America and some Caribbean Islands RIPE NCC: Europe, Middle east and Central AsiaIf you are interested, click here for an overview of all IPv6 prefix assignments by IANA.When a large ISP (or large company) in North America wants IPv6 addresses then they will contact ARIN who will assign them an IPv6 prefix if they meet all requirements. The ISP can then assign prefixes to their customers.

Let’s take a look at some actual prefixes:

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

https://www.ripe.net/

http://www.lacnic.net/

https://www.arin.net/

https://www.apnic.net/

http://www.afrinic.net/

IANA is using the 2000::/3 prefix for global unicast address space. According to this list, RIPE NCC received prefix 2001:4000::/23 from IANA. A large ISP called Ziggo in The Netherlands receives prefix 2001:41f0::/32 from RIPE

NCC. The ISP assigns prefix 2001:41f0:4060::/48 to one of their customers.Now it’s up to the customer what they want to do with their IPv6 prefix…

IPv6 Global Unicast Subnet Assignments

Our customer received prefix 2001:41f0:4060::/48 and they want to use it to configure IPv6 on their entire network. Where do we start? Take a look at the image below:

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

The 48-bit prefix that we received is typically called the global routing prefix or site prefix. The interface ID is normally 64 bit which means we have 16 bits left to create subnets.If I want I can steal some more bits from the Interface ID to create even more subnets but there’s no need for this. Using 16 bits we can create 65.536 subnets …more than enough for most of us. Let’s see what we can do for our customer:

16 bits gives us 4 hexadecimal characters. All possible combinations that we can create with those 4 hexadecimal characters are our possible subnets. Everything from 0000 to FFFF are valid subnets:

2001:41f0:4060:0000::/64 2001:41f0:4060:0001::/64 2001:41f0:4060:0002::/64 2001:41f0:4060:0003::/64 2001:41f0:4060:0004::/64 2001:41f0:4060:0005::/64 2001:41f0:4060:0006::/64 2001:41f0:4060:0007::/64 2001:41f0:4060:0008::/64 2001:41f0:4060:0009::/64 2001:41f0:4060:000A::/64 2001:41f0:4060:000B::/64 2001:41f0:4060:000C::/64 2001:41f0:4060:000D::/64 2001:41f0:4060:000E::/64 2001:41f0:4060:000F::/64 2001:41f0:4060:0010::/64 2001:41f0:4060:0011::/64 2001:41f0:4060:0012::/64 2001:41f0:4060:0013::/64 2001:41f0:4060:0014::/64 And so on…Now you know what subnets you can use, here's an example of a small network where we use some of these subnets:

In the example above I used some numbers some make sense, for example on VLAN 10 we use 2001:41f0:4060:10::/64, another good option would be 2001:41f0:4060:A::/64 since the A in hexadecimal equals 10 in decimal. For the VLANs it's best to use a /64 so that you can use autoconfiguration for hosts.On the link between R1 and R2 I used a /64 but according to RFC 6164 you should use a /127 on point-to-point links.

Each subnet will require an IPv6 address on the router that will be used as the default gateway. The most simple solution is probably to use the first IPv6 address in the subnet. For example for VLAN 20 you could use 2001:41f0:4060:20::1/64 or for VLAN 2 you could use 2001:41f0:4060:2::1/64.


https://networklessons.com/ipv6/stateless-autoconfiguration-for-ipv6/

Conclusion

I hope this lesson has helped to understand where IPv6 prefixes come from and how you can create your own subnets for your network. There's one more overview I want to share with you that has some of the terminology:

Name Assignment Example

Registry prefix IANA to RIR 2001:4000::/23

ISP prefix RIR to ISP 2001:41f0::/32

Global routing prefix or site prefix ISP to customer 2001:41f0:4060::/48

Subnet prefix Network engineer 2001:41f0:4060:1234::/64

If you have any questions, feel free to leave a comment!

IPv6 EUI-64 explainedEUI-64 (Extended Unique Identifier) is a method we can use to automatically configure IPv6 host addresses. An IPv6 device will use the MAC address of its interface to generate a unique 64-bit interface ID. However, a MAC address is 48 bit and the interface ID is 64 bit. What are we going to do with the missing bits?

Here’s what we will do to fill the missing bits:

1. We take the MAC address and split it into two pieces.2. We insert “FFFE” in between the two pieces so that we have a 64 bit value.3. We invert the 7th bit of the interface ID.So if my MAC address would be 1234.5678.ABCD then this is what the interface ID will become:

Above you see how we split the MAC address and put FFFE in the middle. It doesn’t include the final step which is “inverting the 7th” bit. To do this you have to convert the first two hexadecimal characters of the first byte to binary, lookup the 7 th bit and invert it. This means that if it’s a 0 you need to make it a 1, and if it’s a 1 it has to become a 0.

The 7th bit represents the universal unique bit. A “built in” MAC address will always have this bit set to 0. When you change the MAC address this bit has to be set to 1. Normally people don’t change the MAC addresses of their interfaces which means that EUI-64 will change the 7th bit from 0 to 1 most of the time. Here’s what it looks like:

We take the first two hexadecimal characters of the first byte which are “12” and convert those back to binary. Then we invert the 7th bit from 1 to 0 and make it hexadecimal again. The EUI-64 interface ID will look like this:

Now you know how EUI-64 works, let's see what it looks like on a router. I'll use a Cisco IOS router for this and use 2001:1234:5678:abcd::/64 as the prefix:

Router(config)#interface fastEthernet 0/0Router(config-if)#ipv6 address 2001:1234:5678:abcd::/64 eui-64

In this I configured the router with the IPv6 prefix and I used EUI-64 at the end. This is how we can automatically generate the interface ID using the mac address. Now take a look at the IPv6 address that it created:

Router#show interfaces fastEthernet 0/0 | include Hardware Hardware is Gt96k FE, address is c200.185c.0000 (bia c200.185c.0000)Router#show ipv6 interface fa0/0FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C000:18FF:FE5C:0 No Virtual link-local address(es): Global unicast address(es): 2001:1234:5678:ABCD:C000:18FF:FE5C:0, subnet is 2001:1234:5678:ABCD::/64 [EUI]

See the C000:18FF:FE5C:0 part above? That’s the MAC address that is split in 2, FFFE in the middle and the “2” in “C200” of the MAC address has been inverted which is why it now shows up as “C000”.

When you use EUI-64 on an interface that doesn’t have a MAC address then the router will select the MAC address of the lowest numbered interface on the router.

I hope this has been useful to understand EUI-64, if you have any questions feel free to leave a comment!

IPv6 Summarization ExampleSummarizing IPv6 prefixes is similar to IPv4 summarization, the big difference is that IPv6 uses 128 bit addresses compared to 32 bits for IPv4 and IPv6 uses hexadecimal addresses.

In this lesson, I’ll explain how to create IPv6 summaries and we’ll walk through some examples together.

Example 1

Let’s start with a simple example:

2001:DB8:1234:ABA2::/64 2001:DB8:1234:ABC3::/64

Let’s say we have to create a summary that includes the two prefixes above. Each hextet represents 16 bits. The first three hextets are the same (2001:DB8:1234) so we have 16 + 16 + 16 = 48 bits that are the same so far. To find the other bits that are the same we only have to focus on the last hextet:

ABA2 ABC3

We’ll have to convert these from hexadecimal to binary to see how many bits are the same:

ABA2 1010101110100010

ABC3 1010101111000011

I highlighted the bits in red that are the same, the first 9 bits. The remaining blue bits are different. To get our summary address, we have to zero out the blue bits:

AB80 1010101110000000

When we calculate this from binary back to hexadecimal we get AB80. The first three hextets are the same and in the 4th octet we have 9 bits that are the same. 48 + 9 = 57 bits. Our summary address will be:

2001:DB8:1234:AB80::/57

That’s how you can create a summary address for IPv6.

Example 2

This time we have the following 3 prefixes:

2001:DB8:0:1::/64 2001:DB8:0:2::/64 2001:DB8:0:3::/64

https://networklessons.com/network-services/hexadecimal-decimal-binary/

And our goal is to create the most optimal summary address. The first three hextets are the same so that’s 16 + 16 + 16 = 48 bits that these prefixes have in common. For the remaining bits, we’ll have to look at the 4th hextet in binary:

0001 0000000000000001

0002 0000000000000010

0003 0000000000000011

Keep in mind that each hextet represents 16 bits. The first 14 bits are the same, to get the summary address we have to zero out the blue bits:

0000 0000000000000000

When we calculate this from binary back to hexadecimal we get 0000. The first three hextets are the same and in the 4th octet we have 14 bits that are the same. 48 + 14 = 62 bits. Our summary address will be:

2001:DB8::/62

Example 3

Let's try one more:

2001:DB8:0:7::/64 2001:DB8:0:12::/64

Let's see what the most optimal summary address is that has these two prefixes. The first three hextets are the same so that's 16 + 16 + 16 = 48 bits in common. Let's look at the 4th hextet for the remaining bits:

0007 0000000000000111

0012 0000000000010010

Be careful that you don't accidently convert number 12 from decimal to binary. We are working with hexadecimal values here! We have 11 bits that are the same, let's zero out the remaining 5 bits:

0000 0000000000000000

We have 48 + 11 bits that are the same so our summary address will be:

2001:DB8::/59

I hope these examples have been useful. If you have any questions, feel free to leave a comment.

iPv6 Solicited Node Multicast AddressEvery device that uses an IPv6 address will also compute and join a solicited node multicast group address. This address is required for IPv6 Neighbor Discovery which we use for layer two address discovery.All solicited node multicast group addresses start with FF02::1:FF /104:

FF /8 is the IPv6 multicast range. FF02 /16 is the multicast link local scope.Let’s take a look on a Cisco IOS router to see what these solicited node multicast group addresses look like:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 enable

I just enabled IPv6 on an interface, this causes the router to create a link-local IPv6 address. It will also compute and join the solicited node multicast group address:

R1#show ipv6 interface FastEthernet 0/0FastEthernet0/0 is up, line protocol ibs up IPv6 is enabled, link-local address is FE80::21D:A1FF:FE8B:36D0 No Virtual link-local address(es): No global unicast address is configured Joined group address(es): FF02::1 FF02::1:FF8B:36D0

Above you can see that the router joined FF02::1:FF8B:36D0. The last 6 hexadecimal characters were copied from the link local address. Here’s a picture:

Above you can see the complete uncompressed solicited node multicast address.

I can configure multiple IPv6 addresses on the interface, if the last 6 hexadecimal characters are similar then there is no need to join another multicast address. For example, let’s configure an IPv6 unicast address:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 address 2001:DB8:1212:1212::/64 eui-64

I’ll use EUI-64 to generate the last 64 bits. Take a look at the joined group addresses:

R1#show ipv6 interface FastEthernet 0/0FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::21D:A1FF:FE8B:36D0 No Virtual link-local address(es): Global unicast address(es): 2001:DB8:1212:1212:21D:A1FF:FE8B:36D0, subnet is 2001:DB8:1212:1212::/64 [EUI] Joined group address(es): FF02::1

FF02::1:FF8B:36D0

The last 64 bits of the link local and unicast address are the same so the solicited node multicast group address remains the same. If we configure an IPv6 address where the last 6 hexadecimal characters are different then the router will join another multicast group. Let’s try that:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 address 2001:DB8:1234:5678:1234:5678:1234:5678/64

Instead of using EUI-64 I'll use make up an address myself. The router will now join an additional multicast group:

R1#show ipv6 interface FastEthernet 0/0FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::21D:A1FF:FE8B:36D0 No Virtual link-local address(es): Global unicast address(es): 2001:DB8:1212:1212:21D:A1FF:FE8B:36D0, subnet is 2001:DB8:1212:1212::/64 [EUI] 2001:DB8:1234:5678:1234:5678:1234:5678, subnet is 2001:DB8:1234:5678::/64 Joined group address(es): FF02::1 FF02::1:FF34:5678 FF02::1:FF8B:36D0

Above you can see the router also joined the FF02::1:FF34:5678 solicited node multicast group address.

You have now seen that an IPv6 device computes and joins a solicited node multicast group address for each IPv6 address that you configure.

The big question remains: why and where do we use it?I'll answer this with some examples in the IPv6 Neighbor Discovery lesson.

IPv6 Neighbor Discovery Protocol on Cisco RouterOne of the differences between IPv4 and IPv6 is that we don’t use ARP (Address Resolution Protocol) anymore. ND (Neighbor Discovery Protocol) will replace the functionality of ARP. In this lesson we’ll take a look how ND works.ND uses ICMP and solicited node multicast addresses to discover the layer 2 address of other IPv6 hosts the same network (local link). It uses two messages to accomplish this: Neighbor solicitation message Neighbor advertisement messageLet’s take closer look at these two messages.

IPv6 Neighbor Solicitation MessageThe neighbor solicitation message is used primarily to find the layer two address of another IPv6 address on the local link, it’s also used for DAD (Duplicated Address Detection). In this packet the source address will be the source address of the host that is sending the neighbor solicitation, the destination address will be the solicited node multicast address of the remote host. This message also includes the layer two address of the host that is sending it. In the ICMP header of this packet you will find a type value of 135.

Using solicited node multicast addresses as the destination is far more efficient than IPv4’s ARP requests that are broadcasted to all hosts.

Every IPV6 device will compute a solicited node multicast address by taking the multicast group address (FF02::1:FF /104) and adding the last 6 hexadecimal

https://networklessons.com/ipv6/ipv6-solicited-node-multicast-address/

https://networklessons.com/ipv6/arp-address-resolution-protocol-explained/

https://networklessons.com/ipv6/arp-address-resolution-protocol-explained/

characters from its IPv6 address. It will then join this multicast group address and “listens” to it.

When one host wants to find the layer two address of another host, it will send the neighbor solicitation to the remote host’s solicited node multicast address.It can calculate the solicited node multicast address of the remote host since it knows about the multicast group address and it knows the IPv6 address that it wants to reach.

The result will be that only the remote host will receive the neighbor solicitation. That’s far more efficient than a broadcast that is received by everyone…Neighbor solicitation messages are also used to check if a remote host is reachable. In this case, the destination address will be the unicast address of the remote host.

IPv6 Neighbor Advertisement MessageOnce the remote host receives the neighbor solicitation it will reply with the neighbor advertisement message. The source address is the IPv6 address of the host and the destination address is the IPv6 address of the remote host that sent the neighbor solicitation. The most important part is that this message includes the layer two address of the host. The neighbor advertisement message uses type 136 in the ICMPv6 packet header.

Once R1 receives the neighbor advertisement, these two IPv6 hosts will be able to communicate with each other.

Neighbor advertisement messages are also used when the layer two address of a host changes. When this message is sent, the destination address will be the all-nodes multicast address.

Configuration

Now you have an idea how IPv6 neighbor discovery works. Let’s see what it looks like on some real devices. I’ll also show you some wireshark captures. I will use these two routers for this demonstration:

First we will configure some IPv6 addresses on our routers:

R1 & R2(config)#interface FastEthernet 0/0(config-if)#ipv6 enable

Using ipv6 enable is enough to generate some link local addresses which is all we need for this exercise. Here are the IPv6 addresses that the routers created:

R1#show ipv6 interface FastEthernet 0/0 | include FE80 IPv6 is enabled, link-local address is FE80::C001:2FF:FE40:0 [TEN]R2#show ipv6 interface FastEthernet 0/0 | include FE80 IPv6 is enabled, link-local address is FE80::C002:3FF:FEE4:0 [TEN]

To see the neighbor discovery in action I will enable a debug on both routers:

R1 & R2#debug ipv6 nd

Let's send a ping from R1 to R2:

R1#ping FE80::C002:3FF:FEE4:0Output Interface: FastEthernet0/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to FE80::C002:3FF:FEE4:0, timeout is 2 seconds:

Packet sent with a source address of FE80::C001:2FF:FE40:0!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/60 ms

Now you will see the following debug messages:

R1#ICMPv6-ND: DELETE -> INCMP: FE80::C002:3FF:FEE4:0ICMPv6-ND: Sending NS for FE80::C002:3FF:FEE4:0 on FastEthernet0/0ICMPv6-ND: Received NA for FE80::C002:3FF:FEE4:0 on FastEthernet0/0 from FE80::C002:3FF:FEE4:0ICMPv6-ND: Neighbour FE80::C002:3FF:FEE4:0 on FastEthernet0/0 : LLA c202.03e4.0000ICMPv6-ND: INCMP -> REACH: FE80::C002:3FF:FEE4:0ICMPv6-ND: Received NS for FE80::C001:2FF:FE40:0 on FastEthernet0/0 from FE80::C002:3FF:FEE4:0ICMPv6-ND: Sending NA for FE80::C001:2FF:FE40:0 on FastEthernet0/0

First we see a line that includes INCMP, this indicates that the address resolution is in progress. Next we see that R1 is sending the NS (neighbor solicitation) and receiving the NA (neighbor advertisement). In the neighbor advertisement it finds the layer two address of R2 (c202.03e4.0000). The status jumps from INCMP to REACH since R1 now knows how to reach R2. You can also see that R1 receives a neighbor solicitation from R2 and replies with the neighbor advertisement. Here's what it looks like on R2:

R2#ICMPv6-ND: Received NS for FE80::C002:3FF:FEE4:0 on FastEthernet0/0 from FE80::C001:2FF:FE40:0ICMPv6-ND: DELETE -> INCMP: FE80::C001:2FF:FE40:0ICMPv6-ND: Neighbour FE80::C001:2FF:FE40:0 on FastEthernet0/0 : LLA c201.0240.0000ICMPv6-ND: INCMP -> STALE: FE80::C001:2FF:FE40:0ICMPv6-ND: Sending NA for FE80::C002:3FF:FEE4:0 on FastEthernet0/0ICMPv6-ND: STALE -> DELAY: FE80::C001:2FF:FE40:0ICMPv6-ND: DELAY -> PROBE: FE80::C001:2FF:FE40:0ICMPv6-ND: Sending NS for FE80::C001:2FF:FE40:0 on FastEthernet0/0ICMPv6-ND: Received NA for FE80::C001:2FF:FE40:0 on FastEthernet0/0 from FE80::C001:2FF:FE40:0ICMPv6-ND: PROBE -> REACH: FE80::C001:2FF:FE40:0ICMPv6-ND: REACH -> STALE: FE80::C001:2FF:FE40:0

These debugs are interesting but they don't show us the source and destination address that are in use.

Wireshark Captures

Let's take a look at these messages in wireshark, this will show us the source and destination addresses. Here's the neighbor solicitation from R1 to R2:

Above you can see the source and destination MAC addresses. The source address is the MAC address of R1 and the destination is a multicast MAC address. The source IPv6 address is the link-local address of R1 and the destination is the solicited node multicast address of R2:

FF02::1:FF /104 is the multicast group address. e4:0000 are the last 6 hexadecimal characters of the link-local address of R2

(FE80::C002:3FF:FEE4:0). This is compressed to e4:0.As you can see the layer two destination address is a multicast address. When a switch receives this it will flood it out all of its interfaces. That's a bad idea since it defeats the purpose of our solicited node multicast addresses. For this reason, we should enable MLD snooping on our switch.

Here's the capture of R2 that sends the neighbor advertisement:

You can see the source and destination MAC addresses of R2. The IPv6 addresses are the link-local addresses of R1 and R2. You can also see the ICMPv6 type value of 136.

If you want to take a look for yourself then you can find the wireshark capture here:

IPv6 Neighbor Discovery.That's all I have on IPv6 neighbor discovery. I hope this lesson has been useful to you, if you have any questions...feel free to leave a comment.

Stateless autoconfiguration for IPv6Stateless autoconfiguration for IPv6 is like a “mini-DHCP” server for IPv6. Routers running IPv6 can give the prefix of the network and a gateway address to clients looking for an IPv6 address. IPv6 uses the NDP (Neighbor Discovery Protocol) and one of the things this protocol offers is RS (Route Solicitation and (RA) Router Advertisement messages that help an IPv6 device to automatically configure an IPv6 address. Let’s take a look at a configuration example:

https://www.cloudshark.org/captures/b55c3e5acc7c

I’m going to use two routers to show you how stateless autoconfiguration works. R2 will have an IPv6 address and is going to send router advertisements. R1 will use this to configure it’s own IPv6 address.

R2(config)#ipv6 unicast-routing R2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 address 2001:1234::/64 eui-64

Besides configuring an IPv6 address we have to use the ipv6 unicast-routing command to make R2 act like a router. Remember this command since you need it for routing protocols as well.

R1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 address autoconfig

We need to enable ipv6 address autoconfig on R1 to make sure it generates its own IPv6 address.

R1#debug ipv6 nd ICMP Neighbor Discovery events debugging is onR2#debug ipv6 nd ICMP Neighbor Discovery events debugging is on

We can use debug ipv6 nd to watch the whole process.

R2# ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0ICMPv6-ND: MTU = 1500ICMPv6-ND: prefix = 2001:1234::/64 onlink autoconfig

Here you can see R2 sending the router advertisement with the prefix.

R1#ICMPv6-ND: Received RA from FE80::CE0A:18FF:FE0E:0 on FastEthernet0/0

ICMPv6-ND: Autoconfiguring 2001:1234::CE09:18FF:FE0E:0 on FastEthernet0/0

This is R1 receiving the router advertisement and configuring its own IPv6 address.

R1#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE09:18FF:FE0E:0 2001:1234::CE09:18FF:FE0E:0

And here is the proof that we have a fresh new IPv6 address on R1.

R1#show ipv6 routersRouter FE80::CE0A:18FF:FE0E:0 on FastEthernet0/0, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 0 msec Prefix 2001:1234::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800

You can also use the show ipv6 routers command to see all cached router advertisements. This is a good example where you will see the link-local address of R2 instead of the global unicast address.Not bad right? If we can do this why do we still care about DHCPv6? Don’t forget DHCP can do many more things than just giving out IPv6 addresses like:

Registering hostnames of computers in DNS. Include a list of DNS or WINS servers. Include the IPv6 address of Callmanager (for VoIP phones) or a wireless LAN controller

(for lightweight access points).DHCP is of course also available for IPv6 and is called DHCPv6. The big difference between DHCP for IPv6 and DHCPv6 is that we don’t use broadcast traffic anymore. When a IPv6 device is looking for a DHCPv6 server it will send multicast packets to FF02::1:2. Routers will forward these packets to DHCP servers.ConfigurationsR2

Troubleshooting IPv6 Stateless

Autoconfiguration

In the picture above we have two routers, R1 and R2. We only have IPv6 addresses and you can see that in between R1 and R2 we have configured the 2001::/64 prefix. R1 has been configured for stateless autoconfiguration but for some reason it’s not receiving an IPv6 address from R2. Let’s find out what is wrong here shall we?

R1#show ipv6 interface fa0/0FastEthernet0/0 is up, line protocol is upIPv6 is enabled, link-local address is FE80::CE00:29FF:FE35:0

We can verify that the FastEthernet 0/0 interface is operational and that IPv6 has been enabled. Let’s see if the interface is configured for stateless autoconfiguration:

R1#show ipv6 interface fa0/0 | include statelessHosts use stateless autoconfig for addresses.

We can see this is the case. At this moment we at least know that IPv6 has been enabled on R1 and that it is not receiving an IPv6 address through stateless Autoconfiguration. What is the next step of our plan? Let’s see if R1 receives anything from R2:

R1#debug ipv6 nd ICMP Neighbor Discovery events debugging is on

Stateless autoconfiguration is a part of neighbor discovery. We’ll enable a debug to see if anything is going on. Let’s reset the interface:

R1(config)#interface fa0/0R1(config-if)#shutdownR1(config-if)#no shutdown

After a few seconds this is what we see:

R1#ICMPv6-ND: Sending NS for FE80::CE00:29FF:FE35:0 on FastEthernet0/0%LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to upICMPv6-ND: DAD: FE80::CE00:29FF:FE35:0 is unique.ICMPv6-ND: Sending NA for FE80::CE00:29FF:FE35:0 on FastEthernet0/0ICMPv6-ND: Address FE80::CE00:29FF:FE35:0/10 is up on FastEthernet0/0%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to upICMPv6-ND: Sending RS on FastEthernet0/0ICMPv6-ND: Sending RS on FastEthernet0/0ICMPv6-ND: Sending RS on FastEthernet0/0

In the debug we see that R1 is sending RS (Router Solicitation) messages. Unfortunately we are not receiving any response to these messages so it seems that something is going on with R2. Let’s check it out:

R2#show ipv6 interface fa0/0FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::CE01:29FF:FE35:0 Global unicast address(es): 2001::12:2, subnet is 2001::/64

We can verify that R2 has a working FastEthernet 0/0 interface and that IPv6 address 2001::12:2 has been configured.

We know that R2 has a working IPv6 address and there are no issues with the interface. What prevents it from sending RA (Router Advertisements)? Configuring an IPv6 address isn’t enough to enable IPv6 features like routing protocols or router advertisements. We need to make sure IPv6 unicast-routing is enabled. Let’s see if this is the case:

R2#show running-config | include unicast-routing

There’s maybe another show command to verify it but this time I’m checking the running-configuration to see if IPv6 unicast-routing has been enabled, it seems to be disabled. Let's enable it:

R2(config)#ipv6 unicast-routing

Now here's what you will see on the debug of R1:

R1#ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0ICMPv6-ND: MTU = 1500ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0ICMPv6-ND: MTU = 1500ICMPv6-ND: Received RA from FE80::CE01:29FF:FE35:0 on FastEthernet0/0ICMPv6-ND: Sending NS for 2001::CE00:29FF:FE35:0 on FastEthernet0/0ICMPv6-ND: Autoconfiguring 2001::CE00:29FF:FE35:0 on FastEthernet0/0ICMPv6-ND: DAD: 2001::CE00:29FF:FE35:0 is unique.ICMPv6-ND: Sending NA for 2001::CE00:29FF:FE35:0 on FastEthernet0/0ICMPv6-ND: Address 2001::CE00:29FF:FE35:0/64 is up on FastEthernet0/0ICMPv6-ND: Received RA from FE80::CE01:29FF:FE35:0 on FastEthernet0/0

As soon as I enable unicast-routing on R2 you’ll see some debug information on R1. It receives the router advertisement and it has configured itself with IPv6 address 2001::CE00:29FF:FE35:0. You can see it here:

R1#show ipv6 interface briefFastEthernet0/0 [up/up] FE80::CE00:29FF:FE35:0 2001::CE00:29FF:FE35:0

Let's try a quick ping to the other side:

R1#ping 2001::12:2

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001::12:2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/16 ms

Problem solved!

Lesson learned: Make sure IPv6 unicast-routing is enabled if you want to use router advertisements or IPv6 routing protocols.

IPv6 Router Advertisement PreferenceIn the IPv6 SLAAC (Stateless Autoconfiguration) lesson I explained how IPv6 routers send router advertisements which hosts can use to receive the prefix on the subnet, configure their own IPv6 address using EUI-64 and how they select the router as a default gateway.


What happens however when we have more than one router on the subnet? Which router advertisement will our host then use? To figure this out, we’ll use the following

topology:

We have two routers, R1 and R2 who will send router advertisements. Our host will be configured for SLAAC so that it will configure its own IPv6 address. With two router advertisements, our host will have to make a decision which one to use.

Let’s start with the configuration.

Configuration

First we will enable IPv6 unicast routing on R1 and R2, otherwise they won’t send any router advertisements:

R1 & R2(config)#ipv6 unicast-routing

Let’s configure a global unicast address on each router so that they can advertise a prefix in the RA:

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ipv6 address 2001:DB8:123:123::1/64R2(config)#interface GigabitEthernet 0/1R2(config-if)#ipv6 address 2001:DB8:123:123::2/64

That’s all we have to do on the routers. Before we configure the host, let’s enable a debug so we can see the router advertisements in real-time:

R1 & R2 & H1#debug ipv6 nd ICMP Neighbor Discovery events debugging is on

Now we will configure the host to use the router advertisements for autoconfiguration:

Host(config)#interface GigabitEthernet 0/1Host(config-if)#ipv6 address autoconfig

As soon as you enable this command, the host will send a router solicitation:

H1#ICMPv6-ND: (GigabitEthernet0/1) Sending RS

The routers will receive the router solicitation and will respond with a router advertisement:

R1#ICMPv6-ND: (GigabitEthernet0/1) Sending solicited RAICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE8F:86C2) send RA to FF02::1ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE8F:86C2) Sending RA (1800) to FF02::1ICMPv6-ND: MTU = 1500ICMPv6-ND: prefix 2001:DB8:123:123::/64 [LA] 2592000/604800R2#ICMPv6-ND: (GigabitEthernet0/1) Sending solicited RAICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) send RA to FF02::1ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Sending RA (1800) to FF02::1ICMPv6-ND: MTU = 1500ICMPv6-ND: prefix 2001:DB8:123:123::/64 [LA] 2592000/604800

What does our host think of this?

H1#ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RAICMPv6-ND: [default] New router interface context created/GigabitEthernet0/1ICMPv6-ND: [default] New router interface context created/C645C24ICMPv6-ND: [default] inserted router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1ICMPv6-ND: [default] Select default routerICMPv6-ND: [default] best rank is 811ICMPv6-ND: [default] router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1 is new bestICMPv6-ND: [default] Selected new default routerICMPv6-ND: [default] Install default to FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1ICMPv6-ND: Prefix : 2001:DB8:123:123::, Length: 64, Vld Lifetime: 2592000, Prf Lifetime: 604800, PI Flags: C0ICMPv6-ND: New on-link prefix 2001:DB8:123:123::/64 on GigabitEthernet0/1/FE80::F816:3EFF:FE19:6D0, lifetime 2592000ICMPv6-ND: Autoconfiguring 2001:DB8:123:123:F816:3EFF:FEDF:47FD on GigabitEthernet0/1

Above you can see that it receives the RA from R2 first which is selected as the default router. The host configures its own address with the prefix it receives. A few seconds later it receives the RA from R1:

H1#ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE8F:86C2) Received RAICMPv6-ND: [default] New router interface context created/C645C24ICMPv6-ND: [default] inserted router FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1ICMPv6-ND: [default] Select default routerICMPv6-ND: [default] best rank is 811ICMPv6-ND: Prefix : 2001:DB8:123:123::, Length: 64, Vld Lifetime: 2592000, Prf Lifetime: 604800, PI Flags: C0ICMPv6-ND: Update on-link prefix 2001:DB8:123:123::/64 on GigabitEthernet0/1/FE80::F816:3EFF:FE8F:86C2, lifetime 2592000

Another way to verify that we received two router advertisements is by using the show ipv6 routers command:

H1#show ipv6 routers Router FE80::F816:3EFF:FE19:6D0 on GigabitEthernet0/1, last update 1 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 (unspecified), Retransmit time 0 (unspecified) Prefix 2001:DB8:123:123::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800Router FE80::F816:3EFF:FE8F:86C2 on GigabitEthernet0/1, last update 1 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 (unspecified), Retransmit time 0 (unspecified) Prefix 2001:DB8:123:123::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800

If you want to see which one was selected as the default then you need to add the default parameter:

H1#show ipv6 routers default Router FE80::F816:3EFF:FE19:6D0 on GigabitEthernet0/1, last update 1 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium, trustlevel = 0 Reachable time 0 (unspecified), Retransmit time 0 (unspecified) Prefix 2001:DB8:123:123::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800

Great, as you can see our host is using R2 as the default router. Why? all parameters in the router advertisements from our routers are equal so there’s nothing in the RA that

the host will use to make a selection. It decided to use R2 since that’s the first RA that it received. We can demonstrate this by shutting the interface on R2:

R2(config)#interface GigabitEthernet 0/1R2(config-if)#shutdown

R2 will inform our host that it is leaving, you can see it in the debug:

H1#ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RAICMPv6-ND: Packet contains no optionsICMPv6-ND: Validating ND packet options: validICMPv6-ND: Packet contains no optionsICMPv6-ND: Zero lifetime, deletingICMPv6-ND: [default] Delete router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1ICMPv6-ND: [default] Select default routerICMPv6-ND: [default] best rank is 811ICMPv6-ND: [default] router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1 no longer bestICMPv6-ND: [default] Free router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1ICMPv6-ND: [default] router FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1 is new bestICMPv6-ND: [default] Selected new default routerICMPv6-ND: [default] Install default to FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1

Above you can see that our host receives the RA from R2, it will select R1 as the new default router. We can also verify this with the show command we just used:

H1#show ipv6 routers default | include RouterRouter FE80::F816:3EFF:FE8F:86C2 on GigabitEthernet0/1, last update 0 min

R1 is now the new default router. Let’s enable R2 again:

R2(config)#interface GigabitEthernet 0/1R2(config-if)#no shutdown

The host will receive the fresh RA from R2:

H1#ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RAICMPv6-ND: Validating ND packet options: validICMPv6-ND: [default] New router interface context created/C645C24ICMPv6-ND: [default] inserted router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1ICMPv6-ND: [default] Select default routerICMPv6-ND: [default] best rank is 811ICMPv6-ND: Prefix : 2001:DB8:123:123::, Length: 64, Vld Lifetime: 2592000, Prf Lifetime: 604800, PI Flags: C0

So does it select R2 as the new default router again? Let’s find out:

H1#show ipv6 routers Router FE80::F816:3EFF:FE8F:86C2 on GigabitEthernet0/1, last update 2 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 (unspecified), Retransmit time 0 (unspecified) Prefix 2001:DB8:123:123::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800Router FE80::F816:3EFF:FE19:6D0 on GigabitEthernet0/1, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 (unspecified), Retransmit time 0 (unspecified) Prefix 2001:DB8:123:123::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800H1#show ipv6 routers default | include RouterRouter FE80::F816:3EFF:FE8F:86C2 on GigabitEthernet0/1, last update 2 min

R1 is still the default router even though we also received the router advertisement from R2. What if we want to use one router as the preferred router?

This is possible with the preference setting. By default our Cisco IOS routers will advertise a medium preference in their router advertisements:

H1#show ipv6 routers default | include Preference HomeAgentFlag=0, Preference=Medium, trustlevel = 0

There are three levels we can select from though:

R1(config)#interface GigabitEthernet0/1R2(config-if)#ipv6 nd router-preference ? High High default router preference Low Low default router preference Medium Medium default router preference

Let’s change R2 so that it advertises a high preference. This should force our host to use R2 as the default router:

R2(config-if)#ipv6 nd router-preference High

As soon as you configure this, it will trigger R2 to send a new RA:

R2#ICMPv6-ND: (GigabitEthernet0/1) RA parameter changeICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) send RA to FF02::1ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Sending RA (1800) to FF02::1ICMPv6-ND: MTU = 1500ICMPv6-ND: prefix 2001:DB8:123:123::/64 [LA] 2592000/604800

Once our host receives it, it will act upon it:

H1#ICMPv6-ND: (GigabitEthernet0/1,FE80::F816:3EFF:FE19:6D0) Received RAICMPv6-ND: [default] Select default routerICMPv6-ND: [default] best rank is 819ICMPv6-ND: [default] router FE80::F816:3EFF:FE8F:86C2/GigabitEthernet0/1 no longer bestICMPv6-ND: [default] router FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1 is new bestICMPv6-ND: [default] Selected new default routerICMPv6-ND: [default] Install default to FE80::F816:3EFF:FE19:6D0/GigabitEthernet0/1

Above you can see that the host now prefers R2 as the new default router and installs a default route for it.

Cisco DHCPv6 Server ConfigurationIn this tutorial we’ll take a look at DHCPv6 so we can automatically assign IPv6 addresses to our hosts. The functionality of DHCPv6 is the same as DHCP for IPv4 but there are some differences. First of all, DHCPv6 supports two different methods: Stateful configuration Stateless configuration (also known as SLAAC…StateLess AutoConfiguration)The stateful version of DHCPv6 is pretty much the same as for IPv4. Our DHCPv6 server will assign IPv6 addresses to all DHCPv6 clients and it will keep track of the bindings. In short, the DHCPv6 servers knows exactly what IPv6 address has been assigned to what host.

Stateless works a bit different…the DHCPv6 server does not assign IPv6 addresses to the DHCPv6 clients, this is done through autoconfiguration. The DHCPv6 server is only used to assign information that autoconfiguration doesn’t….stuff like a domain-name, multiple DNS servers and all the other options that DHCP has to offer.The other difference is the number of messages that DHCPv6 uses:

Normal: 4 messages called solicit, advertise, request and reply. Rapid: 2 messages, only solicit and reply.By default it uses normal mode, if you want the rapid mode you have to enable it on both the DHCPv6 server and client.

You might be wondering why there is a normal and rapid mode, so did I…RFC 4039 says that the rapid mode is useful in “high mobility” networks where clients come and go often. The overhead of 4 messages might not be required so 2 messages is enough to do the job. If you have multiple DHCPv6 servers (for redundancy) then you need to use the normal mode (4 messages). Seeing the advantage of both modes might be fun for a tutorial in the future, for now…let’s start with the basics and configure our DHCPv6 server!DHCPv6 Server Configuration

To demonstrate DHCPv6 I will use the following topology:

http://tools.ietf.org/html/rfc4039


https://networklessons.com/ipv6/introduction-to-dhcp/

Our DHCPv6 router has two interfaces, the one connected to R1 will be used for stateful DHCPv6 and the interface connected to R2 will be used for stateless. You can also see the prefixes that I will use.

Before you can do anything with IPv6, make sure that unicast routing is enabled:

DHCPV6(config)#ipv6 unicast-routing

Now we can configure the DHCPv6 pools…

DHCPv6 Stateful Configuration

Let’s configure the stateful pool, it is similar to doing this for IPv4:

DHCPV6(config)#ipv6 dhcp pool STATEFULDHCPV6(config-dhcpv6)#address prefix 2001:1111:1111:1111::/64DHCPV6(config-dhcpv6)#dns-server 2001:4860:4860::8888DHCPV6(config-dhcpv6)#domain-name NETWORKLESSONS.LOCAL

The pool is called “STATEFUL” and besides the prefix I configured a DNS server (that’s google DNS) and a domain name. To activate this, we have to make some changes to the interface:

DHCPV6(config)#interface FastEthernet 0/0DHCPV6(config-if)#ipv6 address 2001:1111:1111:1111::1/64DHCPV6(config-if)#ipv6 dhcp server STATEFULDHCPV6(config-if)#ipv6 nd managed-config-flagDHCPV6(config-if)#ipv6 nd prefix 2001:1111:1111:1111::/64 14400 14400 no-autoconfig

On the interface you have to add the ipv6 dhcp server command and tell it what pool it has to use. The ipv6 nd managed-config-flag sets a flag in the router advertisement that tells the hosts that they could use DHCPv6. The last command that ends with no-autoconfig tells the hosts not to use stateless configuration.That’s all we have to do on the DHCPv6 server, let’s move on to the stateless configuration.

DHCPv6 Stateless Configuration

First we’ll make a pool:

DHCPV6(config)#ipv6 dhcp pool STATELESSDHCPV6(config-dhcpv6)#dns-server 2001:4860:4860::8888DHCPV6(config-dhcpv6)#domain-name NETWORKLESSONS.LOCAL

As you can see I didn’t configure a prefix…I don’t have to since autoconfiguration will be used by the client to fetch the prefix. Let’s enable it on the interface:

DHCPV6(config)#interface FastEthernet 0/1DHCPV6(config-if)#ipv6 address 2001:2222:2222:2222::2/64DHCPV6(config-if)#ipv6 dhcp server STATELESSDHCPV6(config-if)#ipv6 nd other-config-flag

We use the same command to activate the pool on the interface but there is one extra item. The ipv6 nd other-config-flag is required as it will inform clients through RA (Router Advertisement) messages that they have to use DHCPv6 to receive extra information like the domain name and DNS server after they used autoconfiguration.That’s all we have to do on the server, you can view the DHCPv6 pools like this if you want:

DHCPV6#show ipv6 dhcp pool DHCPv6 pool: STATEFUL Address allocation prefix: 2001:1111:1111:1111::/64 valid 172800 preferred 86400 (0 in use, 0 conflicts) DNS server: 2001:4860:4860::8888 Domain name: NETWORKLESSONS.LOCAL Active clients: 0DHCPv6 pool: STATELESS DNS server: 2001:4860:4860::8888 Domain name: NETWORKLESSONS.LOCAL Active clients: 0

You can see both pools, our stateful pool with the prefix and the stateless pool without. Before I configure the clients, I will enable a debug so we can see some of the messages in realtime:

DHCPV6#debug ipv6 dhcp IPv6 DHCP debugging is on

Let’s configure the clients now…

DHCPv6 Client Configuration

R1 will be the stateful client and R2 is the stateless client, let’s do R1 first…

DHCPv6 Stateful Client Configuration

There are two things that we have to do, first you need to enable IPv6 on the interface and secondly, tell it to get an IPv6 address through DHCP:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 enable R1(config-if)#ipv6 address dhcp

Let’s see if it has an IPv6 address:

R1#show ipv6 interface briefFastEthernet0/0 [up/up] FE80::21D:A1FF:FE8B:36D0 2001:1111:1111:1111:255A:E159:32AF:5E42

That’s looking good, you can see that it has an IPv6 address with the 2001:1111:1111:1111::/64 prefix. There’s another nice command that shows us what else we received:

R1#show ipv6 dhcp interface FastEthernet 0/0FastEthernet0/0 is in client mode Prefix State is IDLE Address State is OPEN Renew for address will be sent in 11:59:10 List of known servers: Reachable via address: FE80::216:C7FF:FEBE:EC8 DUID: 000300010016C7BE0EC8 Preference: 0 Configuration parameters: IA NA: IA ID 0x00030001, T1 43200, T2 69120 Address: 2001:1111:1111:1111:255A:E159:32AF:5E42/128 preferred lifetime 86400, valid lifetime 172800 expires at Jul 19 2014 08:30 PM (172750 seconds) DNS server: 2001:4860:4860::8888 Domain name: NETWORKLESSONS.LOCAL Information refresh time: 0 Prefix Rapid-Commit: disabled Address Rapid-Commit: disabled

The show ipv6 dhcp interface command shows us what DNS and domain information we received, this is looking good. Meanwhile you can see this on the server:

DHCPV6#IPv6 DHCP: Received SOLICIT from FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0IPv6 DHCP: Using interface pool STATEFULIPv6 DHCP: Creating binding for FE80::21D:A1FF:FE8B:36D0 in pool STATEFULIPv6 DHCP: Binding for IA_NA 00030001 not foundIPv6 DHCP: Allocating IA_NA 00030001 in binding for FE80::21D:A1FF:FE8B:36D0IPv6 DHCP: Looking up pool 2001:1111:1111:1111::/64 entry with username '00030001001DA18B36D000030001'IPv6 DHCP: Poolentry for user not foundIPv6 DHCP: Allocated new address 2001:1111:1111:1111:255A:E159:32AF:5E42IPv6 DHCP: Allocating address 2001:1111:1111:1111:255A:E159:32AF:5E42 in binding for FE80::21D:A1FF:FE8B:36D0, IAID 00030001IPv6 DHCP: Updating binding address entry for address 2001:1111:1111:1111:255A:E159:32AF:5E42

IPv6 DHCP: Setting timer on 2001:1111:1111:1111:255A:E159:32AF:5E42 for 60 secondsIPv6 DHCP: Source Address from SAS FE80::216:C7FF:FEBE:EC8

IPv6 DHCP: Sending ADVERTISE to FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0IPv6 DHCP: Received REQUEST from FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0IPv6 DHCP: Using interface pool STATEFULIPv6 DHCP: Looking up pool 2001:1111:1111:1111::/64 entry with username '00030001001DA18B36D000030001'IPv6 DHCP: Poolentry for user foundIPv6 DHCP: Found address 2001:1111:1111:1111:255A:E159:32AF:5E42 in binding for FE80::21D:A1FF:FE8B:36D0, IAID 00030001IPv6 DHCP: Updating binding address entry for address 2001:1111:1111:1111:255A:E159:32AF:5E42IPv6 DHCP: Setting timer on 2001:1111:1111:1111:255A:E159:32AF:5E42 for 172800 secondsIPv6 DHCP: Source Address from SAS FE80::216:C7FF:FEBE:EC8IPv6 DHCP: Sending REPLY to FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0

Above you can see the 4 messages (solicit, advertise, request and reply) because we are using normal mode. Let’s switch the server and client to rapid mode so you can see the difference:

DHCPV6(config)#interface FastEthernet 0/0DHCPV6(config-if)#ipv6 dhcp server STATEFUL rapid-commit

We have to change this on the interface level, same for the client:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 address dhcp rapid-commit

This is what the debug looks like now:

DHCPV6#IPv6 DHCP: Received SOLICIT from FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0IPv6 DHCP: Using interface pool STATEFULIPv6 DHCP: Creating binding for FE80::21D:A1FF:FE8B:36D0 in pool STATEFULIPv6 DHCP: Allocating IA_NA 00030001 in binding for FE80::21D:A1FF:FE8B:36D0

IPv6 DHCP: Looking up pool 2001:1111:1111:1111::/64 entry with username '00030001001DA18B36D000030001'IPv6 DHCP: Poolentry for user not foundIPv6 DHCP: Allocated new address 2001:1111:1111:1111:5D5B:C84C:9648:9D1FIPv6 DHCP: Allocating address 2001:1111:1111:1111:5D5B:C84C:9648:9D1F in binding for FE80::21D:A1FF:FE8B:36D0, IAID 00030001IPv6 DHCP: Updating binding address entry for address 2001:1111:1111:1111:5D5B:C84C:9648:9D1FIPv6 DHCP: Setting timer on 2001:1111:1111:1111:5D5B:C84C:9648:9D1F for 172800 secondsIPv6 DHCP: Source Address from SAS FE80::216:C7FF:FEBE:EC8IPv6 DHCP: Sending REPLY to FE80::21D:A1FF:FE8B:36D0 on FastEthernet0/0

2 messages instead of 4, that's it...you now have seen the difference between normal and rapid mode. Let's move on to the stateless client!

DHCPv6 Stateless Client Configuration

We already prepared the server so it's just the client, this is what we do on R2:

R2(config)#interface FastEthernet 0/0R2(config-if)#ipv6 enableR2(config-if)#ipv6 address autoconfig

This time I have to use the ipv6 address autoconfig command since we use autoconfiguration to get an IPv6 address. Let's see if that worked:

R2#show ipv6 interface briefFastEthernet0/0 [up/up] FE80::217:5AFF:FEED:7AF1 2001:2222:2222:2222:217:5AFF:FEED:7AF1

Great, we received an address. This is what the debug on the server looks like:

DHCPV6#IPv6 DHCP: Add routes, pool STATELESS, idb FastEthernet0/1IPv6 DHCP: Received INFORMATION-REQUEST from FE80::217:5AFF:FEED:7AF1 on FastEthernet0/1IPv6 DHCP: Using interface pool STATELESSIPv6 DHCP: Source Address from SAS FE80::216:C7FF:FEBE:EC9

IPv6 DHCP: Sending REPLY to FE80::217:5AFF:FEED:7AF1 on FastEthernet0/1

It receives an information request which basically means that the clients wants to know about the "extra" stuff that the DHCPv6 pool has to offer. In our example that's the DNS server and the domain name. Let's check if the client received those:

R2#show ipv6 dhcp interface FastEthernet 0/0FastEthernet0/1 is in client mode Prefix State is IDLE (0) Information refresh timer expires in 23:57:37 Address State is IDLE List of known servers: Reachable via address: FE80::216:C7FF:FEBE:EC9 DUID: 000300010016C7BE0EC8 Preference: 0 Configuration parameters: DNS server: 2001:4860:4860::8888 Domain name: NETWORKLESSONS.LOCAL Information refresh time: 0 Prefix Rapid-Commit: disabled Address Rapid-Commit: disabled

That's good, it learned about the DNS server and the domain name. What does the pool look like on the server?

DHCPV6#show ipv6 dhcp pool DHCPv6 pool: STATEFUL Address allocation prefix: 2001:1111:1111:1111::/64 valid 172800 preferred 86400 (1 in use, 0 conflicts) DNS server: 2001:4860:4860::8888 Domain name: NETWORKLESSONS.LOCAL Active clients: 1DHCPv6 pool: STATELESS DNS server: 2001:4860:4860::8888 Domain name: NETWORKLESSONS.LOCAL Active clients: 0

This is a good example as it shows you that the DHCPv6 servers sees an active client for the stateful pool but not for the stateless pool.

How to configure IPv6 Static RouteIf you know how to configure a static route for IPv4 then you shouldn’t have any issues with IPv6 static routes. The configuration and syntax are similar, there are only some minor differences. In this lesson, I will show you how to configure all IPv6 static route types.Configuration

To demonstrate this topology, I will use the following topology:

R1 and R2 are connected with a serial link. R2 has a loopback interface with IPv6 addresss 2001:DB8:2:2::2/64. Let’s see if we can reach this address.

Static route for a prefix

Let’s start with a simple example where we create a static route for the prefix we want to reach: 2001:DB8:2:2::/64.

Static route for a prefix – outgoing interface

Just like with IPv4, it is possible to use an interface as the next hop. This will only work with point-to-point interfaces:

R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0

Here’s what the routing table looks like:

R1#show ipv6 route static

S 2001:DB8:2:2::/64 [1/0] via Serial0/0/0, directly connected

Let’s see if it works:

R1#ping 2001:DB8:2:2::2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms

Our ping is working.

If you try this with a FastEthernet interface, you’ll see that the router will accept the command but the ping won’t work. You can’t use this for multi-access interfaces.

Static route for a prefix – global unicast next hop

Instead of an outgoing interface, we can also specify the global unicast address as the next hop:

R1(config)#ipv6 route 2001:DB8:2:2::/64 2001:DB8:12:12::2



S 2001:DB8:2:2::/64 [1/0] via 2001:DB8:12:12::2

Let’s see if it works:


No problem at all…

Instead of global unicast addresses, you can also use unique local addresses. These are the IPv6 equivalent of IPv4 private addresses.

Static route for a prefix – link-local next hop

One of the differences between IPv4 and IPv6 is that IPv6 generates a link-local address for each interface. In fact, these link-local addresses are also used by routing protocols like RIPng, EIGRP, OSPFv3, etc as the next hop addresses. Let’s see what the link-local address is of R2:

R2#show ipv6 interface Serial 0/0/0 | include link-local IPv6 is enabled, link-local address is FE80::21C:F6FF:FE11:41F0

Let’s use this as the next hop address. When you use a global unicast address as the next hop, your router will be able to look at the routing table and figure out what outgoing interface to use to reach this global unicast address. With link local addresses, the router has no clue which outgoing interface to use so you will have to specify both the outgoing interface and the link local address:

R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0



S 2001:DB8:2:2::/64 [1/0] via FE80::21C:F6FF:FE11:41F0, Serial0/0/0

Just to be sure, let’s try a ping:


No problems there.

Static default route

Just like IPv4, we can also create static default routes. A default route has only zeroes (::) and a /0 prefix-length. This is the equivalent of 0.0.0.0/0 in IPv4. We can do this with an interface, global unicast or link-local address. Let’s try all options!

Static default route – outgoing interface

Let’s start with the outgoing interface first:

R1(config)#ipv6 route ::/0 Serial 0/0/0

Here’s the routing table:


S ::/0 [1/0] via Serial0/0/0, directly connected

Let’s try a quick ping:


Static default route – global unicast next hop

Instead of an outgoing interface, let’s try a global unicast next hop address:

R1(config)#ipv6 route ::/0 2001:DB8:12:12::2



S ::/0 [1/0]via 2001:DB8:12:12::2



Time for the next option.

Static default route – link-local next hop

Let’s replace the global unicast next hop address with a link-local address:

R1(config)#ipv6 route ::/0 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0



S ::/0 [1/0] via FE80::21C:F6FF:FE11:41F0, Serial0/0/0



Our ping is working.

Static host route

We can also create static routes for a single IPv6 address, this is called a static host route. These examples are the same as the ones you have seen before but this time, we will create an entry for 2001:DB8:2:2::2/128 which is similar to using a /32 subnet mask in IPv4.Static host route – outgoing interface

First we will try the outgoing interface:

R1(config)#ipv6 route 2001:DB8:2:2::2/128 Serial 0/0/0

Here is the routing table:


S 2001:DB8:2:2::2/128 [1/0] via Serial0/0/0, directly connected



Static host route – global unicast next hop

Let’s try a global unicast address as the next hop:

R1(config)#ipv6 route 2001:DB8:2:2::2/128 2001:DB8:12:12::2



S 2001:DB8:2:2::2/128 [1/0] via 2001:DB8:12:12::2

And let’s try a quick ping:


Static host route – link-local next hop

Last but not least, a link-local address as the next hop address:

R1(config)#ipv6 route 2001:DB8:2:2::2/128 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0

Here’s R1’s routing table:


S 2001:DB8:2:2::2/128 [1/0] via FE80::21C:F6FF:FE11:41F0, Serial0/0/0

Let’s try another ping:


Static floating route

We can also configure floating static routes. To test this, I have to add another router:

R3 is added to our topology and I configured the same loopback address (2001:DB8:23:23::23/128) on both routers. R3 will be used as our main path to reach this address. When the link is down we want to use R2.

Here’s the static route that is used to use R3 as the primary path:

R1(config)#ipv6 route 2001:DB8:23:23::/64 2001:DB8:13:13::3

Static floating route – outgoing interface

Let’s try the outgoing interface first. The static route looks like this:

R1(config)#ipv6 route 2001:DB8:23:23::/64 Serial 0/0/0 2

Note that at the end of the line above, I specified the administrative distance with a value of 2. With both interfaces up, R1 will send all traffic to R3:


S 2001:DB8:23:23::/64 [1/0] via 2001:DB8:13:13::3

Above you can see that the default administrative distance is 1. Let’s shut the FastEthernet 0/0 interface to test our static floating route:

R1(config)#interface FastEthernet 0/0R1(config-if)#shutdown

Let’s look at the routing table again:


S 2001:DB8:2:2::/64 [2/0] via Serial0/0/0, directly connected

The entry to R2 is now installed. You can also see the administrative distance value of two in the routing table.

Static floating route – global unicast next hop

Instead of the outgoing interface, we can also use a global unicast address as the next hop:

R1(config)#ipv6 route 2001:DB8:2:2::/64 2001:DB8:12:12::2 2

The routing table will then look like this:


S 2001:DB8:2:2::/64 [2/0] via 2001:DB8:12:12::2

Static floating route – link-local next hop

Or use a link-local address as the next hop:

R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0 2



S 2001:DB8:2:2::/64 [2/0] via FE80::21C:F6FF:FE11:41F0, Serial0/0/0

Conclusion

You have now learned how to configure the following IPv6 static routes:

Static route for a prefix Static default route Static host route Static floating routeAnd how to do this with different next hop types:

Outgoing interface (only for point-to-point interfaces) Global unicast address Link-local addressI hope these examples have been useful to you!

How to configure RIPNG on Cisco IOS RouterRIPNG is the exact same protocol as RIP for IPv4 but it has been upgraded to support IPv6. In this lesson i’ll demonstrate to you how to configure it on Cisco routers. Here’s the topology that we’ll use:

Let’s use this topology to configure RIPNG. I’m going to create a loopback interface on each router to advertise in RIPNG. Note that I don’t have any global unicast IPv6 addresses on the FastEthernet interface because the RIPNG updates will be sent using the link-local addresses.

R1(config)#ipv6 unicast-routing R1(config)#interface loopback 0R1(config-if)#ipv6 address 2001::1/128R2(config)#ipv6 unicast-routing R2(config)#interface loopback 0R2(config-if)#ipv6 address 2001::2/128

Don’t forget to enable IPv6 unicast routing otherwise no routing protocol will work for IPv6.

R1#show ipv6 interface brief FastEthernet0/0 [up/up]Loopback0 [up/up] FE80::CE09:18FF:FE0E:0 2001::1R2#show ipv6 interface brief FastEthernet0/0 [up/up]Loopback0 [up/up] FE80::CE0A:18FF:FE0E:0 2001::2

After configuring the IPv6 addresses on the loopback interface you can see the global unicast and the link-local IPv6 addresses. There is no link-local address on the FastEthernet interfaces however.

R1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 enableR2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 enableR1#show ipv6 interface brief

FastEthernet0/0 [up/up] FE80::CE09:18FF:FE0E:0Loopback0 [up/up] FE80::CE09:18FF:FE0E:0 2001::1R2#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE0A:18FF:FE0E:0Loopback0 [up/up] FE80::CE0A:18FF:FE0E:0 2001::2

Use the IPv6 enable command to generate a link-local address for the FastEthernet interfaces.

R1(config)#ipv6 router rip RIPNGTESTR1(config-rtr)#exitR1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 rip RIPNGTEST enableR1(config-if)#exitR1(config)#interface loopback 0R1(config-if)#ipv6 rip RIPNGTEST enableR2(config)#ipv6 router rip RIPNGTESTR2(config-rtr)#exitR2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 rip RIPNGTEST enableR2(config-if)#exitR2(config)#interface loopback 0R2(config-if)#ipv6 rip RIPNGTEST enable

To enable RIPNG you first have to start the process with the IPV6 router rip command. You have to give it a tag name and I called mine “RIPNGTEST”.It doesn’t matter what tag name you choose and it doesn’t have to be the same on both routers. Second step is to activate RIPNG on the interfaces you want by using the IPv6 rip enable command. That’s not too bad right? No stinky network commands! Just enable it on the interface and you are ready to go. The ipv6 rip enable command does two things:

Activate the prefix on the interface in RIPNG. Send RIPNG updates out of this interface.

R1#debug ipv6 ripRIP Routing Protocol debugging is on

RIPng: Sending multicast update on FastEthernet0/0 for RIPNGTEST src=FE80::CE09:18FF:FE0E:0

dst=FF02::9 (FastEthernet0/0) sport=521, dport=521, length=32 command=2, version=1, mbz=0, #rte=1 tag=0, metric=1, prefix=2001::1/128RIPng: Process RIPNGTEST received own response on Loopback0RIPng: response received from FE80::CE0A:18FF:FE0E:0 on FastEthernet0/0 for RIPNGTEST src=FE80::CE0A:18FF:FE0E:0 (FastEthernet0/0) dst=FF02::9 sport=521, dport=521, length=32 command=2, version=1, mbz=0, #rte=1 tag=0, metric=1, prefix=2001::2/128

Here’s part of the output of the debug IPv6 rip command. You can see that the link-local IPv6 addresses are used as source of the updates. The destination address is multicast FF02::9.

R1#show ipv6 route ripIPv6 Routing Table - 4 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 2001::2/128 [120/2] via FE80::CE0A:18FF:FE0E:0, FastEthernet0/0R2#show ipv6 route rip IPv6 Routing Table - 4 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 2001::1/128 [120/2] via FE80::CE09:18FF:FE0E:0, FastEthernet0/0

A quick look at the routing table with the show IPv6 route command shows us that RIP has learned about the networks.

Troubleshooting IPv6 RIPNG

In the picture above we have 2 routers, each router has a loopback interface and IPv6 addresses have been configured on the loopback0 interfaces. RIPNG has been configured and we should have connectivity between the two loopback0 interfaces. Unfortunately R1 is not learning about network 2002::2/128. Let’s find out why!

R1#show ipv6 route ripIPv6 Routing Table - 5 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

R1 hasn’t learned any RIPNG routes. What about R2?

R2#show ipv6 route ripIPv6 Routing Table - 6 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 1001::1/128 [120/2] via FE80::CE00:4DFF:FE47:0, FastEthernet0/0

R2 has learned about the loopback0 interface behind R1. Let’s see if all interfaces are up and running and configured for IPv6:

R1#show ipv6 interface brief

FastEthernet0/0 [up/up] FE80::CE00:4DFF:FE47:0 2001:12::1Loopback0 [up/up] FE80::CE00:4DFF:FE47:0 1001::1R2#show ipv6 interface briefFastEthernet0/0 [up/up] FE80::CE01:4DFF:FE47:0 2001:12::2Loopback0 [up/up] FE80::CE01:4DFF:FE47:0 2002::2

All interfaces are configured for IPv6 and up and running, there are no issues here. Let’s check if RIPNG is enabled on all interfaces:

R1#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "rip NEXTGEN" Interfaces: Loopback0 FastEthernet0/0 Redistribution: NoneR2#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "rip NEXTGEN" Interfaces: FastEthernet0/0 Redistribution: None

We’ll use show ipv6 protocols to see if all prefixes are advertised. You can see that RIPNG is not enabled on the loopback0 interface of R2, let’s fix that:

R2(config)#interface loopback 0 R2(config-if)#ipv6 rip NEXTGEN enable

This is how we enable it. Let's verify this:

R2#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "rip NEXTGEN" Interfaces: Loopback0 FastEthernet0/0 Redistribution: None

Now we see that the loopback0 interface has joined RIPNG. Let's check the routing table of R1 again:

R1#show ipv6 route ripIPv6 Routing Table - 6 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 2002::2/128 [120/2] via FE80::CE01:4DFF:FE47:0, FastEthernet0/0

Now we see that 2002::2/128 is in the routing table of R1, problem solved!

Lesson learned: Make sure you activate RIPNG on all interfaces if they have prefixes that you want to see advertised.

How to configure IPv6 EIGRP on Cisco IOS RouterCisco’s EIGRP is one of the routing protocols that is suitable for IPv6. Configuration is a bit different and in this lesson I’ll demonstrate to you how to configure it. This is the topology we’ll use:

Note that I don’t have any global unicast IPv6 addresses on the FastEthernet interface because the EIGRP updates will be sent using the link-local addresses.

Configuration

First we will enable routing for IPv6:


And let’s configure some IPv6 addresses:

R1 & R2(config)#interface GigabitEthernet 0/1(config-if)#ipv6 enable R1(config)#interface loopback 0R1(config-if)#ipv6 address 2001::1/128R2(config)#interface loopback 0R2(config-if)#ipv6 address 2001::2/128

Enabling IPv6 on the Gigabit interfaces will generate an IPv6 link local address. The loopback interfaces will have a global unicast address. Let’s verify our work:

R1#show ipv6 interface briefGigabitEthernet0/1 [up/up] FE80::F816:3EFF:FE7B:61CALoopback0 [up/up] FE80::F816:3EFF:FEC5:1BD7 2001::1R2#show ipv6 interface brief GigabitEthernet0/1 [up/up] FE80::F816:3EFF:FE8F:4F66Loopback0 [up/up]

FE80::F816:3EFF:FED1:4100 2001::2

After configuring the IPv6 addresses on the loopback interface you can see the global unicast and the link-local IPv6 addresses.

This is how you enable EIGRP for IPv6:

R1(config)#ipv6 router eigrp 1R1(config-rtr)#router-id 1.1.1.1R1(config-rtr)#no shutdown

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ipv6 eigrp 1

R1(config)#interface loopback 0R1(config-if)#ipv6 eigrp 1R2(config)#ipv6 router eigrp 1R2(config-rtr)#router-id 2.2.2.2R2(config-rtr)#no shutdown

R2(config)#interface GigabitEthernet 0/1R2(config-if)#ipv6 eigrp 1

R2(config)#interface loopback 0R2(config-if)#ipv6 eigrp 1

First, you need to start EIGRP with the ipv6 router eigrp command. The number you see is the autonomous system number and it has to match on both routers. Each EIGRP router needs a router ID which is the highest IPv4 address on the router.If you don’t have any IPv4 addresses you need to specify it yourself with the router-id command. By default, the EIGRP process is in shutdown mode and you need to type no shutdown to activate it.Last step is to enable it on the interfaces with the ipv6 eigrp command. Let’s verify our configuration:

R1#show ipv6 eigrp neighbors EIGRP-IPv6 Neighbors for AS(1)H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num

0 Link-local address: Gi0/1 13 00:01:31 1586 5000 0 3 FE80::F816:3EFF:FE8F:4F66R2#show ipv6 eigrp neighbors EIGRP-IPv6 Neighbors for AS(1)H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num0 Link-local address: Gi0/1 10 00:01:44 9 100 0 3 FE80::F816:3EFF:FE7B:61CA

Use show ipv6 eigrp neighbors to verify you have an adjacency.

R1#show ipv6 route eigrp IPv6 Routing Table - default - 3 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid a - ApplicationD 2001::2/128 [90/130816] via FE80::F816:3EFF:FE8F:4F66, GigabitEthernet0/1R2#show ipv6 route eigrp IPv6 Routing Table - default - 3 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid a - ApplicationD 2001::1/128 [90/130816]

via FE80::F816:3EFF:FE7B:61CA, GigabitEthernet0/1

Here we go…we have an EIGRP prefix in the routing table. That's all there is to it!

How to configure IPv6 OSPFv3 on Cisco IOS RouterWhen we use OSPF for IPv4 we are using OSPFv2. OSPF has been updated for IPv6 and is now called OSPFv3. These are two different routing protocols and in this lesson I’ll show you how to configure OSPFv3 so that you can route IPv6 traffic. Here’s the topology we’ll use:

Let’s start with the configuration of the interfaces and the IPv6 addresses. We don’t have to configure any global unicast IPv6 addresses on the FastEthernet interfaces because OSPFv3 uses link-local addresses for the neighbor adjacency and sending LSAs.

R1(config)#ipv6 unicast-routing R1(config)#interface loopback 0R1(config-if)#ipv6 address 2001::1/128R2(config)#ipv6 unicast-routing R2(config)#interface loopback 0R2(config-if)#ipv6 address 2001::2/128

Don’t forget to enable IPv6 unicast routing otherwise no routing protocol will work for IPv6.

R1#show ipv6 interface brief FastEthernet0/0 [up/up]Loopback0 [up/up] FE80::CE09:18FF:FE0E:0 2001::1R2#show ipv6 interface brief FastEthernet0/0 [up/up]Loopback0 [up/up] FE80::CE0A:18FF:FE0E:0 2001::2

After configuring the IPv6 addresses on the loopback interface you can see the global unicast and the link-local IPv6 addresses. There is no link-local address on the FastEthernet interfaces however so we’ll have to fix this:

R1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 enableR2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 enableR1#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE09:18FF:FE0E:0Loopback0 [up/up] FE80::CE09:18FF:FE0E:0 2001::1R2#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE0A:18FF:FE0E:0Loopback0 [up/up] FE80::CE0A:18FF:FE0E:0 2001::2

Now we can configure OSPFv3:

R1(config)#ipv6 router ospf 1R1(config-rtr)#router-id 1.1.1.1R1(config-rtr)#exitR1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 ospf 1 area 0R1(config-if)#exitR1(config)#interface loopback 0R1(config-if)#ipv6 ospf 1 area 0R2(config)#ipv6 router ospf 1R2(config-rtr)#router-id 2.2.2.2R2(config-rtr)#exit

R2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 ospf 1 area 0R2(config-if)#exit R2(config)#interface loopback 0R2(config-if)#ipv6 ospf 1 area 0

Just like OSPFv2 you need to start a process and specify a process ID. For OSPFv3 we have to use the ipv6 router ospf command. Just like EIGRP for IPv6 we need a router-ID if we don’t have any IPv4 addresses configured on our router. Finally go to the interface and use the ipv6 ospf area command to enable OSPFv3 and select the correct area.

R1#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface2.2.2.2 1 FULL/BDR 00:00:30 4 FastEthernet0/0R2#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface1.1.1.1 1 FULL/DR 00:00:39 4 FastEthernet0/0

Use show ipv6 ospf neighbor to see your neighbors. It’s funny to see the old IPv4 neighbor ID even though OSPFv3 is IPv6-only.

R1#show ipv6 route ospf IPv6 Routing Table - 3 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP externalO 2001::2/128 [110/10] via FE80::C00F:1AFF:FEA7:0, FastEthernet0/0R2#show ipv6 route ospf IPv6 Routing Table - 3 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP externalO 2001::1/128 [110/10] via FE80::C00E:1AFF:FEA7:0, FastEthernet0/0

In our routing table we find the fresh OSPFv3 route. That's it! This is a fairly simple example but it should help you to get going with OSPFv3 for IPv6.

IPv6 OSPFv3 Default RouteJust like OSPF for IPv4, it is possible to advertise a default route in OSPFv3 for IPv6. In this lesson, I’ll show you how to do this.

Configuration

We only need two routers for this example:

R2 has a loopback interface with IPv6 address 2001:DB8:2:2::2/128. We won’t advertise this in OSPFv3 directly but will reach it from R1 with a default route that is advertised by R2.

First, we have to enable IPv6 routing:


Let’s configure some global unicast IPv6 addresses. We don’t need global unicast addresses for OSPFv3 but we will need them if we want to send a ping from R1 to R2’s loopback address.

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ipv6 address 2001:DB8:12:12::1/64R2(config)#interface GigabitEthernet 0/1R2(config-if)#ipv6 address 2001:DB8:12:12::2/64

R2(config)#interface loopback 0R2(config-if)#ipv6 address 2001:DB8:2:2::2/128

Let’s enable OSPFv3 on R1:

R1(config)#ipv6 router ospf 1R1(config-rtr)#router-id 1.1.1.1

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ipv6 ospf 1 area 0

We do the same thing on R2, but also include the default route:

R2(config)#ipv6 router ospf 1R2(config-rtr)#router-id 2.2.2.2R2(config-rtr)#default-information originate always

R2(config)#interface GigabitEthernet 0/1R2(config-if)#ipv6 ospf 1 area 0

The default-information originate command is what advertises the default route, it’s the same command that OSPFv2 for IPv4 uses.

The always parameter is required if you don’t have a default route in your own local routing table. If R2 had a default route pointing to another router, then you can remove the always parameter.

Verification

Let’s verify our work. First, let’s make sure our two routers are OSPFv3 neighbors:


OSPFv3 Router with ID (1.1.1.1) (Process ID 1)

Neighbor ID Pri State Dead Time Interface ID Interface2.2.2.2 1 FULL/BDR 00:00:34 3 GigabitEthernet0/1

This seems to be the case. Let’s check if R1 has learned a default route from R2:

R1#show ipv6 route ospf

OE2 ::/0 [110/1], tag 1 via FE80::F816:3EFF:FE06:2CB2, GigabitEthernet0/1

Above you can see the default route. Note that it is advertised as an OSPF external type 2 route with a default cost of 1. Let’s see if we can ping the loopback interface of R2:


Our ping is working, which proves that our default route works.

Conclusion

You have now learned how to configure an IPv6 OSPFv3 default route with the default-information originate command. Keep in mind you need the always parameter if you don’t have a default route in the routing table of the router that is going to advertise the default route. The default route type is an external type 2 with a cost of 1.

Troubleshooting IPv6 OSPFv3 Neighbor Adjacencies

In this lesson we’ll take a look at some OSPFv3 neighbor adjacency issues. Most of what you learned about OSPFv3 for IPv4 also applies to OSPFv3. Let’s take a look at the first issue!

OSPFv3 Router ID

I will use the following topology:

In the topology above we have 2 routers and there’s only a single area. For some reason the two routers are unable to become OSPF neighbors, up to us to find out why! Let’s check the interfaces first:

R1#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE00:1BFF:FE29:0R2#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE01:1BFF:FE29:0

IPv6 routing protocols use the link-local addresses for neighbor adjacency and next-hops. We can see that both interfaces have a link-local IPv6 address and are active (up/up). Just in case, let’s ping the other side just to be sure that we have connectivity:

R1#ping FE80::CE01:1BFF:FE29:0Output Interface: FastEthernet0/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to FE80::CE01:1BFF:FE29:0, timeout is 2 seconds:Packet sent with a source address of FE80::CE00:1BFF:FE29:0

!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 0/4/8 ms

No issues there, let’s continue by checking OSPFv3:

R1#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): FastEthernet0/0 R2#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): FastEthernet0/0

OSPFv3 is running on the FastEthernet0/0 interfaces of R1 and R2. No issues there, let’s check if we have neighbors or not:

R1#show ipv6 ospf neighbor %OSPFv3: Router process 1 is INACTIVE, please configure a router-idR2#show ipv6 ospf neighbor %OSPFv3: Router process 1 is INACTIVE, please configure a router-id

This command reveals it all. We find out that the router-id has not been configured. OSPFv3 requires an IPv4 address-style router-ID and we need to configure it ourselves. Let’s do that:

R1(config-rtr)#router-id ? A.B.C.D OSPF router-id in IP address format

R1(config-rtr)#router-id 1.1.1.1R2(config)#ipv6 router ospf 1R2(config-rtr)#router-id 2.2.2.2

The router-ID has to be an IPv4 address format. I have no idea why they decided to do it this way for OSPFv3 but my best guess is someone got a bit nostalgic. Anyway this fixes the issue:

R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading DoneR2# %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done

After configuring the router-ID we almost immediately see a message that the OSPFv3 neighbor adjacency has been established. Let’s verify this:


Neighbor ID Pri State Dead Time Interface ID Interface2.2.2.2 1 FULL/DR 00:00:33 4 FastEthernet0/0R2#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface1.1.1.1 1 FULL/BDR 00:00:31 4 FastEthernet0/0

Problem solved!

Lesson learned: Make sure you configure a router-ID for OSPFv3.OSPFv3 Hello Packet Mismatch

Let’s look at another issue, same topology:

R1 and R2 are once again unable to form an OSPFv3 neighbor adjacency. Let’s check a couple of things:

R1#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE00:1BFF:FE29:0R2#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::CE01:1BFF:FE29:0

The interfaces and IPv6 addresses are fine. Let’s do a quick ping:

R1#ping FE80::CE01:1BFF:FE29:0Output Interface: FastEthernet0/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to FE80::CE01:1BFF:FE29:0, timeout is 2 seconds:Packet sent with a source address of FE80::CE00:1BFF:FE29:0!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 0/4/8 ms

Pinging each other is no issue. Is OSPFv3 running?

R1#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): FastEthernet0/0R2#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): FastEthernet0/0

OSPFv3 has been enabled on the interfaces, still we don’t have any neighbors:

R1#show ipv6 ospf neighbor R2#show ipv6 ospf neighbor

Unfortunately we don’t have any neighbors. Let’s enable a debug:

R1#debug ipv6 ospf hello OSPFv3 hello events debugging is on

Becoming OSPFv3 neighbors starts with a hello packet, let’s see what we discover:

R1# OSPFv3: Mismatched hello parameters from FE80::CE01:1BFF:FE29:0 OSPFv3: Dead R 36 C 40, Hello R 9 C 10 OSPFv3: Send hello to FF02::5 area 0 on FastEthernet0/0 from FE80::CE

There we go…we see that there is a mismatch in the hello parameters. R1 is configured to send hello packets each 10 seconds and R2 is configured to send them every 9 seconds. The dead timer also has a mismatch. Here’s what the timers look like:

R1#show ipv6 ospf 1 interface fa0/0 | include intervals Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5R2#show ipv6 ospf 1 interface fa0/0 | include intervals Timer intervals configured, Hello 9, Dead 36, Wait 36, Retransmit 5

We can verify the timers by using the show ipv6 ospf interface command. Let’s make sure they match:

R2(config)#interface fa0/0R2(config-if)#ipv6 ospf hello-interval 10

Let’s change the hello timer back to 10 seconds, this also changes the dead timer interval. After a few seconds you’ll see this:

R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading DoneR2# %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done

That’s looking good, the routers have become OSPFv3 neighbors:


Neighbor ID Pri State Dead Time Interface ID Interface2.2.2.2 1 FULL/DR 00:00:33 4 FastEthernet0/0R2#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface1.1.1.1 1 FULL/BDR 00:00:31 4 FastEthernet0/0

Another problem bites the dust!

Lesson Learned: OSPFv3 for IPv6 has the same requirements to form a neighbor adjacency as OSPFv2 for IPv4. Apply your “IPv4 OSPF” knowledge to solve neighbor adjacency issues.OSPFv3 over Frame-Relay

Here’s something different for you. We are still working on troubleshooting OSPFv3 neighbor adjacencies but we will use a different topology:

In the scenario above we have a frame-relay setup. There’s a single PVC between R1 and R2. R1 has been configured to use 2001:12::1 and R2 is using 2001:12::2. For some reason the OSPFv3 neighbor adjacency is not working…let’s troubleshoot!

What’s the best place to start troubleshooting a problem like this? There are two options:

Start in the middle of the OSI-model and dive into the OSPFv3 configuration right away. Start at the bottom of the OSI-model and check if the frame-relay configuration is

properly configured.Personally I like a structured approach and start at the bottom of the OSI model and work my way up. In this case that means we have to check if the interfaces are up, frame-relay encapsulation has been configured, if the PVC is working, if we have a valid frame-relay map, if we can ping each other and then move on to OSPFv3.

If you start at the bottom you’ll find the problem eventually but it might be a bit more time-consuming sometimes. Just to try something different I’ll start in the middle of the OSI-model this time and we’ll check the OSPFv3 configuration first:


I can confirm that there are no neighbor adjacencies. Let’s see if OSPFv3 is active:

R1#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): Serial0/0R2#show ipv6 protocols IPv6 Routing Protocol is "connected"IPv6 Routing Protocol is "static"IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): Serial0/0

You can see that OSPFv3 has been enabled for the serial 0/0 interfaces. Let’s take a closer look at the OSPFv3 configuration:

R1#show ipv6 ospf interface serial 0/0Serial0/0 is up, line protocol is up Link Local Address FE80::9CD7:2EFF:FEF0:99FA, Interface ID 4 Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1 Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, local address FE80::9CD7:2EFF:FEF0:99FA

No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5R2#show ipv6 ospf interface serial 0/0Serial0/0 is up, line protocol is up Link Local Address FE80::9CD7:2EFF:FEF0:99FA, Interface ID 4 Area 0, Process ID 1, Instance ID 0, Router ID 2.2.2.2 Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 2.2.2.2, local address FE80::9CD7:2EFF:FEF0:99FA No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

This is something that is worth a closer look. The network type and timer intervals match. The network type is “NON_BROADCAST” which means that we have to configure our neighbors ourselves. Has this been done? Let's take a look:


Nobody configured any neighbors otherwise they would show up in the output above. Let's fix this, first I'll have to check what the link-local addresses are:

R1#show ipv6 interface brief Serial0/0 [up/up] FE80::9CD8:2EFF:FEF0:99FAR2#show ipv6 interface brief Serial0/0 [up/up] FE80::9CD7:2EFF:FEF0:99FA

Here you can see the link-local addresses that we need to use. Let's configure the neighbors:

R1(config)#interface serial 0/0R1(config-if)#ipv6 ospf neighbor FE80::9CD7:2EFF:FEF0:99FAR2(config)#interface serial 0/0R2(config-if)#ipv6 ospf neighbor FE80::9CD8:2EFF:FEF0:99FA

This is how we configure the neighbors ourselves. Let's see if this solves our problem:


Neighbor ID Pri State Dead Time Interface ID InterfaceN/A 0 ATTEMPT/DROTHER 00:01:00 0 Serial0/0R2#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID InterfaceN/A 0 ATTEMPT/DROTHER 00:00:39 0 Serial0/0

Too bad…I want to see “FULL” but I’m only seeing “ATTEMPT” here. My OSPFv3 configuration looks fine to me so this would be a good moment to move further down the OSI model. Let's try a quick ping between the two routers:

R1#ping FE80::9CD7:2EFF:FEF0:99FAOutput Interface: Serial0/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to FE80::9CD7:2EFF:FEF0:99FA, timeout is 2 seconds:Packet sent with a source address of FE80::9CD8:2EFF:FEF0:99FA.....Success rate is 0 percent (0/5)

I’m unable to ping between the link-local addresses. Now I know that layer 3 of the OSI-model is not working, let’s dive deeper…

R1#show frame-relay map R2#show frame-relay map

There seems to be no frame-relay map. We need this in order to bind the DLCI to the IPv6 addresses. Normally Inverse ARP takes care of this but not this time. It’s probably disabled (or the interface is not operational). Let's check if the PVCs are active:

R1#show frame-relay pvc | include ACTIVEDLCI = 102, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0R2#show frame-relay pvc | include ACTIVEDLCI = 201, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

We’ll check if the PVC is operational and what the DLCI number is. It’s active on both sides and you can see the DLCI numbers, let’s create some frame-relay maps:

R1(config)#interface serial 0/0R1(config-if)#frame-relay map ipv6 FE80::9CD7:2EFF:FEF0:99FA 102R2(config)#interface serial 0/0R2(config-if)#frame-relay map ipv6 FE80::9CD8:2EFF:FEF0:99FA 201

I’ll map the link-local addresses to the DLCI numbers. After a few seconds we'll see this:

R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from LOADING to FULL, Loading DoneR2# %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0 from LOADING to FULL, Loading Done

This is looking good! Let's verify our work:


Neighbor ID Pri State Dead Time Interface ID Interface2.2.2.2 1 FULL/DR 00:01:47 4 Serial0/0R2#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface1.1.1.1 1 FULL/BDR 00:01:58 4 Serial0/0

Problem solved!

Lesson learned: Check the OSPFv3 network type and configure the neighbors using the link-local addresses. Also make sure you have the correct frame-relay maps.That's all I have for now, keep in mind that most of what you know about OSPF (version 2) can also be applied to troubleshooting OSPFv3. If you have any questions, feel free to leave a comment!

Multiprotocol BGP (MP-BGP) ConfigurationThe normal version of BGP (Border Gateway Protocol) only supported IPv4 unicast prefixes. Nowadays we use MP-BGP (Multiprotocol BGP) which supports different addresses: IPv4 unicast IPv4 multicast IPv6 unicast IPv6 multicast

MP-BGP is also used for MPLS VPN where we use MP-BGP to exchange the VPN labels. For each different “address” type, MP-BGP uses a different address family.

To allow these new addresses, MBGP has some new features that the old BGP doesn’t have:

Address Family Identifier (AFI): specifies the address family. Subsequent Address Family Identifier (SAFI): Has additional information for some address

families. Multiprotocol Reachable Network Layer Reachability Information (MP_UNREACH_NLRI): This

is an attribute used to transport networks that are unreachable. BGP Capabilities Advertisement: This is used by a BGP router to announce to the other BGP

router what capabilities it supports. MP-BGP and BGP-4 are compatible, the BGP-4 router can ignore the messages that it doesn’t understand.

Since MP-BGP supports IPv4 and IPv6 we have a couple of options. MP-BGP routers can become neighbors using IPv4 addresses and exchange IPv6 prefixes or the other way around. Let’s take a look at some configuration examples…

Configuration

MP-BGP with IPv6 adjacency & IPv6 prefixes

Let’s start with a simple example where we use IPv6 for the neighbor adjacency and exchange some IPv6 prefixes. Here’s the topology I will use:

Here’s the configuration of R1:

R1(config)#router bgp 1R1(config-router)#neighbor 2001:db8:0:12::2 remote-as 2R1(config-router)#address-family ipv4R1(config-router-af)#no neighbor 2001:db8:0:12::2 activateR1(config-router-af)#exitR1(config-router)#address-family ipv6R1(config-router-af)#neighbor 2001:db8:0:12::2 activateR1(config-router-af)#network 2001:db8::1/128

In the configuration above we first specify the remote neighbor. The address-family command is used to change the IPv4 or IPv6 settings. I disable the IPv4 address-family and enabled IPv6. Last but not least, we advertised the prefix on the loopback interface. The configuration of R2 looks similar:

R2(config)#router bgp 2R2(config-router)#neighbor 2001:db8:0:12::1 remote-as 1

R2(config-router)#address-family ipv4R2(config-router-af)#no neighbor 2001:db8:0:12::1 activateR2(config-router-af)#exitR2(config-router)#address-family ipv6R2(config-router-af)#neighbor 2001:db8:0:12::1 activateR2(config-router-af)#network 2001:db8::2/128

After awhile the neighbor adjacency will appear:

R1#%BGP-5-ADJCHANGE: neighbor 2001:DB8:0:123::2 Up

Now let’s check the routing tables:

R1#show ipv6 route bgpIPv6 Routing Table - default - 7 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery l - LISP O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2B 2001:DB8::2/128 [20/0] via FE80::217:5AFF:FEED:7AF0, FastEthernet0/0R2#show ipv6 route bgpIPv6 Routing Table - default - 7 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery l - LISP O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2B 2001:DB8::1/128 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0

The routers learned each others prefixes…great! This example was pretty straight-forward but you have now learned how MP-BGP uses different address families.

Configurations R1 R2

Want to take a look for yourself? Here you will find the configuration of each device.

MP-BGP with IPv4 adjacency & IPv6 prefixes

let’s look at a more complex example, the routers will become neighbors through IPv4 but will exchange IPv6 prefixes. I’ll use the same topology but with an IPv4 subnet in between:

Here’s the configuration:

R1(config)#router bgp 1R1(config-router)#neighbor 192.168.12.2 remote-as 2R2(config)#router bgp 2R2(config-router)#neighbor 192.168.12.1 remote-as 1

Now we can configure the address-family for IPv6 unicast:

R1(config)#router bgp 1R1(config-router)#address-family ipv6R1(config-router-af)#network 2001:db8::1/128R1(config-router-af)#neighbor 192.168.12.2 activateR2(config)#router bgp 2R2(config-router)#address-family ipv6R2(config-router-af)#network 2001:db8::2/128R2(config-router-af)#neighbor 192.168.12.1 activate

Once we enter the address-family IPv6 configuration there are two things we have to configure. The prefix has to be advertised and we need to specify the neighbor. The prefixes on the loopback interface should now be advertised. Let’s check it out:

R1#show ip bgp ipv6 unicastBGP table version is 2, local router ID is 192.168.12.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-FilterOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 2001:DB8::1/128 :: 0 32768 i* 2001:DB8::2/128 ::FFFF:192.168.12.2 0 0 2 iR2#show ip bgp ipv6 unicastBGP table version is 2, local router ID is 192.168.12.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-FilterOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path* 2001:DB8::1/128 ::FFFF:192.168.12.1 0 0 1 i*> 2001:DB8::2/128 :: 0 32768 i

As you can see the routers have learned about each others prefixes. There’s one problem though…we were able to exchange IPv6 prefixes but we only use IPv4 between R1 and R2, there is no valid next hop address that we can use.

To fix this, we need to use some IPv6 addresses that we can use as the next hop. We’ll have to configure a prefix between R1 and R2 for this:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 address 2001:db8:0:12::1/64R2(config)#interface FastEthernet 0/0R2(config-if)#ipv6 address 2001:db8:0:12::2/64

Now we have IPv6 addresses that we can use as the next hop. We are using IPv4 for the neighbor peering so the next hop doesn’t change automatically. We’ll have to use a route-map for this:

R1(config)#route-map IPV6_NEXT_HOP permit 10R1(config-route-map)#set ipv6 next-hop 2001:db8:0:12::2R1(config)#router bgp 1R1(config-router)#address-family ipv6R1(config-router-af)#neighbor 192.168.12.2 route-map IPV6_NEXT_HOP inR2(config)#route-map IPV6_NEXT_HOP permit 10R2(config-route-map)#set ipv6 next-hop 2001:db8:0:12::1R2(config)#router bgp 2R2(config-router)#address-family ipv6R2(config-router-af)#neighbor 192.168.12.1 route-map IPV6_NEXT_HOP in

Both routers will now advertise their IPv6 address as the next hop for all prefixes that are advertised. Let’s reset BGP:

R1#clear ip bgp *

Take a look now:

R1#show ip bgp ipv6 unicast | begin 2001*> 2001:DB8::1/128 :: 0 32768 i*> 2001:DB8::2/128 2001:DB8:0:12::2R2#show ip bgp ipv6 unicast | begin 2001*> 2001:DB8::1/128 2001:DB8:0:12::1

The next hop IPv6 addresses are now reachable so they can be installed in the routing table. The downside of this solution is that we had to fix the next hop ourselves, the advantage however is that we have a single BGP neighbor adjacency that can be used for the exchange of IPv4 and IPv6 prefixes.

BGP IPv6 Route Filtering on Cisco IOSFiltering IPv6 routes in BGP is similar to IPv4 filtering. There are 3 methods we can use: Prefix-list Filter-list Route-mapEach of these can be applied in- or outbound. I’ll explain how you can use these for filtering, this is the topology I will use:

R1 and R2 are using IPv6 addresses and will use MP-BGP so that R1 can advertise some prefixes on its loopback interfaces. All prefixes on the loopback interfaces are /64 subnets while loopback3 has a /96 subnet.

Configuration

Let’s start with a basic MP-BGP configuration so that R1 and R2 become eBGP neighbors:

R1 & R2#(config)ipv6 unicast-routingR1(config)#router bgp 1R1(config-router)#bgp router-id 1.1.1.1R1(config-router)#neighbor 2001:db8:0:12::2 remote-as 2R1(config-router)#address-family ipv6R1(config-router-af)#neighbor 2001:db8:0:12::2 activateR1(config-router-af)#network 2001:db8:0:1::/64R1(config-router-af)#network 2001:db8:0:11::/64R1(config-router-af)#network 2001:db8:0:111::/64R1(config-router-af)#network 2001:db8:0:1111::/96R2(config)#router bgp 2R2(config-router)#bgp router-id 2.2.2.2

https://networklessons.com/bgp/multiprotocol-bgp-mp-bgp-configuration/

https://networklessons.com/bgp/bgp-prevent-transit-as/

R2(config-router)#neighbor 2001:db8:0:12::1 remote-as 1R2(config-router)#address-family ipv6R2(config-router-af)#neighbor 2001:db8:0:12::1 activate

Let’s check if R2 has learned all prefixes:

R2#show ipv6 route bgp | begin 2001B 2001:DB8:0:1::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0B 2001:DB8:0:11::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0B 2001:DB8:0:111::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0B 2001:DB8:0:1111::/96 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0

There we go, everything is in the routing table. Now we can play with some of the filtering options…

Prefix-List Filtering

Let’s start with the prefix-list. R1 is advertising one /96 subnet. Let’s see if we can configure R2 to filter this network:

R2(config)#ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64

This prefix-list checks the entire 2001::/16 range and permits subnets with a /64 or larger. Anything smaller will be denied. Let’s activate it:

R2(config)#router bgp 2R2(config-router)#address-family ipv6R2(config-router-af)#neighbor 2001:db8:0:12::1 prefix-list SMALL_NETWORKS in

We activate the prefix-list inbound on R2 for everything that we receive from R1. Let’s reset BGP to speed things up:

R2#clear ip bgp *

Let’s check R2 to see if our prefix is gone:

R2#show ipv6 route bgp | begin 2001B 2001:DB8:0:1::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0B 2001:DB8:0:11::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0B 2001:DB8:0:111::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0

Great, it has been filtered succesfully!

Filter-List Filtering

Let’s try the filter-list. We can use this to filter prefixes from certain autonomous systems. Everything that R1 is advertising only has AS 1 in the AS path, I’ll configure AS prepending so we have something to play with:

R1(config)#ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64

R1(config)#route-map PREPEND permit 10R1(config-route-map)#match ipv6 address prefix-list FIRST_LOOPBACKR1(config-route-map)#set as-path prepend 11R1(config)#route-map PREPEND permit 20

R1(config)#router bgp 1R1(config-router)#address-family ipv6R1(config-router-af)#neighbor 2001:db8:0:12::2 route-map PREPEND out

The above configuration will make sure that whenever R1 advertises 2001:db8:0:1::/64 it will add AS 11 to the AS path. Let’s verify this:

R2#show ip bgp allFor address family: IPv4 Unicast

For address family: IPv6 Unicast

BGP table version is 4, local router ID is 2.2.2.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-FilterOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 2001:DB8:0:1::/64 2001:DB8:0:12::1 0 0 1 11 i*> 2001:DB8:0:11::/64 2001:DB8:0:12::1 0 0 1 i*> 2001:DB8:0:111::/64 2001:DB8:0:12::1 0 0 1 i

For address family: IPv4 Multicast

Above you can see that 2001:DB8:0:1::/64 now has AS 11 in its AS path. Let’s configure a filter-list on R2 to get rid of this network:

R2(config)#ip as-path access-list 11 permit ^1$

R2(config)#router bgp 2R2(config-router)#address-family ipv6R2(config-router-af)#neighbor 2001:db8:0:12::1 filter-list 11 in

R2#clear ip bgp *

The as-path access-list above only permits prefixes from AS1, nothing else. We attach it inbound to everything we receive from R1. This is the result:

R2#show ipv6 route bgp | begin 2001B 2001:DB8:0:11::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0B 2001:DB8:0:111::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0

It’s gone from the routing table, mission accomplished.

Route-Map Filtering

Route-maps are really useful and can be used to match on many different things. I’ll use an IPv6 access-list in a route-map to filter 2001:DB8:0:11::/64:

R2(config)#ipv6 access-list THIRD_LOOPBACK

R2(config-ipv6-acl)#permit 2001:db8:0:11::/64 any

R2(config)#route-map MY_FILTER deny 10R2(config-route-map)#match ipv6 address THIRD_LOOPBACKR2(config-route-map)#exitR2(config)#route-map MY_FILTER permit 20

R2(config)#router bgp 2R2(config-router-af)#neighbor 2001:db8:0:12::1 route-map MY_FILTER in

R2#clear ip bgp *

The configuration above has an access-list called "THIRD_LOOPBACK" that matches 2001:DB8:0:11::/64 and is denied in the route-map called "MY_FILTER". Last but not least, we apply it inbound on R2. Here's the result:

R2#show ipv6 access-listIPv6 access list THIRD_LOOPBACK permit ipv6 2001:DB8:0:11::/64 any (1 match) sequence 10R2#show ipv6 route bgp | begin 2001B 2001:DB8:0:111::/64 [20/0] via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0

The access-list tells us that it has a match and you can see it's gone from the routing table.

Order of Operation

You have now seen how you can use a prefix-list, filter-list and route-map to filter IPv6 prefixes. You can apply all of these at the same time if you want, I didn't remove any of my previous configurations when I was writing this lesson. Take a look at R2:

R2#show run | sec address-family ipv6 address-family ipv6 neighbor 2001:DB8:0:12::1 activate neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in neighbor 2001:DB8:0:12::1 route-map MY_FILTER in neighbor 2001:DB8:0:12::1 filter-list 11 in

On a production network you probably won't use all of these at the same time. The route-map is a popular choice since you can use it for pretty much anything, filtering and doing things like prepending the AS path.

If you do activate all of these at the same time then you might want to know in what order the router will process these filtering techniques. Here they are:

Inbound: Route-map Filter-List Prefix-ListOutbound: Prefix-List Filter-List Route-MapWhy do we care about this? Imagine you have an inbound route-map and prefix-list. If you permitted a prefix in the prefix-list but denied it in the route-map then you will never see the prefix in your BGP table since the route-map is processed before the prefix-list.

For outbound filtering it's the other way around. If you permit something in the route-map but denied it in a filter-list then it will never be advertised...the filter-list is processed before the route-map for outbound updates.

Don't make it too hard for yourself...it's best to stick to using the route-map only since you can attach prefix-lists and as-path access-lists to it.

How to configure IPv6 Redistribution RIPNG OSPFv3Redistribution for IPv6 is pretty much the same as for IPv4, the same rules apply. I want to show you an example of IPv6 redistribution between RIPNG and OSPFv3. Here’s the topology that we will use:

In the middle we have router R2 that will perform the redistribution between RIPNG and OSPFv3. R1 and R3 have a loopback interface that will be advertised.

R1(config)#ipv6 unicast-routing R1(config)#interface loopback 0R1(config-if)#ipv6 address 2001::1/128R1(config-if)#exitR1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 enableR2(config)#ipv6 unicast-routing R2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 enable R2(config-if)#exitR2(config)#interface fastEthernet 1/0R2(config-if)#ipv6 enableR3(config)#ipv6 unicast-routing R3(config)#interface loopback 0R3(config-if)#ipv6 address 2001::3/128R3(config-if)#exitR3(config)#interface fastEthernet 0/0R3(config-if)#ipv6 enable

This is what we’ll start with. I’m using the loopbacks to have something to advertise in RIPNG or OSPFv3. On the FastEthernet interfaces I only need a link-local IPv6 address.

R2(config)#ipv6 router rip RIPNGR2(config-rtr)#exit R2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 rip RIPNG enableR1(config)#ipv6 router rip RIPNGR1(config-rtr)#exitR1(config)#interface loopback 0

R1(config-if)#ipv6 rip RIPNG enable R1(config-if)#exitR1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 rip RIPNG enable

I’m configuring RIPNG on R2 and R1 to get things going.

R3(config)#ipv6 router ospf 1R3(config-rtr)#router-id 3.3.3.3R3(config-rtr)#exitR3(config)#interface fastEthernet 0/0R3(config-if)#ipv6 ospf 1 area 0R3(config-if)#interface loopback 0R3(config-if)#ipv6 ospf 1 area 0 R2(config)#ipv6 router ospf 1R2(config-rtr)#router-id 2.2.2.2R2(config-rtr)#exit R2(config)#interface fastEthernet 1/0R2(config-if)#ipv6 ospf 1 area 0

And this is what we need on R3 and R2 to get OSPFv3 working.

R2(config)#ipv6 router ospf 1R2(config-rtr)#redistribute rip RIPNGR2(config-rtr)#exitR2(config)#ipv6 router rip RIPNGR2(config-rtr)#redistribute ospf 1 metric 1

We use the redistribute command to exchange routing information between OSPFv3 and RIPNG. This is all you have to do to redistribute everything.

R1#show ipv6 route ripIPv6 Routing Table - 4 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 2001::3/128 [120/2] via FE80::CE04:19FF:FE67:0, FastEthernet0/0R3#show ipv6 route ospf IPv6 Routing Table - 4 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2OE2 2001::1/128 [110/20] via FE80::CE04:19FF:FE67:10, FastEthernet0/0

We can verify our configuration by looking at the routing tables. If you want you can be a bit more specific with redistribution using route-maps:

R2(config)#ipv6 router rip RIPNGR2(config-rtr)#redistribute ospf 1 route-map ONLYTHESER2(config-rtr)#exit

R2(config)#ipv6 prefix-list MYPREFIXES permit 2001::3/128

R2(config)#route-map ONLYTHESE permit 10R2(config-route-map)#match ipv6 address prefix-list MYPREFIXES

Using a route-map and a prefix-list like in the example above I can select only the prefixes that I want redistributed. This is a better solution than just redistributing everything.

Troubleshooting IPv6 RedistributionRedistribution for IPv6 is pretty similar to IPv4, the same rules and issues apply here. There is however one issue that only applies to IPv6 redistribution which I will show you here. This is the topology I will use:

R1 and R2 are configured to use EIGRP, R2 and R3 use OSPF. R2 is redistributing between the two routing protocols. The problem is that R1 is unable to reach 2001:0DB8:23:23::/64 and R3 is unable to reach 2001:0DB8:12:12::/64. Everything else is reachable…

Let’s check some routing tables, see what we are dealing with:

R1#show ipv6 route eigrp

EX 2001:DB8:3:3::3/128 [170/1757696] via FE80::C002:17FF:FE28:0, FastEthernet0/0R2#show ipv6 route

D 2001:DB8:1:1::1/128 [90/409600] via FE80::C001:18FF:FEB0:0, FastEthernet0/0O 2001:DB8:3:3::3/128 [110/10] via FE80::C003:FFF:FE10:0, FastEthernet0/1R3#show ipv6 route ospf

OE2 2001:DB8:1:1::1/128 [110/20] via FE80::C002:17FF:FE28:1, FastEthernet0/0

Looking at these routing tables, we can see that R1 knows how to reach the loopback of R3 and vice versa. Since we have something in the routing table, we know that the

EIGRP and OSPF neighbor adjacencies are working. There are a couple of reasons why we could miss something in the routing table:

Networks are not configured: Keep in mind that IPv6 routing protocols use their link-local IPv6 addresses for the neighbor adjacency.

Filtering: Route filtering could filter some of the prefixes. Redistribution: Configuration errors with redistribution could cause issues.Let’s check if those two networks are configured correctly, you could check the addresses or do a quick ping:

R2#show ipv6 interface briefFastEthernet0/0 [up/up] FE80::C002:17FF:FE28:0 2001:DB8:12:12::2FastEthernet0/1 [up/up] FE80::C002:17FF:FE28:1 2001:DB8:23:23::2R2#ping 2001:0DB8:12:12::1

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:DB8:12:12::1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/28 msR2#ping 2001:0DB8:23:23::3

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:DB8:23:23::3, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/28 ms

It seems that these networks are configured and the pings are working. What about filtering? Normally I’d like to use specific show commands but in this case, checking the EIGRP and OSPF configs will be easier:

R1#show run | section ipv6 routeripv6 router eigrp 12 router-id 1.1.1.1 no shutdownR2#show run | section ipv6 router

ipv6 router eigrp 12 router-id 2.2.2.2 no shutdown redistribute ospf 1 metric 1500 100 255 1 1500ipv6 router ospf 1 router-id 2.2.2.2 log-adjacency-changes redistribute eigrp 12R3#show run | section ipv6 routeripv6 router ospf 1 router-id 3.3.3.3 log-adjacency-changes

These configurations are pretty straight-forward. There are no filters and no route-maps attached to the redistribution config, everything is looking good. So what’s the issue here?

Redistribution for IPv6 works a little bit different compared to IPv4. When you redistribute with IPv4, all networks that are advertised in your routing protocols will be redistributed…that includes the directly connected networks.

With IPv6, networks that are directly connected and advertised in your routing protocols are NOT redistributed by default…this is something we have to enable ourselves. Let me show you what I mean:

R2(config)#ipv6 router eigrp 12R2(config-rtr)#redistribute ospf 1 metric 1500 100 255 1 1500 include-connectedR2(config)#ipv6 router ospf 1R2(config-rtr)#redistribute eigrp 12 include-connected

We need to add the include-connected keyword when we want to redistribute the directly connected networks that are advertised in our routing protocol. Let’s see the result of this:

R1#show ipv6 route eigrp

EX 2001:DB8:3:3::3/128 [170/1757696] via FE80::C002:17FF:FE28:0, FastEthernet0/0EX 2001:DB8:23:23::/64 [170/1757696] via FE80::C002:17FF:FE28:0, FastEthernet0/0R3#show ipv6 route ospf

OE2 2001:DB8:1:1::1/128 [110/20]

via FE80::C002:17FF:FE28:1, FastEthernet0/0OE2 2001:DB8:12:12::/64 [110/20] via FE80::C002:17FF:FE28:1, FastEthernet0/0

R1 and R3 are now able to learn about the 2001:DB8:23:23::/64 and 2001:DB8:12:12::/64 networks…problem solved.

Lesson learned: IPv6 redistribution behaves a bit different than IPv4 redistribution.

IPv6 Access-list on Cisco IOSAs explained in my first tutorial that introduces access-lists, we can use access-lists for filtering (blocking packets) or selecting traffic (for VPNs, NAT, etc).This also applies to IPv6 access-lists which are very similar to IPv4 access-lists. There are two important differences however:

IPv4 access-lists can be standard or extended, numbered or named. IPv6 only has named extended access-lists.

IPv4 access-lists have an invisible implicit deny any at the bottom of every access-list. IPv6 access-lists have three invisible statements at the bottom:o permit icmp any any nd-nao permit icmp any any nd-nso deny ipv6 any any

The two permit statements are required for neighbor discovery which is an important protocol in IPv6, it’s the replacement for ARP.When you use a deny ipv6 any any at the bottom of your access-list, make sure you also add the two permit statements for neighbor discovery just before the final statement or this traffic will be dropped.

Having said that, let’s take a look at the configuration.

Configuration

For this demonstration we only need two routers:

https://networklessons.com/ipv6/ipv6-neighbor-discovery-protocol-on-cisco-router/

https://networklessons.com/ipv6/introduction-to-access-lists-on-cisco-ios-router/

I’ll use subnet 2001:DB8:0:12::/64 in between R1 and R2. To demonstrate the access-list, I’ll create one inbound on R2 and we will try to filter some packets from R1. Let’s take a look at the access-list:

R2(config)#ipv6 access-list ? WORD User selected string identifying this access list log-update Control access list log updates

As you can see above the only option is the named access-list. There’s also no option for standard or extended access-list. Let’s create that access-list:

R2(config)#ipv6 access-list R1_TRAFFIC

I’ll call it “R1_TRAFFIC”. Here are our options when we create a statement:

R2(config-ipv6-acl)#permit ? <0-255> An IPv6 protocol number X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/<z> ahp Authentication Header Protocol any Any source prefix esp Encapsulation Security Payload host A single source host icmp Internet Control Message Protocol ipv6 Any IPv6 pcp Payload Compression Protocol sctp Streams Control Transmission Protocol tcp Transmission Control Protocol udp User Datagram Protocol

This is similar to IPv4 access-lists. You can pick any protocol you like. Let’s see if we can permit telnet traffic from R1 and deny everything else:

R2(config-ipv6-acl)#permit tcp ?

X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/<z> any Any source prefix host A single source host

Let's permit telnet traffic from R1:

R2(config-ipv6-acl)#permit tcp host 2001:db8:0:12::1 ? X:X:X:X::X/ IPv6 destination prefix x:x::y/ any Any destination prefix eq Match only packets on a given port number gt Match only packets with a greater port number host A single destination host lt Match only packets with a lower port number neq Match only packets not on a given port number range Match only packets in the range of port numbers

After specifying the source IP I also have to select the destination IP, let's do that:

R2(config-ipv6-acl)#permit tcp host 2001:db8:0:12::1 any eq 23

This should permit telnet traffic from R1. Let's take a look at our access-list:

R2#show access-lists IPv6 access list R1_TRAFFIC permit tcp host 2001:DB8:0:12::1 any eq telnet sequence 10

Above you see our statement. One cosmetic difference with IPv4 access-lists is that the sequence number is behind the statement. Let's apply this access-list on the interface:

R2(config)#interface FastEthernet 0/0R2(config-if)#ipv6 traffic-filter R1_TRAFFIC in

Instead of using the access-group command you have to use the ipv6 traffic-filter command. Let's see if it works:

R1#telnet 2001:db8:0:12::2Trying 2001:DB8:0:12::2 ... Open

R1 is able to telnet to R2. Let's see if we find any matches on our access-list:

R2#show access-lists IPv6 access list R1_TRAFFIC permit tcp host 2001:DB8:0:12::1 any eq telnet (10 matches) sequence 10

There we go, we see it matches the access-list. Anything else should be dropped...let's try a simple ping:

R1#ping 2001:db8:0:12::2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:DB8:0:12::2, timeout is 2 seconds:AAAAASuccess rate is 0 percent (0/5)

The AAAAAs that you see above indicate that the destination is administratively unreachable, it means that an access-list is dropping our packets.

Usually, this output indicates that an access list is blocking traffic. For security reasons it might be a bad idea to tell someone that traffic has been dropped. If you want you can disable this:

R2(config)#interface FastEthernet 0/0R2(config-if)#no ipv6 unreachables

Use the no ipv6 unreachables command to disable this. When we send another ping now you will see this:

R1#ping 2001:db8:0:12::2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:DB8:0:12::2, timeout is 2 seconds:.....Success rate is 0 percent (0/5)

R2 is no longer informing R1 that the packets have been dropped. That's all I have for now, have fun configuring IPv6 access-lists.

OSPFv3 Authentication and EncryptionOSPFv3 doesn’t have an authentication field in its header like OSPFv2 does, instead it relies on IPsec to get the job done.

IPsec supports two encapsulation types. The first one is AH (Authentication Header) which as the name implies, authenticates the header. The other encapsulation type is ESP (Encapsulating Security Payload) which encrypts packets. We can use both for OSPFv3 so besides authentication, encryption is also a possibility.

In this lesson I’ll show you how to configure both options.

Configuration

We will use the following topology for this:

We only need two routers for this demonstration. I will only use the link-local IPv6 addresses on these two routers. Let’s enable OSPFv3:

R1 & R2#(config)#interface FastEthernet 0/0(config-if)#ipv6 ospf 1 area 0

Now we can play with authentication…

IPsec Authentication

To get started we have to use the ipv6 ospf authentication command:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 ospf authentication ?ipsec Use IPsec authenticationnull Use no authentication

Since we want authentication, we’ll select ipsec:

R1(config-if)#ipv6 ospf authentication ipsec ? spi Set the SPI (Security Parameters Index)

First we have to choose a SPI. You can pick any number you like but it has to match on both routers. Let’s pick the lowest available number (256):

R1(config-if)#ipv6 ospf authentication ipsec spi 256 ? md5 Use MD5 authentication sha1 Use SHA-1 authentication

Now we can choose what authentication we would like, MD5 or SHA1. SHA1 is more secure so let’s select that:

R1(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 ? 0 The key is not encrypted (plain text) 7 The key is encrypted Hex-string SHA-1 key (40 chars)

Now we have to type in a key string ourselves. Normally IPsec uses IKE (Internet Key Exchange) for the security association between two devices. However since we can have multiple OSPFv3 neighbors on a single segment we can’t use IKE and we’ll have to use a static key instead.

For this example I will use an online SHA1 generator to generate a key but for a production network you really should use a safer method to generate a key. Let’s enter that key:

R1(config)#interface FastEthernet 0/0R1(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1

http://www.sha1-online.com/

As soon as you do this the OSPFv3 neighbor adjacency will drop so let’s copy and paste the same line on R2:

R2(config)#interface FastEthernet 0/0R2(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1

That should do the job.

It’s also possible to configure authentication for the entire area. If you want this you’ll have to use the area 0 authentication command under the OSPFv3 process.

let’s verify our work:

R1#show ipv6 ospf interface FastEthernet 0/0 | include auth SHA-1 authentication SPI 256, secure socket UP (errors: 0)R2#show ipv6 ospf interface FastEthernet 0/0 | include auth SHA-1 authentication SPI 256, secure socket UP (errors: 0)

If you look at the OSPF specific information on the interface then you can see that authentication has been enabled. Since we are using IPsec, you can also check the security associations:

R1#show crypto ipsec sa

interface: FastEthernet0/0 Crypto map tag: (none), local addr ::

IPsecv6 policy name: OSPFv3-1-256 IPsecv6-created ACL name: FastEthernet0/0-ipsecv6-ACL

protected vrf: (none) local ident (addr/mask/prot/port): (FE80::/10/89/0) remote ident (addr/mask/prot/port): (::/0/89/0) current_peer :: port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 50, #pkts encrypt: 50, #pkts digest: 50 #pkts decaps: 31, #pkts decrypt: 31, #pkts verify: 31 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0

local crypto endpt.: ::, remote crypto endpt.: :: path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb FastEthernet0/0 current outbound spi: 0x100(256) PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas: spi: 0x100(256) transform: ah-sha-hmac , in use settings ={Transport, } conn id: 2001, flow_id: NETGX:1, sibling_flags 80000001, crypto map: (none) no sa timing replay detection support: N Status: ACTIVE

inbound pcp sas:

outbound esp sas:

outbound ah sas: spi: 0x100(256) transform: ah-sha-hmac , in use settings ={Transport, } conn id: 2002, flow_id: NETGX:2, sibling_flags 80000001, crypto map: (none) no sa timing replay detection support: N Status: ACTIVE

outbound pcp sas:

Above you can see our SPI number and that we are using SHA authentication. There’s one more useful command:

R1#show crypto ipsec policy Crypto IPsec client security policy data

Policy name: OSPFv3-1-256Policy refcount: 1Inbound AH SPI: 256 (0x100)Outbound AH SPI: 256 (0x100)Inbound AH Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1

Outbound AH Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1Transform set: ah-sha-hmac

This gives us a nice overview with our authentication method, SPI and keys. If you are interested, here’s a wireshark capture of our authenticated OSPFv3 packets:

Above you can see the authentication header. If you want to take a look for yourself then you can find the capture file here.

Configurations R1 R2

Want to take a look for yourself? Here you will find the configuration of each device.

https://networklessons.com/wp-content/uploads/2015/07/wireshark-ospfv3-ah.pcap

IPsec Encryption

Let’s take a look at the second method, using IPsec ESP to authenticate and encrypt OSPFv3 traffic. Let’s get rid of the current IPsec AH configuration:

R1 & R2#(config)#interface FastEthernet 0/0(config-if)no ipv6 ospf authentication ipsec spi 256 sha1 A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1

Now we can enable ESP, there’s a different command we have to use:

R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp ? 3des Use 3DES encryption aes-cbc Use AES-CBC encryption des Use DES encryption null ESP with no encryption

This time you have to use the ipv6 ospf encryption command. You still have to select the SPI number and above you can see the options for ESP. Let's select AES since it's the most secure encryption method:

R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc ? 128 Use 128 bit key 192 Use 192 bit key 256 Use 256 bit key

We get to select the size of our key. Let's go for 256-bit:

R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256 ? 0 The key is not encrypted (plain text) 7 The key is encrypted Hex-string 256bit key (64 chars)

Now we have to enter the 256-bit key ourselves. For this example I used this website to generate one but for a production network it's probably best to use something a bit more secure. Let's enter our key:

R1(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256 FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B sha1 A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1

https://www.grc.com/passwords.htm

Once you enter the encryption key you also have to specify the authentication algorithm and key. Just like the previous example I used SHA1 for this. Let's copy and paste this entire line to R2 as well:

R2(config)#interface FastEthernet 0/0R2(config-if)#ipv6 ospf encryption ipsec spi 256 esp aes-cbc 256 FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B sha1 A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1

Let's verify our work:

R1#show ipv6 ospf interface FastEthernet 0/0 | include auth AES-CBC-256 encryption SHA-1 auth SPI 256, secure socket UP (errors: 0)

Here we can see that we are using AES for encryption ahd SHA1 for authentication. Let's check our IPsec SA:

R1#show crypto ipsec sa

interface: FastEthernet0/0 Crypto map tag: (none), local addr FE80::21D:A1FF:FE8B:36D0

IPsecv6 policy name: OSPFv3-1-256 IPsecv6-created ACL name: FastEthernet0/0-ipsecv6-ACL

protected vrf: (none) local ident (addr/mask/prot/port): (FE80::/10/89/0) remote ident (addr/mask/prot/port): (::/0/89/0) current_peer :: port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 80, #pkts encrypt: 80, #pkts digest: 80 #pkts decaps: 41, #pkts decrypt: 41, #pkts verify: 41 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0

local crypto endpt.: FE80::21D:A1FF:FE8B:36D0, remote crypto endpt.: :: path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb FastEthernet0/0 current outbound spi: 0x100(256) PFS (Y/N): N, DH group: none

inbound esp sas: spi: 0x100(256) transform: esp-256-aes esp-sha-hmac , in use settings ={Transport, } conn id: 2003, flow_id: NETGX:3, sibling_flags 80000001, crypto map: (none) no sa timing IV size: 0 bytes replay detection support: N Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas: spi: 0x100(256) transform: esp-256-aes esp-sha-hmac , in use settings ={Transport, } conn id: 2004, flow_id: NETGX:4, sibling_flags 80000001, crypto map: (none) no sa timing IV size: 0 bytes replay detection support: N Status: ACTIVE

outbound ah sas:

outbound pcp sas:

Above you can see that some packets have been encrypted / decrypted and that we are using IPsec ESP / AH. If you only want a quick overview, take a look below:

R1#show crypto ipsec policy Crypto IPsec client security policy data

Policy name: OSPFv3-1-256Policy refcount: 1Inbound ESP SPI: 256 (0x100)Outbound ESP SPI: 256 (0x100)Inbound ESP Auth Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1Outbound ESP Auth Key: A5DEC4DD155A695A8B983AACEAA5A97C6AECB6D1Inbound ESP Cipher Key: FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85B

Outbound ESP Cipher Key: FDCEA619E8AA73F517F6EA997D7D782F3EB47B4FA425AA0AD19D73C2A7FBD85BTransform set: esp-256-aes esp-sha-hmac

Let me also show you a wireshark capture of some encrypted OSPFv3 traffic:

How to configure IPv6 tunneling over IPv4Since IPv4 and IPv6 are not compatible with each other we need some migration strategies. One technique that we can use is tunneling. Basically it means that we encapsulate IPv6 packets into IPv4 packets (or the other way around) so that it can be routed. In this lesson I’ll show you how to configure IPv6 static tunneling over an IPv4 network, there are two methods: Manual tunnels GRE (Generic Routing Encapsulation) tunnelsBoth tunnel types are very similar with just minor differences. Both support IPv6 IGPs through the tunnel interface and forwarding of multicast traffic. The manual tunnels refer to RFC 4213 which defines how to encapsulate IPv6 packets in IPv4. GRE is a generic encapsulation type that rides on top of IPv4 and isn’t only for IPv6. It can carry many different protocols and if you ever configured an IPSEC VPN with IGPs running through it you had to use GRE.

Let’s continue by looking at some examples and how to configure the static point-to-point IPv6 tunnels.

This is the topology we’ll be using. Three routers are running IPv4. R1 and R3 also run IPv6 and we want connectivity between them without adding IPv6 support on R2.

R1(config)#interface loopback 0R1(config-if)#ipv6 address 2001::1/128R1(config-if)#exitR1(config)#interface fastEthernet 0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0R2(config)#interface fastEthernet 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0R2(config-if)#exit R2(config)#interface fastEthernet 1/0R2(config-if)#ip address 192.168.23.2 255.255.255.0R3(config)#interface fastEthernet 0/0R3(config-if)#ip address 192.168.23.3 255.255.255.0R3(config-if)#exitR3(config)#interface loopback 0R3(config-if)#ipv6 address 2001::3/128

First we’ll fix the IPv4 and IPv6 addresses on the interfaces. Next step is to create a tunnel interface between R1 and R3. They need to be able to reach each other through IPv4.

R1(config)#interface loopback 1R1(config-if)#ip address 1.1.1.1 255.255.255.0R1(config-if)#exitR1(config)#router eigrp 123R1(config-router)#no auto-summary R1(config-router)#network 192.168.12.0R1(config-router)#network 1.1.1.0R2(config)#router eigrp 123R2(config-router)#no auto-summary R2(config-router)#network 192.168.12.0R2(config-router)#network 192.168.23.0R3(config)#interface loopback 1R3(config-if)#ip address 3.3.3.3 255.255.255.0R3(config-if)#exitR3(config)#router eigrp 123R3(config-router)#no auto-summary R3(config-router)#network 192.168.23.0R3(config-router)#network 3.3.3.0

I’ll create a new loopback interface on R1 and R3. I’ll use these loopback interfaces to establish a tunnel interface between the two routers. I could also use physical interfaces but they can go down. Whenever a physical interface goes down our IGP (EIGRP in this example) could find another path (if there is another path).

R1(config)#interface tunnel 0R1(config-if)#tunnel source loopback 1R1(config-if)#tunnel destination 3.3.3.3R1(config-if)#tunnel mode ipv6ipR3(config)#interface tunnel 0R3(config-if)#tunnel source loopback 1R3(config-if)#tunnel destination 1.1.1.1R3(config-if)#tunnel mode ipv6ip

This is how we configure a tunnel interface. By default a tunnel interface is always GRE so by using the tunnel mode ipv6ip command I changed it to a “manual” tunnel per RFC 4213. You can also configure the tunnel interface between the physical interfaces but I like to use loopback interfaces. This will make sure that when a physical interface fails your IGP will try to find another route to the loopback interface of your neighbor.

R1#show interfaces tunnel 0Tunnel0 is up, line protocol is up Hardware is Tunnel

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 1.1.1.1 (Loopback1), destination 3.3.3.3 Tunnel protocol/transport IPv6/IPR3#show interfaces tunnel 0Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 3.3.3.3 (Loopback1), destination 1.1.1.1 Tunnel protocol/transport IPv6/IP

Use the show interfaces tunnel command to check if the tunnel is working. You can see mine is up and the encapsulation type is TUNNEL. At this moment our tunnel is working but we have some things left to do.

R1(config)#ipv6 unicast-routingR1(config)#ipv6 router rip RIPNGR1(config-rtr)#exitR1(config)#interface loopback 0R1(config-if)#ipv6 rip RIPNG enable R1(config-if)#exitR1(config)#interface tunnel 0R1(config-if)#ipv6 enableR1(config-if)#ipv6 rip RIPNG enableR3(config)#ipv6 unicast-routing R3(config)#ipv6 router rip RIPNGR3(config-rtr)#exitR3(config)#interface loopback 0R3(config-if)#ipv6 rip RIPNG enableR3(config-if)#exitR3(config)#interface tunnel 0R3(config-if)#ipv6 enable R3(config-if)#ipv6 rip RIPNG enable

I enabled RIPNG (could have chosen OSPFv3 or EIGRP as well) on the loopback0 and tunnel0 interface. You can see I also added an IPv6 address on the tunnel0 interfaces. We don’t need any IPv4 addresses on our tunnel0 interfaces.

R1#show ipv6 route rip IPv6 Routing Table - 4 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 2001::3/128 [120/2] via FE80::303:303, Tunnel0R3#show ipv6 route rip IPv6 Routing Table - 4 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2R 2001::1/128 [120/2] via FE80::101:101, Tunnel0

You can see both routers learned about each other IPv6 networks.

R1#ping 2001::3 source loopback 0

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:Packet sent with a source address of 2001::1!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

A quick ping proves us that we have connectivity.

That’s all you have to do to create a manual tunnel and encapsulate IPv6 packets in IPv4 packets. Not that bad right? How about GRE?

R1(config)#interface tunnel 0R1(config-if)#tunnel mode gre ipR3(config)#interface tunnel 0R3(config-if)#tunnel mode gre ip

Use tunnel mode gre ip or type no tunnel mode ipv6ip so it switches back to the default (GRE).

R1#show interfaces tunnel 0Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 1.1.1.1 (Loopback1), destination 3.3.3.3 Tunnel protocol/transport GRE/IP

It looks pretty much the same except it now says GRE. The only difference between GRE and the manual tunnel is that GRE has a higher MTU by default and there’s something with the link-local IPv6 address of the tunnel interface:

The link-local address for the GRE tunnel is created with EUI-64 and takes the lowest numbered interface’s MAC address.

The link-local address for the manual tunnel is FE80::/96 + 32 bits from tunnel source IPv4 address.

How to configure IPv6 Automatic 6to4 TunnelingDynamic multipoint IPv6 tunnels are another migration technique we can use. It’s called dynamic because we don’t have to specify the end-point IPv4 address ourselves but its being automatically determined. The downside of multipoint IPv6 tunnels is that they don’t support IPv6 IGPs. You have to use static routes or BGP.There are two different flavors:

Automatic 6to4 ISATAPLet’s dive in the automatic 6to4 tunnel to see how it works. We don’t configure the IPv4 end-point address ourselves but instead the IPv4 end-point address will be wrapped in the IPv6 destination address. Our IPv4 address is only 32-bit so it’s easy to fit it in a 128-bit IPv6 address right?The 2002::/16 range has been reserved to use for tunneling. This IPv6 address space is only for tunneling and will never be used for IPv6 global unicast addresses. If we start with the 2002::/16 prefix we create a /48 prefix for each tunnel end-point. What we have to do is take the IPv4 address of the end-point and convert it into hexadecimal as bits 17 to 48.

The second step is that we can create subnets from /48 up to /64 prefixes for all the subnets behind the end-point.

Here’s a graphical overview. 2002::/16 is the range we can use for the tunnels. The second part is the IPv4 end-point address converted to hexadecimal. Up to /64 we can use to create subnets. C0A8:1703 converts to IPv4 address 192.168.23.3. Do you have trouble calculating from hex to binary/decimal and vice versa?

R3(config)#ipv6 general-prefix MYPREFIX 6to4 fastEthernet 0/0

R3#show ipv6 general-prefix IPv6 Prefix MYPREFIX, acquired via 6to4 2002:C0A8:1703::/48

There is a neat trick on Cisco routers that can do the work for you. First you have to configure an IPv4 address on an interface and then use the ipv6 general-prefix command. It will convert the IPv4 address in hexadecimal and give you the correct IPv6 tunnel prefix with the show ipv6 general-prefix command. I’m not sure if this is available on the CCNP ROUTE exam but it’s nice to know anyway! Let’s take a look at an actual configuration of automatic 6to4 tunneling, this is the topology:

Let’s look at another example and configure automatic tunneling. The idea is that I don’t want to configure a tunnel destination on R1 nor R3…it should be created dynamically!

We’ll start with the configuration of the interfaces and IPv4 / IPv6 addresses:

R1(config)#interface loopback 0R1(config-if)#ipv6 address 2001::1/128R1(config-if)#exitR1(config)#interface fastEthernet 0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0R2(config)#interface fastEthernet 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0R2(config-if)#exit R2(config)#interface fastEthernet 1/0R2(config-if)#ip address 192.168.23.2 255.255.255.0R3(config)#interface fastEthernet 0/0R3(config-if)#ip address 192.168.23.3 255.255.255.0R3(config-if)#exitR3(config)#interface loopback 0R3(config-if)#ipv6 address 2001::3/128

Next step is to configure routing so that we have reachability in IPv4:

R1(config)#router eigrp 123R1(config-router)#no auto-summary R1(config-router)#network 192.168.12.0R1(config-router)#network 1.1.1.0R2(config)#router eigrp 123R2(config-router)#no auto-summary R2(config-router)#network 192.168.12.0R2(config-router)#network 192.168.23.0R3(config)#router eigrp 123R3(config-router)#no auto-summary R3(config-router)#network 192.168.23.0R3(config-router)#network 3.3.3.0

We will use the FastEthernet0/0 interfaces to build the tunnel. Since the tunnel is created automatically we need to know the IPv6 equivalent of the IPv4 addresses:

R1(config)#ipv6 general-prefix MYPREFIX 6to4 fastEthernet 0/0R3(config)#ipv6 general-prefix MYPREFIX 6to4 fastEthernet 0/0R1#show ipv6 general-prefix IPv6 Prefix MYPREFIX, acquired via 6to4 2002:C0A8:C01::/48R3#show ipv6 general-prefix IPv6 Prefix MYPREFIX, acquired via 6to4 2002:C0A8:1703::/48

This time I’m going to use the IP addresses on the FastEthernet0/0 interfaces to build the tunnel. Since the tunnel is created automatically we need to know the IPv6 equivalent of the IPv4 addresses.

R1(config)#interface tunnel 0R1(config-if)#ipv6 address 2002:C0A8:C01::1/64R1(config-if)#tunnel source fastEthernet 0/0R1(config-if)#tunnel mode ipv6ip 6to4R3(config)#interface tunnel 0R3(config-if)#ipv6 address 2002:C0A8:1703::3/64R3(config-if)#tunnel source fastEthernet 0/0R3(config-if)#tunnel mode ipv6ip 6to4

Let me walk you through this configuration: The tunnel interface has an IPv6 address that starts with 2002: and then the IPv4 address in hex:

Router R1: 192.168.12.1 - C0A8:C01 Router R3: 192.168.23.3 - C0A8:1703The tunnel is sourced from the FastEthernet interface (I could have used a loopback as well) and there is no destination. That’s why we need the tunnel mode ipv6ip 6to4 command for. It tells the router to get the IPv4 address from the IPv6 address.Are we done? Well almost. The tunnel configuration is OK but we still have to tell our routers how to reach the loopback0 interfaces. It’s impossible to run an IGP on dynamic tunnel interfaces so we can use static routes or BGP. I’m going to use static routes.

R1(config)#ipv6 route 2001::3/128 2002:C0A8:1703::3 R1(config)#ipv6 route 2002::/16 tunnel 0R3(config)#ipv6 route 2001::1/128 2002:C0A8:C01::1 R3(config)#ipv6 route 2002::/16 tunnel 0

The first static route we need to tell our routers how to reach the loopback0 interface of the other side. It points to the IPv6 address which has the IPv4 address in hex in it. The routers will have to do recursive routing to find an entry for 2002:: which is why we need the second static route. Since 2002::/16 is reserved for tunneling I’m creating a static that points directly to our tunnel0 interface.

R1#ping 2001::3 source loopback 0

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:Packet sent with a source address of 2001::1!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

A quick ping shows we can reach the loopback0 interface of the other side! That's how it is done.

Troubleshooting IPv6 Automatic 6to4 TunnelIn this lesson we’ll take a look how to troubleshoot an automatic IPv6 6to4 tunnel. Take a look at the following topology:

This scenario requires some more explanation. R1 and R3 each have a loopback0 interface with an IPv6 prefix on it. The FastEthernet interfaces of R1, R2 and R3 only have IPv4 addresses. The network engineer that designed this topology created an automatic 6to4 tunnel to establish connectivity between the two IPv6 networks. Of course this is not working so we’ll have some fixing to do.

I’ll show you the tunnel configuration from the running-config:

R1#show running-config | begin Tunnel0 interface Tunnel0 no ip address no ip redirects

ipv6 address 2002:A0A:A01::1/64 tunnel source FastEthernet0/0 tunnel mode ipv6ip 6to4R3#show running-config | begin Tunnel0interface Tunnel0 no ip address no ip redirects ipv6 address 2002:A14:1403::3/64 tunnel source FastEthernet0/0 tunnel mode ipv6ip 6to4

Above you can see the tunnel interfaces, they have been configured for 6to4 tunneling and there’s an IPv6 address on each tunnel. Let’s see if the tunnel works:

R1#ping 2001:1::3

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:1::3, timeout is 2 seconds:.....Success rate is 0 percent (0/5) R3#ping 2001:1::1

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:1::1, timeout is 2 seconds:.....Success rate is 0 percent (0/5)

A quick ping shows us that we can’t ping the IPv6 addresses on the loopback interfaces. So where should we start troubleshooting? Let’s check if R1 and R3 are able to reach each other:

R1#ping 192.168.23.3 source fastEthernet 0/0

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:Packet sent with a source address of 192.168.12.1 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms

The tunnel 0 interfaces are sourced from the FastEthernet 0/0 interfaces of R1 and R3. By sending a ping from R1 to R3 between the FastEthernet 0/0 interfaces I know that IPv4 routing is not the issue. Let’s take a closer look at the IPv6 addresses:

R1#show ipv6 interface brief FastEthernet0/0 [up/up]Loopback0 [up/up] FE80::CE09:25FF:FEB0:0 2001:1::1Tunnel0 [up/up] FE80::C0A8:C01 2002:A0A:A01::1R3#show ipv6 interface brief FastEthernet0/0 [up/up]Loopback0 [up/up] FE80::CE0B:25FF:FEB0:0 2001:1::3Tunnel0 [up/up] FE80::C0A8:1703 2002:A14:1403::3

Taking a quick look at the interfaces tells us that the IPv6 addresses on the loopback 0 interfaces have been configured correctly and that the interfaces are up and running. You can also see the IPv6 addresses on the tunnel 0 interfaces. What do the 2002:A0A:A01::1 and 2002:A14:1403::3 addresses mean?

Keep in mind that the tunnel mode is automatic 6to4. The “automatic” part means that the tunnel destination IP is not configured statically but within the IPv6 address. 2002::/16 is the range that is reserved for tunnels. Let’s see if we can ping these tunnel IPv6 addresses:

R1#ping 2002:A14:1403::3

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2002:A14:1403::3, timeout is 2 seconds:.....Success rate is 0 percent (0/5)R3#ping 2002:A0A:A01::1

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2002:A0A:A01::1, timeout is 2 seconds:.....Success rate is 0 percent (0/5)

We are unable to ping the IPv6 addresses on the tunnel 0 interfaces. This could mean that 2002:A0A:A01::1 and 2002:A14:1403::3 are not correct or that my routing is not working.

The tunnel should be built between IP address 192.168.12.1 and 192.168.23.3. If you want you can manually calculate from decimal to hexadecimal but there’s an easier method! Here’s how:

R1(config)#ipv6 general-prefix IAMLAZY 6to4 fastEthernet 0/0

We can let our router do the calculation from decimal to hexadecimal for us. Here’s the result:

R1#show ipv6 general-prefix IPv6 Prefix IAMLAZY, acquired via 6to4 2002:C0A8:C01::/48

There you go, the IPv6 address should be in this range 2002:C0A8:C01/48 so 2002:A0A:A01::1/64 on R1 is incorrect. Let’s fix it:

R1(config)#interface tunnel 0R1(config-if)#no ipv6 address 2002:A0A:A01::1/64R1(config-if)#ipv6 address 2002:C0A8:C01::1/64

We’ll remove the old IPv6 address and configure a new one in the 2002:C0A8:C01/48 range. Let’s see if the address on R3 is correct as well:

R3(config)#ipv6 general-prefix IAMLAZY 6to4 FastEthernet 0/0

Here’s the result:

R3#show ipv6 general-prefix IPv6 Prefix IAMLAZY, acquired via 6to4 2002:C0A8:1703::/48

The correct prefix is 2002:C0A8:1703::/48 so 2002:A14:1403::3 is not going to work. Let’s fix it:

R3(config-if)#no ipv6 address 2002:A14:1403::3/64R3(config-if)#ipv6 address 2002:C0A8:1703::3/64

We’ll remove the IPv6 address and configure another one that falls within the 2002:A14:1403::3 range.

Now we know that the IPv6 addresses on the tunnel 0 interfaces are correct. Next step is to check our routing to see if R1 and R3 know how to reach each other’s IPv6 addresses. Let’s check the routing tables:

R1#show ipv6 routeIPv6 Routing Table - 7 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2LC 2001:1::1/128 [0/0] via ::, Loopback0S 2001:1::3/128 [1/0] via 2002:A14:1403::3S 2002::/16 [1/0] via ::, Tunnel0C 2002:C0A8:C01::/64 [0/0] via ::, Tunnel0L 2002:C0A8:C01::1/128 [0/0] via ::, Tunnel0L FE80::/10 [0/0] via ::, Null0L FF00::/8 [0/0] via ::, Null0

There are two static routes here. The 2001:1::3/128 points to the loopback 0 interface of R3 but the next hop IPv6 address is 2002:A14:1403::3. This next hop is incorrect so we’ll have to change it. The static route for 2002::/16 to the tunnel 0 interface is fine. This prefix is reserved for tunneling and we need it because the router will do a recursive routing looking when it tries to reach 2001:1::3/128. Let’s fix it:

R1(config)#no ipv6 route 2001:1::3/128 2002:A14:1403::3R1(config)#ipv6 route 2001:1::3/128 2002:C0A8:1703::3

We’ll remove the old static route and create a new one with the correct next hop. Let's check R3 as well:

R3#show ipv6 routeIPv6 Routing Table - 7 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2S 2001:1::1/128 [1/0] via 2002:A0A:A01::1LC 2001:1::3/128 [0/0] via ::, Loopback0S 2002::/16 [1/0] via ::, Tunnel0C 2002:C0A8:1703::/64 [0/0] via ::, Tunnel0L 2002:C0A8:1703::3/128 [0/0] via ::, Tunnel0L FE80::/10 [0/0] via ::, Null0L FF00::/8 [0/0] via ::, Null0

R3 has the same issue. The static route with 2002::/16 to the tunnel0 interface is fine but 2001:1::1/128 has the old (and wrong) next hop. Time to fix it:

R3(config)#no ipv6 route 2001:1::1/128 2002:A0A:A01::1R3(config)#ipv6 route 2001:1::1/128 2002:C0A8:C01::1

After making these changes, let's see if there is connectivity between R1 and R3:

R3#ping 2001:1::1 source loopback 0

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:1::1, timeout is 2 seconds:Packet sent with a source address of 2001:1::3!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

There we go! A ping between the loopback 0 interfaces of R1 and R3 proves that they know how to reach each other’s prefixes…problem solved!

Lesson learned: Make sure you use the correct 6to4 tunnel IPv6 addresses and correct routes.

I hope this example has been useful, if you have any questions please leave a comment.

Cisco NAT64 Static ConfigurationIn this lesson we’ll take a look how to configure NAT64 so that an IPv4 host can communicate with an IPv6 host. Here’s the topology I will use:

On the left side we have R1 where we use IPv4, on the right side we use R3 which only uses IPv6.

R2 in the middle will be configured for static NAT64 so that these two routers can communicate with each other.

NAT64 is a bit more complicated than “regular” NAT that you know from IPv4. When we use IPv4 NAT for internet connectivity then you only need to translate the source address, with NAT64 we have to translate everything.

When we send a packet from R1 to R3, what destination address will we use? R1 only understands IPv4 and R3 only understands IPv6.

To make this work, R1 needs to think it’s talking to an IPv4 address and R3 needs to think it’s talking with an IPv6 address. We’ll need some “mapping” between addresses and protocols on our NAT64 router.

Let’s take a look how it works…

Configuration

I will configure everything from scratch, let’s start with the interfaces:

R1(config)#interface FastEthernet 0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0R2(config)#interface FastEthernet 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0

R2(config)#interface FastEthernet 1/0R2(config-if)#ipv6 address 2001:DB8:2323:2323::2/64R3(config)#interface FastEthernet 0/0R3(config-if)#ipv6 address 2001:DB8:2323:2323::3/64

That’s all we need. R2 will require unicast routing or it won’t do any NAT64 at all:

R2(config)#ipv6 unicast-routing

R3 will require a default route to R2, you’ll see why when we configure NAT64:

R3(config)#ipv6 route ::/0 2001:DB8:2323:2323::2

Before we configure NAT64, let’s do a quick test to make sure R2 can reach both routers:

R2#ping 192.168.12.1Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 msR2#ping 2001:DB8:2323:2323::3Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:DB8:2323:2323::3, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms

So far so good, now we can enable NAT64. First we have to enable it on the interfaces:

R2(config)#interface FastEthernet 0/0R2(config-if)#nat64 enableR2(config)#interface FastEthernet 1/0R2(config-if)#nat64 enable

Once you enable this you will see a syslog message that tells us that a virtual interface has been created:

%LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up

Now we can configure the actual translation rules. We will use a fake IPv4 address that R1 can use as its destination and a fake IPv6 address that R3 can use as its destination.

IANA has allocated prefix 64:FF9B::/96 for NAT64 translations. When R2 receives anything that starts with this prefix then it will be processed by NAT64. We can use this prefix or we can use another one, I’ll show you how to choose your own prefix:

R2(config)#nat64 prefix stateful 3001::/96

Now we can use prefix 3001::/96 for our translation.

Let’s configure the actual translation rule:

R2(config)#nat64 v6v4 static 2001:DB8:2323:2323::3 192.168.12.3

This tells R2 that whenever we receive an IPv4 packet with destination address 192.168.12.3 that it has to be translated and forwarded to 2001:DB8:2323:2323::3. Let's see if this works...

Verification

Before I try some pings, let's enable a debug. This allows us to see what source and destination addresses are used:

R1#debug ip icmp ICMP packet debugging is onR3#debug ipv6 icmp ICMP Packet debugging is on

Now let's send a ping from R1 to our fake IPv4 destination address:

R1#ping 192.168.12.3Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/16 ms

Great it's working, the debugs tell us what addresses were used:

R1#ICMP: echo reply rcvd, src 192.168.12.3, dst 192.168.12.1, topology BASE, dscp 0 topoid 0

R1 thinks it received a packet from 192.168.12.3. What about R3?

R3#ICMPv6: Received echo request, Src=3001::C0A8:C01, Dst=2001:DB8:2323:2323::3ICMPv6: Sent echo reply, Src=2001:DB8:2323:2323::3, Dst=3001::C0A8:C01

R3 thinks it's talking with 3001::C0A8:C01. Where did this address come from? The first part looks familiar, that's the 3001::/96 prefix that we configured. The last part is the IPv4 address of R1 in hexadecimal:

C0 = 192 A8 = 168 C = 12 1 = 1In case you are wondering, this works in both directions:

R3#ping 3001::C0A8:C01Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 3001::C0A8:C01, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

We can also use some show commands on R2 to verify things:

R2#show nat64 mappings static

Static mappings configured: 1

Direction Protocol Address (Port, if any) Non-key Address (Port, if any) RG ID Mapping ID Is Valid

v6v4 --- 2001:DB8:2323:2323::3 192.168.12.3 0 0 FALSE

Above you can see what we have configured. The next show command is a bit more interesting:

R2#show nat64 statistics NAT64 Statistics

Total active translations: 1 (1 static, 0 dynamic; 0 extended)Sessions found: 90Sessions created: 13Expired translations: 13Global Stats: Packets translated (IPv4 -> IPv6) Stateless: 0 Stateful: 63 MAP-T: 0 Packets translated (IPv6 -> IPv4) Stateless: 0 Stateful: 40 MAP-T: 0

Interface Statistics FastEthernet0/0 (IPv4 configured, IPv6 not configured): Packets translated (IPv4 -> IPv6) Stateless: 0 Stateful: 63 MAP-T: 0 Packets translated (IPv6 -> IPv4) Stateless: 0 Stateful: 0 MAP-T: 0 Packets dropped: 0 FastEthernet1/0 (IPv4 not configured, IPv6 configured): Packets translated (IPv4 -> IPv6) Stateless: 0

Stateful: 0 MAP-T: 0 Packets translated (IPv6 -> IPv4) Stateless: 0 Stateful: 40 MAP-T: 0 Packets dropped: 10Dynamic Mapping Statistics v6v4Limit Statistics

The output above shows us how many translations were done and in what direction. The last show command is the most interesting one:

R2#show nat64 translations

Proto Original IPv4 Translated IPv4 Translated IPv6 Original IPv6 ----------------------------------------------------------------------------

--- --- --- 192.168.12.3 2001:db8:2323:2323::3 icmp 192.168.12.1:15 [3001::c0a8:c01]:15 192.168.12.3:15 [2001:db8:2323:2323::3]:15

Total number of translations: 2

Above you can see the dynamically created 3001::C0A8:C01 address that was created.

Conclusion

NAT64 can be pretty complex and this is one of those "last resort" methods. You should probably always use dual stack and/or tunneling instead of trying to translate entire protocols.

IPv6 Multicast BSR and RP Example

Multicast for IPv6 can be configured using static RPs, BSR or embedded RP. In this example I want to show you how to configure IPv6 multicast using BSR. This is the topology that I will use:

Above we have 3 routers. R1 will be the receiver of the multicast stream, R2 will be the BSR and R3 will be the RP. First we’ll have to do our homework and configure all IPv6 addresses on the interfaces:

R1(config)#ipv6 unicast-routing R1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 address 2001:12::1/64R2(config)#ipv6 unicast-routing R2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 enableR2(config-if)#exitR2(config)#interface fastEthernet 1/1 R2(config-if)#ipv6 enableR2(config-if)#exitR2(config)#interface loopback 0R2(config-if)#ipv6 address 2001::2/128R3(config)#ipv6 unicast-routing R3(config)#interface fastEthernet 0/0R3(config-if)#ipv6 enableR3(config-if)#exitR3(config)#interface loopback 0R3(config-if)#ipv6 address 2001::3/128

With the IPv6 addresses up and running we can configure EIGRP to advertise the loopback interfaces of R2/R3 and the 2001:12::/64 network between R1/R2:

R1(config)#ipv6 router eigrp 1R1(config-rtr)#router-id 1.1.1.1R1(config-rtr)#no shutdownR1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 eigrp 1 R2(config)#ipv6 router eigrp 1R2(config-rtr)#router-id 2.2.2.2R2(config-rtr)#no shutdownR2(config)#interface loopback 0R2(config-if)#ipv6 eigrp 1R2(config-if)#exitR2(config)#interface fastEthernet 0/0R2(config-if)#ipv6 eigrp 1 R2(config-if)#exitR2(config)#interface fastEthernet 1/1R2(config-if)#ipv6 eigrp 1 R3(config)#ipv6 unicast-routing R3(config)#ipv6 router eigrp 1R3(config-rtr)#router-id 3.3.3.3R3(config-rtr)#no shutdownR3(config)#interface loopback 0R3(config-if)#ipv6 eigrp 1R3(config-if)#exitR3(config)#interface fastEthernet 0/0R3(config-if)#ipv6 eigrp 1

Because I don’t have any IPv4 addresses I have to configure an EIGRP router ID myself. With the configuration above the 2001:12::/64, 2001::2/128 and 2001::3/128 networks should be reachable from any router. Now we can continue with our multicast setup:

R1,R2 & R3:(config)#ipv6 multicast-routing

First enable multicast routing for IPv6 or we are going nowhere. Next step is to configure the RP and BSR:

R3(config)#ipv6 pim bsr candidate rp 2001::3

Use the ipv6 pim bsr candidate rp command to advertise R3 as the Rendezvous Point...

R2(config)#ipv6 pim bsr candidate bsr 2001::2

And R2 as the BSR...now we'll configure R1 to join a multicast group, I'll use FF07::7 for this example:

R1(config)#interface fastEthernet 0/0R1(config-if)#ipv6 mld join-group FF07::7

Let's see if R2 has found the RP:

R2#show ipv6 pim bsr rp-cache PIMv2 BSR C-RP Cache

BSR Candidate RP Cache

Group(s) FF00::/8, RP count 1 RP 2001::3 SM Priority 192, Holdtime 150 Uptime: 00:00:06, expires: 00:02:23

R2 sees R3 as the RP for the entire multicast group range. We can also take a look at the multicast routing table:

R2#show ipv6 mroute Multicast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/ExpiresInterface state: Interface, State

(*, FF07::7), 00:03:53/never, RP 2001::3, flags: SCJ Incoming interface: FastEthernet0/1 RPF nbr: FE80::C006:23FF:FE22:0 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:03:53/never

Above we see that R2 built a (*,G) entry for FF07::7 towards the RP. Let's generate some multicast traffic to see if it reaches R1:

R3#ping ff07::7

Output Interface: FastEthernet0/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to FF07::7, timeout is 2 seconds:Packet sent with a source address of 2001::3

Reply to request 0 received from 2001:12::1, 8 msReply to request 1 received from 2001:12::1, 8 msReply to request 2 received from 2001:12::1, 8 msReply to request 3 received from 2001:12::1, 4 msReply to request 4 received from 2001:12::1, 8 msSuccess rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms5 multicast replies and 0 errors.

There we go...R3 receives a reply from R1.

Documents

rms.koenig-solutions.comrms.koenig-solutions.com/.../Trainer/QMS/824-20191014… · Web viewIPV6 NOTES: Introduction to IPv6. In this lesson i’ll give you an introduction to IPv6