Hi there! Just a quick answer, I've been in a bit of stress the last days, and had no time to further investigate the issue... CSCdm68862 really looks like it, I'll look into it, weird though that it affects both 12.1 and 12.2, but I guess Cisco isn't that quick to fix all their bugs :-)
I'll return with more info as soon as time is on my side :-) Merry christmas by the way, and really thanx for your info/reply! Greetings, Peter ""Paul Werner"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Comments within and below. [Verbosity bit is set] > > > > Hi there! > > > > Just a quick answer. First of all thanx for all your replies, > it's very > > valuable. In regards to the article about HSRP/PIM problems, > I have also > > found that one, but it didn't fit into the problem (sadly..). > > I figured that was probably the case. ALthough you did mention > that HSRP was affected with the addition of PIM to your > configurations, it was no guarantee that there were other > forces at play. > > > I'm at home today with no access to the equipment, but I'll > continue > > with it > > tomorrow together with a collegue of mine. The router CPU- > load is very > > low, > > there is now traffic since this is only done in our lab- > enviroment for > > the > > moment. > > > Well, I would not necessarily rule out a bug either (as was > originally suggested by another poster). The trick is > identifying the router CPU utilization/load during the > introduction of PIM commands. If no spike is seen during the > entire process, my hunch would be that other problems are at > stake. Still, I did find a few bugs that indicated loss of > connectivity in OSPF routes and HSRP problems with the addition > of PIM. > > > CSCdm68862 > > Hot Standby Router Protocol (HSRP) does not work when IP > Protocol Independent Multicast (PIM) is configured on a Fast > Ethernet interface that uses the DEC211140 chipset. The active > router does not reply to an Internet Control Message Protocol > (ICMP) ping of the virtual IP address. > > Workaround: Use the burned-in address by entering the standby > use-bia command. > > or this: > > CSCdr11784 > > If you configure Protocol Independent Multicast (PIM) or Hot > Standby Router Protocol (HSRP) on an ATM-LANE interface, the > CPU of the Route Switch Processor (RSP) may reach 99 percent. > This situation only occurs when Open Shortest Path First (OSPF) > is enabled on more than 12 interfaces in combination with ATM- > LANE. This situation does not occur on an RSP that is running > Cisco IOS Release 12.0 S or Release 11.2 GS. There is no > workaround. > > > > In regards to RP or not RP, it doesn't matter, for the moment > it's > > configured with BSR's where wg3r2 is the Candidate-RP for a > couple of > > groups. > > See, the lines listed above are another good example of what I > made reference to earlier. It is nearly impossible to make any > degree of accurate diagnosis of these type of problems without > all of the complete information. Partial configs are analogous > to the patient that goes to see the doctor and complains that > his head is always hurting. The doctor runs a battery of tests > and cannot come up with anything conclusive. When the patient > is ready to get discharged, the doctor turns to write on the > charts and finds the patient banging his head on the wall. The > doctor asks why he is doing this? The patient responds, "Well > doc, it feels really good when I stop" Obviously, a complete > medical history on the patient would have rendered a more > accurate and timely diagnosis - admission to the psyche ward. > > You need to post full sanitized configs of your routers to show > what is really going on. You just mentioned two salients facts > that were not previously mentioned. First is the fact that you > are using BSRs. In Cisco design for multicast networks, the > presence of a bootstrap router implies a non-homogeneous > network, i.e. you are using non-Cisco routers to do multicast. > You did not mention this previously. Also, since you are using > a BSR, this implies you are working with PIM version 2. The > real question to be asked is are all your routers also using > PIM version 2? > > > The adjacency is the same even if we run Auto-RP. In regards to > > PIM > > only sparse or only dense...haven't tried that yet :-) > > Another thought here on running Auto-RP in an environment with > a configured BSR; you may want to read this section (watch > wrap): > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ > 121cgcr/ip_c/ipcprt3/1cdmulti.htm#xtocid994543 > > Specifically, make note of the following: > > "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." > > > > I visited Networks in Copenhagen for about a month ago, and > the lecture > > on > > multicast from Beau Williamson was very interesting, and yes > it's very > > true > > Paul Werner that he recommend you to only run sparse- > mode...but for > > Auto-RP > > you need sparse-dense... > > This is not true. Auto RP can be run in sparse mode only, or > sparse-dense mode. I am not sure where you heard this. Maybe > what you might have heard is it is recommended that Auto-RP > should be run in sparse-dense mode? That is entirely > possible. For a link on this, you may want to read here(watch > wrap: > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ > 121cgcr/ip_c/ipcprt3/1cdmulti.htm#xtocid994514 > > Specifically, I am referencing the following passages: > > "Note If you configure PIM in sparse mode or sparse-dense > mode and do not configure Auto-RP, you must statically > configure an RP as described in the section "Assigning an RP to > Multicast Groups" later in this chapter. " > > or, > > "Note If router interfaces are configured in sparse mode, > Auto-RP can still be used if all routers are configured with a > static RP address for the Auto-RP groups." > > It seems the last comment is talking to the issue of migrating > over from a statically assigned RP to using Auto-RP. > > > Anyway, I need to run of to meeting now, I'll be back > tomorrow with some > > more stuff.. > > > > Take care there! > > > To conclude this lengthy reply, much more useful > troubleshooting of the problem can be achieved by fully > documenting all steps and assigning cause/effect to each change > if a problem occurs. Do it methodically, and one step at a > time. > > I mentioned in my previous post how you can run into an anomaly > where all routers are configured as sparse-dense and > potentially break your network. I will give just one example > of how this can happen. Consider the following diagram(watch > wrap): > > http://www.west- > point.org/users/usma1983/40768/chesinc/diagrams/pim.gif > > The source is directly connected to router A. Auto RP is not > in use. An RP is configured on router A, but not configured on > router B. For the given S,G pair formed from the source, all > listeners on all segments have to receive state from their > respective RP for a given group. What happens on router B when > an RP is not configured? How will router B know that a given > Source exists? It will have to depend upon dense mode to hear > a source. Will router A forward knowledge of its source to > router B, if it is using sparse-dense mode and sparse mode is > functioning for a given group? Moreover, what if a static RP > is configured on all routers except for router E and G; will > you have knowledge that a problem exists, given that there are > presently no receivers on those segment? > > This is why the use of Auto RP is so much better than static > RPs. > > HTH, > > Paul Werner > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=29872&t=29336 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
