IEOC - Internetwork Expert's Online Community

I did not get the same output as the solution.  I am not getting the flag that esignates a PIM Assert election winner.

Rack3R1#sho 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        

(155.3.108.10, 239.10.10.10), 00:01:17/00:01:43, flags:
  Incoming interface: Serial0/0.1, RPF nbr 155.3.0.5
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:01:17/00:00:00  

now R6 does show that the correct Router is forwarding and there is an asterisk for the Mroute associated to the above (S,G) see here:

(155.3.108.10, 239.10.10.10), 00:02:29/00:00:37, flags: PLTX
  Incoming interface: FastEthernet0/0.146, RPF nbr 155.3.146.1*
  Outgoing interface list: Null 

Has anyone else found a similar situation?

I have been really digging into the MCAST section.  One thing interesting I noticed about 8.5, if you add "ip igmp join-group 224.9.9.9" on R6 will R1 still "Assert" itself?

My testing show the answer is NO.  If you have done the labs 8.1 - 8.5 then R4 will be the transit mcast router for mcast traffic when it is using the R5 RP.

The reason is because ASSERT does not come into play for traffic that is Sparse-Mode MCAST.  since there will always be one flow of traffic with SM Assert is no in the picture.  Now for traffic that is dense mode (not using the RP) it will arrive at both R4 and R1 and they will forward it and then have an ASERT election.  I had previosuly wrote something fantastical and wrong. this edit corrects that.

R5 route to R6:

Rack10R5#sho ip route 155.10.146.6
Routing entry for 155.10.146.0/24
  Known via "eigrp 100", distance 90, metric 2172416, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets
  Last update from 155.10.45.4 on Serial0/1/0, 01:26:12 ago
  Routing Descriptor Blocks:
  * 155.10.45.4, from 155.10.45.4, 01:26:12 ago, via Serial0/1/0
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

I learned something that was not really stated in the lab (labs were updated and explained this better).... ASSERT scenarios are Dense-mode only, because in Sparse-mode there are mechanisms to select SPT or Shared path.     That is why the lab ommited testing/verification with a 224.0.0.0 mcast group.

maybe this will be useful for someone else.

The solution for this lab can be enhanced.  I want to call out a couple of things. On page 39 the ping form SW4 shows two successful pings and then two dots which mean unsuccessfull.  At this point R1 has WON the ASSERT, but it causes an issue for R6.  R6 now has an RPF neighbor that is not passing the RPF check.  The "sho ip mroute" command issued on R6 will show an asterisk next to R1. (see below)

r6 ("sho ip mroute"):

(155.10.108.10, 239.4.4.4), 00:01:11/00:01:48, flags: PLT
  Incoming interface: FastEthernet0/0.146, RPF nbr 155.10.146.1* 

When R4 loses the ASSERT, it sends a prune message to R5 (the RP) and we basically reach a point where pings do not work until timers expire and R5 starts to send to both R4 and R1 again.  Once this starts to happen, R6 will then change the RPF nbr to R4 and the pings will start flowing.  I am not sure exactly what timer expires and why there is not another ASSERT election. Anyone know?

Bottom line: the solution covers the bare minimum and does not explain behavior of the traffic (clearly).   I can see from  previous posts that this has caused some grief in the past.

I am hoping someone form INE can review this lab and just clear up the solution.  Is the goal to just see R1 win the ASSERT and that is it?  Or is there value in looking at how the whole lab plays out?

Hi, ..

I am struggeling with this task too. Brilliant explanations.

I have to add one point, that makes me wonder :

I dont get any Dense-Mode traffic across the FR-Link.

I have stripped down the topologo to R6, R1, R5, SW2 and SW4 to avoid any  RPF issues.

I have full reachability, Mroute table on R5 looks fine.

When i do a ping 239.6.6.6, i get one response and everyone else fails.

R5 sends traffic into the FR-cloud, but R1 does not receive any packets.

When i do a ping 224.6.6.6 ( R6 has joined 224.6.6.6 ), everything is fine, ping succeeds.

From what i have read in the Docs, it is said that Dense-Mode is not recommended across FR-Links,but they do not say it is impossible.

Tried changing the interface modes to dense mode, tried auto-rp, --> same results.

I am using Dynamips, so i am not sure, if this issue is related to dynamips. I dont have real Hardware to test this.

Maybe someone else can confirm or prove me wrong that it is possible to flood Dense-Mode traffic across a FR-Link ?

Do You use Dynamips or have You built Your Lab on real HW ?

Maybe it is Dynamips to blame, and if it is You get fooled by this.

Cheers, ..

/Christian

deleted this post since it was useless....

Hi, ..

many thanks for Your answer.

I figured it out.

The Solution was 70% Dynamips and 30% Topology.

Using Dynamips in Vol1 is like doing continous Troubleshooting-Labs over and over.

Random L2-Issues  come and go, mostly with Ethernet Connections. The Switchmodule is really bad, and the internal Internalinterfaces are a more reliable, so they are only bad.

Using the full Topology, i can totally agree to Your explanations.

Dense-Mode Traffic does not get through the FR-cloud.

I see the Prune on R4, and the (S,G) on R5 pointing to the FR-cloud in its OIL.

The funny thing was, that if You use Sparse-Groups ( 224.x.x.x ), the ping succeeds, while Dense-Groups did not make it.

From my understanding, the FR-cloud had Problems to transport the Dense-Groups.

Built a small Dynamips-Lab to isloate this ( R5,R1,R2,R4 ) and got my hands on a few routers, so i cuold redo this setup using real Routers.

In both setups, i saw the same issues :

I had trouble transporting MCast over FR-cloud. I had to apply ip pim nbma mode on the Hub (R5) to get it up and running.

Without NBMA-Mode, R1 ( igmp join 224.1.1.1 ) did not receive the (S,G) entries froim the RP

sh ip mroute showed an (S.G) entry with the Flag REGISTER set, which indicates thet PIM conversation between the RP and R1 had issues.

Using nbma-mode solved this.

The Lesson learnt from this topology was, that using Dense-Mode in such a "shared" Partial-Mesh FR-cloud is a really bad idea.

You have to use "ip pim nbma" on R5 to get this up and running.

And dont trust Dynamips..

Thanks and have a great weekend.

Cheers,..

/Christian

IE TEAM, could you explain issue with PIM ASSERT?

I also have similar problem as topicstarter

PIM Assert is in my queue of blog posts.

A pretty important topic that is very easy to overlook when studying MCAST. 

I always get weird results on this lab.

I think INE shoudl publish final configs for these labs so that we can compare more than snippets.

Currently, I am getting the two replies, from r6, for the two paths down R4 and R1.  After which R1 ASSERTS itself and wins and then every three minutes R4 floods the traffic again (ping goes through) but then R1 does and ASSERT and PINGS are nto working again.  After a few cycles R4 just takes over and R1 starts to complain about RPF failure (it starts to see the pings on its FA0/0 interface (239.6.6.6).  i see R4 send a PRUNE to R5 when the pings are not working.

R6 ping responses to SW4:

Rack28SW4#ping 239.6.6.6 repeat 334

Type escape sequence to abort.
Sending 334, 100-byte ICMP Echos to 239.6.6.6, timeout is 2 seconds:

Reply to request 0 from 155.28.146.6, 32 ms
Reply to request 0 from 155.28.146.6, 76 ms.....................................................................
.....................
Reply to request 91 from 155.28.146.6, 28 ms................................................
..........................................
Reply to request 182 from 155.28.146.6, 28 ms
Reply to request 183 from 155.28.146.6, 28 ms
Reply to request 184 from 155.28.146.6, 28 ms
Reply to request 185 from 155.28.146.6, 28 ms
Reply to request 186 from 155.28.146.6, 28 ms     

Here is the trace from R6(I moved the igmp interface to fa 0/0.67 for testing), you can see the two pings folowed by an ASSERT:

Rack28R6#
Rack28R6#
Rack28R6#
Mar 11 22:25:05.774: IP(0): s=155.28.108.10 (FastEthernet0/0.146) d=239.6.6.6 (FastEthernet0/0.67) id=1260, ttl=251, prot=1, len=100(100), mforward
Mar 11 22:25:05.818: IP(0): s=155.28.108.10 (FastEthernet0/0.146) d=239.6.6.6 (FastEthernet0/0.67) id=1260, ttl=251, prot=1, len=100(100), mforward
Mar 11 22:25:05.818: PIM(0): Received v2 Assert on FastEthernet0/0.146 from 155.28.146.4
Mar 11 22:25:05.818: PIM(0): Assert metric to source 155.28.108.10 is [90/2174976]
Mar 11 22:25:05.818: PIM(0): Cached metric is [Inf/-1]
Mar 11 22:25:05.818: PIM(0): Set join delay timer to 1000 msec for (155.28.108.10/32, 239.6.6.6) on FastEthernet0/0.146
Mar 11 22:25:06.758: PIM(0): Received v2 Assert on FastEthernet0/0.146 from 155.28.146.1
Mar 11 22:25:06.758: PIM(0): Assert metric to source 155.28.108.10 is [80/20]
Mar 11 22:25:06.758: PIM(0): Cached metric is [90/2174976]
Mar 11 22:25:06.758: MRT(0): New RPF nbr 155.28.146.1 from Assert for (155.28.108.10/32, 239.6.6.6)
Mar 11 22:25:06.758: PIM(0): Join delay timer running at 0 for (155.28.108.10, 239.6.6.6) on FastEthernet0/0.146
Mar 11 22:25:06.762: PIM(0): Received v2 Join/Prune on FastEthernet0/0.146 from 155.28.146.4, not to us
Mar 11 22:25:06.762: PIM(0): Prune-list: (155.28.108.10/32, 239.6.6.6)
Mar 11 22:25:06.762: PIM(0): Join delay timer running at 0 for (155.28.108.10, 239.6.6.6) on FastEthernet0/0.146
Mar 11 22:25:06.762: PIM(0): Received v2 Join/Prune on FastEthernet0/0.146 from 155.28.146.4, not to us
Mar 11 22:25:06.766: PIM(0): Prune-list: (155.28.108.10/32, 239.6.6.6)
Mar 11 22:25:06.766: PIM(0): Join delay timer running at 0 for (155.28.108.10, 239.6.6.6) on FastEthernet0/0.146
Mar 11 22:25:06.814: PIM(0): Insert (155.28.108.10,239.6.6.6) join in nbr 155.28.146.1's queue
Mar 11 22:25:06.814: PIM(0): Building Join/Prune packet for nbr 155.28.146.1
Mar 11 22:25:06.814: PIM(0):  Adding v2 (155.28.108.10/32, 239.6.6.6) Join
Rack28R6#
Mar 11 22:25:06.814: PIM(0): Send v2 join/prune to 155.28.146.1 (FastEthernet0/0.146)
Rack28R6#
Rack28R6#            

Okay, well please give me some advice on this. Anyone else seeing this?

Ray

TECH-EDIT team:

things worked like a charm after putting an MROUTE on R6:

Rack28R6#
Rack28R6#sho ip route 155.28.108.10
Routing entry for 155.28.108.0/24
  Known via "eigrp 100", distance 90, metric 2177536, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets
  Last update from 155.28.146.4 on FastEthernet0/0.146, 01:12:37 ago
  Routing Descriptor Blocks:
  * 155.28.146.4, from 155.28.146.4, 01:12:37 ago, via FastEthernet0/0.146
      Route metric is 2177536, traffic share count is 1
      Total delay is 20300 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 3

Rack28R6(config)#ip mroute 155.28.108.10 255.255.255.255 155.28.146.1
Rack28R6(config)#
Rack28R6(config)#
Rack28R6(config)#
Rack28R6(config)#
Rack28R6(config)#
Mar 11 22:48:37.454: IP(0): s=155.28.108.10 (FastEthernet0/0.146) d=239.6.6.6 (FastEthernet0/0.67) id=1680, ttl=251, prot=1, len=100(100), mforward
Rack28R6(config)#
Mar 11 22:48:39.446: IP(0): s=155.28.108.10 (FastEthernet0/0.146) d=239.6.6.6 (FastEthernet0/0.67) id=1681, ttl=251, prot=1, len=100(100), mforward
Rack28R6(config)#
Mar 11 22:48:41.446: IP(0): s=155.28.108.10 (FastEthernet0/0.146) d=239.6.6.6 (FastEthernet0/0.67) id=1682, ttl=251, prot=1, len=100(100), mforward
Rack28R6(config)#
Mar 11 22:48:43.450: IP(0): s=155.28.108.10 (FastEthernet0/0.146) d=239.6.6.6 (FastEthernet0/0.67) id=1683, ttl=251, prot=1, len=100(100), mforward
Rack28R6(config)#  

Nadeem, you recently did MCAST section, right?  Did you have any issue with the ASSERT lab?  It worked for me but the pings do not go through R1 indefintely without the MROUTE on R6. 

Thanks buddy.  When are you going to hit MPLS again? I remember we both started and stopped a while back but they udpated it twice since then.

Ray

--Nevermind-- wrong configs.  Working correct now.