multicast
Filtering multicast/PIM
05/02/11 11:03
Multicast, PIM and SA filtering can happen on a router interface, on a PIM process, on a RP or on a MA.
Every type of filtering has a different purpose and scope. Here's a quick review.
ROUTER INTERFACE
On a router interface we can filter multicast, IGMP, PIM and BSR messages.
FILTERING MULTICAST PACKETS - ip multicast boundary
RATE-LIMIT MULTICAST - ip multicast rete-limit
Can rate-limit all multicast packets or only specific groups selected by an access-list.
ACCESS-LIST
Can specify only dest multicast address or both source and destination.
FILTERING BSR MESSAGES - ip pim bsr border
BSR messages should not go out the domain.
FILTERING PIM - ip pim neighbor-filter
Filtering PIM can be use to block PIM neighbors to form
FILTERING IGMP - ip igmp access-group
Filtering IGMP allows to specify which groups the clients connected to a interface can join.
A standard ACL specifies groups only, extended ACL specified both source and groups.
ROUTER / RP
A multicast-enabled router receives and forwards join/prune messages towards one or more RP.
We can filter those messages on both RP and non-RP routers.
ACCEPT-RP - ip pim accept-rp
Filters join/prune messages destined for specific RP and-or group.
RP
A RP receives SA messages from multicast sources. We can filter which SA messages are accepted by the RP:
ACCEPT-REGISTER - ip pim accept-register
A RP sends rp-annouce messages that should reach a MA. We can limit the scope of those messages tuning the TTL so if two MA are located ad different hop-count this can be a way to filter too.
RP-ANNOUNCE TTL - ip pim send-rp-announce L0 scope X
MAPPING AGENT
The mapping agent receives rp-announces from RP candidates.
We can filter RP announces to accept specific groups from specific RPs.
RP-ANNOUNCE-FILTER - ip pim rp-announce-filter
The RP chosen by the MA for a group follows two rules:
- more specific entry wins
- highest IP wins
To achieve redundancy and a sort of load-balancing, announce both specific and less specific route on RPs.
HTH
IGMP filtering on switches
03/02/11 21:04
Example of filter:
ip igmp profile 1
permit
range 232.0.0.0 232.255.255.255
If action is "deny" all the others groups are permitted. If action is "permit" all the other groups are denied.
Apply filter to interface:
inte f0/0
ip igmp filter 1
As reported on Cisco docs, igmp filters cannot be applied to routed, SVI or etherchannel member interfaces. Only plain L2 interfaces can be filtered.
LINKS
A Networker Blog
CCIE to be Blog
SSM - Source Specific Multicast
03/02/11 20:22
Source specific Multicast block is 232.0.0.0/8 as defined on RFC3171. SSM is described on RFC3569.
Source Specific Multicast configuration recipe:
1) enable IGMP v3 on all required interfaces
R2(config-if)#ip igmp version 3
2) enable SSM for the default groups (232.0.0.0/8) or specific groups, defined on ACL:
R2(config)#ip pim ssm ?
default Use 232/8 group range for SSM
range ACL for group range to be used for SSM
All RPF rules are still used: multicast packets are dropped if not coming from RPF valid interface.
RP and MSDP are not needed for SSM since the destination requests multicast traffic directly to the source.
Source discovery via application or SAP should not be part of CCIE blueprint.
Bidir PIM
03/02/11 19:18
Bidirectional PIM is used when there're many sources and destinations of multicast traffic, like a videoconference with many participants.
How to configure bidir PIM?
First, enable it on all routers:
R2(config)#ip pim bidir-enable
Second, configure one ore more Bidir RP with static RP, Auto-RP or BSR. Notice the "bidir" option.
ip pim rp-address IP ACL bidir
ip pim send-rp-announce INT scope TTL group-list GROUPS bidir
ip pim rp-candidate INT group-list GROUPS bidir
Verify:
(*, 231.0.0.4), 01:02:53/00:02:40, RP 4.4.4.4, flags: BP
Bidir-Upstream: FastEthernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Bidir-Upstream/Dense, 00:00:18/00:00:00
IGMP timers and tweaking
03/02/11 16:09
DEFAULTS:
R2#sh ip igmp interface f0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 10.0.123.2/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: 4 joins, 2 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 10.0.123.2 (this system)
IGMP querying router is 10.0.123.2 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1)
QUERY INTERVAL - default 60s
How often the querier request membership reports from multicast clients
R2(config-if)#ip igmp query-interval ?
<1-18000> Query interval in seconds
QUERIER TIMEOUT - default 120s
If query message timeout is missed a new querier is elected
R2(config-if)#ip igmp querier-timeout ?
<60-300> timeout value in seconds
MAX QUERY RESPONSE - default 10s
Amount of time the querier waits for membership responses from clients.
When timeout reached, if no response came router removes mroute state.
R2(config-if)#ip igmp query-max-response-time ?
<1-25> query response value in seconds
LAST MEMBER QUERY COUNT AND INTERVAL - default 2 messages every 1000ms
When the last member of a group is removed, the querier sends C messages each I interval if there's any other memeber in the subnet. If no answer group is removed.
R2(config-if)#ip igmp last-member-query-count ?
<1-7> Last member query count
R2(config-if)#ip igmp last-member-query-interval ?
<100-25500> Last member query interval in milliseconds
It is possible to disable the last member query for specific groups:
R2(config-if)#ip igmp immediate-leave group-list ?
<1-99> Access list number
<1300-1999> Access list number (expanded range)
WORD IP Named Standard Access list
IGMP LIMIT - default no limit
Limits che number of active groups membership on a interface
R2(config-if)#ip igmp limit ?
<1-64000> Max Allowed State on this interface
PIM DR
03/02/11 12:50
Following my previous post, another election happens on a multi-access segment: PIM DR - Designated Router.
The election is based on this order:
• highest priority
• highest IP
Notice that this election is preemptive, do not be confused by OSPF DR election that is not preemptive.
What are the duties of the PIM DR?
• signal multicast receivers to the RP, tracking IGMP messages
• register active sources on the segment to the RP
Back to the previous topology, R3 is the DR of R1-R2-R3 segment:
R2#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.0.123.3 FastEthernet0/0 00:35:46/00:01:21 v2 1 / DR S
10.0.123.1 FastEthernet0/0 01:04:13/00:01:20 v2 1 / S
Notice that default prioriy is 1. What if we set R2 priority value to 2?
R2(config-if)#ip pim dr-priority 2
R2(config-if)#
*Mar 1 01:43:32.367: PIM(0): Changing DR for FastEthernet0/0, from 10.0.123.3 to 10.0.123.2 (this system)
*Mar 1 01:43:32.367: %PIM-5-DRCHG: DR change from neighbor 10.0.123.3 to 10.0.123.2 on interface FastEthernet0/0
Since it's a permanent election, R2 preempts R3 and became DR.
NOTE
DR election is someway related to forward election, maybe priority is considered on both?
Software used: C3725-ADVENTERPRISEK9-M
When R2 is DR it's forwared too:
R2#
(10.0.234.4, 231.0.0.1), 00:00:22/00:02:38, flags: JT
Incoming interface: FastEthernet0/1, RPF nbr 10.0.234.4
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:22/00:02:37
R3#
(10.0.234.4, 231.0.0.1), 00:00:03/00:02:58, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 10.0.234.4
Outgoing interface list: Null
PIM ASSERT
03/02/11 11:46
On a broadcast segment the multicast forwarder is elected based on:
• lowest AD
• lowest metric
• highest IP
What if the segment is a NBMA? The hub must be elected as forwarder.
That the purpose of "ip pim nbma-mode" command. Apply this on the hub interface.
A quick lab:
R4 is RP for all groups/routers
PIM sparse enabled on all interfaces
R1 joins group 231.0.0.1
R4 ping to 231.0.0.1
Which router is elected as forwarder on R1-R2-R3 segment?
R3 is elected since it has the same AD and metric of R1 but it's F0/0 has a higher IP address than R2.
How do we verify it?
Enable "deb ip mpacket" and disable mroute-cache on interfaces with "no ip mroute-cache".
Now ping 231.0.0.1 from R4:
R4#ping 231.0.0.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 231.0.0.1, timeout is 2 seconds:
Reply to request 0 from 10.0.123.1, 24 ms
We get an reply, great!
Check the packet on R3:
R3#
*Mar 1 00:46:39.899: IP(0): s=10.0.234.4 (FastEthernet0/1) d=231.0.0.1 (FastEthernet0/0) id=3, ttl=254, prot=1, len=100(100), mforward
Check the same packet on R2:
R2#
*Mar 1 00:48:22.955: IP(0): s=10.0.234.4 (FastEthernet0/1) d=231.0.0.1 id=4, ttl=254, prot=1, len=114(100), mroute olist null
*Mar 1 00:48:22.959: IP(0): s=10.0.234.4 (FastEthernet0/0) d=231.0.0.1 id=4, ttl=253, prot=1, len=114(100), not RPF interface
Only R3 forwards the packet.
Mroute on R2, pruned (P flag):
(10.0.234.4, 231.0.0.1), 00:01:46/00:01:42, flags: PJT
Incoming interface: FastEthernet0/1, RPF nbr 10.0.234.4
Outgoing interface list: Null
Mroute on R3:
(10.0.234.4, 231.0.0.1), 00:00:31/00:02:58, flags: JT
Incoming interface: FastEthernet0/1, RPF nbr 10.0.234.4
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:31/00:02:49, A
As we expected the mroute is pruned on R2 since it's not the forwarder. Notice the A flag on R3 mroute, meaning it won the Assert election.
What happens if we shutdown R3 interface F0/0? R2 becomes forwarder for the segment:
(*, 231.0.0.1), 00:00:57/stopped, RP 4.4.4.4, flags: SJC
Incoming interface: FastEthernet0/1, RPF nbr 10.0.234.4
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:26/00:02:33
R2#
*Mar 1 00:53:46.683: IP(0): s=10.0.234.4 (FastEthernet0/1) d=231.0.0.1 (FastEthernet0/0) id=12, ttl=254, prot=1, len=100(100), mforward
IP Multicast Helper Map
19/12/10 17:04
Multicast helper-map as described on Doc-CD is used:
"to allow IP multicast routing in a multicast-capable internetwork between two broadcast-only internetworks"
This is the simple lab:
Initial configuration:
- pim dense mode between R2 an R3
- usual addressing standard
- Ripv2 on R1 and R4
We use R1 and R4 as broadcast only routers. They're configured with RIPv2 in broadcast mode on F0/0:
ip rip v2-broadcast
ip rip advertise 5
Out task is to allow R1 and R4 to get RIP updates between each other.
We can divide the problem for each direction, the first is from R1 to R4, the second is from R4 to R1.
1) the first helper-map is applied on R2, used to convert broadcast incoming from R1 in multicast towards R3. Since broadcast comes from F0/0 that is the interface where the helper-map is applied to:
access-list 100 permit udp any any eq rip
! this is both necessary and easy to forget
ip forward-protocol udp rip
inte f0/0
ip multicast helper-map broadcast 228.0.0.1 100 ttl 10
Access-list 101 defines which traffic will be converted to multicast.
2) the second helper-map is applied to interface F0/0 on R3, it used to convert back multicast traffic in broadcast so it can be heard by R4 RIP process:
access-list 100 permit udp any any eq rip
! this is both necessary and easy to forget
ip forward-protocol udp rip
inte f0/0
ip multicast helper-map 228.0.0.1 10.0.34.255 100
On R4 interface F0/1 we must enable directed broadcast:
R4(config)#int f0/1
R4(config-if)#ip directed-broadcast
On R4 we enable debug of RIP and we get this message:
R4(config-router)#
*Mar 1 01:19:17.459: RIP: sending v2 update to 255.255.255.255 via FastEthernet0/0 (10.0.34.4)
*Mar 1 01:19:17.459: RIP: build update entries
*Mar 1 01:19:17.459: 4.4.4.4/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:19:17.463: IP: s=10.0.34.4 (local), d=255.255.255.255 (FastEthernet0/0), len 52, sending broad/multicast
*Mar 1 01:19:17.547: IP: s=10.0.12.1 (FastEthernet0/0), d=255.255.255.255, len 52, rcvd 2
*Mar 1 01:19:17.547: RIP: ignored v2 update from bad source 10.0.12.1 on FastEthernet0/0
We can easily get rid of it:
R4(config)#router rip
R4(config-router)#no validate-update-source
Check if R4 is getting the RIP route from R1:
R 1.1.1.1 [120/1] via 10.0.12.1, 00:00:03
The other direction is done the same way, inverting R2 and R3 roles and using another multicast address.
We can check if mroutes are correct on R2 and R3:
R2#show ip mroute
(10.0.12.1, 228.0.0.1), 00:45:29/00:02:50, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:45:29/00:00:00
(10.0.34.4, 228.0.0.2), 00:35:54/00:02:56, flags: PLT
Incoming interface: FastEthernet0/1, RPF nbr 10.0.23.3
Outgoing interface list: Null
R3#show ip mroute
(10.0.12.1, 228.0.0.1), 00:29:08/00:02:56, flags: PLTX
Incoming interface: FastEthernet0/0, RPF nbr 10.0.23.2
Outgoing interface list: Null
(10.0.34.4, 228.0.0.2), 00:35:15/00:02:49, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:35:15/00:00:00
Great!
NOTES
There are at least two possible issues with this configuration.
1) forget the command
ip forward-protocol udp rip
2) forget to set the TTL in the broadcast to multicast helper-map. The default TTL is set to 1 so the packet will die after the first hop never getting the destination.
We can verify it using Wireshark in the segment between R2 and R3:
Other references:
INE blog
MSDP SA filtering - lab
19/12/10 13:26
On R3 we want to filter SA messages towards R2 so if we ping address 227.0.0.10 from R4 we should not get response.
Step 1:
create inte lo10 on R1 with ip address 10.10.10.10. This interface joins group 227.0.0.10
interface Loopback10
ip address 10.10.10.10 255.255.255.255
ip pim sparse-mode
ip igmp join-group 227.0.0.10
end
Step 2:
verify connectivity. From R4 ping 227.0.0.10
R4#ping 227.0.0.10 re 1
Sending 1, 100-byte ICMP Echos to 227.0.0.10, timeout is 2 seconds:
Reply to request 0 from 10.0.12.1, 24 ms
On R2 MSDP SA-caceh there's a entry for this traffic:
R2#sh ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(4.4.4.4, 227.0.0.10), RP 3.3.3.3, BGP/AS 300, 00:01:22/00:05:34, Peer 3.3.3.3
Learned from peer 3.3.3.3, RPF peer 3.3.3.3,
SAs received: 2, Encapsulated data received: 0
Step 3:
apply sa-filter on R3
We create and access-list matching the SA for the group:
R3#sh access-lists 104
Extended IP access list 104
10 deny ip host 4.4.4.4 host 227.0.0.10 log (5 matches)
20 permit ip any any (12 matches)
and apply the filter to peer R2 ip 2.2.2.2:
ip msdp sa-filter out 2.2.2.2 list 104
Check the sa-filter is properly applied:
R3#sh ip msdp peer
MSDP Peer 2.2.2.2 (?), AS 200
Connection status:
State: Up, Resets: 3, Connection source: Loopback0 (3.3.3.3)
Uptime(Downtime): 03:49:26, Messages sent/received: 241/241
Output messages discarded: 0
Connection and counters cleared 05:59:23 ago
Elapsed time since last message: 00:00:10
Local Address of connection: 3.3.3.3
Local Port: 639, Remote Port: 26547
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: 104, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
Message counters:
RPF Failure count: 0
SA Messages in/out: 34/27
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 8/9
Now try to ping again from R4:
R4#ping 227.0.0.10 re 1
Sending 1, 100-byte ICMP Echos to 227.0.0.10, timeout is 2 seconds:
.
We don't get any answer, that is correct.
This is the capture of the filtered SA message that matched the access-list:
On R2 the msdp sa-cache is empty:
R2#sh ip msdp sa-cache
MSDP Source-Active Cache - 0 entries
Now we verify that we can still reach 227.0.0.1 from R4 since this SA does not match ACL 104:
R4#ping 227.0.0.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 227.0.0.1, timeout is 2 seconds:
Reply to request 0 from 10.0.12.1, 56 ms
The entry is on R2 sa-cache:
R2#sh ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(4.4.4.4, 227.0.0.1), RP 3.3.3.3, BGP/AS 300, 00:00:27/00:05:45, Peer 3.3.3.3
Learned from peer 3.3.3.3, RPF peer 3.3.3.3,
SAs received: 2, Encapsulated data received: 1
We can apply sa-filter on both inbound and outbound direction on the msdp peers to a granular filtering of multicast sources between domains.
HTH
MSDP SA filtering - theory
15/12/10 19:08
Basics first.
*** SOURCE ACTIVE ***
What’s on a SA message?
Source Address of the source
Group address the data source send to
IP address of the RP
Who sends a SA?
Only RPs send and receive SA messages (only DR on shared networks)
When a SA messages is send?
When an RP in a PIM-SM domain first learns of a new sender, e.g., via
PIM register messages, it constructs a "Source-Active" (SA) message
and sends it to its MSDP peers.
(from RFC3618)
To who a SA message is forwarded?
If the MSDP peer receives the SA from a non-RPF peer towards the
originating RP, it will drop the message. Otherwise, it forwards the
message to all its MSDP peers (except the one from which it received
the SA message).
(from RFC3618)
*** SA REQUESTS ***
What’s on a SA request?
A multicast prefix with his its prefix lenght. When a host request a join to a particular group, the RP sends a SA request to its MSDP peers.
Who sends a SA request?
SA requests are sent only by RPs configured to do so and should be sent only to caching peers
(Routing TCP/IP vol2 page 610).
What’s on a SA response?
The RP address for the requested group, the group address and the source address for that group.
A Cisco router can filter both incoming and outgoing SA messages to and from a specific MSDP peer.
*** FILTERING INBOUND SOURCE ACTIVE MESSAGES ***
Accept from MSDP peer 10.0.0.1 only SA for groups 224.0.0.0/4 from sources in subnet 10.254.0.0/24:
access-list 101 permit 10.254.0.0 0.0.255.255 224.0.0.0 31.255.255.255
ip msdp sa-filter in 10.0.0.1 list 101
10.0.0.1 is the MSDP peer to which the filter is applied
10.254.0.0/24 is the range of multicast sources accepted
224.0.0.0/4 are the multicast groups accepted from this peer whit this sources
*** FILTERING OUTBOUND SOURCE ACTIVE MESSAGES ***
Send SA messages to peer 10.0.0.1 only from specific sources/groups:
access-list 102 permit 172.16.0.0 0.0.255.255 230.0.0.0 0.255.255.255
ip msdp sa-filter out 10.0.0.1 list 102
The SA messages can be local originated or forwarded from another MSDP peer.
*** FILTERING OUTBOUND LOCAL ORIGINATED SOURCES ***
This filter is applied to all MSDP peers but only for locally originated SA messages:
access-list 102 permit 192.168.1.0 0.0.0.255 231.0.0.0 0.255.255.255
ip msdp redistribute list 102
Only sources in subnet 192.168.1.0/24 for groups in range 231.0.0.0/8 are advertised to MSDP peers.
Multicast Source Discovery Protocol (MSDP)
15/12/10 19:01
MSDP, as described in RFC3618, is a mechanism to connect multiple PIM domains together. The general concept is to connect the RPs from different domains to make them aware of multicast sources in each domain.
This is a simple lab for testing MSDP functions. Each Rx-Ry network has address 10.0.xy.0/24 with x,y.
Initial configuration:
- ip addresses of routers
- R2 and R3 are BGP neighbors for both unicast and multicast
- IGP is running between R1-R2 and R3-R4
Configuring PIM:
R1 and R2 are part of a PIM domain with AutoRP enabled.
R2 is the RP
To be sure R2 and R3 are on different domain we filter on R2 and R3 both BSR and AutoRP messages:
interface FastEthernet0/1
ip address 10.0.23.2 255.255.255.0
ip access-group PIM in
ip access-group PIM out
ip pim bsr-border
ip pim sparse-mode
no ip mroute-cache
duplex auto
speed auto
end
R2#sh access-lists PIM
Extended IP access list PIM
10 deny ip any host 224.0.1.40
20 deny ip any host 224.0.1.39
30 deny ip host 224.0.1.39 any
40 deny ip host 224.0.1.40 any
50 permit ip any any
Now let’s configure MSDP between R2 and R3:
R2(config)#ip msdp peer 3.3.3.3 connect-source Loopback0
R3(config)#ip msdp peer 2.2.2.2 connect-source Loopback0
Check correct peering, note that MSDP uses TCP/639:
R2#sh ip msdp peer
MSDP Peer 3.3.3.3 (?), AS 300
Connection status:
State: Up, Resets: 3, Connection source: Loopback0 (2.2.2.2)
Uptime(Downtime): 00:38:35, Messages sent/received: 43/43
Output messages discarded: 0
Connection and counters cleared 02:49:05 ago
Elapsed time since last message: 00:00:49
Local Address of connection: 2.2.2.2
Local Port: 26547, Remote Port: 639
R3#sh ip msdp peer
MSDP Peer 2.2.2.2 (?), AS 200
Connection status:
State: Up, Resets: 3, Connection source: Loopback0 (3.3.3.3)
Uptime(Downtime): 00:39:47, Messages sent/received: 45/45
Output messages discarded: 0
Connection and counters cleared 02:49:43 ago
Elapsed time since last message: 00:00:04
Local Address of connection: 3.3.3.3
Local Port: 639, Remote Port: 26547
Now we test that MSDP actually works as expected.
R1 joins multicast group 227.0.0.1:
R1#sh run inte l0
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip pim sparse-mode
ip igmp join-group 227.0.0.1
no ip mroute-cache
ip ospf 1 area 0
end
R4 should be get an answer pinging R1:
R4#ping 227.0.0.1 so l0 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 227.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
Reply to request 0 from 10.0.12.1, 20 ms
On R3 we can see the entry in MSDP cache:
R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(4.4.4.4, 227.0.0.1), RP 2.2.2.2, MBGP/AS 200, 00:01:14/00:05:31, Peer 2.2.2.2
Learned from peer 2.2.2.2, RPF peer 2.2.2.2,
SAs received: 2, Encapsulated data received: 1
Using Wireshark or debug commands we should be able to see MSDP SA messages:
*Mar 1 04:00:32.927: MSDP(0): 3.3.3.3: Originating SA message
*Mar 1 04:00:32.927: MSDP(0): (4.4.4.4/32, 227.0.0.1)
*Mar 1 04:00:32.927: MSDP(0): (1.1.1.1/32, 227.0.0.8)
On my next post I'll check how to filter SA messages between MSDP peers. Stay tuned!
MSTAT
14/12/10 18:40
A great command for multicast troubleshooting: MSTAT
Other useful commands are MRINFO and MTRACE.
(Routing TCP/IP vol.2 Chapter 6)
How multicast works in LAN?
14/12/10 12:35
A network engineer asked me how to configure his switches to support Multicast in LAN. He asked about PIM, RP and so on but the answer is... “nothing”!
Here’s the explanation.
Inside a VLAN the multicast is part of the usual L2 traffic, the only difference is the MAC address.
The multicast source sends its traffic to a particular MAC address:
An IP host group address is mapped to an Ethernet multicast address
by placing the low-order 23-bits of the IP address into the low-order
23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex).
http://www.ietf.org/rfc/rfc1112.txt
The hosts that want to receive the multicast traffic just have to listen for this MAC address.
Only if sender and receivers are on different subnets we need PIM.
Note: since MAC address is defined, there’ll be no ARP queries.