p o c e | e n g i n e e r i n g

Customizing IGMP

DR and Querier election in an LAN
If there are multiple routers on a LAN, a designated router (DR) must be elected to avoid duplicating multicast traffic for connected hosts and a IGMP Querier for coordinating IGMP related queries and registration. From IGMPv2 the two functions (DR and Querier) are decoupled.
=> The DR is the router with the highest IP address on the subnet;
=> The IGMP Querier is the router with the lowest IP address on the subnet;

Designated Router

The DR is responsible for the following tasks: sending PIM register and PIM Join and Prune messages towards the RP to inform it about host group membership. To explicitly set the priority for which a router is elected as the designated router (DR), use the {ip pim dr-priority} command in interface configuration mode.
RT3sh ip pim interface eth0 detail
Ethernet0 is up, line protocol is up
PIM: enabled
PIM version: 2, mode: sparse
PIM DR: 10.1.23.8 <<<<<<<<
PIM neighbor count: 2
PIM Hello/Query interval: 30 seconds

Querier

The Querier is responsible for the following tasks:
- Sending group-specific queries (IGMPv2);
- Sending host-query messages (IGMPv1 by default every 60 seconds);

All routers (excluding the querier) start the query timer controlled by the “ip igmp query timeout” command, which is reset whenever a general query message is received from the IGMP Querier (meaning that the Querier is still alive). If the query timer expires, it is assumed that the IGMP querier has gone down, and the election process is performed again to elect a new IGMP querier. By default, the timer is 2x times the query interval controlled by the “ip igmp query-interval” command.

The “ip igmp query-max-response-time” command allows a router to set how quickly must be detected the fact that there are no more directly connected group members on a LAN. Decreasing the value allows the router to prune groups faster. By default this timer is 10 seconds.

RT3sh ip igmp interface eth0
Ethernet0 is up, line protocol is up
Internet address is 10.1.23.3/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds <<<<<<
IGMP querier timeout is 120 seconds <<<<<<
IGMP max query response time is 10 seconds <<<<<<
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 3 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 10.1.23.8 <<<<<< DR
IGMP querying router is 10.1.23.2 <<<<<< Querier
Multicast groups joined (number of users):
224.0.1.40(1) 239.1.1.1(1) 232.1.1.1(1)
RT3(config)int ethernet 0
RT3(config-if)ip igmp query-interval 80 <<<< Frequency queries for IGMPv1
RT3(config-if)ip igmp querier-timeout 180 <<<< How long before Querier is dead
RT3(config-if)ip igmp query-max-response-time 3 <<<< How long after query

IGMP Access Lists and Filters

A router by default listens to all IGMP join messages from an IGMP enabled interface. This behavior can be limited by permitting joining of a restricted set of groups for the served segment. To do this:
– Define a standard access list with the Group to be permitted;
– Apply the “ip igmp access-group <ACL>” to the served interface;

RT3(config)access-list 1 permit 239.0.0.0 0.255.255.255
RT3(config)int eth0
RT3(config-if)ip igmp access-group 1

IGMP State Limit (DoS on IGMP mitigation)

The IGMP State Limit feature limits the vulnerability of a router to DoS attacks with IGMP packets. A high rate of IGMP messages sent to a router can pose a DoS attack scenario because the router processes IGMP, IGMP v3lite, and URD messages at the process level. The IGMP State Limit feature can be configured per interface, per subinterface, or globally.
Use the “except <access-list>” keyword to exclude certain groups or channels from being counted against the IGMP limit so that they can be joined to an interface without counting against the interface limit.
RT8(config)access-list 1 permit 239.0.0.0 0.255.255.255
RT8(config)int eth0
RT8(config-if)ip igmp limit 10 except 1

RT8sh ip igmp interface et0
Ethernet0 is up, line protocol is up
Internet address is 10.1.35.8/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 1 joins, 0 leaves
Interface IGMP State Limit : 0 active out of 10 max <<<<<<<
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 10.1.35.8 (this system)
IGMP querying router is 10.1.35.6
Multicast groups joined by this system (number of users):
224.0.1.40(1)

IGMPv3 Explicit Tracking

IGMPv3, which is basically used for SSM environments, enhances the registration and leaving information by allowing the hosts to specify (or exclude) a specific source for a specific group. Further IGMPv3 permits the router to explicitly track all hosts which have joined a (S,G) group. In this way the router can immediately stop forwarding the group if the last host leaves (without any delay or workaround).
=> ip igmp version 3
=> ip igmp explicit-tracking

Intermediate Multicast to Broadcast Helper

In case two separate LAN segments do not support multicast but a network in-between does, broadcast streaming (on a selected UDP port) can be converted as Multicast by the first hop router (which faces the source side NON-Mcast capable network) and converted back to broadcast at the last hop router (which faces the receiver side NON-Mcast capable). The solution can also be “partially used”, in the way that broadcast packets can simply be translated to multicast udp packets or that multicast udp packets can be translated to broadcast udp packets.
The syntax of the “ip multicast helper-map” command used on these two routers IS DIFFERENT:
To convert broadcast to Multicast:
ip multicast helper-map broadcast <multicast-address> <access-list>
To convert Multicast to broadcast
ip multicast helper-map <group-address> <broadcast-address> <access-list>
=> In both cases a UDP based access-list which specifies traffic must be defined;
=> The UDP port must be included in the “ip forward-protocol udp” statement (specifies traffic for any helper action).
=> The “ip directed-broadcast” must be enabled to inter-route broadcast to mcast or vice versa. On the first hop router this must happen on the interface that receives broadcast. On the last hop router on the interface that sends broadcast (that is the internal, not where the helper is configured!)
=> Finally, because no PIM join can be formed, the Mcast enabled network in-between must use PIM Dense Mode (on the inside interface of last hop is not needed, because it will be converted to broadcast).

hostname RT6
!
ip multicast-routing
!
interface Ethernet0/0
ip address 192.168.1.119 255.255.255.0
ip directed-broadcast <<<<< Routing FROM broadcast
ip pim sparse-dense-mode <<<<<< Dense needed
ip multicast helper-map broadcast 239.2.2.2 120 <<<<<< Translates
!
interface Ethernet0/0.2
encapsulation dot1Q 2
ip address 10.1.35.6 255.255.255.0
ip pim dense-mode <<<<<< Dense needed
no cdp enable
!
ip forward-protocol udp 4000 <<<<<< define UDP port to add to FWD
access-list 120 permit udp any any eq 4000 <<<<<< select UDP port to help
!
end

hostname RT8
!
ip multicast-routing
!
interface Ethernet0
ip address 10.1.35.8 255.255.255.0
ip pim dense-mode <<<<< Dense needed
ip multicast helper-map 239.2.2.2 10.1.23.255 120 <<<<< Translate back
!
interface Ethernet1
ip address 10.1.23.8 255.255.255.0
ip directed-broadcast <<<<< routing TO broadcast (HERE!!!)
!
ip forward-protocol udp 4000 <<<<<< define UDP port to add to FWD
access-list 120 permit udp any any eq 4000 <<<<<< select UDP port to help
!
end
NOTE ON: “ip directed broadcast”
An IP directed broadcast is an IP packet whose destination address is a valid broadcast address for some IP subnet, but which is NOT originated from a node part of that destination subnet. It has to be routed. A router that is not directly connected to the destination subnet, and that is enabled with an ip directed broadcast command, forwards an IP directed broadcast in the same way it would forward unicast IP packets destined to a host on that subnet. (THIS IS THE EFFECT ON THE FIRST HOP ROUTER).
When a directed broadcast packet reaches a router that is directly connected to its destination subnet, that packet is “exploded” as a broadcast on the destination subnet. The destination address in the IP header of the packet is rewritten to the configured IP broadcast address for the subnet, and the packet is sent as a link-layer broadcast. The “ip directed-broadcast” command controls the explosion of directed broadcasts when they reach their target subnets. The command affects only the final transmission of the directed broadcast on its ultimate destination subnet. It does not affect the transit unicast routing of IP directed broadcasts. (THIS IS THE EFFECT ON THE LAST ROUTER).
If the “no ip directed-broadcast” command has been configured for an interface (which is the default), directed broadcasts destined for the subnet to which that interface is attached will be dropped, rather than being broadcasted.
NOTE: there is an implicit JOIN on the place where it is configured!!!
RT8(config)int eth0
RT8(config-if)ip multicast helper-map 239.2.2.2 10.1.23.255 120
RT8sh ip igmp groups
\IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.2.2.2 Ethernet0 00:00:02 00:02:57 10.1.35.8 <<< Automatic

RT6sh ip mrou
(*, 239.2.2.2), 00:04:00/stopped, RP 10.2.1.2, flags: SJC
Incoming interface: Serial0/0.2, RPF nbr 138.1.15.11
Outgoing interface list:
Ethernet0/0.2, Forward/Dense, 00:04:00/00:00:00
(192.168.1.1, 239.2.2.2), 00:00:11/00:02:51, flags: JT
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0.2, Forward/Dense, 00:00:11/00:00:00

RT8sh ip mroute
IP Multicast Routing Table
(*, 239.2.2.2), 00:04:43/stopped, RP 10.2.1.2, flags: SJPCL
Incoming interface: Ethernet0, RPF nbr 10.1.35.6
Outgoing interface list: Null
(192.168.1.1, 239.2.2.2), 00:00:54/00:02:06, flags: PLTX <<<<<<< Terminates the Mcast
Incoming interface: Ethernet0, RPF nbr 10.1.35.6 on the inbound IF
Outgoing interface list: Null

RT8sh ip mroute count
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.2.2.2, Source count: 1, Packets forwarded: 0, Packets received: 76
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.1.1/32, Forwarding: 0/0/0/0, Other: 76/0/76 <<<<<<< Not forwarded, but
Transformed……
NOTE: IF then PIM is enabled, Mcast will stream further AND been translated to Broadcast as well.
RT8(config)int eth1
RT8(config-if)ip pim dense-mode

RT3sh debugging
Generic IP:
IP packet debugging is on
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd 2
*Mar 1 10:13:31: IP: s=192.168.1.1 (Ethernet0), d=255.255.255.255, len 56, rcvd

Stub IP Multicast Routing and IGMP helper

Stub IP multicast routing allows simple multicast connectivity and configuration at stub networks (routers which are leaves in the network and do not have to route any mcast traffic further). By not running PIM on such routers, the mechanism eliminates periodic PIM flood-and-prune behavior across links (potentially slow) towards the stub routers. In order to do this dense mode is used on the interface of the central router towards such stub router. The only thing the stub router has to do is to forward IGMP reports as a type of Join message to the central router.
=> Stub router is configured with PIM Dense Mode AND with IGMP helper. The stub router needs PIM DM in order to start processing IGMP.
=> Central router runs PIM Sparse Mode towards the Stub router, but applies a neighbor filter to suppress all communication. Sparse Mode is sufficient because the router will see an explicit join from the Stub router.
hostname RT8
!
ip multicast-routing
!
interface Ethernet0
ip address 10.1.35.8 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1
ip address 10.1.23.8 255.255.255.0
ip pim neighbor-filter 11
ip pim sparse-mode
!
end

hostname RT3
!
ip multicast-routing
!
interface Loopback100
ip address 10.100.100.100 255.255.255.255
ip pim dense-mode <<<<< Needed for IGMP
ip igmp helper-address 10.1.23.8
ip igmp join-group 239.1.1.3
!
interface Ethernet0
ip address 10.1.23.3 255.255.255.0
ip pim dense-mode <<<<< Needed for IGMP
!
end

RT8sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.1.1.3 Ethernet1 00:00:32 00:02:27 10.1.23.3

RT8sh ip mroute
(192.168.1.33, 239.1.1.3), 00:03:41/00:02:21, flags: JT
Incoming interface: Ethernet0, RPF nbr 10.1.35.6
Outgoing interface list:
Ethernet1, Forward/Dense, 00:00:39/00:00:00
(192.168.1.120, 239.1.1.3), 00:01:19/00:01:49, flags: JT
Incoming interface: Ethernet0, RPF nbr 10.1.35.6
Outgoing interface list:
Ethernet1, Forward/Dense, 00:00:40/00:00:00

RT8sh ip mroute count
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.1.1.3, Source count: 4, Packets forwarded: 332, Packets received: 454
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.1.33/32, Forwarding: 325/0/56/0, Other: 447/0/122
Source: 192.168.1.120/32, Forwarding: 1/0/100/0, Other: 1/0/0

RT8sh ip pim neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.1.35.6 Ethernet0 01:39:59/00:01:42 v2 1 / S

Facilitating hosts not running IGMP: Interface Joining a group (Static and Join)
In order to help segments that are not able to use IGMP to require Multicast traffic and make the segment perform as an IGMP join is constantly received use either the “ip igmp join-group” or “ip igmp static-group” commands. The first command makes also the interface of the router itself join the group, BUT make also the router process switch the traffic. It is useful only for tests. The Static join instead lets the router perform in fast switched mode, but the interface itself does not process any traffic.