Category Archives: Routing and Switching

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

IPv6 Tunneling Part 2: IPv6 Over IPv4 GRE Tunnels

Hello Followers,

 

In this post we will cover the second tunneling technique of this series of posts of IPv6.

This time we will transport our IPv6 traffic inside a GRE packet.

If you want to review the first tunneling technique, check our previous post about IPv6 tunneling.

 

2) IPv6 over IPv4 GRE Tunnels

The real benefit of running this type of tunnel is the fact that you will be able to encapsulate any traffic other than IPv6 and you will also have support for IPSec (if needed).

Just like the first type of VPN we talked about this are Point-To-Point in nature.

Now let’s get our hands dirty by configuring using the same Lab Scenario than before.

 

Screen Shot 2015-07-29 at 4.32.24 PM

 

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

 

 

R1

interface Tunnel1

no ip address

ipv6 address 2001:AAAA:AAAA:AAAA::1/64

ipv6 ospf 100 area 0

tunnel source FastEthernet0/0

tunnel destination 13.0.0.1

tunnel mode gre ip

R3

interface Tunnel1

no ip address

ipv6 address 2001:AAAA:AAAA:AAAA::3/64

ipv6 ospf 100 area 0

tunnel source FastEthernet0/0

tunnel destination 12.0.0.1

tunnel mode gre ip

As you can see the only difference relies in the command “tunnel mode gre ip“. Remember we are trying to encapsulate IPv6 inside an IPv4 GRE packet (that’s why we use tunnel mode gre ip and not tunnel mode gre ipv6).

Verification Stage:

We are still running OSPF between the sites as we did in the first part of this tunneling series and now it’s just time to test connectivity between the sites.

R3#ping 2001:AAAA:BBBB:CCCC::1 source loopback 1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:AAAA:BBBB:CCCC::1, timeout is 2 seconds:

Packet sent with a source address of 2001:BBBB:CCCC:DDDD::1

!!!!!

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

R3#sh ipv6 route 2001:AAAA:BBBB:CCCC::/64 longer-prefixes

IPv6 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 2

O   2001:AAAA:BBBB:CCCC::1/128 [110/11111]

     via FE80::C201:2FF:FE37:0, Tunnel1

R3#sh int tunnel 1

Tunnel1 is up, line protocol is up

  Hardware is Tunnel

  MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source 13.0.0.1 (FastEthernet0/0), destination 12.0.0.1

  Tunnel protocol/transport GRE/IP

That’s it!! We just tested connectivity and we also confirmed that the IPv6 traffic is being encapsulated by GRE/IP.

I hope you liked this post.

Regards,

Jcarvaja

IPv6 Tunneling Part 1: Manually Configured Tunnels

Hello,

Today’s topic will be the IPv6 transition technique of using IPv6 tunnels to communicate IPv6 hosts over IPv4 networks.

There are several methods available to make this happen and we will cover each of them to the point we are comfortable with the way they work.

It’s important to say that we will use this mechanism in order to run both IPv6 and IPv4 in our networks and have dual-stack support in our network equipment it’s a MUST.

The way it works consists on encapsulating the IPv6 data traffic in an IPv4 data packet.

Here is the Lab we will be using for today’s scenarios

 

Screen Shot 2015-07-29 at 4.32.24 PM

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

 

1) Manually Configured IPv6 Tunnel 

This tunneling technique is point to point in nature and it’s gonna require to statically configure the tunnel destination IP address in the Tunnel interface.

In fact if you know how to configure a regular GRE tunnel interface then you will know how to do this pretty fast as it requires the same steps. The only difference being that the IP address of the tunnel interface will be an IPv6 address and of course the tunnel mode.

For our scenario the tunnel IPv6 address will be 2001:AAAA:AAAA:AAAA::/64

Configuration 

Note: Basic Routing and IP address information has been already configured on each router (Only the relevant information will be shown in the next examples).

R1 

interface Tunnel1

no ip address

ipv6 address 2001:AAAA:AAAA:AAAA::1/64

tunnel source FastEthernet0/0

tunnel destination 13.0.0.1

tunnel mode ipv6ip

 

R3

interface Tunnel1

no ip address

ipv6 address 2001:AAAA:AAAA:AAAA::3/64

tunnel source FastEthernet0/0

tunnel destination 12.0.0.1

tunnel mode ipv6ip

That’s all the configuration we need in order for the IPv6 tunnel to come up.

If you try to ping from R3 tunnel interface to the R1 tunnel interface you will have a success result. We can see it here:

R3#ping 2001:AAAA:AAAA:AAAA::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:AAAA:AAAA:AAAA::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/41/52 ms

To finish this lab we need to configure a static route towards the other side IPv6 subnet pointing the tunnel interface or configuring a Dynamic Routing Protocol.

We will use OSPFv3  for this

R1

interface loopback 1

ipv6 ospf 100 area 0

  int tunne 1

  ipv6 ospf 100 area 0

R3

interface loopback 1

ipv6 ospf 100 area 0

  int tunne 1

  ipv6 ospf 100 area 0

Note: ipv6 unicast-routing is already running on R1 and R3.

Afterwards OSPF will come up and will build a neighbor relationship where the IPv6 subnets will be exchanged via the respective LSAs and the routing tables will be populated for the IPv6 protocol

Verification Stage

R1#sh ipv6  ospf  neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface

13.0.0.1          1   FULL/  -        00:00:35    11              Tunnel1

R3#sh ipv6  ospf  neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface

12.0.0.1          1   FULL/  -        00:00:38    11              Tunnel1

Finally it’s time to ping from the Loopback interface on R1 to the Loopback interface on R3.

R1#ping 2001:BBBB:CCCC:DDDD::1 source loopback 1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:BBBB:CCCC:DDDD::1, timeout is 2 seconds:

Packet sent with a source address of 2001:AAAA:BBBB:CCCC::1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/29/36 ms

That’s it! The first tunneling technique (and the easiest one) is covered and working.

In our IPv6 Tunneling Part 2 we will cover the IPv6 over IPv4 GRE tunnel method.

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

Dynamic GRE Tunnels Part 1

Hello to all of our followers,

Today’s post involves GRE Tunnels but this time  we will focus on the scenarios where we can run a dynamic GRE tunnel.

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

 

Scenario 1. All traffic going through the Hub

 

In this scenario we have 3 sites separated by a Service Provider, one of this sites (R1) is the Headquarters of our business and it will be running as a Hub.

All traffic from Spokes (R3-R4) will need to go through the Hub for security reasons.

Due to the fact we will be adding a lot of spokes in the future we want to avoid the creation of multiple GRE Tunnel interfaces and instead just use one Dynamic GRE tunnel Interface.

Here is how we get this working.

Note: Only the relevant information will be shown

R1 (Hub) Configuration:

interface Tunnel1

ip address 10.10.10.1 255.255.255.0

no ip redirects

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 100

tunnel source FastEthernet0/0

tunnel mode gre multipoint

This configuration in the tunnel interface will allow us to have more than one spoke registered to this specific tunnel interface (no additional IPv4 addresses will be waisted).

Let’s now talk about the commands inside the interface

The first thing you need to understand is that when we talk about the NBMA address we are talking about the tunnel source IP address on the tunnel interface of a router.

It’s important to recall that we need to enter the tunnel mode of GRE multipoint as the default it’s simple GRE (Point-To-Point)

The command ip nhrp map multicast dynamic  allow the router to send Broadcast or Multicast traffic to the NBMA address over the tunnel network.

You can also check there is no tunnel destination address, this happens because we will have multiple destinations that will register dynamically to it.

Before talking about the no ip split-horizon eigrp 100 we need to think about how the traffic will flow through this network.

Traffic from Spoke R3 LAN to Spoke R4 LAN or backwards needs to go through the Hub (as per the Scenario Requirements).

So let’s imagine a PC behind R3 LAN sends ICMP packets to a Server behind R4 LAN. That traffic will enter R1’s Multipoint GRE tunnel interface and do a U-Turn to go out the same Multipoint GRE Tunnel interface heading to R4’s Server.

There is a concept known as Split-Horizon that says that ” in order to prevent routing loops if I receive a network update on interface “X” that network update cannot go out the same interface”.

In this scenario we are going to hit this loop prevention engine so we need to make sure split-horizont is disabled on that interface for the EIGRP AS  we are running.

Here is R1’s EIGRP Config

router eigrp 100

network 10.0.0.0

network 192.168.10.0

no auto-summary

It’s time to move to the Spokes Config:

R3 (Spoke1) Config 

interface Tunnel1

ip address 10.10.10.3 255.255.255.0

ip nhrp map multicast 1.1.1.1

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel destination 1.1.1.1

 Let’s try to decode this interface configuration:

We have the tunnel destination command as we know all traffic will flow through the hub.

We are mapping all multicast/broadcast traffic to the NBMA IP address in the hub router (ip nhrp map multicast 1.1.1.1)

We also map the Tunnel Interface IP address to the NBMA IP address in the hub router (ip nhrp map 10.10.10.1 1.1.1.1)

Finally we also set manually the next hop server IP to the Tunnel interface of the hub (ip nhrp nhs 10.10.10.1)

Note: Remember that the ip nhrp network-id it’s just an identifier.

The same config it’s gonna be used in R4’s except for the IP address in the tunnel interface.

R4 (Spoke2) Config

interface Tunnel1

ip address 10.10.10.4 255.255.255.0

ip nhrp map multicast 1.1.1.1

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel destination 1.1.1.1

The Routing Protocol config it’s pretty simple on both sides, just advertise the Tunnel Interface subnet and the LAN subnet.

Verification Stage

Now that we have configured our lab it’s time to make sure everything works in our network.

Let’s go to our hub router and check the EIGRP Neighbor relationships, the routing table and the NHRP mappings.

R1#sh ip nhrp brief

   Target             Via            NBMA           Mode   Intfc   Claimed

10.10.10.3/32      10.10.10.3      1.1.1.5         dynamic  Tu1     <   >

10.10.10.4/32      10.10.10.4      1.1.1.9         dynamic  Tu1     <   >

R1#sh ip eigrp neighbor

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.10.10.4              Tu1               14 00:43:14 1129  5000  0  14

0   10.10.10.3              Tu1               11 00:43:15   41  5000  0  12

IP-EIGRP neighbors for process 10

R1#sh ip route eigrp 100

D    192.168.30.0/24 [90/297372416] via 10.10.10.4, 00:43:27, Tunnel1

D    192.168.20.0/24 [90/297372416] via 10.10.10.3, 00:43:27, Tunnel1

Excellent! At the Hub level everything seems perfect so it’s time to test connectivity from Spoke 3 LAN to Spoke 4 LAN.

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 = 96/149/188 ms

AWESOME!!! Now let’s do the same but while we run a debug IP Packet Detail in the hub router! I mean the traffic it’s supposed to go through it so we should see it, right?

Well, let’s confirm it:

R1#debug ip packet detail 100

note: the IP access-list 100 makes reference to all ICMP traffic.

We run the same ping from R3 LAN to R4 LAN and we get the following output at R1

*Mar  1 01:13:11.835: IP: tableid=0, s=192.168.20.1 (Tunnel1), d=192.168.30.1 (Tunnel1), routed via FIB

*Mar  1 01:13:11.835: IP: s=192.168.20.1 (Tunnel1), d=192.168.30.1 (Tunnel1), g=10.10.10.4, len 100, forward

*Mar  1 01:13:11.839:     ICMP type=8, code=0

*Mar  1 01:13:11.935: IP: tableid=0, s=192.168.30.1 (Tunnel1), d=192.168.20.1 (Tunnel1), routed via FIB

*Mar  1 01:13:11.935: IP: s=192.168.30.1 (Tunnel1), d=192.168.20.1 (Tunnel1), g=10.10.10.3, len 100, forward

*Mar  1 01:13:11.939:     ICMP type=0, code=0

The ICMP Echo and Echo-Reply are flowing through the Hub’s Tunnel 1 interface.

Mystery solved and our customer scenario us up and running.

Stay tuned for our second part of Multipoint GRE Tunnels where we will talk about how to send traffic from Spoke 1 to Spoke 2 without going through the hub.

Regards,

Julio Carvajal

CCIE #42930, 2xCCNP, JNCIS-SEC

GRE Point-To-Point Configuration

So Today I have sometime to write about the GRE Fundamentals and how it works.

Let’s get started!

The Generic Encapsulation Protocol (GRE) it’s the IP protocol number 47 and it’s beauty relies in the fact that it allows to encapsulate a different variety of IP network layer protocols into a GRE Tunnel.

When do we need to run GRE tunnels?

There might be times where you cannot send “X” protocol over a network cause it’s not supported or even allowed.

With GRE you could send the “X” protocol encapsulated into a GRE header in order to let it go through.

Configuration Fundamentals:

Point-To-Point-GRE Tunnel Scenario

Screen Shot 2015-07-15 at 9.54.03 AM

In this lab we have LAN-A and LAN-B separated by an ISP.

We want to communicate between those 2 subnets using a Routing Protocol but the ISP is not willing to run a Dynamic Routing Protocol.

GRE is here to save us! We can build a GRE tunnel between R1 and R3 and then inside that GRE tunnel run a Dynamic Routing Protocol.

Let’s do it

First R1:

interface Tunnel1

ip address 1.1.1.1 255.255.255.252

tunnel source FastEthernet0/0

tunnel destination 3.3.3.1

Next R3:

interface Tunnel1

ip address 1.1.1.2 255.255.255.252

tunnel source 3.3.3.1

tunnel destination 2.2.2.1

 NOTE: For this to work connectivity between 2.2.2.1 and 3.3.3.1 MUST exist (Otherwise the tunnel will never come up).

Verification commands:

R3#sh ip int brief | ex unassigned 

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            3.3.3.1         YES manual up                    up      

Loopback1                  192.168.20.1    YES manual up                    up      

Tunnel1                    1.1.1.2         YES manual up                    up

Now let’s get the routing over the tunnel configured in such a way both Subnets are reachable through the tunnel interface 1.

R1

router ospf 1

log-adjacency-changes

network 1.1.1.0 0.0.0.3 area 0

network 192.168.10.0 0.0.0.255 area 0

R3

router ospf 10

log-adjacency-changes

network 1.1.1.0 0.0.0.3 area 0

network 192.168.20.0 0.0.0.255 area 0

Afterwards we can see the OSPF neighbor relationship is formed and both routers know that to reach each other Subnets need to send the traffic via the tunnel.

R1#sh ip ospf  neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.20.1      0   FULL/  -        00:00:37    1.1.1.2         Tunnel1

R1#sh ip route 192.168.20.0

Routing entry for 192.168.20.0/32, 1 known subnets

O       192.168.20.1 [110/11112] via 1.1.1.2, 03:17:29, Tunnel1

R3#sh ip ospf  neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.10.1      0   FULL/  -        00:00:37    1.1.1.1         Tunnel1

R3#sh ip route 192.168.10.0

Routing entry for 192.168.10.0/32, 1 known subnets

O       192.168.10.1 [110/11112] via 1.1.1.1, 03:18:07, Tunnel1

Finally let’s test the reachability between both sites

R3#ping 192.168.10.1 source 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.10.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 = 20/41/48 ms

That’s it! Reachability has been tested through a GRE tunnel that is tunnelling OSPF packets.

Regards,

Jcarvaja

Spanning-Tree MST “Shr Bound(PVST)” Tree

I have came across an issue lately where one of my customers was reporting that a specific port on their switch while running the command show spanning-tree vlan # shown a different port-type than the rest of them.

The output was something like:

SW1#sh spanning-tree vlan 13

MST1
Spanning tree enabled protocol mstp
Root ID Priority 24577
Address aabb.cc00.0600
This bridge is the root
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Address aabb.cc00.0600
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–

Et3/3 Desg FWD 2000000 128.100 Shr
Po12A Desg FWD 1000000 128.515 Shr Bound(PVST)

Customer was concerned about it and if it could create loops on the l2 network.

The flag being shown there basically let us know that the Port-Channel 12 has determined that it connects to a device running PVST so its basically an MST Region Boundary Port.

As simple as that.

MST is able to identify that a neighbor switch is running PVST as soon as it determine the neighbor it’s on a different region or if it receives legacy 802.1d BPDUs from that neighbor.

This does not means that a loop will happen as this 2 protocols can co-exist but if you have access to the other box you can go ahead and enable MST on the other side.

As soon as you do that you should see the following output instead:

SW1#sh spanning-tree vlan 13

MST1
Spanning tree enabled protocol mstp
Root ID Priority 24577
Address aabb.cc00.0600
This bridge is the root
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Address aabb.cc00.0600
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–

Po12A Desg FWD 1000000 128.515 Shr

Regards,

iNetworks

Spanning-Tree MST “Shr Bound(PVST)”tree

I have came across an issue lately where one of my customers was reporting that a specific port on their switch shown a different port-type than the rest of them.

The output was something like:

SW1#sh spanning-tree vlan 13

MST1
Spanning tree enabled protocol mstp
Root ID Priority 24577
Address aabb.cc00.0600
This bridge is the root
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Address aabb.cc00.0600
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Interface Role    Sts         Cost              Prio.Nbr            Type
——————- —- — ——— ——– ——————————–

Et3/3     Desg      FWD   2000000   128.100             Shr
Po12A     Desg    FWD   1000000   128.515              Shr Bound(PVST)

Customer was concerned about it and if it could create loops on the l2 network.

The flag being shown there basically let us know that the Port-Channel 12 has determined that it connects to a device running PVST so its basically a MST Region Boundary Port. As simple as that.

MST is able to identify that a neighbor is running PVST as soon as it determine the neighbor it’s on a  different region or if it receives legacy 802.1d BPDUs from that neighbor.

This does not means that  a loop will happen as this 2 can co-exist but if you have access to the other box you can go ahead and enable MST on the other side.

As soon as you do that you should see the following output instead:

SW1#sh spanning-tree vlan 13

MST1
Spanning tree enabled protocol mstp
Root ID Priority 24577
Address aabb.cc00.0600
This bridge is the root
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Address aabb.cc00.0600
Hello Time 2 sec Max Age 30 sec Forward Delay 15 sec

Interface Role    Sts         Cost              Prio.Nbr            Type
——————- —- — ——— ——– ——————————–

Po12A    Desg    FWD      1000000   128.515            Shr

 

Regards,

 

iNetworks

MPLS The Fundamentals Part 1

Hello to All,

MPLS is one of those protocols that you must know if you attempt to reach the CCIE Level Knowledge in your career, is one of those topics that will give you a really hard time at the beginning while you understand how it operates, the different flavors available but once you understand it you will see it’s just Mind-Blowing.

This is exactly why I wanted to write down a introduction blog post about it (Don’t worry.. This is just the beginning of our MPLS series).

Why would you implement MPLS?? I mean is there a need for it? Is it a routing protocol?

Those are the kind of questions that people new to MPLS ask themselves and they are completely valid. I actually asked myself those same questions (and a whole bunch of other questions about it).

MPLS define a new way of transporting traffic across a network. It uses Labels in order to determine where to send the traffic.

In order to transmit this labels there is a need for a protocol and that is LDP (The Label Distribution Protocols that runs on top of TCP 646).

As soon as you enable MPLS and LDP you will start announcing labels for all of your known routes.

That’s right we are going to look at something different than the routing table. We will look at the MPLS Forwarding-Table

So MPLS uses labels.. big deal… What’s the benefit of that??

Well, one of the major benefits is the fact that now L3 devices will perform a quicker decision about whenever they need to send a packet.

For example in your LAN if you wanted to send a packet to Google’s web servers you will need to check your routing table for the destination IP Address  and then check for the Next-Hop IP address and Mac-Address of that next hop (CEF Forwarding Table lookup is actually quicker as it gets both in just one step). This process will happen from source to destination.

With MPLS you would check for the destination IP address and if you reach that destination via an interface where MPLS is enabled you will route the packets using Labels.  The Huge benefit of it is that the next routers inside the MPLS cloud will not perform that check, they will only look at the label and they will determine where to send the traffic! As simple as that folks.

Another benefit of MPLS is the possibility of running  what is known as the “Free BGP Core

MPLS BGP Free Core

In that scenario shown above we have 2 Offices that are connected via an MPLS Cloud (PE1,P1,P2,PE2). Do not worry we will explain what that means in the next blog post about MPLS.

Without running MPLS if CE1 and CE2 wanted to communicate with each other, all of the routers across the MPLS cloud (ISP) would need to know about their networks in order to route the packet properly.

With MPLS and BGP that will not be needed! what I am about to tell you is just AMAZING!!

If you configure PE1 and PE2 via a BGP neighborhood through the MPLS cloud they will exchange the prefixes between each other and all the PE routers need to have is an MPLS label to send the traffic to PE1 and PE2.

So as long as the P1 and P2 have a label for the ip address of PE1 and PE2 (Next-Hops) we will be able to route traffic.

Imagine if you have a hundred subnets on your Network and you need to announce it to a remote location! The routing table of the devices in the ISP will growth a lot but if you run MPLS all they will need to know is how to reach your router.

So to understand it better let’s use our scenario as an example.

  1. PE1-P1-P2-PE2 are running EIGRP as the IGP protocol between each other so they all know how to reach each other.
  2. MPLS and LDP has been enabled on all of the links between this routers  (Between CE1-PE1 and CE2-PE2 MPLS-LDP is disabled).
  3. PE1 and PE2 build a BGP relationship and they exchange the prefixes learn with CE1 and CE2 respectively.
  4. P1 and P2 have no knowledge of this routes.

Without MPLS as soon as P1 receives a packet from CE1 to CE2 it would drop it as it does not have an entry on it’s routing table for any of those two devices.

With MPLS the forwarding logic would be as follows:

  • CE1 sends a packet to CE2 IP address using the regular IP routing lookup and forwarding decisions.
  • PE1 looks for the destination IP address which is the BGP peer PE2. It determines that the next hop is available via an interface where MPLS-LDP is enabled so it needs to route the packet based on the MPLS forwarding table (Where the mapping for IP-Addresses and label are).
  • It sends the packet with the MPLS label in order to reach PE2.
  • P1 receives it and check the label that was used to forward the packet and sends the packet to that same next hop again using the label (Look that P1 did not look at any IP address, it just received an MPLS label packet and forwarded an MPLS label packet).
  • Same process happen till reaches PE2.
  • When PE2 receives it with a Label of “X” it will check at is MPLS forwarding table to determine where to send it as any other router in the MPLS core has done and will determine that there is no label to be imposed to that packet but instead needs to be forwarded to an IP network.
  • The label will be remove and then will be normally send over an IP network.

That’s the magic behind MPLS and BGP Free Core.

There other many benefits or running this wonderful protocol such as L2VPNs, MPLSVPN, Traffic Engineering but that will be covered on a future blog post.

So bottom line:

  • Packets will now have a MPLS label field that will allow the transmission of MPLS packets over an IP network.
  • Routers do not need to look a the Destination IP address but only at the label.

 

Regards,

 

iNetworks

Multicast BGP

Hello,

 

In this post I will cover what is known as “Multicast BGP” , why it’s used for and how to configure it.

 

This is one of the topics that if by any chance you encounter it in the CCIE lab you are going to get mad as you might not seeing it in the past or at least provide it the attention needed to such an easy topic but let’s start with the basics: It’s usage.

 

Multicast BGP exist to fix the RPF failures on the network. As simple as that! You can build a BGP relationship between two routers in order to build a Multicast topology that will satisfy the network requirements that the IGP protocols did not satisfy and of course the CCIE did not allow you to create any Mroute.

 

So now that we know why to use it let’s show you our scenario today.

Multicast BGP

 

  • All of the routers are running OSPF as the IGP protocol.
  • There is full reachability across the entire  network.
  • PIM Sparse-Mode will be used.
  • R5 will be the RP Multicast Router (Using loopback 5.5.5.5).
  • R5-R4 have 2 links connecting each other (one is  a FastEthernet link and the other a Ethernet port).
  • The multicast group is 239.1.1.1
  • R5 and R4 are not running PIM on the 100 Mbps link.

 

So where does Multicast BGP fits here????

 

Well check the connections between R5 and R4.

  1. There are two links running OSPF but only one is running PIM.
  2. OSPF uses bandwidth as the metric for path calculation (higher bandwidth = Better metric) .

 

What route do you think R4 will choose to get to either the RP  address or R1 (source of traffic)?

 

Let’s check the routing table of R4 to determine that:

R4#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via “ospf 1″, distance 110, metric 2, type intra area
Last update from 192.168.30.1 on FastEthernet0, 00:01:33 ago
Routing Descriptor Blocks:
* 192.168.30.1, from 192.168.40.1, 00:01:33 ago, via FastEthernet0
Route metric is 2, traffic share count is 1

R4#sh ip route 192.168.10.0
Routing entry for 192.168.10.0/24
Known via “ospf 1″, distance 110, metric 21, type intra area
Last update from 192.168.30.1 on FastEthernet0, 00:01:38 ago
Routing Descriptor Blocks:
* 192.168.30.1, from 192.168.20.1, 00:01:38 ago, via FastEthernet0
Route metric is 21, traffic share count is 1

Of course the one with the higher Bandwidth. The problem lies on the fact that PIM is not enabled on that link so any multicast packet received over the link ethernet 0 will be dropped.

R4#sh ip rpf 192.168.10.1
RPF information for ? (192.168.10.1) failed, no route exists
R4#sh ip rpf 5.5.5.5
RPF information for ? (5.5.5.5) failed, no route exists
R4#

 

How to Fix it?

 

Well that’s the whole idea of this post, using Multicast BGP as the routing protocol that will be the source of the Multicast Topology information for R4-R5.

 

Configuration Tasks:

  1. Enable a BGP process and the right neighborhood (BGP Session must be enabled using the interfaces where PIM is enabled)
  2. Establish a BGP session over the multicast address-family.
  3. Make sure you announce the required networks over the BGP session (Make sure you can reach the RP and the Multicast Source).

 

Step 1 and 2 BGP session between the routers where the RPF Failure happens using the Multicast address family.

R5

router bgp 100
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 192.168.40.2 remote-as 100
!
address-family ipv4 multicast
neighbor 192.168.40.2 activate
no auto-summary
no synchronization
network 5.5.5.5 mask 255.255.255.255
network 192.168.10.0
exit-address-family

 

R4

router bgp 100

no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 192.168.40.1 remote-as 100

!
address-family ipv4 multicast
neighbor 192.168.40.1 activate
no auto-summary
no synchronization
exit-address-family

 

We have disabled the bgp ipv4-unicast process so no sessions are established using the unicast routing table of the devices. We are already running IGP to populate the unicast routing table so no need for this.

 

We must only focus on the Multicast routes.

 

Let’s check if the session was build

R4#sh ip bgp (This command only shows sessions established via the IPv4 unicast database so it’s expected to see no entries)

R4#sh ip bgp all summary (Will show you sessions from all of the address families used in your router)

For address family: IPv4 Multicast
BGP router identifier 7.7.7.7, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 234 bytes of memory
2 path entries using 96 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.40.1 4 100 10 8 3 0 0 00:05:15 2

 

Now that the session got successfully established it’s time to fix the RPF issue.

 

!Remember that the problem in this lab is that R4 is learning via IGP the IP address of the RP and the source of the multicast traffic but all of this via the link with the highest bandwith (100 Mbps). Problem is that PIM is not enabled on that link and we are not allow to do it.

 

R5  will announce the routes that are failing the RPF check via multicast BGP  and as soon as R4 receives them, they will be considered válid.

 

router bgp 100

address-family ipv4 multicast

neighbor 192.168.40.2 activate
no auto-summary
no synchronization
network 5.5.5.5 mask 255.255.255.255
network 192.168.10.0
exit-address-family

 

After those announcements R4 RPF issues will fade away

On R4

 

R4# sh ip rpf 5.5.5.5
RPF information for ? (5.5.5.5)
RPF interface: Ethernet0
RPF neighbor: ? (192.168.40.1)
RPF route/mask: 5.5.5.5/32
RPF type: mbgp
RPF recursion count: 0
Doing distance-preferred lookups across tables
R4#sh ip rpf 192.168.10.1
RPF information for ? (192.168.10.1)
RPF interface: FastEthernet0
RPF neighbor: ? (192.168.50.1)
RPF route/mask: 192.168.10.0/24
RPF type: mbgp
RPF recursion count: 0
Doing distance-preferred lookups across tables
R4#

 

Time to test the Multicast Network:

R1#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.40.2, 308 ms

 

That’s it! We have successfully re converged our network without modifying the IGP metrics, setting a static Mroute or enabling PIM on all links.

 

Additional Stuff:

While doing the lab I tried to build the BGP multicast session using as source and remote IP the loopbacks of each R5 and R4. The results were the following:

  • The BGP session was established for the Multicast family as needed.
  • The BGP prefixes were announced.
  • RPF Failure fade away as well (I was able to do a show ip rpf 5.5.5.5 and get a succesful result) but pointing via the 100 Mbps.
  • PIM is still not enabled on that link so Multicast traffic will not flow so this will not work.
  • We must use an IP address that forces both peers to send traffic via the PIM Sparse link.

 

Regards,

iNetworks