Multicast - Source Specific Multicast

Overview

Source specific multicast or SSM uses IGMPv3 PM messages to allow receivers to specify the group and source they want to listen to. As a result  there is no need to configure any RP infrastructure since SSM only uses the shortest path tree and not the shared tree to the RP. This simplifies configuration considerably.

Concepts tested

• Configuration PIM SSM
• Verifying PIM SSM

Topology

Lab Tasks

• Configure PIM SM across all paths between R1 and R5
• Configure PIM SSM on all multicast routers
• Configure PIM SSM to use the default SSM multicast group range of 232.0.0.0/8
• Have R1 join the group 232.0.10.1 with source 120.0.45.5

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R1(config)#ip multicast-routing
R1(config)#ip pim ssm default
R1(config)#int g0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#ip igmp version 3
R1(config-if)#exit

R2(config)#ip multicast-routing

R2(config)#ip pim ssm default

R2(config)#int g0/0

R2(config-if)#ip pim sparse-mode

R2(config-if)#exit

R2(config)#int g1/0

R2(config-if)#ip pim sparse-mode

R2(config-if)#exit

R3(config)#ip multicast-routing
R3(config)#ip pim ssm default
R3(config)#int g0/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#exit
R3(config)#int g1/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#exit

R4(config)#ip multicast-routing
R4(config)#ip pim ssm default
R4(config)#int g0/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#int g1/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#int g2/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit

R5(config)#ip multicast-routing
R5(config)#ip pim ssm default
R5(config)#int g0/0
R5(config-if)#ip pim sparse-mode
R5(config-if)#ip igmp version 3
R5(config-if)#exit

Verification


R1(config)#int g0/0
R1(config-if)#ip igmp join-group 232.0.10.1 source 120.0.45.5

R1#sh ip igmp groups 232.0.10.1 detail

Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,

       SS - Static Source, VS - Virtual Source,

       Ac - Group accounted towards access control limit

Interface:      GigabitEthernet0/0

Group:          232.0.10.1

Flags:          L SSM

Uptime:         00:00:46

Group mode:     INCLUDE

Last reporter:  120.0.0.1

Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,

                    V - Virtual, M - SSM Mapping, L - Local,

                    Ac - Channel accounted towards access control limit)

  Source Address   Uptime    v3 Exp   CSR Exp   Fwd  Flags

  120.0.45.5       00:00:46  00:02:46  stopped   Yes  RL

R1#sh ip mroute 232.0.10.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(120.0.45.5, 232.0.10.1), 00:02:20/00:02:15, flags: sPLTI
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3
  Outgoing interface list: Null

R1#sh ip mroute 232.0.10.1 120.0.45.5
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(120.0.45.5, 232.0.10.1), 00:54:00/stopped, flags: sLTI
  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.0.3
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:11:25/00:00:34

R4#sh ip mroute 232.0.10.1 120.0.45.5

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(120.0.45.5, 232.0.10.1), 00:11:47/00:02:33, flags: sT

  Incoming interface: GigabitEthernet2/0, RPF nbr 120.0.45.5

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Sparse, 00:11:47/00:02:33

Multicast - Bi-directional PIM

Overview

Bidirectional PIM is an extension to PIM SM that only uses the shared tree for multicast distribution. Typical use cases are when receivers also need to be senders such as with video conferencing. To enable PIM BiDir simple configure the global command ip pim bidir-enable on all multicast routers and designate an RP for the BiDir Multicast groups.


Concepts tested

• Bidirectional PIM configuration
• PIM SM configuratin
• PIM BSR
• Verification

Topology

Lab Tasks

• Configure PIM SM on all paths between R1 and R5
• Configure bi-direction PIM between R1 and R5 with R4 as the BSR and RP
• Only the group 224.0.0.0 /5 should be bidirectional
• Verify configuration

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R1(config)#ip multicast-routing
R1(config)#ip pim bidir-enable
R1(config)#int g0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#exit

R2(config)#ip multicast-routing

R2(config)#ip pim bidir-enable

R2(config)#int g0/0

R2(config-if)#ip pim sparse-mode

R2(config-if)#exit

R2(config)#int g1/0

R2(config-if)#ip pim sparse-mode

R2(config-if)#exit

R3(config)#ip multicast-routing

R3(config)#ip pim bidir-enable

R3(config)#int g0/0

R3(config-if)#ip pim sparse-mode

R3(config-if)#exit

R3(config)#int g1/0

R3(config-if)#ip pim sparse-mode

R3(config-if)#exit

R3(config)#

R4(config)#ip multicast-routing
R4(config)#ip pim bidir-enable
R4(config)#int g0/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#int g1/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#int loopback 0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#int g2/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
R4(config)#ip access-list standard BIDIR_GROUP
R4(config-std-nacl)#permit 224.0.0.0 7.255.255.255
R4(config-std-nacl)#exit
R4(config)#ip pim rp-candidate loopback 0 group-list BIDIR_GROUP bidir
R4(config)#ip pim bsr-candidate loopback 0
R4(config)#

R5(config)#ip multicast-routing
R5(config)#ip pim bidir-enable
R5(config)#
R5(config)#int g0/0
R5(config-if)#ip pim sparse-mode
R5(config-if)#exit

Verification

R1(config)#int g0/0

R1(config-if)#ip igmp join-group 224.0.10.1

R1(config-if)#

R5(config)#int g0/0

R5(config-if)#ip igmp join-group 224.0.10.1

R5(config-if)#

R4#ping 224.0.10.1 rep 100

Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to 224.0.10.1, timeout is 2 seconds:

Reply to request 0 from 120.0.45.5, 28 ms

Reply to request 0 from 120.0.0.1, 104 ms

Reply to request 0 from 120.0.45.5, 76 ms

Reply to request 0 from 120.0.0.1, 76 ms

R1#sh ip mroute 224.0.10.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.10.1), 00:02:36/00:02:49, RP 4.4.4.4, flags: BPL

  Bidir-Upstream: GigabitEthernet0/0, RPF nbr 120.0.0.3

  Outgoing interface list:

    GigabitEthernet0/0, Bidir-Upstream/Sparse, 00:02:36/00:00:00

R2#sh ip mroute 224.0.10.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.10.1), 00:02:36/00:02:49, RP 4.4.4.4, flags: BP

  Bidir-Upstream: GigabitEthernet1/0, RPF nbr 120.0.24.4

  Outgoing interface list:

    GigabitEthernet1/0, Bidir-Upstream/Sparse, 00:02:36/00:00:00

R3#sh ip mroute 224.0.10.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.10.1), 00:02:36/00:02:49, RP 4.4.4.4, flags: BC

  Bidir-Upstream: GigabitEthernet1/0, RPF nbr 120.0.34.4

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Sparse, 00:02:36/00:02:49

    GigabitEthernet1/0, Bidir-Upstream/Sparse, 00:02:36/00:00:00

R4#sh ip mroute 224.0.10.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.10.1), 00:10:13/00:02:57, RP 4.4.4.4, flags: BC

  Bidir-Upstream: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Sparse, 00:02:36/00:02:52

    GigabitEthernet2/0, Forward/Sparse, 00:03:13/00:02:57

R5#sh ip mroute 224.0.10.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.10.1), 00:03:37/00:02:57, RP 4.4.4.4, flags: BPL

  Bidir-Upstream: GigabitEthernet0/0, RPF nbr 120.0.45.4

  Outgoing interface list:

    GigabitEthernet0/0, Bidir-Upstream/Sparse, 00:03:37/00:00:00

Multicast - PIM Accept register

Overview

PIM Accept-register is a security feature that allows control over which sources and groups can register with the RP. The command is configured in addition to the RP configuration and includes an access list option that controls sources and groups based on the access list configuration below:

ip access-list extended ip source source_wildcard_mask group group_wildcard_mask

The access list above is included in the ip pim accept-register command or optionally a route-map can also be used.

Concepts tested

• Configuring PIM-SM 
• DR election and placement
• PIM accept register

Topology

Lab Tasks

• Configure all devices with PIM-SM on connected interfaces
• Configure R1 as the RP
• Configure R1 so that it only accepts source registrations from the source IP 4.4.4.4 for the group 239.0.0.0/24.
• Test your configuration by having R1's g0/0 join the group 239.0.0.1 and ping the group from R4 sourcing from its loopback 0 interface which should be successful.
• Test your configuration again by having R1's g0/0 interface join the group 239.1.1.1 and have R4 ping the group sourcing it from its loopback 0 interface which should fail.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 1.1.1.1
R1(config)#int g0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#int g1/0

R1(config-if)#ip pim sparse-mode
R1(config)#ip access-list extended ALLOWED_GROUPS
R1(config-ext-nacl)#permit ip host 4.4.4.4 239.0.0.0 0.0.0.255
R1(config-ext-nacl)#deny ip any any <== So we can look at the counters and confirm its working

R1(config-ext-nacl)#exit

R1(config)#ip pim accept-register list ALLOWED_GROUPS

R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 1.1.1.1
R2(config)#int g0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int g1/0

R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing
R3(config)#ip pim rp-address 1.1.1.1
R3(config)#int g0/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#int g1/0

R3(config-if)#ip pim sparse-mode

R4(config)#ip multicast-routing

R4(config)#int g0/0

R4(config-if)#ip pim sparse-mode

R4(config-if)#int g1/0

R4(config-if)#ip pim sparse-mode

Verification

R1#deb ip pim 239.0.0.1

R1(config-if)#ip igmp join-group 239.0.0.1

R4#ping 239.0.0.1 source loopback 0 rep 5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

.

Reply to request 1 from 120.0.0.1, 140 ms

Reply to request 2 from 120.0.0.1, 112 ms

Reply to request 3 from 120.0.0.1, 120 ms

Reply to request 4 from 120.0.0.1, 112 ms

Extended IP access list ALLOWED_GROUPS

    10 permit ip host 4.4.4.4 239.0.0.0 0.0.0.255 (5 matches)

*Nov 20 07:24:26.167: PIM(0): Received v2 Register on GigabitEthernet0/0 from 120.0.24.4

*Nov 20 07:24:26.167:      for 4.4.4.4, group 239.0.0.1

*Nov 20 07:24:26.175: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (4.4.4.4, 239.0.0.1).

*Nov 20 07:24:26.179: PIM(0): Send v2 Register-Stop to 120.0.24.4 for 4.4.4.4, group 239.0.0.1

Now lets try a group that isn't in our access list.

R4#ping 239.1.1.1 source loopback 0 rep 5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

.....

R1:

*Nov 20 07:26:23.643: %PIM-4-INVALID_SRC_REG: Received Register from 120.0.24.4 for (4.4.4.4, 239.1.1.1), not willing to be RP

Multicast - PIM DR election

Overview

The PIM DR in a sparse mode environment is responsible for source and receiver registration with the RP. The DR receives IGMP query report notices from interested receivers and encapsulates those messages into unicast packets and forwards them to its configured RP. Since sources don't notify they simply start sending traffic, the DR when it receives an initial multicast packet for a *,G entry for its configure RP, it will encapsulate the packet and forward it to the RP for registration via unicast. This lab will focus on DR election and placement.

Concepts tested

• IP PIM-SM DR placement
• IP PIM RP
• IP PIM-SM configuration and troubleshooting

Topology

Lab Tasks

• Configure PIM sparse mode on all interfaces in the path between the source and receiver hosts
• Configure PIM sparse mode on R3's g0/0 interface
• Configure R1 and R2 so that the host RP becomes the RP. 
• Do not configure source, receiver, or R3 as static RPs.
• Test your configuration by having receiver join its g0/0 interface to the 239.1.1.1 group then have source ping the group.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

Receiver(config)#ip multicast-routing
Receiver(config)#int g0/0
Receiver(config-if)#ip pim sparse-mode

R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 5.5.5.5

R1(config)#int g0/0

R1(config-if)#ip pim sparse-mode
R1(config-if)#int g1/0
R1(config-if)#ip pim sparse-mode

RP(config)#ip multicast-routing

RPconfig)#ip pim rp-address 5.5.5.5

RP(config)#int lo 0

RP(config-if)#ip pim sparse-mode

RP(config)#int g0/0

RP(config-if)#ip pim sparse-mode

RP(config-if)#int g1/0

RP(config-if)#ip pim sparse-mode

R2(config)#ip multicast-routing

R2(config)#ip pim rp-address 5.5.5.5

R2(config)#int g0/0

R2(config-if)#ip pim sparse-mode

R2(config-if)#int g1/0

R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing

R3(config)#int g0/0

R3(config-if)#ip pim sparse-mode

Source(config)#ip multicast-routing

Source(config)#int g0/0

Source(config-if)#ip pim sparse-mode

Verification

Lets begin our verification by joining receiver to the group 239.1.1.1 and attempting to ping it.

Receiver(config)#int g0/0

Receiver(config-if)#ip igmp join-group 239.1.1.1

Source#ping 239.1.1.1 rep 1000

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

...........

It failed, why? lets investigate.

Lets first make sure our PIM domain is properly configured between receiver and source. A quick way to check this is with mtrace at the reciever toward the source. This tool verifies SPT via RPF to the source. Keep in mind this doesn't necessarily verify the shared tree from receiver to RP and RP to source. In our case they are the same path.

Receiver#mtrace 120.0.45.1

Type escape sequence to abort.

Mtrace from 120.0.45.1 to 120.0.0.254 via RPF

From source (?) to destination (?)

Querying full reverse path...

 0  120.0.0.254

-1  120.0.0.254 None  [120.0.45.0/24]

-2  120.0.0.1 None  [120.0.45.0/24]

-3  120.0.12.5 None  [120.0.45.0/24]

-4  120.0.13.2 PIM  [120.0.45.0/24]

-5  120.0.45.1

Looks OK. Now lets look at our *,G and S,G tables.

R1#sh ip mroute 239.1.1.1

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:02:01/00:02:38, RP 5.5.5.5, flags: SP

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.12.5

  Outgoing interface list: Null

RP#sh ip mroute 239.1.1.1

Group 239.1.1.1 not found

R2#sh ip mroute 239.1.1.1

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:01:55/stopped, RP 5.5.5.5, flags: SP

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.13.5

  Outgoing interface list: Null

(120.0.45.1, 239.1.1.1), 00:01:55/00:01:03, flags: PT

  Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.45.1

  Outgoing interface list: Null

So the obvious issue appears to be that the RP does not know about 239.1.1.1. So the RP has not been notified of the receiver or the source.

In this case based on our multicast design the next hop routes R1 and R2 should be notifying the RP but they are not. 

For a receiver in a sparse mode environment the next hop PIM router is responsible for sending join/prune messages to the RP for registration. On a LAN that responsibility falls to the elected DR. lets see who are the DRs.

R1#sh ip pim int g0/0 det

GigabitEthernet0/0 is up, line protocol is up

  Internet address is 120.0.0.1/24

  Multicast switching: fast

  Multicast packets in/out: 0/442

  Multicast TTL threshold: 0

  PIM: enabled

    PIM version: 2, mode: sparse

    PIM version: 2, mode: sparse

    PIM DR: 120.0.0.254

    PIM neighbor count: 1

    PIM Hello/Query interval: 30 seconds

    PIM Hello packets in/out: 721/741

    PIM State-Refresh processing: enabled

    PIM State-Refresh origination: disabled

    PIM NBMA mode: disabled

    PIM ATM multipoint signalling: disabled

    PIM domain border: disabled

    PIM neighbors rpf proxy capable: TRUE

  Multicast Tagswitching: disabled

R2#sh ip pim int g0/0 det

GigabitEthernet0/0 is up, line protocol is up

  Internet address is 120.0.45.2/24

  Multicast switching: fast

  Multicast packets in/out: 591/0

  Multicast TTL threshold: 0

  PIM: enabled

    PIM version: 2, mode: sparse

    PIM version: 2, mode: sparse

    PIM DR: 120.0.45.254

    PIM neighbor count: 2

    PIM Hello/Query interval: 30 seconds

    PIM Hello packets in/out: 1460/744

    PIM State-Refresh processing: enabled

    PIM State-Refresh origination: disabled

    PIM NBMA mode: disabled

    PIM ATM multipoint signalling: disabled

    PIM domain border: disabled

    PIM neighbors rpf proxy capable: TRUE

  Multicast Tagswitching: disabled

The reciever and R3 our the DR's for their respective LANs. But they are not configures as RPs nor do they know about the DR.

Receiver#sh ip pim rp map

PIM Group-to-RP Mappings

R3#sh ip pim rp map

PIM Group-to-RP Mappings

So for the receiver LAN the host receiver is responsible for taking IGMP membership reports and turning them into PIM join/prune messages and forwarding them to the RP for the appropriate *,G entry. But it is not configured with an RP so it can't do this.

The same is essentially true for R3 accept sources don't notify they just send traffic. But the DR with a source on its local LAN is responsible for taking the mcast packets and encapsulating them and forwarding them on to the RP as unicast packets for registration, but again its not configured with an RP so it can't do this.

The solution is to either configure these devices with RP information or simply change the DR for each LAN. We will change the DR.

R1(config-if)#ip pim dr-priority 2

R1(config-if)#

*Nov 18 23:30:14.358: %PIM-5-DRCHG: DR change from neighbor 120.0.0.254 to 120.0.0.1 on interface GigabitEthernet0/0

R2(config-if)#ip pim dr-priority 2

R2(config-if)#

*Nov 18 23:30:52.618: %PIM-5-DRCHG: DR change from neighbor 120.0.45.254 to 120.0.45.2 on interface GigabitEthernet0/0

Now lets ping our group again and see what happens. It may be necessary to clear your mroute cache and re-join the group on the receiver to ensure everything gets registered properly.

Source#ping 239.1.1.1 rep 1000

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 120.0.0.254, 220 ms

Reply to request 1 from 120.0.0.254, 128 ms

Reply to request 1 from 120.0.0.254, 196 ms

Reply to request 2 from 120.0.0.254, 72 ms

Reply to request 3 from 120.0.0.254, 112 ms

Sources:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/multicast/configuration_guide/b_mc_3se_3850_cg/b_mc_3se_3850_cg_chapter_01101.html#GUID-8A53F572-FFF7-47B0-BBC9-67C2E3F15CF3

Multicast - PIM Assert

Overview

When multiple multicast devices attempt to simultaneously send multicast traffic onto the same LAN segment the potential for packet duplication can occur. PIM employees a mechanism called PIM assert to prevent this scenario by electing a designated sender for the LAN segment responsible for forwarding multicast traffic onto the shared LAN segment. This lab will focus on this mechanism

Concepts tested

• PIM dense mode configuration
• PIM assert election metric manipulation

Topology

Lab Tasks

• Enable PIM dense mode on all interfaces from the receiver to the source
• Ensure the R3 is elected the PIM assert winner on the 120.0.0.0/24 shared network
• Do not modify any dynamic routing configuration or metrics to do this.
• For testing purpose have the reciever join the group 232.0.0.2 on its G0/0 interface
• Have the source ping the group 232.0.0.2 and confirm R3 win's the assert election and the ping is successful.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

Begin by configuring our PIM neighbors.

Source(config)#ip multicast-routing
Source(config)#int g0/0
Source(config-if)#ip pim dense-mode
Source(config-if)#ip igmp join-group 232.0.0.2

R4(config)#ip multicast-routing

R4(config-if)#int g1/0

R4(config-if)#ip pim dense-mode
R4(config-if)#int g2/0
R4(config-if)#ip pim dense-mode
R4(config-if)#int s3/0
R4(config-if)#ip pim dense-mode

R3(config)#ip multicast-routing

R3(config)#int g0/0

R3(config-if)#ip pim dense-mode

R3(config-if)#int g1/0

R3(config-if)#ip pim dense-mode

R2(config)#ip multicast-routing

R2(config)#int g0/0

R2(config-if)#ip pim dense-mode

R2(config-if)#int s2/0

R2(config-if)#ip pim dense-mode

Receiver(config)#ip multicast-routing

Receiver(config)#int g0/0

Receiver(config-if)#ip pim dense-mode

Verification

You can confirm PIM neighbor with the following command.

Receiver#sho ip pim neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable

Neighbor          Interface                Uptime/Expires    Ver   DR

Address                                                            Prio/Mode

120.0.0.2         GigabitEthernet0/0       00:22:38/00:01:43 v2    1 / S P G

120.0.0.3         GigabitEthernet0/0       00:47:59/00:01:44 v2    1 / DR S P G

Do this for the remaining routers and confirm you see neighbors for every interface on each router where PIM was enabled.

Next you can confirm that the reciever has successfully registered with the following command.

Now lets test our receiver is properly getting multicast packets via our preferred path.

Source#ping 232.0.0.2 rep 500

Type escape sequence to abort.

Sending 500, 100-byte ICMP Echos to 232.0.0.2, timeout is 2 seconds:

Reply to request 0 from 120.0.45.5, 48 ms

Reply to request 1 from 120.0.45.5, 8 ms

Reply to request 1 from 120.0.0.1, 244 ms

Reply to request 2 from 120.0.45.5, 12 ms

Reply to request 2 from 120.0.0.1, 116 ms

Below indicates that R2 has actually won the election so it is forwarding multicast traffic onto the 120.0.0.0/24 network which is not what we want.

R2#sh ip mroute 232.0.0.2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:33:53/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:11:57/00:00:00

    Serial2/0, Forward/Dense, 00:33:53/00:00:00

(120.0.45.5, 232.0.0.2), 00:00:33/00:02:26, flags: T

  Incoming interface: Serial2/0, RPF nbr 120.0.24.4

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:00:33/00:00:00, A

We can see this if we enable debug.

R3#debug ip pim

R$#debug ip pim

R2 output:

*Nov 15 16:53:39.623: PIM(0): Send v2 Assert on GigabitEthernet0/0 for 232.0.0.2, source 120.0.45.5, metric [90/2170112]

*Nov 15 16:53:39.627: PIM(0): Assert metric to source 120.0.45.5 is [90/2170112]

*Nov 15 16:53:39.631: PIM(0): We win, our metric [90/2170112]

*Nov 15 16:53:39.631: PIM(0): (120.0.45.5/32, 232.0.0.2) oif GigabitEthernet0/0 in Forward state

R3 output:

*Nov 15 16:53:39.251: PIM(0): Received v2 Assert on GigabitEthernet0/0 from 120.0.0.2

*Nov 15 16:53:39.255: PIM(0): Assert metric to source 120.0.45.5 is [90/2170112]

*Nov 15 16:53:39.255: PIM(0): We lose, our metric [110/2]

*Nov 15 16:53:39.259: PIM(0): Prune GigabitEthernet0/0/232.0.0.2 from (120.0.45.5/32, 232.0.0.2)

So how do we fix this to meet the lab requirements?

When a multiple routers attempt to simultaneously send multicast traffic onto the same network with the same (S,G) each router will immediately send a PIM assert message to prevent duplication of traffic. The election is won based on the following criteria.

First, the IGP AD is compared, with the better AD winning the election

If the AD is equal then the metric is compared the better metric winning the election

If both AD and Metric are equal then the router with the higher IP address wins.

The loser of the election it will remove its (S,G) state and prune its interfaces.

So to fix this issue we need to get R3 to win this election. So to do this and meet the lab requirements we need to have R3 have a better multicast route with a better AD. 

R3(config)#ip mroute 120.0.45.0 255.255.255.0 120.0.34.4

The above command should fix this problem.

R3#sh ip mroute 232.0.0.2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:49:13/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Dense, 00:49:13/00:00:00

    GigabitEthernet0/0, Forward/Dense, 00:49:13/00:00:00

(120.0.45.5, 232.0.0.2), 00:00:37/00:02:22, flags: T

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.34.4, Mroute

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:00:37/00:00:00, A


R2:

*Nov 15 17:08:55.835: PIM(0): Received v2 Assert on GigabitEthernet0/0 from 120.0.0.3
*Nov 15 17:08:55.835: PIM(0): Assert metric to source 120.0.45.5 is [0/0]
*Nov 15 17:08:55.835: PIM(0): We lose, our metric [90/2170112]

R3:

*Nov 15 17:08:56.367: PIM(0): Send v2 Assert on GigabitEthernet0/0 for 232.0.0.2, source 120.0.45.5, metric [0/0]
*Nov 15 17:08:56.367: PIM(0): Assert metric to source 120.0.45.5 is [0/0]
*Nov 15 17:08:56.367: PIM(0): We win, our metric [0/0]

EIGRP Lab 1 - Multi-AF Mode

With the release of IOS 15 came several new enhancements and features one of which is EIGRP named mode. EIGRP has the advantage of consolidating all EIGRP commands into a single hierarchical set of configuration under router mode. Multiple address families and autonomous system can be configured under a single named instance of EIGRP. This lab will look at how to use named mode to configure basic EIGRP peering and prefix advertisement.

Tasks:

-Create loopback address on R1 using IP 1.1.1.1/24

-Create a loopback address on R2 using IP 2.2.2.2/24

-Create Named instances called EIGRP_R1 and EIGRP_R2 on R1 and R2 respectively

-Configure IPV4 address family to use autonomous system 10

-Establish neighborship between R1 and R2 using their directly connected links

-Advertise each routers loopback address

Topology

GNS3 files: Link

  

Solution:

We begin by creating our loopback addresses.

R1(config)#int loopback 0

R1(config-if)#ip address 1.1.1.1 255.255.255.0

R2(config)#int loopback 0

R2(config-if)#ip address 2.2.2.2 255.255.255.0

Next we create our named EIGRP instances on R1 and R1. The syntax is essentially the same to create the instance and get into router mode as with the classic mode. We type router eigrp then the instance name instead of the autonomous system number. Once in named router mode we move into address family mode using the command address-family ipv4 unicast [autonomous-system-number]. This is slightly different syntax compared to say BGP's address family syntax. From there we add our network statements to define which interfaces will participate in EIGRP.

R1(config)#router eigrp EIGRP_R1

R1(config-router)#address-family ipv4 unicast autonomous-system 10

R1(config-router-af)#network 145.1.0.0 0.0.255.255

R1(config-router-af)#network 1.1.1.0 0.0.0.255

R2(config)#router eigrp EIGRP_R2

R2(config-router)#address-family ipv4 unicast autonomous-system 10

R2(config-router-af)#network 145.1.0.0 0.0.255.255

R2(config-router-af)#network 2.2.2.0 0.0.0.255

With the configuration completed we need to verify that what we have done is working as expected. First lets confirm we have established peering between R1 and R2.

Next lets confirm we have our loopback networks in the global RIB table.

Everything looks good. I hope you enjoyed this brief lab on EIGRP named mode.

Sources:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-classic-to-named.html