Tag Archives: CCIE

CGMP Summary

  • 2015-08-02
  • Posted by jcarvaja

Hello Everyone,

Today’s post will talk about one Multicast LAN Optimization Protocol.

As you remember from one of our posts IGMP it’s the protocol used by hosts to inform routers they want to join a specific Multicast Group or they want to leave that Multicast Group.

But here comes a question!! What does a switch do when it receives a Multicast Packet??

I mean the destination IP address would be one in the Multicast Range 224.0.0.0-239.255.255.255 but switches forward packets based in the MAC address not in the IP address, so how would they forward the traffic?

That’s a very good question and to answer that I will provide a scenario.

Imagine that Server A wants to send traffic to the Multicast Group 225.1.1.1 and that Router 1 connects to a LAN where the PC-A wants to receive that traffic.

That PC sends a IGMP Join message for that group and immediately the router starts to forward any multicast traffic it receives about that group.

When the Router send the multicast traffic the IP packet will have the following IP and MAC address info:

  • IP: 225.1.1.1
  • MAC: 0100.5e01.0101

 

So Far So Good.. Right!!!

Now here it’s a question for you (that you should be able to answer).

When would a switch store a MAC address in it’s CAM table?

This will happen whenever a station sends a packet to the network and reaches the switch.

The switch will then store the source MAC address on the stations in it’s CAM with the respective port where it received it! so it knows where to send any traffic destined to that MAC address.

And now a different question.

Can you use a Multicast IP to source traffic?

NEVER!!! Multicast IP addresses and hence MAC addresses are only used as destination addresses.

 

This means that the switch will never store the MAC address of the multicast group in the CAM table.

 

Here  you have another question.

What does a switch do when it receives a packet for a destination MAC address it does not know?

The traffic will be forwarded to all of the ports in the same VLAN except to the port where it was received.

WOW, do you imagine a LAN with 100,200 or more users where only one user in the LAN wants to receive Multicast Traffic for a specific group?

There will be a waist of resources as the Switch will forward the traffic to all the ports, PCs will get it and will discard it as they are not expecting that traffic.

 

OMG….. Is there a way we can fix this or better said “Is there a way we can optimize the behaviour of Multicast in a LAN environment?

 

YES, it is!!! There are actually about 3 different protocols that will allow us to improve this and they are:

  • Cisco Group Management Protocol (CGMP)
  • IGMP Snooping
  • Router-Port- Group Management Protocol (RGMP)

 

Now that we know there is a need for this protocols, let’s start talking about the CGMP protocol (this is why we created this post anyway)

 

CGMP

This Cisco Proprietary Protocol allows Switches and Routers to maintain a communication where they can exchange information about to what ports in the Switch the Multicast Listeners are.

CGMP needs to be configured in the L3 device (Multilayer Cisco Switch or a Cisco Router) as they are the ones that send CGMP packets. Switches only listen for CGMP messages.

 

In the router you just get into the LAN interface that goes to the switch and enter the following command

Ex:

 

Layer 3 Device Config

 

interface fa0/1

ip cgmp

 

Layer 2 Device Config

ip cgmp (Globally defined)

 

That’s it! Afterwards the router will start communicating to the switch information learned from IGMP messages.

The destination MAC address of the  CGMP messages is 0100.0cdd.dddd

The use of this destination MAC address forces the switch to forward this CGMP packets through all the ports so that all switches in a campus can successfully add the respective ports into the Multicast Output Ports.

 

Within CGMP messages there is one key set of information known as:

  • Group Destination Address (GDA)
  • Unicast Source Address (USA)

 

CGMP Join Process

1) As soon as the router running CGMP gets connected to a LAN switch, it will send a CGMP message with the GDA set to zero and the USA set with it’s own MAC address.

The CGMP capable switch will then now that a multicast router lives on the port where it learned the MAC address of the port.

This CGMP message that the router sent is re-transmitted each 60 seconds.

 

2) If a host in that LAN join a multicast group, it will send an IGMP Multicast Join packet.

That packet will reach the router and normally the router would just focus on the L3 Info of the packet (determine what multicast group is the host trying to join) but as we have CGMP turned on the router would also check L2 information and it will obtain the source MAC address of the host.

The router will then send a CGMP message to the switch that will have the GDA set to the Multicast Group MAC address the host is trying to join and the USA to the Unicast MAC address of the host that wants to join that Multicast Group.

It’s important to mention that the destination MAC address of this packet it’s the well known multicast CGMP address 0100.0cdd.dddd.

 

3) The switch will get this CGMP join message and will search in the CAM address for the port where the USA address is connected to.

The switch will then create a new entry for the multicast MAC address listed in the GDA field and will add the port number associated with the host MAC address.

That’s how the joining process works, now we are going to discuss the leave process.

 

CGMP Leave Process

1) When a host does not want to receive multicast traffic it will send an IGMP leave message.

That message will get to the router and the router will check the source MAC address of the host as well as the Multicast IP address (so it can map it to the L2 Multicast Address) in order to be able to build the respective CGMP message.

The router generates the CGMP leave message and sets the GDA to the L2 address of the multicast group the user is leaving and the USA to the host source MAC address.

2) The switch will receive this CGMP leave message and will delete from it’s CAM table the entry that allows the forwarding of that GDA group (Multicast L2 Address) to the port where the USA (Host Source MAC address) exists.

 

This is exactly how CGMP works in a LAN environment.

 

I hope you liked this post and get back to us if you have any questions.

 

Regards,

 

Jcarvaja

IPv6 Tunneling Part 3: Automatic 6to4 Tunnels

  • 2015-07-30
  • Posted by jcarvaja

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

  • 2015-07-26
  • Posted by jcarvaja

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


Fatal error: Call to undefined function twentythirteen_paging_nav() in /home/inetworks/public_html/wp-content/themes/inetworks/tag.php on line 33