IEOC - Internetwork Expert's Online Community

Instead of doing a route map, I've made an access list:

ip pim accept-register list 100
access-list 100 permit ip host 155.1.146.6 any
access-list 100 deny   ip 155.1.146.0 0.0.0.255 any
access-list 100 permit ip any any

2 questions on this:

- Should I always use 224.0.0.0/15.255.255.255 as multicast range (instead of being lazy and putting 'any' in there) I these cases I ask myself if I'd do it in production, but I'm not really sure, because I figure the set of IP's for the multicast groups is limited by protocol anyway. Does this matter in any way?

- Does it make any difference using an access-list instead of a route map? (as always, if it isn't specified, will I lose points if I do? =)

This is much cleaner, and the way I chose as well.

I've been trying to get this to work for a while in dynagen, using both methods the one in the solution and by using an access list and for some reason that I can't work out the RP which is R5 it says that its not willing to be the RP for the (S,G) but it still works.. ie the ping is successful and the S,G appears in the show ip mroute on the RP.

Can anyone please advise on this issue?

Rack1R1#ping 224.10.10.10 source 155.1.146.1 rep 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 155.1.146.1

Reply to request 0 from 155.1.108.10, 296 ms

Rack1R5

*Mar  1 12:02:16.937: %PIM-4-INVALID_SRC_REG: Received Register from 155.1.0.1 f
or (155.1.146.1, 224.10.10.10), not willing to be RP

Rack1R5#sh ip mroute
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.10.10.10), 00:14:34/00:03:24, RP 150.1.5.5, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial1/0, Forward/Sparse-Dense, 00:08:22/00:03:24
    Ethernet0/0, Forward/Sparse-Dense, 00:14:34/00:02:42

(155.1.146.1, 224.10.10.10), 00:02:43/00:03:22, flags: JT
  Incoming interface: Serial1/0, RPF nbr 155.1.0.4
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse-Dense, 00:02:43/00:02:42

(*, 224.110.110.110), 00:14:26/00:02:52, RP 150.1.5.5, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse-Dense, 00:14:26/00:02:52

(*, 224.0.1.40), 00:15:01/00:02:37, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial1/0, Forward/Sparse-Dense, 00:15:04/00:00:00
    Ethernet0/0, Forward/Sparse-Dense, 00:15:04/00:00:00

I get the same Chris but I didn't notice until reading this thread.

I get that too...

%PIM-4-INVALID_SRC_REG: Received Register from 155.1.0.1 for (155.1.146.1, 224.10.10.10), not willing to be RP

(155.1.0.1, 224.10.10.10), 00:00:51/00:02:48, flags: T
  Incoming interface: Serial1/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse-Dense, 00:00:51/00:02:38

I think I'll just chalk it up to a Dynamips oddity.

I was using the "graded-labs" racks and tested this.

I reproduced the issue (from this thread) so thought it could be a couple of things:

1) source interface should be the vlan 146 interface for R1 or R4

2) from the dcoumentation there is an issue when the registering router (toward the RP is also the source)

I found that it was possibly the #2 option that was catching us (actually it is not 100% clear: since the documentation states when the DR/RP and source are the same), see below: (I validated by changing the iP address on R6 which is what the solution guide suggests)

I tested using the VLAN 146 as the source form R4 and R1 and pinging 224.110.110.110.  R1 was the DR but R4 is just directly connected to the RP.

Usage Guidelines

Use this command to prevent unauthorized sources from registering with the RP. If an unauthorized source sends a register message to the RP, the RP will immediately send back a register-stop message.

The access list or route map provided for the ip pim accept-register command should only filter on IP source addresses and IP destination addresses. Filtering on other fields (for example, IP protocol or UDP port number) will not be effective and may cause undesired traffic to be forwarded from the RP down the shared tree to multicast group members. If more complex filtering is desired, use the ip multicast boundary command instead.

Note If the RP is also the first hop designated router (DR) for directly connected sources, PIM register packets will not be filtered using the ip pim accept-register command. For this case, use the ip multicast boundary command to filter the directly connected source traffic.

Examples

The following example shows how to permit register packets for source address 172.16.10.1 sending to the SSM group range (232.0.0.0/8). All other PIM register messages not matching the extended access list (ssm-range) are denied. These statements should be configured on all candidate RPs because candidate RPs will receive PIM registers from first hop routers.

ip pim accept-register list ssm-range

ip access-list extended ssm-range

 permit ip 172.16.10.1 0.0.0.255 232.0.0.0 0.255.255.255

Related Commands

Hi Guys and INE 

I have been testing this and getting the same output. Instead of making R1 or R4 as a source, i attempted Ping from the SW1 interface vlan 146 (e.g, 155.1.146.7/24) and it shows the desired behavior on the RP:

Received v2 Register on Serial0/0 from 155.1.0.1

*Mar  2 00:51:59.457:      (Data-header) for 155.1.146.7, group 224.10.10.10

*Mar  2 00:51:59.461: %PIM-4-INVALID_SRC_REG: Received Register from 155.1.0.1 for (155.1.146.7, 224.10.10.10), not willing to be RP

Rack1R5#

*Mar  2 00:51:59.465: PIM(0): Register for 155.1.146.7, group 224.10.10.10 rejected

*Mar  2 00:51:59.469: PIM(0): Send v2 Register-Stop to 155.1.0.1 for 155.1.146.7, group 224.10.10.10

Everthing seems to work fine but  just after that we see this message on R5 which shows a Join message coming from SW2, see the underlined text:

Mar  2 00:52:19.469: PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 155.1.58.8, to us

*Mar  2 00:52:19.473: PIM(0): Join-list: (*, 224.110.110.110), RPT-bit set, WC-bit set, S-bit set

*Mar  2 00:52:19.477: PIM(0): Update FastEthernet0/0/155.1.58.8 to (*, 224.110.110.110), Forward state, by PIM *G Join

*Mar  2 00:52:19.477: PIM(0): Update FastEthernet0/0/155.1.58.8 to (155.1.146.6, 224.110.110.110), Forward state, by PIM *G Join

*Mar  2 00:52:19.877: PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 155.1.58.8, to us

*Mar  2 00:52:19.877: PIM(0): Join-list: (155.1.146.7/32, 224.10.10.10), S-bit set

and After that, an entry is created on R5 for VLAN 146 interface (source SW1) that should not have been created:

*Mar  2 00:52:54.221: PIM(0): Insert (155.1.146.7,224.10.10.10) join in nbr 155.1.45.4's queue

*Mar  2 00:52:54.229: PIM(0): Building Join/Prune packet for nbr 155.1.45.4

*Mar  2 00:52:54.229: PIM(0): Adding v2 (155.1.146.7/32, 224.10.10.10), S-bit Join

*Mar  2 00:52:54.229: PIM(0): Send v2 join/prune to 155.1.45.4 (Serial0/1)

*Mar  2 00:52:55.221: PIM(0): Send RP-reachability for 224.110.110.110 on FastEthernet0/0

Rack1R5#show ip mroute 155.1.146.7 224.10.10.10

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,

       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

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

 Timers: Uptime/Expires

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

(155.1.146.7, 224.10.10.10), 00:28:52/00:03:29, flags: T

  Incoming interface: Serial0/1, RPF nbr 155.1.45.4

  Outgoing interface list:

    FastEthernet0/0, Forward/Sparse-Dense, 00:28:29/00:02:45

The configuration is alright (i used the Access list version and not the route-map) however for some reason this is not working, can i assume it as some anomaly of the multicast where sometimes you need to perform "clear ip mroute " or Reloading your routers a number of times?

I am using Routers on Dynamips connected to Real 4 x Cisco 3750 Catalyst switches.

Can someone from the INE comment on this one as this is a feature that could be very well asked in the CCIE lab.

Regards

Muhammad

Just in regards to my this email, i am thinking that it is because of the dense mode fallback which is allowing this to work. This is the only thing coming in my mind after seeing the Join message from SW2 (155.1.58.8).

Your Comments awaited.

Muhammad,

We need to have some additional questions answered before we can table your observations.

1. Are pings successful at any time during your testing from SW1?

2. Are you using the most recent version of the workbook? (we think not based on the contents of your post)

3. Are you using gradedlabs equipment? If not are you using your own rack or dynamips.

The sooner you get us these answers the sooner we can get you a response.

-- The TechEdit Team

Answer to your queries:

1. Yes, Pings are successful from SW1 which should not have been

2. Yes i am a subscriber of Volume-1, and have got the latest workbook which was just updated recently (2010-02-08 22:45:40)

3. I am using Dynamips for Routers R1 to R6, while they are connected to Real Cisco 3750 switches.

Thanks for the information.

In an attempt to reverify this lab we just loaded it up on Gradelabs equipment.  We of course had to change ip addresses to conform to the rack numbering sequence. Our output and verification matched the workbook exactly.  We encountered no issues where pings where successful from SW1 to R5 (no matter how long we waited).  As specified in the documentation there are issues pinging from R1 and R4 but none from SW1. Given our inability to reproduce your issue we are at a loss as to how to advise you to proceed.  Perhaps there is an issue with your dynamips session.

A number of us in the TechEdit Team work closely with dynamips and we have seen some strange behaviour exhibited when working with dynamips and technologies like multicasting.  I understand this is not what you want to hear but given that lab functionality has been verified both during the previous editing session and now during this check, we must assume the issue is not related to the lab configuration.

--The TechEdit Team

Hi TechTeam

I can't doubt your effort and lab verification, but this has led me to be dissapointed. If this is the case that dynamips have issues, then INE should identify them openly in the blogs. Why then we have a volume-2 workbook covered for dynamips as well. If the correct output is not obtained, how a student will feel comfortable in appearing for real exam by using dynamips. 

I now doubt the Dynamips functionality as a whole, how would now i differentiate b/w the correct and wrong configurations if it's behavior is strange.

We have workbooks that incorporate dynamips becuase its a tool that many students use to prepare for the exam and we want them to have reliable tools to do so.

Dynamips is an emulation environment that is used by hundreds of people.  But its not an actual router. There are dozens of issues that impact functionality with regard to dynamips.  These include idlepc values, cpu performance, and misconfigurations. Add to this the "load" generated by protocols like multicasting, BGP and OSPF.  Keep in mind that there is an entire application substrate running behind the scenes. We recognize that Dynamips is a valid and useful tool, but we also have to embrace it's short falls. There are forums where these issues are posted and shared by developers and the software designers (a common one is where interfaces just stop sending data, they stay up but won't send data).

I personally, never recommend learning a protocol on Dynamips or GNS3.  I learn on live equipment and once I UNDERSTAND how things work then I use Dynamips (that way I can recognize strange behavior).  Please note that there are no Volume 1 Labs designed for Dynamips. The Volume 2 Dynamips Labs where designed for Dynamips and compensate for its shortfalls in the lab design.

Issues like these are why we standardized Volume One on the Gradelabs equipment or matching configurations.

Hope This Help!

--The TechEdit Team

We have workbooks that incorporate dynamips becuase its a tool that many students use to prepare for the exam and we want them to have reliable tools to do so.

Dynamips is an emulation environment that is used by hundreds of people.  But its not an actual router. There are dozens of issues that impact functionality with regard to dynamips.  These include idlepc values, cpu performance, and misconfigurations. Add to this the "load" generated by protocols like multicasting, BGP and OSPF.  Keep in mind that there is an entire application substrate running behind the scenes. We recognize that Dynamips is a valid and useful tool, but we also have to embrace it's short falls. There are forums where these issues are posted and shared by developers and the software designers (a common one is where interfaces just stop sending data, they stay up but won't send data).

I personally, never recommend learning a protocol on Dynamips or GNS3.  I learn on live equipment and once I UNDERSTAND how things work then I use Dynamips (that way I can recognize strange behavior).  Please note that there are no Volume 1 Labs designed for Dynamips. The Volume 2 Dynamips Labs where designed for Dynamips and compensate for its shortfalls in the lab design.

Issues like these are why we standardized Volume One on the Gradelabs equipment or matching configurations.

Hope This Help!

--The TechEdit Team

Internetwork Expert - The Industry Leader in CCIE Preparation
http://www.internetworkexpert.com

Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx

I am also using dynamips/ubuntu connecting 6 routers to 2xc3560s and 2x3550s. All routers are c3660s running C3640-JK9O3S-M), Version 12.4(10a) I didnt have any issues on this task.

The few times I have ran across issues like this I've used wireshark to sniff packets leaving/entering the routers interface to verify that the data is being sent/received. Or running associated debugs on the switches.  Its not a solution but just some comfort that 'hey there is high probability this is configured correctly and would work on actual equipment'. HTH