http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm#wp1003511 ---------- Forwarded message ---------- From: "Ralph" To: dusth@comcast.net Date: Thu, 01 Sep 2005 08:59:49 -0400 Subject: Re igmp and multicast boundary Dustin, Try this. -----Original Message----- From: "Chris Lewis (chrlewis )" To: "Ralph" , Date: Tue, 23 Aug 2005 22:22:34 -0400 Subject: RE: Multicast Filtering The following is what I use to remind myself of the options for filtering multicast traffic: If you want to stop certain multicast groups from passing through an interface, that is multicast boundary, an example of how to deny anything in the 235 range and permit everything else: Interface fa0/0 Ip multicast boundary 1 filter-autorp ! Access-list 1 deny 235.0.0.0 0.255.255.255 Access-list 1 permit 224.0.0.0 15.255.255.255 If you want to control which multicast group hosts attached to a router interface can join, that is the igmp access-group, shown here for 238.1.2.3 and the whole 235. range Interface fa0/0 Ip igmp access-group 1 ! Access-list 1 deny 238.1.2.3 Access-list 1 deny 235.0.0.0 0.255.255.255 Access-list 1 permit any I am not familiar with the igmp profile command, but it looks like that it is the 3550 way to accomplish the above, ip igmp profile is not an option under interface configuration on a router. The documentation says the following: From the IGMP profile configuration mode, you can specify the parameters of the IGMP profile to be used for filtering IGMP join requests from a port. Configuration is as below: Switch # config t Switch(config) # ip igmp profile 4 Switch(config-igmp-profile)# permit Switch(config-igmp-profile)# range 229.9.9.0 Switch(config-igmp-profile)# end Switch(config)# interface fastethernet2/12 Switch(config-if)# ip igmp filter 4 To limit which routers can become PIM neighbors (in this case stopping neighbor 172.16.15.1) Interface fa0/0 Ip pim neighbor-filter 1 Access-list 1 deny 172.16.15.1 Access-list 1 permit any To prevent multicast packets with TTLs less than 15 from being forwarded Interface fa0/0 Ip multicast ttl-threshold 14 Chris -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Ralph Sent: Saturday, August 20, 2005 7:29 PM To: ccielab@groupstudy.com Subject: Multicast Filtering Guys: I'm trying to understand the various ways of filtering multicast traffic. I need some assistance with the use of the following multicast commands; under what circumstance would some use one instead of the other: 1. ip multicast boundary 2. ip igmp access-group 3. igmp profile TIA Ralph --- ---------- Forwarded message ---------- From: "simon hart" To: , Date: Thu, 1 Sep 2005 14:14:12 +0100 Subject: RE: ip multicast boundary vs. ip igmp access-group Dustin, The difference between the two commands are: ip multicast boundary - this will prevent mulicast traffic within the specified access list from transiting the interface, thus blocking the defined traffic. ip igmp access-group - this will prevent hosts within the attached subnet from joining multicast groups identified within the associated access list. This command does not stop the multicast traffic from transiting the interface (ie to a PIM neighbor), just stops the hosts from joining. HTH Simon -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of dusth@comcast.net Sent: 01 September 2005 13:43 To: ccielab@groupstudy.com Subject: ip multicast boundary vs. ip igmp access-group Hello group, I'm confused the difference between < ip multicast boundary vs. ip igmp access-group>. I do not know exactly when to use one or the other. Is command used when filter out only one single multicast stream? In contrast, is command used when need to filter a range of multicast stream? Please help. Thanks, Dustin -- Subject: Re: Multicast forwarding fails with fast switching but OK with process.Can U help? > Hi, > > this is a normal behaviour with Multicast over NBMA. > It works with "pseudobroadcast", that means, by replicating > the packets on the hub to the spoke VC's, when broadcast is > enabled per auto-mapping ( inverse-arp ) or manual mapping > ( frame-relay map IP-address dlci DLCi-number braodcast ). > > The hub must pseudobroadcast because of the split horizon rule, > but that can be only done on layer 2 with process-switching on > a router. > > To override this behavior, configure on the hub interface the > command "ip pim nbma-mode". > Now the hub router can replicate the packets on layer 3 > with fast-switching. > > When you take a look in the Multicast routing table you will > notice, that every spoke-connection joined for a multicast > group will appear as a seperate entry in the > Outgoing Interface List ( OIL ). > For that reason, no more problems will noticed, when a spoke > router leaves a multicast-group while working in PIM DM. > > Hope that helps. > > W. Marschner > CCIE #8232 > > > ----- Original Message ----- > From: "Duongla" > To: > Sent: Friday, September 02, 2005 7:15 PM > Subject: Multicast forwarding fails with fast switching but OK with > process.Can U help? > > > > Hi group, > > > > I have tried the following scenario on 4 Cisco 2600: > > R1,R2 and R3 are connected via multipoint frame-relay (physical > > interface), R2 > > is the HUB. > > Routing is running normally, all routers can reach all subnets. > > R2 f0/0 connect to R4 whichs is a test router, responsible for genarating > > multcast traffic. > > R1,R2,R3 are all configured with multicast PIM sparse mode and loopback > > interface of R3 > > is configured manually on 3 routers as RP. > > R1f0/0 and R3 f0/0 are configured to join group 239.1.1.1 > > Before PING 239.1.1.1 from R4, the mroute tables int 3 router are in > > normal > > state: > > R1,R3 send Join msg to RP which is R2, so R2 has a (*,239.1.1.1) entry in > > its > > mroute table. > > For first PING 239.1.1.1 from R4, both R1 and R3 reply. > > From second PING, just R3 replies. > > Do debug ip mpacket fastswitch 239.1.1.1, I saw R2 forwarded the mcast > > packet > > from R4 out serial0/0 > > (the frame relay port, connecting to R1 and R3) but just R3 got the packet > > and > > sent PING echo-reply. > > One interesting notice is: router with higher IP address of frame relay > > interface receives the PING mcast packet. > > In this case R3. > > If I turn off fast switching on R2 s0/0 then both R1 and R3 receive mcast > > packet. > > > > Can anyone help clarify the above behaviour ? > > Thanks in advance. > > Duongla --- Subject: RE: switchort block multicast IGMP only applies with IP multicast joins. That will be presented as MAC addresses that begin with 01-00-5E. However, there are many more multicast/group packets at Layer 2 than just those. This command applies to ALL Layer 2 multicast traffic, not just the Layer 2 presentation of IP multicast. How do you know whether a frame received is multicast or not? (Hint, look up the I/G bit) ----- Subject: RE: switchort block multicast You're thinking of IP multicast. The switch is a layer 2 device and is basing decisions on Layer 2 multicast traffic. -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of simon hart Sent: Saturday, September 03, 2005 9:11 AM To: Group Study Subject: switchort block multicast Hi All, I am trying to understand the validity of this command. This command blocks unknown multicast traffic. If IGMP snooping is enabled on a switch, then surely this command is not necessary. My understanding is that with igmp snooping unless a reciever on a port has specifically joined a group then multicast traffic will not be forward from that port. If a reciever joins a group then the port will forward the mcast stream by virtue of the fact it now has a known mac address to deliver too. Therefore would this command be only used when igmp snooping is disabled --- Hello Mohammed, there is no need for configuring a loopback interface with a "ip pim sparse-mode" together with static RP or Auto-RP ( on the Candidate router ). You must only configure "ip pim sparse-mode" for a loopback interface on a Mapping Agent for Auto-RP! The reason for this is, that the loopback-interface with it's address is used for sending PIM discovery messages. Kind regards Wolfgang Marschner CCSI #8232, CSSI #23525 ---- ---------- Forwarded message ---------- From: "Curt Girardin" To: "Cisco certification" Date: Tue, 13 Sep 2005 19:13:48 -0400 Subject: RE: OT - multicast generator Dan, I use the NTP server/client that's built into cisco routers and switches. The 2600/3600/3550 devices all support both NTP multicast server and NTP multicast client. It might not be quite as cool as streaming media, but it works for study purposes... Curt -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Gene Thorne Sent: Tuesday, September 13, 2005 11:33 AM To: 'Cisco certification' Subject: RE: OT - multicast generator That multimedia streamer looks interesting, but if you would prefer a minimalist app, try mgen http://mgen.pf.itd.nrl.navy.mil/ It takes a few minutes to become comfortable with the format of the scripts, but once you do its easy to use. -gt -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Jaycee Cockburn - BCX SS Sent: Tuesday, September 13, 2005 10:07 AM To: Danshtr; Cisco certification Subject: RE: OT - multicast generator Hi D, I use VLC... It's a free multimedia app, so I stream mp3 or video to a multicast address as I feel... Just make sure you increase the ttl value in the options otherwise it will not work for you. http://www.videolan.org/vlc/ It also works on most OS'... Cheers JC -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Danshtr Sent: 13 September 2005 04:51 PM To: Cisco certification Subject: OT - multicast generator Hello all, I am looking for a tool which can generate multicast packets and can also listen for them. I need it for testing mutlicast, and pings are not good anough. --- Wouldn't the Multicast Routing Monitor give us what we need ...and something that is fair game on the lab test. Dave -----Original Message----- From: nobody@groupstudy.com To: Danshtr; Cisco certification Sent: 9/13/2005 11:04 AM Subject: RE: OT - multicast generator Dan, Use any router. rtr 1 type udpEcho dest-ipaddr 225.25.25.25 dest-port 31337 source-ipaddr 162.1.55.5 source-port 31337 control disable timeout 1 frequency 5 rtr schedule 1 start-time now --- --------- Forwarded message ---------- From: "Godswill Oletu" To: "Matt Mullen" , "Schulz, Dave" Date: Fri, 16 Sep 2005 06:12:00 -0400 Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode Matt, This is also my understanding, I even went back to re-read my Cisco press books...Page 244 of CCIE Practical Studies Vol. 2 by Karl Solie & Leah Lynch states that and I quote... "Auto-RP uses 224.0.1.39 and 224.0.1.40 multicast groups to send information. Auto-RP floods this information through PIM dense mode. For auto-RP to work properly, the routers must use the "ip pim sparse-dense-mode" interface command. WITHOUT the dense mode capability, the RP will never be learned." Cisco documentation seems to be backing that up: http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008049ccb3.html#wp1112026 The relevant section states that: Prerequisites for Using Auto-RP .When configuring Auto-RP, you must either specify sparse mode using the ip pim sparse-mode command and configure the Auto-RP listener feature using the ip pim autorp listener command (Steps 6 and 7) or specify sparse-dense mode (Step 8) using the ip pim sparse-dense mode command. I will prefer to stay with the text, especially in the exam, despite the fact that it has been proven to work in sparse-mode with configuring the ip pim autorp listerner. Dave, The 'ip pim sparse-mode' is specially useful on two occations: 1. It makes multicast traffic eg video streams from tying down the strick priority broadcast queue reserve for management control multicast traffics like ospf, eigrp, etc. Without the command, huge multicast video streams can burden down this queue thus starving it. It essentially make these multicast traffics to be "normal" queued at the interface just like other normal traffics. 2. On multipoint interfaces, properly processing join and prune messages is made difficult, because one router on that multi-interface prune's message can cut off traffic for every other router connected via that mutipoint interface, the "ip pim sparse-mode" will allow for the proper processing of these messages. -- ---------- Forwarded message ---------- From: Gajewski Mariusz - TP POLPAK To: moelkomy@cisco.com Date: Fri, 16 Sep 2005 14:59:48 +0200 Subject: RE: IGMP profiles Hi Mohammed , It's upside down actually ... If you permit range then everything else is denied If you deny range then everything else is permited Play with deb ip igmp filter on Cat a little bit and this clear things up for you :) HTH Mariusz -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of moelkomy@cisco.com Sent: Friday, September 16, 2005 1:00 PM To: ccielab@groupstudy.com Subject: IGMP profiles Guys, Just a simple question concerning configuring IGMP profiles on cat 3550....if I say config# ipigmpprofile 1 config-igmp-profile# deny config-igmp-profile# range 224.2.2.0 224.3.3.0 int f0/5 ip igmp filter 1 Does that mean that only this range is denied or is there an implicit deny for everything else?? ---- The commands are pretty different, ip igmp query-timeout When you have more than one router on a subnet configured for multicast, then one router will need to establish who will be sending General Queries and Group Specific Queries. The router with highest IP address will be the querier. However any other attached multicast router will be listening to the queries on the subnet. If it fails to hear any queries after a specified amount of time it will take on the responsibility of being the querier for the subnet. This time can be changed by the command ip igmp query-timeout ip igmp query-max-response-time The router will periodically send out an igmp query - default 60 seconds. Once a query is sent out on the subnet, any hosts that wish to join an mcast group, or wish to continue receiving an mcast group will respond with a membership report. Now if a router is forwarding to an mcast group on the subnet due to a previous join, it will as stated above send out a query every 60 seconds. If it hears no response from any hosts that wish to continue to recieve this mcast group, then the router will delete the group and stop forwarding the traffic. The time before it takes this action is the: ip igmp query-max-response-time HTH Simon --- From: "Chris Lewis (chrlewis )" To: "Ralph" , Date: Tue, 23 Aug 2005 22:22:34 -0400 Subject: RE: Multicast Filtering The following is what I use to remind myself of the options for filtering multicast traffic: If you want to stop certain multicast groups from passing through an interface, that is multicast boundary, an example of how to deny anything in the 235 range and permit everything else: Interface fa0/0 Ip multicast boundary 1 filter-autorp ! Access-list 1 deny 235.0.0.0 0.255.255.255 Access-list 1 permit 224.0.0.0 15.255.255.255 If you want to control which multicast group hosts attached to a router interface can join, that is the igmp access-group, shown here for 238.1.2.3 and the whole 235. range Interface fa0/0 Ip igmp access-group 1 ! Access-list 1 deny 238.1.2.3 Access-list 1 deny 235.0.0.0 0.255.255.255 Access-list 1 permit any I am not familiar with the igmp profile command, but it looks like that it is the 3550 way to accomplish the above, ip igmp profile is not an option under interface configuration on a router. The documentation says the following: From the IGMP profile configuration mode, you can specify the parameters of the IGMP profile to be used for filtering IGMP join requests from a port. Configuration is as below: Switch # config t Switch(config) # ip igmp profile 4 Switch(config-igmp-profile)# permit Switch(config-igmp-profile)# range 229.9.9.0 Switch(config-igmp-profile)# end Switch(config)# interface fastethernet2/12 Switch(config-if)# ip igmp filter 4 To limit which routers can become PIM neighbors (in this case stopping neighbor 172.16.15.1) Interface fa0/0 Ip pim neighbor-filter 1 Access-list 1 deny 172.16.15.1 Access-list 1 permit any To prevent multicast packets with TTLs less than 15 from being forwarded Interface fa0/0 Ip multicast ttl-threshold 14 ---- Date: Sat, 15 Oct 2005 07:13:14 -0700 (PDT) Subject: Re: Where I should place "ip pim spt-threshold " ? I assume you mean the infinity option. the answer is that it depends. Your topology does not really have an spt :-). But in reality you would put the command on every router up to the RP. Think of it like this, multicast will stay on the shared tree until a router that finds it has a shorter path to the multicast source, this box needs to be told to ignore your routing table that says if has a better way to get the the source and keep the tree back to the RP. That router has to have the ip pim spt-threshold command. In essence the choice to stay or leave the shared tree is a router by router choice. If you know the point that those tree diverge you can get away with putting it on one box. But it is sound practice in the real world to put it along the whole shared tree ---- If you look at some of the detail in the messages that are going out, you'll find that whenever you implement PIM on an interface, it sends out PIM messages to discover any other PIM neighbors on that interface. You'll do things like figure out who the PIM DR is for that interface. It will send out IGMP messages to do the same thing, figure out who is going to be in charge and be the querier. But I haven't ever seen it use IGMP to try to join these groups unless you issue an "igmp join-group" command on an interface. A router with "ip multicast-routing" enabled is inherently able to do IGMP on multiaccess interfaces, this doesn't mean it sends out an igmp join message though! In dense mode (which is how AutoRP works by default) there is no joining or leaving (granted, IGMP is a separate process), but internally on a non-MA and non-RP, you won't even see the groups present in anything until traffic is seen being flooded around via dense mechanisms. Then you'll see these groups in the mroute cache. Up until that time, the router is pleasantly ignorant and just sits there. No igmp joins for those groups, no nothing. The autorp listener is done to prevent future networking disasters. Everyone agrees that dense mode kinda sucks. The problem with pim sparse-dense is that it says we TRY to use sparse, but if we don't know of an RP, can't reach it, or don't get a good answer then dense is fine. So if we have any multicast traffic going on either before we know of the RP or if the RP doesn't respond in a timely fashion, the PIM router thinks dense mode is cool for ANY group. So we would have the potential for many other dense groups working on the network than we may intend, and there's no other way to filter. So autorp listener was created so that we could put the routers in sparse mode only, where if an RP isn't available then NOTHING goes (viewed as a cleaner solution than flooding). Yet, the listener command will override this for ONLY the AutoRP groups. That still puts a non-MA and non-RP router into a listening mode though, where if any discovery packets or announcements aren't forthcoming, there's no igmp joining going on. At least that's the packet traces I've conducted in 12.2 devices. I can't think of a good reason why that would change. *shrug* ----- As Scott mentioned, the global command ip pim autorp listener was created to allow an interface to operate in sparse mode only and still receive dense mode groups .40 and .39 used for auto rp. The pim commands configured on an interface, tells the interface how pim should behave on an interface. If you have configured sparse mode only for the interface, then this interface will do just that. It will not flood auto rp throughout the network. Use the global command ip pim autorp listener to over ride this for auto rp only. As mentioned earlier in this email string, finding and registering with the RP is required for sparse more. If your router can not find a RP, then it will fall back to dense mode. If the interface is configured for sparse-mode only, then it will not be able to send dense mode traffic out of the interface. ---- Actually....I believe it is.....:) Every multicast router has an interface that joins the group 224.0.1.40 and sends out an IGMP report as a host would, because it is a host receiver for discovery packets. Consider this simple setup R1-S3/0----S1/0-R3-S3/0-------S2/0-R2 I am going to set this up in a weird way to illustrate a point. The interfaces between R3 and R2 are set as dense only. The interfaces between R1 and R3 are sparse only. R2 is going to end up as the RP There is no sparse-dense and no autorp listener configured. I now configure the following on R2 ip pim send-rp-announce Loopback0 scope 15 ip pim send-rp-discovery Loopback0 scope 15 So, with no dense mode capability between R3 and R1, no autorp listener and no static configuration, will R1 learn about the RP? This is what R1 tells me Router1#sho ip pim rp mapp PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 192.168.2.2 (?), v2v1 Info source: 192.168.2.2 (?), elected via Auto-RP Uptime: 00:02:13, expires: 00:02:48 The loopback of R2 is 192.168.2.2, so it does learn over a sparse only mode interface about the RP. Why is this? Well some debugs of IGMP show what is happening. R3 *Oct 16 14:38:38.203: IGMP(0): Send v2 Report for 224.0.1.40 on Serial1/0 R1 *Oct 16 14:38:37.923: IGMP(0): Send v2 Report for 224.0.1.40 on Serial3/0 R1 and R3 are sending out reports for 224.0.1.40 on their sparse-enabled interfaces, there are no ip igmp join statements anywhere. So R1 sends a report, R3 uses dense to learn about R2 as the RP. So imagine a CCIE scenario, no sparse-dense allowed, no autorp listener allowed, and a router that needs to learn about the RP is no directly connected to the RP, but auto-RP is required. You can use this behavior to have a router generate an IGMP report over sparse, and other routers use dense mode only to get to the RP. These are the relevant config bits for anyone that wants to lab this themselves, just add a unicast routing protocol of choice. R1 ! ip multicast-routing ! interface Serial3/0 ip address 172.16.31.1 255.255.255.252 ip pim sparse-mode R3 ! ip multicast-routing ! interface Serial1/0 ip address 172.16.31.2 255.255.255.252 ip pim sparse-mode ! interface Serial3/0 ip address 172.16.32.3 255.255.255.0 ip pim dense-mode R2 ! ip multicast-routing ! interface Loopback0 ip address 192.168.2.2 255.255.255.0 ip pim sparse-mode ! interface Serial2/0 ip address 172.16.32.2 255.255.255.0 ip pim dense-mode ! ip pim send-rp-announce Loopback0 scope 15 ip pim send-rp-discovery Loopback0 scope 15 ---- I just read one example of configuring reliable RP point in the PIM sparse mode using msdp. Look: R1 (rouer id is 1.1.1.1) int lo0 ip add 1.1.1.1 int lo1 ip pim sparse-mode ip add 10.10.10.10 255.255.255.255 ip msdp peer 1.1.2.2 connect-source lo0 ip msdp originator-id lo0 ip pim rp-address 10.10.10.10 R2 (router-id is 1.1.2.2) int lo0 ip add 1.1.2.2 int lo1 ip pim sparse-mode ip add 10.10.10.10 255.255.255.255 ip msdp peer 1.1.1.1 connect-source lo0 ip msdp originator-id lo0 ip pim rp-address 10.10.10.10 something like this and all other routers could use just the 10.10.10.10 address as the RP point. And if one of ther router will fail the other router could just act as the RP. I configured this and it seems to work as it should. When I read about MSDP I read that this is interAS multicast protocol. And is configured only between different ASs. Well I found just one example when it could be used in one AS but with different ip addresses of the RPs. Please. Could some one explain the logic of such behaviour, how is it possible to use that, and how MSDP acts in this situation. What is really happening in this config?? Is this correct at all?? Thanks, _________________________________________________________________ MSN Search Ireland has launched - test-drive it today! http://search.msn.ie ---------- Forwarded message ---------- From: "Brant I. Stevens" To: "'Stefan Grey'" , Date: Sun, 16 Oct 2005 13:26:12 -0400 Subject: RE: Multicast "HSRP" (by MSDP) The term typically used for this application of MSDP is Anycast RPs. The logic is that an IGP capable of supporting ECMP (EIGRP, OSPF, IS-IS, etc...) will carry multiple entries for the RP address (10.10.10.10, in your example), and that depending on where you are in the network, your connecting router will choose the best path to the RP as it sees it. Your configuration should include the advertisement of the RP address into whatever IGP being used. To avoid having to statically configure RP information on every router in the network, you could leverage Auto-RP to propagate the Anycast RP address for the desired groups. MSDP peering is configured between the RPs in each "half" of the network to communicate active source information between peers. Should one RP fail, the IGP will reconverge, and a new path to the surviving RP will be recaclulated. At that point, new Multicast flows would be able to be sent/received on the network once again. Depending on the speed of convergence of the IGP in use, you can get RP failover as fast as your IGP can reconverge. ---- Subject: Re: Use of "ip pim rp-announce-filter" ip pim rp-announce-filter should always be configured on mapping agents, what you've configured on RP (group-list etc) is irrelavent, the command is there mainly for security reason, immagine what will happen if a RP is adverstising bogus RP-address. ---- From: "Brian McGahan" To: "Eugene Ward" , Date: Thu, 20 Oct 2005 12:02:08 -0400 Subject: RE: Use of "ip pim rp-announce-filter" > On the mapping agent side, suppose you had three routers advertising > themselves as RPs for the 239.0.0.0/8 range. You could use the "rp-list" > option to specify which routers are allowed to be RPs. Also, you could > use the "group-list" option in conjunction with the "rp-list" option in > the "rp-announce-filter" message to specify a particular RP with a > particular range. For example (on the mapping agent): If by this you mean that a candidate RP can announce 224.0.0.0/4 and the rp-announce-filter can limit them to 224.0.0.0/5, no. The rp-announce-filter is used to either accept or reject an RP, along with the groups it is announcing. If RP "X" is advertising groups 224.0.0.0/5, and mapping agent "Y" wants RP X and only RP X to service these groups there must be matching access-list logic on both X and Y for this range, along with an additional filter on Y assigning 224.0.0.0/5 to no other RPs. You would *assume* that the correct logic would be that the candidate RPs could just announce 224.0.0.0/4 and the mapping agent could sort through it, but it doesn't work that way. Think of this feature instead as a way to prevent arbitrary devices from advertising themselves as candidate RPs for your auto-rp domain. HTH, Brian McGahan, CCIE #8593 ---- Subject: RE: Does PIM dense mode or sparse-dense mode work over frame relay? Nbma mode has two pieces: 1. The paying attention individually to all join and leave requests. This only has a benefit to sparse mode since there are no joins or leaves in dense mode. If you operate in sparse-dense, you do both which means sometimes you'll get the benefit of this feature, sometimes you won't. 2. Normally on a serial link (with two hardware queues) the IP multicast messages are treated like "pseudobroadcasts" and placed in the broadcast hardware queue which is a strict priority queue and process switched. This may be great if you like your streaming stuff, but COULD mess up other traffic and certainly cause additional strain on your router. Nbma mode will reclassify ip multicast traffic into the normal queue. This benefit is enjoyed whether you are using sparse or dense mode. The code, however, in the router will bitch at you if you are running anything other than pure sparse-only stuff. IMHO this is just a hyperactive warning. Everything will still work as it should where it should, just the informational message given to you by the router causes panic. HTH, Scott PS. I wouldn't bother placing nbma mode on the spokes unless the direction of traffic flow is coming OUT of one of the spokes (see #2 above). Otherwise for incoming traffic only and not dealing with joins at all, putting this command on the spokes would accomplish nothing. It wouldn't hurt, it just wouldn't help anything. ---- auto-rp will work with pim sparse-mode if you use the ip pim autorp listener command on your routers. This will "tell" the router to treat the two auto-rp groups 224.0.1.39& 224.0.1.40 as dense-mode groups so they will be "seen" by every other router. That way, the RPs can announce themselves to 224.0.1.39 (which your mapping agent will be listening to) and the mapping agent will then send the details of the RP to the rest of the routers via the 224.0.1.40 address. The command is hidden in the IOS (12.2(15)T anyway) but is on the Doc CD. HTH...Pete On 11/17/05, John Matus wrote: > > the task states: use the most reliable interface on R2 as the RP for all > multicast groups > > the solutions uses static rp's ( ip pim rp-address 150.1.2.2 > )........ > but could't you also use auto-rp for this as well. the previous task is > to use pim sparse mode. does auto rp only work w/ sparse-dense-mode? or > does it work w/ sparse mode as well? hmmm ---- ---------- Forwarded message ---------- From: Chris Lewis To: Anderson Nery Vilas Boas , ccielab@groupstudy.com Date: Sat, 3 Dec 2005 06:38:26 -0800 (PST) Subject: Re: SV: Re: Multicast issue. Look at the multicast configuration guide in the documentation CD at It references these two sections specifically "PIM Version 1, together with the Auto-RP feature, can perform the same tasks as the PIM Version 2 BSR. However, Auto-RP is a standalone protocol, separate from PIM Version 1, and is Cisco proprietary. PIM Version 2 is a standards track protocol in the IETF. We recommend that you use PIM Version 2. Either the BSR or Auto-RP should be chosen for a given range of multicast groups. If there are PIM Version 1 routers in the network, do not use the BSR. " and later on....... When Cisco and non-Cisco routers are being operated in a single PIM domain with PIM Version 2 BSR, care must be taken when configuring candidate RPs because the Cisco IOS implementation of the BSR RP selection is not fully compatible with RFC 2362. RFC 2362 specifies that the BSR RP be selected as follows (RFC 2362, 3.7): --------------------------------- Step 1 Select the candidate RP with the highest priority (lowest configured priority value). Step 2 If there is a tie in the priority level, select the candidate RP with the highest hash function value. Step 3 If there is a tie in the hash function value, select the candidate RP with the highest IP address. --------------------------------- Cisco routers always select the candidate RP based on the longest match on the announced group address prefix before selecting an RP based on priority, hash function, or IP address. Inconsistent candidate RP selection between Cisco and non-Cisco RFC 2362-compliant routers in the same domain if multiple candidate RPs with partially overlapping group address ranges are configured can occur. Inconsistent candidate RP selection can lead to disconnectivity between sources and receivers in the PIM domain. A source may register with one candidate RP and a receiver may connect to a different candidate RP even though it is in the same group. The following example shows a configuration that can cause inconsistent RP selection between a Cisco and a non-Cisco router in a single PIM domain with PIM Version 2 BSR: access-list 10 permit 224.0.0.0 7.255.255.255 ip pim rp-candidate ethernet1 group-list 10 priority 20 access-list 20 permit 224.0.0.0 15.255.255.255 ip pim rp-candidate ethernet2 group-list 20 priority 10 ip pim rp-candidate ethernet2 group-list 20 priority 10 Anderson Nery Vilas Boas wrote: that is it : " it the case of wanting one RP to be primary for half the groups and secondary RP for the other half and be able to become the RP for all groups if the other RP fails ". Can I use ip pim rp-candidate for both groups but with differente priorities ? So I will have two RPs , one for half of the groups? If one fail - by priorities the other can assume the entire function? Can I user just AUTO-RP for this? ps: the questions asks to use PIM V2. Thanks Chris. --- Hi John, Let me give it a shot: (*,G) state shows information for the shared tree, the tree to the rendezvous point. (S,G) state shows information for the shortest path tree. Dense mode: (*,G) state is virtually meaningless. Dense Mode is all about (S,G) state. Sparse Mode: (*,G) state is the shared tree info. (S,G) state is the SPT info. SSM: only has (S,G) state Bidirectional: Only has (*,G) state. IMHO, the best descriptions are in Beau Williamson's "Developing IP Multicast Networks" HTH, Bob Sinclair CCIE #10427, CCSI 30427 www.netmasterclass.net ----- Original Message ----- From: John Matus To: ccielab@groupstudy.com Sent: Wednesday, December 07, 2005 5:33 PM Subject: multicast (s,g) vs (*,g) entries i've read several books which have discussed the entries in the multicast routing tables - (S,G) and (*,G) entries. i understand that the S = source and G = group, but what i just have not been able to grasp (for reasons unbeknowst to me.........perhaps the drugs), the difference between the two and how they relate to sparse and dense mode. can someone explain this in simple terms so my delicate brain can understand the relevance? i seem to remember that they have different meanings in dense mode and sparse mode....... TIA Regards, John D. Matus Technical Support / PAS Fujitsu Consulting 626-568-7716 John.Matus@tokiom.com ============================================ ---- ---------- Forwarded message ---------- From: "Brian McGahan" To: "John Matus" Date: Wed, 7 Dec 2005 20:33:00 -0500 Subject: RE: another dumb multicast question > ok, so .39 and .40 only run in dense mode.... > so even tho you configure an interface in sparse mode, the global command > "forces" the interface to run in dense mode for .39 and .40 only Yes. You can see this in the "show ip mroute" output. > this begs the question............how would you configure this??? i don't > have a router in front of me so i'm thinking perhaps an "ip igmp" command > of some-sort or else some kind for a static mroute perhaps??? ip pim rp-address 1.2.3.4 1 ! access-list 1 permit 224.0.1.39 access-list 1 permit 224.0.1.40 This is covered in the multicast sections of IEWB-RS 3.0, and I think the 2.0 version as well. HTH, Brian McGahan, CCIE #8593 bmcgahan@internetworkexpert.com Internetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 x 705 Outside US: 775-826-4344 x 705 24/7 Support: http://forum.internetworkexpert.com Live Chat: http://www.internetworkexpert.com/chat/ > -----Original Message----- > From: John Matus [mailto:John.Matus@tokiom.com] > Sent: Wednesday, December 07, 2005 7:04 PM > To: Brian McGahan > Cc: ccielab@groupstudy.com > Subject: RE: another dumb multicast question > > ok, so .39 and .40 only run in dense mode.... > so even tho you configure an interface in sparse mode, the global command > "forces" the interface to run in dense mode for .39 and .40 only > > > sparse mode only without auto-rp listener if you statically define an RP > to send joins for 224.0.1.39 and 224.0.1.40.> > > this begs the question............how would you configure this??? i don't > have a router in front of me so i'm thinking perhaps an "ip igmp" command > of some-sort or else some kind for a static mroute perhaps??? > > Regards, > > John D. Matus > Technical Support / PAS > Fujitsu Consulting > 626-568-7716 > John.Matus@tokiom.com > > > > "Brian McGahan" > tworkexpert.com> To > "John Matus" > 12/07/2005 04:57 , > PM > cc > > Subject > RE: another dumb multicast question > > > > > > > > > > > It does run in dense mode, that's what auto-rp listener > accomplishes. Auto-RP listener is essentially sparse-dense mode, but > you're only dense for 224.0.1.39 and 224.0.1.40. You can also run > sparse mode only without auto-rp listener if you statically define an RP > to send joins for 224.0.1.39 and 224.0.1.40. > --- ---------- Forwarded message ---------- From: Peter McCreesh To: "Schulz, Dave" Date: Sat, 10 Dec 2005 16:53:23 +0000 Subject: Re: Multicast source & receiver Hi Dave, the way I set it up in my lab is as follows: SENDER (Just change the multicast ip to whatever you want - no need to enable pim or any other mcast settings) rtr 1 type echo protocol ipIcmpEcho 224.1.2.3 frequency 10 rtr schedule 1 life forever start-time now rtr 2 type echo protocol ipIcmpEcho 224.1.4.6 frequency 10 rtr schedule 2 life forever start-time now rtr 3 type echo protocol ipIcmpEcho 224.4.5.6 frequency 10 RECEIVER (again, change IPs as needed an no PIM config needed either) interface FastEthernet0/0 ip access-group CHECK-MCAST in ip igmp join-group 224.1.2.3 ip igmp join-group 224.1.4.6 ip igmp join-group 224.4.5.6 ip access-list extended CHECK-MCAST permit icmp any host 224.1.2.3 permit icmp any host 224.1.4.6 permit icmp any host 224.4.5.6 permit ip any any if you do a sh ip access-list you will see the hits increasing against those groups that are being successfuly received. HTH ..Pete --- -----Original Message----- From: nobody@groupstudy.com To: Cham Cc: Cisco certification Sent: 12/10/2005 2:50 PM Subject: RE: rp-announce-filter If the candidate RP (cRP) asks for 228/8 and 229/8 but the MA is allowing only 228/8 then the MA will filter the 229/8 and the cRP will be the RP for just 228/8. If the cRP asks for say 224/4 but the MA is only allowing 228/8 then the cRP's 224/4 announcement will be filtered by the MA and the cRP will not be the RP for any groups. HTH, Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security) bdennis@internetworkexpert.com Internetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Direct: 775-745-6404 (Outside the US and Canada) ---- Yes, sorry for not clarifying. (I couldn't tell which piece in your diagram was going to be the source there) The PIM DR by the source will unicast an SA message to the RP. If/when there are joins going on, then you are correct, they're handled through the PIM conversations multicast to 224.0.0.13 (AllPIMRouters). While this conversation goes on, each router attempts to built an mroute (incoming and outgoing interface lists), which obviously can only include PIM-participating interfaces. At this point in time, there is no RPF check occuring. It is only a hop-by-hop buildout. Once the actual multicast messages start to flow at that point, there's an RPF check. Does that help explain it better? What I'm getting by the question is that the source is located somewhere else separate from these two routers... Correct me if I'm wrong in that assumption. Scott -----Original Message----- From: Greg Gombas [mailto:ggombas@hotmail.com] Sent: Wednesday, January 04, 2006 2:16 PM To: swm@emanon.com; ccielab@groupstudy.com Subject: RE: PIM Sparse-Mode join RPF question Hello Scott, Thank you for replying. When you say "the initial conversation to the RP is unicast" you are referring the register message from the source, correct? What I am talking about is the join message from the routers along the shared tree to the RP. I thought the join messages are multicast hop-by-hop to the destination address 224.0.0.13? If so do the routers do an RPF check before sending the join packet? If so how does an mroute solve this issue? --- -------- Forwarded message ---------- From: "Bob Sinclair" To: "Chris Atkins" , Date: Fri, 13 Jan 2006 19:34:59 -0500 Subject: Re: PIM Dense-Mode Hi Chris, To me, there are only two interesting kinds of problems in multicast: RPF problems and OILIST problems. Seems to me your basic spoke-to-spoke multicast issue is not an RPF problem, but an OILIST problem. RPF problems arise when multicast arrives on an interface that is not acceptable. By default, the acceptable interface is that interface on the shortest path to the source. There are two ways to fix this kind of problem: send the multicast on the acceptable interface, or make the interface on which it is arriving acceptable. There are two ways to make the interface acceptable: change the unicast routing table, or override it with a static mroute. OILIST problems arise from the rule that says "the incoming interface cannot be on the outgoing interface list". AFAIK, there is now way to multicast in and back out of a multipoint frame interface using Dense Mode. In order to get multicast from spoke to spoke using Dense mode, you will have to tunnel it. HTH, Bob Sinclair CCIE #10427, CCSI 30427 www.netmasterclass.net