CTs take on Multicasting

cisco_trooper

There are no words to describe my frustration in getting this labbed up....

Anyone with a working lab config? Please save me from this insanity...

jezg76

I agree about the multicast portion of studying for the BSCI. Strange concepts but radically different than the rest of the material. At least for me it is.

Paul Boz

Multicast is one of the subjects that I didn't lab "that much." I spent about 80% of my time studying the concepts and terms and only about 20% working on lab material. Multicast is a pain in the butt without something generating a multicast stream and hosts to receive it.

I didn't even use a router to lab multicast, I just got the commands in my fingers by typing them repeatedly in notepad.

kryolla

just remember multicast routing is source based not destination and it uses the underlying unicast routing table for RPF.

cisco_trooper

Yeah I know. What I have been TRYING to do is use dynamips, which maybe just isn't possible. What I did is set up some clients one one side of an EIGRP cloud, and then had a lone router on the other side to use as my multicast source. All the clients are joined to igmp group 228.x.x.x. I then sent an endless stream of pings to that multicast address, to no avail. Of couse I had all the ip pim sparse-mode/dense-mode on interfaces throughout the domain.

Would like to know if anyone has been successfull trying to nail down multicast with this sort of methodology. I know you can just type commands, but my brain is stubborn. I don't believe it until i DO it.

qplayed

Paul Boz wrote:

Multicast is one of the subjects that I didn't lab "that much." I spent about 80% of my time studying the concepts and terms and only about 20% working on lab material. Multicast is a pain in the butt without something generating a multicast stream and hosts to receive it.

I didn't even use a router to lab multicast, I just got the commands in my fingers by typing them repeatedly in notepad.

http://www.google.com/search?q=multicast+traffic+generator

Paul Boz

That's neat, thank you for the link.

kryolla

Not too sure about dynamips I have actual routers and switches for my lab. Try to get the cisco academy BSCI lab book I not sure if I am allowed to post that lab for multicasting. Also dont forget on how to convert multicast mac address to IP address and vise versa

cisco_trooper

Hah! I just configured a dense-mode multicast lab using only dynamips. I will save these configs and such and have them uploaded for everyone's benefit shortly. URL will be http://www.ipnetworksllc.com/routerconfigs/

Afterwards I will see if I can nail down sparse mode.




By the way..just ping 239.39.39.39 from Source and you'll get to see the action.

Paul Boz

I just spent the last few hours playing with that multicast stream generator and it's neat. A friend of mine at work is trying to develop his web development skills so he's going to build a streaming video site similar to youtube for my lab. He gets the benefit of having a "production like" lab environment and I get the benefit of having legit multicast traffic. I really need to get more hosts though..

Mrock4

I did a couple of multicast labs, but I don't have any of the configs anymore, I don't think. I had to reschedule my BSCI because I'm moving earlier than I planned...ugh...

I did find that even though I did a fair amount of multicast labs, most of the "useful" information was concept-based when it comes to MC.

By the way CT, shoot a msg when you can, I missed your msg the other night..long weekend if you get my drift..

cisco_trooper

PIM Sparse-Mode with Auto-RP
Interesting thing I figured out the hard way this evening. In configuring Auto-RP within a PIM Sparse-Mode environment, it became apparent that there DOES need to be some thought behind which routers you select as your RP Candidates. Before I go into the details, let me give you the topology to make it a little easier to follow along.

Source is fastethernet to Core1.
Source is self-explanatory, this is the source of multicast traffic.

Core1 is fastethernet to Core2
Core1 is fastethernet to Core3

Core2 is serial to Core3
Core2 is fastethernet to Client1 and Client2

Core3 is serial to Core2
Core3 is fastethernet to Client3 and Client4

In my initial attempt at configuring this scenario, I made Core2 and Core3 both RP Candidates, and left Core1 as the MA. Core3 was elect the RP. Anyone care to guess what happened to the multicast routing tables?...FUBAR is too easy and will not be accepted as a valid answer.

cisco_trooper

PIM Sparse-Mode with Auto-RP

Well crap. I'm trying to recreate the RPF tree failure I witnessed earlier this evening but I can't get it to fail. I THOUGHT it was the placement of the RP within the multicast domain, but maybe that was not the problem, and it was just some sort of fluke. There isn't much to this configuration so I don't know what I could possibly be missing...

The only thing I can think of is that when I was switching to AutoRP from the Static RP config I somehow created the loop I was seeing in the multicast routing table. Not sure how that would have even happened though, considering EIGRP is the unicast routing protocol on all the devices.

Royally confused, but unable to reproduce...

cisco_trooper

I'm closing this book. This stuff is a piece of cake right here. Still would like to know how that loop formed. But oh well.

cisco_trooper

Multicast is nuts again...



I now have a bad multicast route table. Once again, I do not know how it formed. I do know I still can't recreate it on my own. This is really beginning to bother me. Especially since configuration is so simple. There has to be a way to insure these loops do not form, but I haven't seen any information to that end as of yet. Anyone some knowledge of multicast can chime in here at any time.

I'm going to **** configs, and routing tables now. Hopefully someone will know what the hell is going on here. I have a theory, but using that theory I was unable to recreate this problem.

cisco_trooper

Hmm. Wondering if Auto-RP and BSR re-converge and rebuild the RPF tree if the unicast route table has to reconverge....

I'm wondering this. This invalid multicast routing table formed when I started all these routers up this morning. BSR was already configured to select an RP. Maybe the unicast routing table was not stable when the RPF tree was built.....

I will have to recreate this.

cisco_trooper

Here are the routing tables for the core routers.
Notice that Core2 is the RP, yet it has no incoming interfaces. It's incoming interface is somehow listed with outgoing interfaces. This is FastEthernet2/1.

Also notice that Core1 has incoming interface FastEthernet2/1, which SHOULD be an outgoing interface. The multicast source is attached to FastEthernet1/0 on Core1.

I'll bet if i remove the BSR configuration and reconfigure it this will all be corrected. I can't prove it yet but I am almost certain this formation was able to occur because EIGRP wasn't converged when the RP election occurred and RPF tree built.

Core1
sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets
D 172.16.23.0 [90/46228736] via 172.16.13.2, 01:19:12, FastEthernet2/0
[90/46228736] via 172.16.12.2, 01:19:12, FastEthernet2/1
C 172.16.12.0 is directly connected, FastEthernet2/1
C 172.16.13.0 is directly connected, FastEthernet2/0
D 192.168.21.0/24 [90/30720] via 172.16.12.2, 01:19:12, FastEthernet2/1
D 192.168.22.0/24 [90/30720] via 172.16.12.2, 01:19:12, FastEthernet2/1
192.168.255.0/32 is subnetted, 8 subnets
D 192.168.255.7 [90/158720] via 172.16.13.2, 01:07:11, FastEthernet2/0
D 192.168.255.6 [90/158720] via 172.16.12.2, 01:06:59, FastEthernet2/1
D 192.168.255.5 [90/158720] via 172.16.12.2, 01:07:28, FastEthernet2/1
D 192.168.255.4 [90/156160] via 172.16.13.2, 01:19:12, FastEthernet2/0
D 192.168.255.3 [90/156160] via 172.16.12.2, 01:19:12, FastEthernet2/1
C 192.168.255.2 is directly connected, Loopback0
D 192.168.255.1 [90/156160] via 192.168.1.1, 01:19:18, FastEthernet1/0
D 192.168.255.8 [90/158720] via 172.16.13.2, 01:06:56, FastEthernet2/0
D 192.168.34.0/24 [90/30720] via 172.16.13.2, 01:19:12, FastEthernet2/0
C 192.168.1.0/24 is directly connected, FastEthernet1/0
D 192.168.33.0/24 [90/30720] via 172.16.13.2, 01:19:12, FastEthernet2/0

Core1#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

(*, 239.39.39.39), 01:08:19/00:03:12, RP 192.168.255.3, flags: S
Incoming interface: FastEthernet2/1, RPF nbr 172.16.12.2
Outgoing interface list:
FastEthernet2/0, Forward/Sparse, 01:07:23/00:03:12

(*, 224.0.1.40), 01:19:31/00:02:22, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:19:31/00:02:22

Core2
sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets
C 172.16.23.0 is directly connected, Serial4/0
C 172.16.12.0 is directly connected, FastEthernet2/1
D 172.16.13.0 [90/30720] via 172.16.12.1, 01:19:42, FastEthernet2/1
C 192.168.21.0/24 is directly connected, FastEthernet3/0
C 192.168.22.0/24 is directly connected, FastEthernet3/1
192.168.255.0/32 is subnetted, 8 subnets
D 192.168.255.7 [90/161280] via 172.16.12.1, 01:07:39, FastEthernet2/1
D 192.168.255.6 [90/156160] via 192.168.22.2, 01:07:27, FastEthernet3/1
D 192.168.255.5 [90/156160] via 192.168.21.2, 01:07:56, FastEthernet3/0
D 192.168.255.4 [90/158720] via 172.16.12.1, 01:19:40, FastEthernet2/1
C 192.168.255.3 is directly connected, Loopback0
D 192.168.255.2 [90/156160] via 172.16.12.1, 01:19:40, FastEthernet2/1
D 192.168.255.1 [90/158720] via 172.16.12.1, 01:19:40, FastEthernet2/1
D 192.168.255.8 [90/161280] via 172.16.12.1, 01:07:23, FastEthernet2/1
D 192.168.34.0/24 [90/33280] via 172.16.12.1, 01:19:40, FastEthernet2/1
D 192.168.1.0/24 [90/30720] via 172.16.12.1, 01:19:40, FastEthernet2/1
D 192.168.33.0/24 [90/33280] via 172.16.12.1, 01:19:40, FastEthernet2/1

Core2#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

(*, 239.39.39.39), 01:08:04/00:02:58, RP 192.168.255.3, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet3/1, Forward/Sparse, 01:07:35/00:02:57
FastEthernet2/1, Forward/Sparse, 01:07:51/00:02:50
FastEthernet3/0, Forward/Sparse, 01:08:04/00:02:58

(*, 224.0.1.40), 01:19:59/00:02:55, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:19:59/00:02:55

Core3
sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets
C 172.16.23.0 is directly connected, Serial4/0
D 172.16.12.0 [90/30720] via 172.16.13.1, 01:20:14, FastEthernet2/0
C 172.16.13.0 is directly connected, FastEthernet2/0
D 192.168.21.0/24 [90/33280] via 172.16.13.1, 01:20:14, FastEthernet2/0
D 192.168.22.0/24 [90/33280] via 172.16.13.1, 01:20:14, FastEthernet2/0
192.168.255.0/32 is subnetted, 8 subnets
D 192.168.255.7 [90/156160] via 192.168.33.2, 01:08:12, FastEthernet3/0
D 192.168.255.6 [90/161280] via 172.16.13.1, 01:08:01, FastEthernet2/0
D 192.168.255.5 [90/161280] via 172.16.13.1, 01:08:30, FastEthernet2/0
C 192.168.255.4 is directly connected, Loopback0
D 192.168.255.3 [90/158720] via 172.16.13.1, 01:20:14, FastEthernet2/0
D 192.168.255.2 [90/156160] via 172.16.13.1, 01:20:14, FastEthernet2/0
D 192.168.255.1 [90/158720] via 172.16.13.1, 01:20:14, FastEthernet2/0
D 192.168.255.8 [90/156160] via 192.168.34.2, 01:07:57, FastEthernet3/1
C 192.168.34.0/24 is directly connected, FastEthernet3/1
D 192.168.1.0/24 [90/30720] via 172.16.13.1, 01:20:14, FastEthernet2/0
C 192.168.33.0/24 is directly connected, FastEthernet3/0

Core3#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

(*, 239.39.39.39), 01:08:27/00:02:26, RP 192.168.255.3, flags: SJC
Incoming interface: FastEthernet2/0, RPF nbr 172.16.13.1
Outgoing interface list:
FastEthernet3/0, Forward/Sparse, 01:08:27/00:02:26

(*, 224.0.1.40), 01:20:29/00:02:26, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:20:29/00:02:26

cisco_trooper

cisco_trooper wrote:

I'll bet if i remove the BSR configuration and reconfigure it this will all be corrected. I can't prove it yet but I am almost certain this formation was able to occur because EIGRP wasn't converged when the RP election occurred and RPF tree built.

yeah. that's a negative on that. this continues to be fubar.

bighornsheep

kryolla wrote:

just remember multicast routing is source based not destination and it uses the underlying unicast routing table for RPF.

This is true for PIM only, multicasting protocols such as DVMRP builds its own routing table.

kryolla

bighornsheep wrote:

kryolla wrote:

just remember multicast routing is source based not destination and it uses the underlying unicast routing table for RPF.

This is true for PIM only, multicasting protocols such as DVMRP builds its own routing table.

That is outside the scope of CCNP lol

cisco_trooper

Sparse Mode is screwing my head up now brother. I change the RP from core2 or core3 to core1 and stuff works great. These so-called bad routes I keep referring to are simply going back to whichever Router is the RP at the time. It sounds like you can force Sparse Mode to use a source based tree rather than the shared tree it seems to use by default. It seems to me like the shared-tree architecture only works if the RP is closer to the source than any of the other routers.

Anyone else have any experience with this? Anyone else even care? How many of you use multicasting functions in production environments? I know I haven't.

kryolla

cisco_trooper wrote:

Sparse Mode is screwing my head up now brother. I change the RP from core2 or core3 to core1 and stuff works great. These so-called bad routes I keep referring to are simply going back to whichever Router is the RP at the time. It sounds like you can force Sparse Mode to use a source based tree rather than the shared tree it seems to use by default. It seems to me like the shared-tree architecture only works if the RP is closer to the source than any of the other routers.

Anyone else have any experience with this? Anyone else even care? How many of you use multicasting functions in production environments? I know I haven't.

I thought you need sparse-dense mode for auto RP and sparse mode for static RP. It uses dense mode to flood the RP announcement but dont quote me on it.

cisco_trooper

kryolla wrote:

I thought you need sparse-dense mode for auto RP and sparse mode for static RP. It uses dense mode to flood the RP announcement but dont quote me on it.

Routing TCP/IP volume II goes into configuration of both AutoRP and BSR with just sparse-mode, but it doesn't go in to design considerations. Maybe there is more to these than is discussed, but the only way I can get AutoRP and BSR to work properly is if the RP is at Core1. I think this is because they use shared tree, which is bringing the routes back to the RP, rather than the multicast source. I just wish I could find some definitive information confirming there are other design considerations in this type of environment, or at least pitfalls to avoid. Perhaps there is simply additional configuration that can be used to prevent this behavior or maybe force a source-based tree to be built.

This is really irritating because I thought I was done with this topic.

I'm itching to knock this test out. Unfortunately it is against my religion to just move on with outstanding issues.

cisco_trooper

Ok...so here I go with the multicast nightmare again.

Looks like I was having trouble last time I looked at this, but I am on a mission to kick this test in the nads in the next week or two, so we shall see how it goes....

Wish me luck.

Mrock4

I love multicasting. Be sure to pay attention to the behavior of multicast routing table, and how changes affect it. I think that is key for the BSCI. Not that I have to tell you that, but hey, its all good.

cisco_trooper

Ok. So I finally got around to reviewing multicast today. I configured my lab in dense mode, sparse mode, sparse-dense-mode, and in sparse-dense-mode i configured the lab for both redundant AutoRP and redundant BSR. All configurations went off without a hitch. I do not understand what my hang up was when I first looked at this material 6 months ago, but nevertheless, I'm moving forward with IPv6 and then knocking this test in the teeth...