As I understand it, public IPv6 addresses allocated by the IANA will have the prefix 2000::/3. These ip addresses will be routable through the Internet.

IPv6 multicast addresses on the other side are prefixed FF00::/8.

So my understanding is that the ipv6 multicast addresses won’t be routable through the internet. I am right? If so, is there any way to do one-to-many ip routing over the Internet in IPv6?

Thanks!

So will I be able to access a multicast group over the internet or
will it only be supported through private networks like in ipv4?

I must correct a assumption you seem to have made here.

If all the routers between you and your destination support it, then Multicast can certainly work over the IPv4 Internet. It is simply blocked or not configured in many places. I suspect this is because multicast is not well understood, and many people believe they do not need it. So they simply do not permit it through their firewalls/routers.

IPv6 certainly is capable just like IPv4 of having Multicast work globally. Only time will tell us if people actually permit multicast through their networks.

Check more discussion of this question.

We have a LAN with 2x Cisco 4500′s as gateways running HSRP.
We’re using Exterity HD IP Encoders to take HD video and put it onto the network as a multicast UDP stream (playable in VLC).

I have a fairely extensive Nagios setup on Linux and would like to find some way to check that:

1. Multicast stream is on the network.
2. Multicast stream isn’t frozen, so check for audio or …
3. Confirm the source IP of the stream matches what we expect from the multicast address.

1 and 3 could be combined maybe.

My approach thus far:

Using SNMP on the Cisco HSRP gateway IP:
Nagios sends 2 arguments, IP of the host (which should be the source of the multicast), i.e. 172.18.25.101
Second argument is IP of the stream ($mroute), i.e. 239.101.0.1

snmpwalk -v 2c -c changed 172.30.0.1 1.3.6.1.3.59.1.1.2.1.4 | grep $mroute | sed -e ‘s/.*IpAddress: //’

A few if’s later, and I have, if the stream is on the network, if the multicast I sid for matches the host ip, or if not tells me where is is coming from. And exits correct for nagios.

Or so I thought. Generally it is working as expected, but randomly with some hosts the source IP is not expected and is something different, and when checking manually it is clearly not correct. I think maybe a topology change or something (we have quite a large network), and it’s seen from the other gateway or… I’m not great on multicast sorry.

I’m pretty much stuck with the above part.

I then wanted to check that the video/audio was not frozen, I thought another check could be to use mplayer to dump the stream for 2 seconds to a file and do a check based on the size of the file. if it is very small then its probably frozen. But the stream will still send an image, so go with an audio check over a longer, say 10 second period. The more I thought about this, the more I thought “there must be a better way”…

IPTV is pretty big these days, how are people monitoring multicast streams.

Thanks very much.

Have you considered using the IP-MROUTE-STD-MIB rather than the IGMP MIB? You can get statistics on a per-mroute basis – which will give you a much better view of the source in particular. There’s also a set of Cisco extensions to this MIB that can provide more in the way of platform-specific info. One item you can potentially look for is a substantial difference in counters on your various routers through the path of the mroute. Some delta is to be expected but this is would be a good place to track thresholds.

For tracking streams freezing there’s a pretty easy answer: ip multicast heartbeat (http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmulti.html#wp1003131). You can configure a given router to throw an SNMP trap if no packets are seen on a configured multicast group for 10 seconds.

There is also a feature called mrm (multicast route monitor) that can be called from the Cisco CLI to set up and track synthetic multicast groups. You’d likely want to use EEM or similar to call it periodically and then throw a trap or syslog if it doesn’t behave normally. This is also a good troubleshooting tool.

Also – just as you (should) monitor for changes in IGP adjacency, so too should you track on PIM. Events like neighbor state changes, elections, etc can indicate instability in the tree. It’s not -necessarily- a big deal in all cases but should generally be quiet on a stable network.

I’m not sure which supervisor you’re running in your 4500′s, but some of the more recent models support netflow for multicast. This would give you a much more granular and global view of multicast performance and would naturally lend itself to statistical trending, storage, etc.. definitely a good way to go.

I hope this helps-

Check more discussion of this question.

My Server and Client softwares run both on Linux.
The Server broadcasts multicast, the Client listens multicast.

My Client has to migrate to another site,
and unfortunately multicast is not allowed between the two sites

How to convey multicast between the two sites?
– Through TCP or UDP?
– What tools do you recommend?
– What about latency?

I received an good answer about Cisco configuration (GRE),
but one of the network teams do not want to monitor/maintain it,

=> when transmission will break, support team will spend too many hours to understand and repair.
=> So, what should be the best alternative to GRE?

Is there a solution based on Linux kernel features
or on network card capabilities? (low latency is important)
Usage examples are appreciated

• Currently: Server and Client on the same site

  

• Future: Server and Client, each one on a different site

  

multicast channel: 225.1.0.1:6666

Related questions

• UPD Multicast (Class D) = How can this be routed over the internet?
• IGMP/Multicast routing in Linux
• Multicast accross the subnets and RSVP answer
• Multiple GRE NAT router and “Multiple VPN limitation” link
• …

I am not sure to understand your graphic in your question, but as far as I understood, you need to forward multicast packet through TCP ? A tool oriented solution may involve socat:

For instance, multicast channel is 224.1.0.1:6666.

On the Server host (IP=SS.SS.SS.SS):

$socat -v UDP4-RECVFROM:6666,ip-add-membership=224.1.0.1:CC.CC.CC.CC,fork TCP:destination.hostname:4444

On the Client host (IP=CC.CC.CC.CC):

$socat -v TCP-LISTEN:4444,fork UDP4-DATAGRAM:224.1.0.1:6666,range=SS.SS.SS.SS/24

I let you check how to tune parameters with the socat manual. It is quite straightforward once you know you MULTICAST GROUP and your network interface’s ip adresses.

Check more discussion of this question.

Could somebody explain what exactly this command means in relation to transmitting and receiving multicast traffic

route add -net 224.0.0.0 netmask 240.0.0.0 eth0

The “224.0.0.0″ is a reserved range of IPv4 addresses having special multicast meaning (IPv4 Multicast).

The command in itself just means that the multicast routing should go through the “eth0″ interface.

Check more discussion of this question.

I have a FreeBSD 9 router (a Soekris net6501) connected to the internet via a dsl modem (bridged), doing NAT for two internal subnets, 10.0.1.0/24 (LAN) and 10.0.2.0/24 (wifi net).

There are routes between the subnets and things like ssh host-A.wifi from host-B.lan works.

But, wireless clients (like iPads and iPhones) on the 10.0.2.0/24 net can’t seem to find stuff on the LAN (for example, airplay to an Apple-TV on the LAN).

I’m not totally sure, but I think this is because Apple uses Bonjour and Bonjour uses Multicast to find things and Multicast is not routed across subnets.

According to the FreeBSD handbook, to route multicast, I need to compile the kernel with options MROUTING and create a /etc/mrouted.conf, but I can’t find any good examples of the configuration file.

1. Is my problem related to multicasting across subnets?
2. Is mrouted the preferred solution in FreeBSD to enable routing?
3. How do I create a /etc/mrouted.conf that routes between 10.0.1.0/24 and 10.0.2.0/24?

Thanks to @chris-s, I solved my own question by using Avahi instead of trying to route the multicast traffic.

This worked for me:

• Compile and install net/avahi and dns/nss_mdns from the ports tree.
• Add avahi_daemon_enable="YES"and dbus_enable="YES" to /etc/rc.conf
• Use the avahi configuration file (/usr/local/etc/avahi/avahi-daemon.conf) and added my two internal network interfaces (two internal subnets) to the allow-interfaces key (comma separated) and set the enable-reflector key to yes to make avahi propagate the traffic to all internal networks.
• Edit the hosts entry in /etc/nsswitch.conf to hosts: files dns mdns

After starting the avahi daemon, you can check if it works either by directly doing a lookup from the mdns server machine:

root@server / # getent hosts apple-tv.local
10.0.1.4          apple-tv.local
root@server / # getent hosts iphone4s.local
10.0.2.27         iphone4s.local
root@server / # getent hosts ipad.local
10.0.2.22         ipad.local

Or by browsing the .local domain with a utility like Bonjour Browser or iStumbler (both excellent). You should be able to see devices, hosts and services on all subnets.

A footnote is that my stock FreeBSD 9.0 installation’s /etc/syslogd.conf didn’t log the messages from avahi-daemon by default so I didn’t see any logging at first (added a daemon.* selector pointing to /var/log/daemon.log)

Check more discussion of this question.

I’m trying to pass mulitcast stream from interface eth1 (192.168.20.41) to interface tun0 (192.168.100.40) on CentOS 5.

I can see incoming multicast stream on eth1:

tcpdump -n -i eth1

type=1700 audit(1324681169.542:52): dev=eth1 prom=256 old_prom=0 auid=4294967295 ses=4294967295
Dec 23 17:59:29 localhost kernel: device eth1 entered promiscuous mode
Dec 23 17:59:29 localhost kernel: type=1700 audit(1324681169.542:52): dev=eth1 prom=256 old_prom=0 auid=4294967295 ses=4294967295
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
17:59:29.576192 IP 192.168.20.20.52194 > 224.1.1.1.search-agent: UDP, length 1328
17:59:29.576277 IP 192.168.20.20.52194 > 224.1.1.1.search-agent: UDP, length 1328
17:59:29.576801 IP 192.168.20.20.52194 > 224.1.1.1.search-agent: UDP, length 1328

But I cannot see multicast on tun0 interface. What I’m doing wrong?
The configuration is attached below:

/etc/igmpproxy.conf file:

phyint eth1 upstream  ratelimit 0  threshold 1
        altnet 192.168.100.0/24
phyint tun0 downstream  ratelimit 0  threshold 1
phyint eth0 disabled
phyint eth5 disabled

iptable configuration:

iptables -A INPUT -p igmp -j ACCEPT
iptables -A INPUT -d 224.0.0.0/240.0.0.0 -p udp -m udp -j ACCEPT
iptables -A FORWARD -d 224.0.0.0/240.0.0.0 -p udp -j ACCEPT
modprobe ipt_TTL
iptables -t mangle -A PREROUTING -d 224.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1

tun0 adapter is GRE tunnel over eth0:
cat /etc/sysconfig/network-scripts/ifcfg-tun0

DEVICE=tun0
TYPE=GRE
ONBOOT=yes
MY_INNER_IPADDR=192.168.100.40
PEER_INNER_IPADDR=192.168.100.30
PEER_OUTER_IPADDR=192.168.20.30

I consider multicast routing kind of a black magic, but here are few shots …

• Check if igmpproxy creates the multicast route using ip mroute command.

• If it does, your kernel is probably still filtering the input.

• Most common cause is missing route to the source. Did you try disabling iptables? Or use TRACE target?

• And if multicast route is not created I’d suggest using pimd (that’s what I use for routing my IPTV multicasts).

• And it seems you use altnet wrong. According to mrouted documentation, it means

Specifies an additional subnet (network) attached to the physical interface described in the phyint entry. mask_len is the length of the network mask.

Check more discussion of this question.

I have secured a linux box, starting with

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

and after adding rules to enable specific protocols and streams.

• Which are the correct rules to add multicast support ?

I am trying with these – for both client and server multicast :

iptables -A INPUT  -m pkttype --pkt-type multicast -j ACCEPT
iptables -A OUTPUT -m pkttype --pkt-type multicast -j ACCEPT
iptables -A INPUT  --protocol igmp -j ACCEPT
iptables -A OUTPUT --protocol igmp -j ACCEPT
iptables -A INPUT  --dst "224.0.0.0/4" -j ACCEPT
iptables -A OUTPUT --dst "224.0.0.0/4" -j ACCEPT

Linux 2.6.38-12 / iptables 1.4.10

• Is there any internet service to test my multicast set ( pc + adsl router + provider ) ?

multicast over the global internet does not exist, it is unicast only.

If you wish to test multicast addresses, configure it within your own network.

Check more discussion of this question.

I have linux computer , this computer connected with entire my network via zyxel gs-2200.

In this zyxel also connected router with 500 vlans, one by client.

On linux computer i have vlc program that stream multicast ip-tv.

In the same vlan where is my linux box, i can see the tv.

Question is, how to reshare this multicast stream to all vlans?

Who (zyxel, router (freebsd) , or linux box) and how must modify stream to be public for all client vlans.

You need to use multicast routing between the VLAN’s to make this work.

From what I can tell you’ll need to compile the FreeBSD kernel with the MROUTING option, and then use mrouted.

See the following thread on the official FreeBSD forums for more information:
http://forums.freebsd.org/showthread.php?t=5875

Check more discussion of this question.

I need a virtualization solution with the following properties:

• guest OSes can receive multicast traffic from the host machine.
• some services running on the guest OS (eg: port 80) can be port forwarded, so it’s visible on the host and other machines.

I tried vmware player, it doesn’t support multicast at all.

I managed to set up port forwarding with Virtualbox, but multicast doesn’t work seem to work.

If you can’t use bridging mode for your virtual machine’s NICs in your configuration, you might try setting up a separate private network and set up multicast routing between the pivate and the public network, presumably including NAT for outbound private traffic.

A possible solution might include host-only networking (this would give you a virtual NIC in your host operating system not connected to anything else but the virtual network) and the appropriate multicast routing / NAT setup at your VM host.

I don’t think this is a good task for a Windows machine. If your Host must be Windows and you are not able to either get even a single further IP address for a Linux guest VM or a separate appliance performing this job or move the public IP address your host uses to the aforementioned Linux guest, you are probably stuck here.

Check more discussion of this question.

I work on a product that consists of a number of headless Linux boxes that work together as a cluster.
These boxes synchronize their state with each other by sending proprietary-format link-local IPv6 multicast packets (to ff12::xxxx%en0). These packets can take up a non-trivial amount of bandwidth when the system state is changing quickly, but that’s okay because the Linux boxes are running over a Gigabit Ethernet LAN and there is plenty of bandwidth to spare.

The problem happens when a customer decides he’d like to use his laptop (or iPad) as a client to the system while roaming the building, and so the customer adds a WiFi access point to the LAN and sets up his laptop to communicate (via unicast) with one of the Linux boxes over the WiFi.

This typically “sort of” works, but the problem is that all the multicast synchronization packets sent by the Linux boxes are now being sent over WiFi, even though the client(s) don’t need them or use them. As a result, WiFi bandwidth is often impacted, sometimes to an unusable state, and the customer complains that our system isn’t working properly.

We could, of course, just tell the customer “don’t do that”, but WiFi is very useful and I’d like to find a more constructive solution to this problem than just forbidding WiFi. Is there some (reasonably simple) way to configure a WiFi access point to filter out these synchronization multicast-packets? Simply getting the WiFi access point to not handle IPv6 packets would be sufficient for our purposes, since the client software can run over IPv4 if necessary, but some more nuanced filtering that doesn’t preclude all IPv6 traffic would be nicer.

Note that the most common access point installed by our customers is Apple’s Airport, but if there is another (more configurable) WiFi access point product that would work better, replacing the access point with a different model is an option.

If your switch (or more accurately the client’s switch) is capable of filtering the multicast packets by address (blocking the multicast prefix) that would be my first suggestion.

Barring that you can put a simple filter device (firewall) between the WAP and the main network that just drops any packets to/from the multicast address range…

Check more discussion of this question.