CTs take on Multicasting

cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
icon_evil.gificon_evil.gificon_mad.gificon_evil.gificon_evil.gif

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...

Comments

  • jezg76jezg76 Member Posts: 97 ■■□□□□□□□□
    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. :)
    policy-map type inspect TACO
    class type inspect BELL
    drop log
  • Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    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.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • kryollakryolla Member Posts: 785
    just remember multicast routing is source based not destination and it uses the underlying unicast routing table for RPF.
    Studying for CCIE and drinking Home Brew
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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. icon_confused.gif
  • qplayedqplayed Member Posts: 303
    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
    If you cannot express in a sentence or two what
    you intend to get across, then it is not focused
    well enough.
    —Charles Osgood, TV commentator
  • Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    That's neat, thank you for the link.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • kryollakryolla Member Posts: 785
    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
    Studying for CCIE and drinking Home Brew
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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.

    :D


    By the way..just ping 239.39.39.39 from Source and you'll get to see the action.
  • Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    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..
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • Mrock4Mrock4 Banned Posts: 2,359 ■■■■■■■■□□
    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_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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. icon_wink.gif
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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... icon_confused.gif
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    Multicast is nuts again...

    allout.gif

    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.

    allout.gif
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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..... icon_confused.gif

    I will have to recreate this.
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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. icon_confused.gif

    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_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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.
  • bighornsheepbighornsheep Member Posts: 1,506
    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.
    Jack of all trades, master of none
  • kryollakryolla Member Posts: 785
    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
    Studying for CCIE and drinking Home Brew
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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.
  • kryollakryolla Member Posts: 785
    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.
    Studying for CCIE and drinking Home Brew
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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. icon_confused.gif

    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_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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.
  • Mrock4Mrock4 Banned Posts: 2,359 ■■■■■■■■□□
    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_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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... :)
Sign In or Register to comment.