IP Multicasting – Part 3 – IGMP

IGMP (Internet Group Management Protocol) is required for communication between hosts and routers to determine where the router have to send the Multicast traffic.
Imagine a network with a router connecting to 4 different subnets with 4 physical interfaces, but with only one Host in one subnet actually requesting the traffic. How does the router know where to send out the multicast traffic? If you automatically send out the traffic through every interface, it’s a waste of bandwidth. So here we need IGMP.

So the router needs to know about:
– Where are the hosts located which require the multicast traffic for a group?
– How do I learn about hosts requiring the traffic?
– How do I learn about hosts no longer requiring the traffic?

There are currently three versions of IGMP available: IGMPv1 (RFC1112), IGMPv2 (RFC2236), IGMPv3 (RFC3376). In this article i’ll focus myself on IGMPv2

Messages supported by IGMPv2

Membership Query
The membership query is used for two function: First to discover if there are any hosts required in receiving any multicast group, second to determine if there are any remaining hosts for a specific multicast group.

Version 1 Membership Report
Version 2 Membership Report
The membership reports is used by the hosts: As a solicited host membership report as an answer to a membership query and as a unsolicited host membership report when first joining the group. (without waiting for the next membership query)

Leave Group
The Leave Group message is, you guessed it, used by the host to tell the router that he’s no longer interested in receiving the traffic.

IP Multicasting – Part 2 – Addresses

As I wrote yesterday, the class D range (224.0.0.0 – 239.255.255.255) is reserved for Multicast use.

Those addresses are again split up in several ranges:
224.0.0.0 – 224.0.0.255 (224.0.0.0/24) – Permanent group for local segment: They are not routed
224.0.1.0 – 224.0.1.255 (224.0.1.0/24) – Permanent group for the whole network: They are forwarded in the entire network
232.0.0.0 – 232.255.255.255 (232.0.0.0/8) – Source-Specific Multicast (SSM) applications
233.0.0.0 – 233.255.255.255 (233.0.0.0/8) – GLOP addressing
239.0.0.0 – 239.255.255.255 (239.0.0.0/8) – Private domain multicast
Everythinge else – Transient group

Permanent Groups
There are two ranges of permanent IP multicast addresses: the first is used for packets that are not forwarded by routers, the second when the packets should be forwarded by routers.
An example: The multicast addresses used by OSPF or EIGRP are in the first range, where only routers located on the same segment can communicate to each other and exchange routes.

Source-Specific Multicast (SSM)
Source-Specific multicast allows you to limit the source address to a specific address. This improves security as no other hosts are able to send traffic to the multicast group.

GLOP Addressing
GLOP addressing allocates each registered AS number 256 global multicast IP addresses. As the 2nd and 3rd octet of the IP address, the 16bit ASN is used.
For example if you are using AS 3303:
3303 convered to binary: 00001100 11100111
00001100 is used as the 2nd octet, decimal: 12
11100111 is used as the 3rd octet, decimal: 231
So, the resulting range would be: 239.12.231.0 – 239.12.231.255

Private Multicast Domain
The private multicast domain addresses can be used within the own network, somewhat like the private unicast addresses defined in RFC1918.

Transient Groups
Transient multicast addresses are globally unique multicast addresses. They get dynamically allocated and released when no longer in use. Any IP addresses in the range 224.0.0.0 to 239.255.255.255 that is not assigned to a specific group/range, is considered as a transient multicast address.

IP Multicasting – Part 1 – The Basics

Everyone already heard about multicast, but what is it? why do we need it?
So let’s first look at the most basic definition of IP multicast:
“Sending a message from a single source to selected multiple destinations across a Layer 3 network in one data stream.”

Can’t we do this with unicast?
Unicast allows you to send messages from one source to one destination. Which mean that if you want to send the same content to multiple destinations, it will require X amount of bandwidth, with X being the number of destination hosts.
So if you transfer a data stream using a bandwidth of 2 Mbps to 1 destination host, ithe source needs to transfer 2 Mbps. If you send the same data stream to 3 destinations, it will require 6 Mbps (3x 2Mbps) of bandwidth, etc.
As you can see this concept causes a large amount of unnecessary traffic.

How about broadcast?
Broadcast on the other hand allows you to send data from one source to all destination hosts. So if you want to send the same content to multiple destinations, it will only require once the bandwidth at the source.
But, and here is the big disadvantage, the data will be transferred the every single host, even to those that are not interested in receiving the traffic! This will increase the processing load on the network devices and wastes bandwidth.

Ok, tell me more about that multicast thing…
Multicast uses a separate range of IP Addresses, often referred to as class D. It includes all IP Addresses starting with “1110” in binary. For those who don’t want to start calculating: it’s the range between 224.0.0.0 and 239.255.255.255.
Multicast also requires the use of a Layer 2 Address, which can be calculated from the corresponding Layer 3 address.

All multicast MAC addresses use an OUI of 01-00-5E, have the 25th bit set to 0, and the last 23 bits copied from the last 23 bits of the IP address. As it would require 28 bits to uniquely distinguish between IP addresses, there are 32 (5^2) Layer 3 multicast addresses that match a single Layer 2 multicast address.

Basic NTP and Timezone Configuration on Cisco IOS

Configuring NTP Servers

ntp server HOST

If you are looking for NTP servers, please consult the NTP Pool Project

Configuring Timezone

clock timezone NAMEOFTIMEZONE X Y

Where “NAMEOFTIMEZONE” defines the name of the (winter) timezone, and “A” definies the offset to GMT in hours, and “B” in minutes.

You can define the summer time using one of these commands

clock summer-time NAMEOFSUMMERTIMEZONE recurring [first/last/1-4] WEEKDAY MONTH HH:MM [first/last/1-4] WEEKDAY MONTH HH:MM

clock summer-time NAMEOFSUMMERTIMEZONE date DAY MONTH YEAR HH:MM date DAY MONTH YEAH HH:MM

The first command sets the start and beginning in recurring mode. It will automatically sets the summertime every year based on the logic you define.
Using the second command you can manually set the start and end date of summertime for every year.

For example when you live in Switzerland:

clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00

Show Time
To display the current time on a Cisco IOS device, use the “show clock [detail]” command. In the detailed view, you’ll find additional information to the timezone and the time source.

RT20#sh clock
18:12:17.145 CET Sun Nov 13 2011
RT20#
RT20#sh clock detail
18:12:22.129 CET Sun Nov 13 2011
Time source is NTP
Summer time starts 02:00:00 CET Sun Mar 25 2012
Summer time ends 03:00:00 CEST Sun Oct 28 2012