All posts by jcarvaja

IGMP Notes

Hello,

This will be a series of notes about IGMP that you should know in case you are about to deploy Multicast or just studying Multicast.

  • IGMP allows host to inform routers they want to receive multicast traffic for a specific multicast group or leave a specific multicast group
  • IGMP V2 Membership Query (Type Code 0x11) and V1 Membership Report (Type Code Ox12) allows backward compatibility between IGMPv2 and IGMPv1.
  • The default version used by Systems is V2.
  • The IGMP Maximum Response Time (MRT) allows a router to define the response time for a host membership report.
  • A host when running multicast will join the 224.0.0.1 group and the specific group it wants to participate. It will also start hearing on a specific MAC address per group that will be created based in the 01-00-5e-XX-XX-XX (where the bold part is the Multicast Identifier and the XX-XX-XX are the last 23 bits of the IPv4 address).
  • If there are more than one IGMP Querier Router in a LAN, the one with the Lowest IP address is the one that will send the IGMP Queries.
  • IGMPv2 Query Interval: 60 seconds (Time Period Between General Queries sent by a router).
  • IGMPv2 Query Response Interval: 10 seconds (MRT for a host to respond to general queries).
  • IGMPv2 Group Membership Interval: 260 seconds (Timer where if a router does not receive an IGMP report concludes that there are no more listeners for that Multicast Group).
  • IGMPv2 Other Querier Present Interval: 255 seconds (Timer where if the non-querier router in a LAN does not receive an IGMP query it will determine the querier router is dead and will take over).
  • IGMPv3 adds more security (It will allow devices to join a group based on their source IP address), this feature is called Source Specific Multicast (SSM).

 

This is just a quick summary of IGMP Notes that you can have handy in case you are studying the topic.

 

Regards,

Jcarvaja

IPv6 Tunneling Part 4: ISATAP Tunnels

Hello Followers,

Today will be our last post about IPv6 Tunneling techniques, the topic will be ISATAP Tunnels.

ISATAP stands for Intra-Site Automatic Tunnel Addressing Protocol and just like the Automatic 6to4 it treats the IPv4 network as a NBMA network (so point-to-multipoint).

Now, the question is how do you obtain the IPv6 address for the tunnel interface for an ISATAP tunnel?

There is an address scheme you should follow:

64-bit link local or global unicast prefix:0000:5EFE:IPv4 address of the ISATAP Link

The bold part is the ISATAP Identifier.

Screen Shot 2015-07-24 at 2.27.07 PM

 

 

So let’s now transform the R1 F0/0 interface IPv4 address into the ISATAP Address Scheme.

 

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 64 Global Unicast Address and the ISATAP Identifier you want to use at the beginning of the address.

2001:AAAA:BBBB:CCCC:0C00:0001:0C00:0001/128

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

Kali SSH Access

Hello Followers,

By default when you install Kali the SSH Daemon it’s not gonna allow any connection via this protocol as it’s not enabled!

In this post I will show you how to make sure the SSH Daemon it’s already installed in your PC and how to enable it for remote access in the best possible way.

As our Kali version 1.1.0 runs over Debian we can use the dpkg command as this is a package manager for this Linux Distribution to find out whether OpenSSH it’s installed in our server or not.

root@kali-Jcarvaja:~# dpkg -s openssh-server
Package: openssh-server
Status: install ok installed

As we can see the package it’s installed but what if the package it’s not installed?

Then get the right package:

root@kali-Jcarvaja~:# apt-get install openssh-server

After you have that done you would like to make sure that SSH it’s enable persistenly (meaning even if the Server it’s rebooted).

In order to make that happen run the following commands:

root@kali-Jcarvaja:~# update-rc.d -f ssh remove

root@kali-Jcarvaja:~# update-rc.d -f ssh defaults

These last 2 commands are going to disable the current run levels being used by the SSH Process and start using the default run levels.

After you have this done you can change the RSA keys being used by this protocol but first you will make sure you save a copy of the default RSA keys.

root@kali-Jcarvaja:~# cd /etc/ssh

root@kali-Jcarvaja:/etc/ssh# mkdir default_kali_keys

root@kali-Jcarvaja:/etc/ssh# mv ssh_host_* default_kali_keys/

In the first command shown we just move to the ssh container and then we create a folder name default_kali_keys.

This is exactly where we want to backup our host SSH default keys and we use the command mv to move that RSA key to the previously created container.

We can then move to the creation of the new key  set

root@kali-Jcarvaja:/etc/ssh# dpkg-reconfigure openssh-server

And finally you restart the SSH daemon
root@kali-Jcarvaja:/etc/ssh# service ssh restart

 

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

Enabling AAA New-Model Must Know

Hello Followers,

I received an email from a Cisco user that goes as follows:

Can you use the password configured on a VTY line as the method of authentication when AAA is enabled??

Here is the answer:

A/ Yes, this can be done and it’s in fact a best practice if you enable AAA authentication on a device but you do not want to use any authentication method-list for the VTY lines or Console ones.

Example:

Let’s say we enabled AAA on our router as we are planning to configure dot1x authentication in our network.

aaa new-model

aaa authentication dot1x test group radius

Cool, we just enabled aaa new-model but what’s up with that?

In the background a few things will happen:

As soon as we enable aaa-new model, all of the lines (except for the console) will start using local authentication even if you have a password set into the vty lines.

For example:

What if we do not have a username or password defined?

Well.. you will not be able to login without one!

So when you enable aaa new-model make sure you have a username and password locally defined or make sure you are not going to authenticate the VTY lines (and if you have a password on them make sure the password on the line is used for the authentication method).

Let’s cover both options here:

1)Using no authentication for the lines:

aaa authentication login default none

line vty 0 4
login authentication default

2)Using the line password as the authentication mechanism

aaa authentication login default line

line vty 0 4
password cisco

That’s it!!

iNetworks

SonicWall VPN Setup and Troubleshooting

For one of our customers we got the task to review and fix a SonicWall Site to Site VPN that stopped working after implementing a new ISP line.

Our engineers have a lot of experience with SonicWall equipment so we were able to resolve the problem in less than 2 hours after checking the Phase 1 and Phase 2 settings on each side, the Routing Table Information on each of the network sides among other things.

At the end of the day the customer VPN was up and running.

Date: December, 2014.