I have a Cisco RV160 setup with two networks (subnets) setup on my desk. This is not a setup that will join the Internet or any other large network for that matter...at least not for my purposes here. So all firewalling and NAT routing have been turned off in order to turn this into a plain router between two subnets.
The LAN ports represent my 2021:: network and the router has an IP of 2021::1 on that subnet.
The WAN portrepresents my 2020:: network and the router has an IP of 2020::92.
Note, my choice of 2020:: and 2021:: were completely arbitrary. If there's something about these numbers that are part of the problem, let me know what I've missed. I was simply trying to avoid using FDxx:: numbers since it's most likely our customers will deploy Internet-valid IPs, not private IPs. So I wanted my test setup using values "similar" to what they would be using...although shorter in complexity just to make typing them faster and viewing them in wireshark easier.
The router routes IPv6 unicasts without any problem between the two networks. However the protocol I'm working with (BACnet) relies heavily on broadcasts for device-discovery (not related to IPv6 discovery functions). As a result all BACnet routers pass broadcasts freely between their datalinks. Not all of the datalinks are Ethernet-based. BACnet supports RS485 networks with protocols such as MSTP and ARCnet. Also note, BACnet routers only route BACnet traffic. These are not routers in the general IT sense.
Because BACnet relies so heavily on the traversal of broadcasts, the protocol pretty much reinvented its own version of multicasting in order to traverse local broadcasts to other IPv4 subnets. It does this with devices called BACnet Broadcast Management Devices (BBMDs) which relay (i.e. unicast) local BACnet IPv4 broadcasts to BBMDs on other IPv4 subnets that require hearing the broadcasts. Each subnet has a BBMD and all the BBMDs know about each other, so they can unicast the local broadcasts to each other.
BACnet only fairly recently started to support IPv6. Since IPv6 doesn't have "broadcasts", the way IPv4 did, BACnet is forced to make use of IPv6 multicasts. There are 3 multicast addresses that are IANA reserved for BACnet, which are:
FF02::BAC0 (link-local multicasts)
FF05::BAC0 (site multicasts)
FF08::BAC0 (organization multicasts)
The link-local multicast address isn't expected to be routable.
However the other two are. It's expected that a local IPv6 router(the "Designated Router" for multicast routing) will hear the ICMPv6 Multicast Listener messages of a listening BACnet client device joining the multicast group, and thus relay any multicasts produced by other devices to that client. Since I'm one of the developers implementing BACnet/IPv6 into our product, I have setup a Cisco RV160 to test this. And as the title of this post indicates, it is not working. Here's what I've got setup on my desk:
The intent is that the two G5RE devices will both join the FF08::BAC0 (or FF05::BAC0) group and send local BACnet broadcast packets, to that multicast group for the other device to hear and redistribute to its local datalinks similar to how BBMDs work in IPv4.
To remove our products from the equation, I've setup a PC, one on the 2021:: subnet, and have it and the Win10 on the 2020:: subnet joining the same multicast as well as producing packets destined to FF08::BAC0. So the network looks more like this:
This allows me to also run wireshark from those PCs and see what's being produced on the network. And what I'm finding is that the Cisco RV160 doesn't seem to be routing my multicasts between the two subnets (captures available if anybody is interested). However pings and other unicast communications directly between the PCs work fine. I can even have my Win10 machine ping FF05::BAC0 and the local Ubuntu (2020::252) machine responds. But I can't get the remote Ubuntu machine to receive any of the 2020:: multicasts. Nor do the 2020:: PCs hear multicasts produced by the Ubuntu 2021::5 machine.
The multicast test code I have is written in Java, so I researched issues with getting Java to route multicasts, and I stumbled across a mention that multicasts, by default, are given a HopCount of 1 to keep them from routing to other subnets. Wireshark confirmed that, indeed, my multicasted UDP packets only had a hop of 1. So I updated my code to make sure my UDP-based Datagram Multicasts are given a hop count of 30 (confirmed with wireshark captures). This didn't help.
I also read some documentation that says that Multicast Listener messages should always be sent using a link-local address as the source, so I've made sure that my client-code is producing the MLDv2 Multicast Listener messages with the fe80: address of my PCs and the UDP packet generation code that sends packets to the mutlicast is using the "global" IP as the source. Again, still not working.
So this had me digging into IPv6 multicast a bit deeper to reaffirm my understanding of IPv6 multicasting. And as I thought, local IPv6 routers (assuming multiple) should negotiate to determine which will be the subnet's "Designated Router" (DR). The DR. Again assuming the network has multiple routers, one needs to be designated as the Rendevous Point (RP) router. All DRs will encapsulate local multicasts into PIM packets destined to the RP. In the process, each router updates their multicast routing table to include info about their local multicast clients PIM routes, and which datalink(s) face the RP router. This would suggest that I should be able to see the Cisco RV160's multicast routing table from its GUI-webserver. But I don't see anything that suggests it configures IPv6 multicasts or indicates the status of DR and RP election results. I also don't have any way of manually setting the router to intentionally win those elections. In the case of a single router network, the router should be the DR on each of its subnets and it's own RP if an RP is even necessary for a single-router network.
So I'm looking for help on what I'm missing and how I can get this RV160 to be the one and only Multicast Router in my little test setup.
By the way, once I get this working, my next test is to separate my multicasting PCs with two routers which effectively will force the need for an RP router and PIM messages from the 2nd router to the RP to traverse multicasts. Then it snow-balls into setting up 6rd and 6to4 networks and testing with those configurations.
Once I get my testcode working, I'll re-introduce our products back to the network and should have a bit more success OR at the very least, know what our code needs updating to make IPv6 multicast routing work. It's clear to me that we will need to also develop multicast testing tools for our field techs. If I'm having this kind of trouble with a single router, I suspect our customers who are migrating to IPv6 are going to have similar problems with their network setups.
If you would like to see the Java test code I have, I'll be glad to post it along with captures. However my suspicion is anybody that's familiar with IPv6 routed multicast will be able to recognize exactly what's missing and explain what I need to do to alleviate the problem.
I'm also open to any other heads-up advise about potential issues that I'm likely to run into as my test setups get more diverse and complicated.
