Multicasting with the GBS

In a recent field op, I got my first chance to experiment with multicasting in a production environment. There were a bunch of scenarios I came across in my CCIE training (which is not currently going so well) and I’ve settled on having a personal preference for BSR. Given I would like to maintain the ability to multicast to non-Cisco devices, I don’t want to do any proprietary configurations, plus BSR is very simple.

This paragraph is not going to even come close to doing the subject justice, but you have two major options when configuring multicasting: dense mode and sparse mode. There are other options out there, but these are the biggies. Dense mode will flood a bunch of traffic and is far from optimal in our already bandwidth constrained environment. Sparse mode elects a “traffic cop” to control who has access to what multicast streams. The traffic cop function is known as a Rendezvous Point (RP). Without a RP, sparse mode will not work.

To start the configurations, you need to turn on multicasting on all layer 3 devices from the multicast source to the multicast destinations.

On a switch:

Switch(config)#ip multicast-routing distributed

On a router:

Router(config)#ip multicast-routing

Your configurations can get pretty complex from this point forward, but the basics are very simple. On one of your devices, configure a loopback and make sure that it is routed throughout your network. The configurations below will configure the device with the loopback as a RP using the loopback you have configured.

On the device you have configured your loopback:

Router(config)#int lo X

Router(config-if)#ip pim sparse-mode

Router(config)#ip pim bsr-candidate lo X

Router(config)#ip pim rp-candidate lo X

On every layer 3 device, on every interface connecting layer 3 devices:

Router(config-if)#ip pim sparse-mode

The basics of your multicast configuration are now complete. The last portion which is specific to the GBS is the trickiest part. Multicast uses a function called Reverse Path Forwarding (RPF). You can read the basics about RPF here: http://en.wikipedia.org/wiki/Reverse_path_forwarding. The GBS will always fail the RPF check because it is a receive only suite. There are certainly other ways to accomplish this, but the easiest way is to create a multicast static route. A multicast static route will allow multicasting to ignore the RPF check for the multicast source specified. The best way to accomplish this is to sniff your multicast traffic, figure out the source of the steams you would like to have routed, and create static routes for those sources. If this is not something you have the time or expertise for and you just want the GBS to work, you can just configure a multicast static route for everything and point it towards the GBS. This is not the best option, but it will get the job done in a pinch. Here is what that looks like:

Router(config)#ip mroute <Network ID> <Mask> <next-hop ip>

Router(config)#ip mroute 0.0.0.0 0.0.0.0 <ip address of SkyStream or KG-250>

If you have any issues with the employment, there are a couple of verification commands that will come in handy. Before you attempt any verification, you actually have to try to activate a multicast stream. Your best bet for this is to try and open VLC and attempt to view a multicast stream. After you have tried this, start with the closest layer 3 device to where you are trying to open VLC and type:

Router#show ip pim rp

If you do not see an RP for the multicast stream you have just tried to view, you most likely forgot an “ip pim sparse-mode” on one of your layer 3 connections. Similar to EIGRP or OSPF neighbors, you can go link by link and make sure you have neighbor relationships. You can verify this by typing:

Router#show ip pim nei

Multicasting is one of the more difficult topics you will come across in your networking career, but this should at least get you started if you are having problems getting multicasting working with the GBS.

8 Responses to "Multicasting with the GBS"

Jason Kirk says:

September 11, 2013 at 9:12 am

Welcome back John!

Reply
Aaron Bauman says:

September 11, 2013 at 7:52 pm

Welcome back!

Reply
Jeff Yanagi says:

September 25, 2013 at 6:26 am

Great post concerning the employment of multicast routing that most Marines don’t have the requisite knowledge on.

There is an alternative to avoid to utilizing static mroutes. If an administrator were to do a “show ip mroute ” for a specific mcast group, they should see the (S,G) listed as a private IP address (192.168.XX.YY , ).

You can actually place a secondary IP address on the SVI or routed port that leads to the SkyStream server. Additionally, it is important to mention that many Marines believe the SkyStream is the SOURCE of the multicast traffic. The SkyStream is not the source, it merely is the vehicle that delivers a unit their video feeds. The real source is on the other side of the GBS 🙂

For instance:

Router(config)# interface VlanX
Router(config-if)# ip address 172.16.0.X 255.255.255.0
Router(config-if)# ip address 192.168.XX.## 255.255.255.0 secondary

The secondary address should be on the same network as the source of the multicast session [The “S” portion of the (S,G)], verified by the “show ip mroute” command.

Instead of placing static mroutes on each switch, we can instead inject these two networks (GBS Network and Source network) into EIGRP, or whatever IGP that a unit is running and dynamically share this throughout a topology (especially if there’s more L3 devices – that’s a lot of static mroutes!)

Router(config)# router eigrp
Router(config-router)# passive-interface VlanX
Router(config-router)# network 172.16.0.X 0.0.0.0
Router(config-router)# network 192.168.XX.## 0.0.0.0
Router(config-router)# no auto-summary

This ensures reachability without the need for static mroutes on all devices within a muticast path, as well as resolves any RPF errors that you may encounter for your CNN, FOX and Pentagon video feeds.

Hope this information helps other units out – we’ve implemented this with the 26th MEU and were successful.

Reply
1. John says:
  
  October 7, 2013 at 8:12 pm
  
  Thanks for the great comment! A secondary address would certainly work, of course then you would need to route that network (as you expertly explained) and it would require de-conflicting the address space (which may or may not work with what you’ve already setup). The secondary address is probably a better solution than the static mroutes. In our topology, it really didn’t matter because because the GBS was connected to our core switch (which is the only place where the RPF check failed), so one static mroute covered it all. If you wanted to you could also send a static route towards the GBS for a third option (a pretty crappy one, but still a third option).
  
  Reply
Jared says:

August 26, 2014 at 1:26 pm

Is it necessary to add the multicast commands on tunnel interfaces as well for this? I am trying to pull this feed through a black core routing environment.

Reply
1. John says:
  
  August 27, 2014 at 1:43 am
  
  I generally recommend against multicast commands on tunnel interfaces unless you have a specific reason for doing so. If you made me answer, I would say no (with the assumption you are pulling the feed from a GBS that is not using the BC). If this is the case, you probably do not need those commands on the tunnel interface unless someone is pulling feeds through your BC connection. One time I could imagine you need to use these commands is if you are extending services to someone through a VSAT who does not have their own GBS, who happens to need feeds. This would crush the connection, but mission might dictate that requirement. Hope this helps.
  
  Reply
Jared says:

August 26, 2014 at 3:08 pm

Also, is there any reason I need to use a loop back as my RP instead of the SVI I’m using to represent my GBS network?

Reply
1. John says:
  
  August 27, 2014 at 1:36 am
  
  You do not NEED to use a loopback, it is just a good idea. The concept being the loopback will always remain up. Your SVI will go down as soon as the final active port in the VLAN drops (which depending on your situation, may or may not be a big deal).
  
  Reply

Leave a Reply Cancel reply