Tag Archives: CCIE

IPv6 Tunneling Part 3: Automatic 6to4 Tunnels

Hello Everyone,

We are now in Part 3 of this IPv6 Tunneling Series and we are about to talk the Automatic 6to4 Tunnels and how they work.

The first thing to understand here is that they are Point-To-Multipoint in nature (different to the first 2 methods of tunneling we saw on this series). This kind of tunnel will treat the IPv4 network as a NBMA network.

They work on a per packet basis in order to encapsulate the traffic to the correct destination (That’s the sole point of Point-To-Multipoint networks).

These tunnels get the right destination address by using the 2002::/16 prefix and the Router Border IPv4 address (Usually the WAN).

As you can see you will be using up to 48 bits till this point, that leaves you with 16 bits to play with in order to generate the subnets at your site.

Note: You can only have one automatic 6to4 tunnel in a Cisco IOS Box and you need to configure a static route to the 2002::/16 range pointing to the tunnel interface for routing to work.

Now it’s time to get the Lab started!!!!

 

 

 

Screen Shot 2015-07-29 at 4.32.24 PM Note: The LAN addresses were derived by the automatic 6to4 prefix. You will see how to obtain it later in this post.

 

As we see in the diagram we have 3 Routers (R1,R2 and R3)

  • R1 runs IPv6 in it’s Loopback 1 interface and IPv4 in it’s connection to R2
  • R2 only runs IPv4
  • R3 runs IPv6 in it’s Loopback 1 interface and IPv4 in it’s connection to R2
  • The idea of the Lab is to make sure the Loopback of R1 can communicate with the Loopback of R3

 

Now let’s get the configuration started:

 

The number one thing to do is to transform your IPv4 Border IP address (Decimal Notation) into Hex Notation so you can place it after the first 2002 (16 bits) in the IPv6 tunnel address.

So let’s focus on R1 first.

R1 Border IPv4 address Transformation to Hex:

R1: 12.0.0.1

 

Step 1) Transform each octet to binary

12 in binary is 00001100

0 in binary is 00000000

0 in binary is 00000000

1 in binary i is 00000001

 

Step 2) Split each of the binary results in 2 parts in order to transform it to Hex

12 in binary is 0000 1100

0 in binary is 0000 0000

0 in binary is 0000 0000

1 in binary is 0000 0001

 

Step 3) Write it down in hex format

0000 in hex is 0

1100 in hex is C (12)

0000 in hex is 0

0000 in hex is 0

0000 in hex is 0

0000 in hex is 0

0000 in hex is 0

0001 in hex is 1

 

Step 4) Put it all together in hex

12.0.0.1  then becomes 0C00:0001

 

Step 5) Finally add the 2001 at the beginning of the address

2002:0C00:0001::/48

 

There are several ways in the internet about how to transform Hex into Decimal, Decimal into Hex, Binary into Hex, etc but today my friend I will show you a Cisco IOS Tip for this.

There is an IOS command that will allow you to transform the IPv4 address into an IPv6 6to4 Tunnel IPv6 address.

Let’s actually run the command and see if it matches what our transformation result is:

R1(config)#ipv6 general-prefix WAN_Int 6to4 FastEthernet0/0 

Note: WAN_Int it’s just a name I wanted to use.

That’s it! Then if you run the show ipv6 general-prefix  you will get the right IPv6 address without having to manually determine it:

R1#sh ipv6 general-prefix

IPv6 Prefix WAN_Int, acquired via 6to4

  2002:C00:1::/48

NICEEEEE! There you have a free tip.

You can try to obtain yourself the IPv6 6to4 address of R3 based on it’s Border (Fa0/0) IPv4 address.

Now that we have the IPv6 address let’s move to the tunnel configuration:

R1

interface Tunnel1

no ip address

no ip redirects

ipv6 address 2002:0:1::1/64

tunnel source FastEthernet0/0

tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 tunnel 1

R3

interface Tunnel1

no ip address

no ip redirects

ipv6 address 2002:D00:1::1/64

tunnel source FastEthernet0/0

tunnel mode ipv6ip 6to4

ipv6 route 2002::/16 tunnel 1

Verification Stage:

Let’s try to ping from R3’s loopback to R1’s loopback and see how R3 is able to find out to what IPv4 address to send it.

R3#ping 2002:0c00:0001:1::1 source loopback 1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2002:C00:1:1::1, timeout is 2 seconds:

Packet sent with a source address of 2002:D00:1:1::1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/33/44 ms

That’s exactly how Automatic 6to4 tunneling work.

Regards,

Julio Carvajal

Dynamic GRE Tunnels Part 2

Hello to all of our followers,

It’s time to continue with the mGRE topic.

The last time we saw how the spokes were able to send traffic dynamically from spoke to spoke through the hub but now we will see how to make the Spokes talk to each other without having to go through the hub.

Here is the link to the previous post:

http://i-networks.us/dynamic-gre-tunnels-part-1

Let’s get started by sharing the topology we will be using today in our lab:

Screen Shot 2015-07-24 at 2.27.07 PM

 

It’s the same topology we use last time, the hub configuration it’s almost the same with only one change in mind.

I will share the config of the Hub first:

Hub (R1) Config

interface Tunnel1

ip address 10.10.10.1 255.255.255.0

no ip redirects

no ip next-hop-self eigrp 100

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 100

tunnel source FastEthernet0/0

tunnel mode gre multipoint

The only thing that should be new to you here is the no ip-next-hop-self command!

Remember that the whole purpose of this lab is to make the spokes to be able to talk to each other without going through the hub.

With EIGRP we have a problem for this scenarios as when you send an update outside one of your interfaces, that update will have the IP address on your interfaces as the NEXT-HOP IP and that would force the packets to be send trough you! We do not want that in our LAB so we need to add that command. We want the Spokes to learn the Updated from the other Spokes by having their own IP’s.

Let’s now move to the Spoke’s config:

R3 Config:

interface Tunnel1

ip address 10.10.10.3 255.255.255.0

no ip redirects

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp map multicast 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

R4 Config:

interface Tunnel1

ip address 10.10.10.4 255.255.255.0

no ip redirects

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp map multicast 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

Do you see the differences here?

Pretty simple, we just change the tunnel mode from a regular GRE mode to a mGRE and we removed the tunnel destination as we don’t need it to be statically defined as the hub anymore.

Now I will show the Routing Protocol Config on each router and then you will see how each Spoke learns the IP Networks

R1 (Hub)

router eigrp 100

network 10.0.0.0

network 192.168.10.0

no auto-summary

R3 (Spoke1)

router eigrp 100

network 10.0.0.0

network 192.168.20.0

no auto-summary

R4(Spoke2)

router eigrp 100

network 10.0.0.0

network 192.168.30.0

no auto-summary

Verfication Stage

Let’s go directly to the Spoke Routers and check the routing table

R3#sh ip route eigrp 100

D    192.168.30.0/24 [90/310172416] via 10.10.10.4, 00:07:22, Tunnel1

D    192.168.10.0/24 [90/297372416] via 10.10.10.1, 00:07:22, Tunnel1

R4#sh ip route eigrp 100

D    192.168.10.0/24 [90/297372416] via 10.10.10.1, 00:10:13, Tunnel1

D    192.168.20.0/24 [90/310172416] via 10.10.10.3, 00:07:28, Tunnel1

Awesome!! As you can see they can see each other routes with their own IP address.

Let’s send a ping packet and see the result

R3#ping 192.168.30.1 source 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.20.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 72/93/120 ms

If we go further on this lab we can check the NHRP Mapping Cache on each router:

R3#sh ip nhrp tunnel 1 brief            

   Target                     Via                   NBMA           Mode   Intfc   Claimed

10.10.10.1/32      10.10.10.1      1.1.1.1         static   Tu1     <   >

10.10.10.4/32      10.10.10.4      1.1.1.9         dynamic  Tu1     <   >

I bet you are asking how did R3 and R4 learn each other NBMA IP. In order to show you that I ran a debug NHRP cache in the Hub Router to obtain the NHRP Resolution request and Reply when R3 first tried to ping R4. All of this cause at the beginning R3 only knew the tunnel destination IP was 10.10.10.4 but who owns that tunnel IP?????

Here is the debug output:

R1#

“Here R3 send the ping and it’s trying to learn the NBMA IP address of 10.10.10.4″

*Mar  1 00:18:10.039: NHRP: Receive Resolution Request via Tunnel1 vrf 0, packet size: 68

*Mar  1 00:18:10.039:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.043:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.043:  (M) flags: “router auth src-stable”, reqid: 7

*Mar  1 00:18:10.043:      src NBMA: 1.1.1.5

*Mar  1 00:18:10.043:      src protocol: 10.10.10.3, dst protocol: 10.10.10.4

*Mar  1 00:18:10.043:  (C-1) code: no error(0)

*Mar  1 00:18:10.047:        prefix: 0, mtu: 1514, hd_time: 7200

*Mar  1 00:18:10.047:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar  1 00:18:10.047: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 96

*Mar  1 00:18:10.051:  src: 10.10.10.1, dst: 10.10.10.3

*Mar  1 00:18:10.051:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.051:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.051:  (M) flags: “router auth dst-stable unique src-stable”, reqid: 7

*Mar  1 00:18:10.051:      src NBMA: 1.1.1.5

*Mar  1 00:18:10.055:      src protocol: 10.10.10.3, dst protocol: 10.10.10.4

*Mar  1 00:18:10.055:  (C-1) code: no error(0)

*Mar  1 00:18:10.055:        prefix: 32, mtu: 1514, hd_time: 6981

*Mar  1 00:18:10.055:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar  1 00:18:10.055:        client NBMA: 1.1.1.9

*Mar  1 00:18:10.059:        client protocol: 10.10.10.4

“Here we can see R4 doing the same thing but for R3s NBMA IP”

*Mar  1 00:18:10.175: NHRP: Receive Resolution Request via Tunnel1 vrf 0, packet size: 68

*Mar  1 00:18:10.175:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.175:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.175:  (M) flags: “router auth src-stable”, reqid: 5

*Mar  1 00:18:10.175:      src NBMA: 1.1.1.9

*Mar  1 00:18:10.179:      src protocol: 10.10.10.4, dst protocol: 10.10.10.3

*Mar  1 00:18:10.179:  (C-1) code: no error(0)

*Mar  1 00:18:10.179:        prefix: 0, mtu: 1514, hd_time: 7200

*Mar  1 00:18:10.179:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar  1 00:18:10.183: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 96

*Mar  1 00:18:10.183:  src: 10.10.10.1, dst: 10.10.10.4

*Mar  1 00:18:10.183:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.187:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.187:  (M) flags: “router auth dst-stable unique src-stable”, reqid: 5

*Mar  1 00:18:10.187:      src NBMA: 1.1.1.9

*Mar  1 00:18:10.187:      src protocol: 10.10.10.4, dst protocol: 10.10.10.3

*Mar  1 00:18:10.187:  (C-1) code: no error(0)

*Mar  1 00:18:10.191:        prefix: 32, mtu: 1514, hd_time: 7147

*Mar  1 00:18:10.191:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar  1 00:18:10.191:        client NBMA: 1.1.1.5

*Mar  1 00:18:10.191:        client protocol: 10.10.10.3

And that’s how mGRE Tunnels work! I hope you enjoyed this post.

Regards,

Jcarvaja