Question

IP multicast over WiNG wireless mesh

  • 31 January 2021
  • 6 replies
  • 98 views
C

I have established a wireless mesh network between 3 AP7532s. One AP is root and is connected into the wired network.

The mesh is mainly stable (although I keep getting messages in smart-rf history like “AP floor3-AP7532 master connectivity timed out” but that is not the purpose of this question).

Both of the non-root APs have a strong signal with the root. They are only a few metres apart.

However I have a problem where services relying on IP multicast are not working EXCEPT on the wired root AP.

 

For example: there is an HP printer that advertises itself on 224.0.1.60; wireless clients (all Win10) with this printer installed report the printer as offline and can print only intermittently. (I have resolved this by setting the clients up with the static IP address of the printer, but this requires manual intervention for every client, so isn’t ideal). Clients and printer are on the same VLAN. All clients can ping the printer’s IP address.

Another example: we are using DHCPv6, and wireless clients are trying to get a DHCPv6 address by sending requests for ff02::1:2. Wireless clients connected to the root AP are succeeding, but wireless clients connected to the mesh APs are sending requests (confirmed with Wireshark) but these requests are not reaching the server - also confirmed with tcpdump on the server.

I have tried both with and without IGMP and MLD snooping on the relevant VLAN but this makes no difference. The meshpoint QoS policy is the default for the moment.

Can anyone suggest anything I should configure in order to enable IP multicast over the mesh?

I can post my configuration if necessary.

Thanks,

ChrisSW.

 

6 replies

C

Thank you Tomek. Disabling the IPv6 firewall (under advanced settings) has now allowed clients to get DHCPv6 addreses. DHCPv6 uses IPv6 multicast.

Clearly disabling that IPv6 firewall isn’t ideal but I think we can live with it for the time being.

I will continue to investigate what can be done about IPv4 multicast.

I have also heard about 7.5.1 being buggy. If I can get an outage window I’ll try again with a 5.x version.

C

BTW the APs are on version 7.5.1.2-008R

O
Rank
Userlevel 5

Hi Chris,

Try sending the multicast traffic over mesh using the higher priority. Under the Mesh QoS policy make the following changes, save the config and check if that helps. You can also specify a multicast address in the following command instead of autodetect. 

 

VX9000-Primary(config-meshpoint-qos-default)~#show context
meshpoint-qos-policy default
 accelerated-multicast autodetect classification voice
 

Since you have mentioned that the multicast traffic does not reach the server, do a service pktcap on “drop” on the wireless then radio interface to see if any packets are being dropped, you can apply filters to these commands to further fine-tune the output.  

VX9000-Primary~#service pktcap on interface radio 2 drop verbose

VX9000-Primary~#service pktcap on bridge drop verbose 

 

Regards,

Ovais

C

Thanks Ovais

I’ve made the config changes you suggested but it has not made any difference.

The printer I mentioned uses only 2.4GHz and connects wirelessly to a mesh AP. The printer’s IP address is 192.168.2.254.

Using service pktcap, I can see that IPv4 multicast traffic from the printer is reaching the AP’s radio1:

AP7532-Ground*#service pktcap on interface radio 1 drop filter host 192.168.2.254 and net 224.0.0.0/4
Capturing up to 50 packets. Use Ctrl-C to abort.
1 radio 1 7:50:05.121099 I IGMP: 192.168.2.254 > 224.0.0.252, DF, IPv4 length 32, DSCP 48
2 radio 1 7:50:10.641489 I IGMP: 192.168.2.254 > 224.0.1.60, DF, IPv4 length 32, DSCP 48
3 radio 1 7:50:10.641674 I IGMP: 192.168.2.254 > 239.255.255.250, DF, IPv4 length 32, DSCP 48

The packets are marked with “I” for incoming. Note that there are no corresponding outgoing packets.

(Incidentally the “drop” keyword doesn’t seem to make any difference).

On the other hand, unicast traffic shows both incoming and outgoing traffic:

43 radio 1 7:57:04.018101 I IGMP: 192.168.2.254 > 224.0.1.60, DF, IPv4 length 32, DSCP 48
44 radio 1 7:57:06.014815 I IGMP: 192.168.2.254 > 224.0.0.252, DF, IPv4 length 32, DSCP 48
45 radio 1 7:57:07.934332 I IGMP: 192.168.2.254 > 239.255.255.250, DF, IPv4 length 32, DSCP 48
46 radio 1 7:57:08.898502 I UDP: 192.168.2.254 > 44.224.180.80 ports 48654 > 9930, data length 80, DF, DSCP 0
47 radio 1 7:57:09.056653 O UDP: 44.224.180.80 > 192.168.2.254 ports 9930 > 48654, data length 144, DF, DSCP 0
48 radio 1 7:57:16.066543 I UDP: 192.168.2.254 > 44.224.180.80 ports 52804 > 9930, data length 80, DF, DSCP 0
49 radio 1 7:57:16.220848 O UDP: 44.224.180.80 > 192.168.2.254 ports 9930 > 52804, data length 144, DF, DSCP 0
50 radio 1 7:57:16.623231 I UDP: 192.168.2.254 > 192.168.2.101 ports 3702 > 51437, data length 2635, IPv4 fragment id 46216, offset 0, DSCP 0

(the 44.* address is a cloud-based service which the printer uses).

The multicast router is connected to the wired side of the root AP.

I’m guessing that whatever is stopping IPv4 multicast going over the mesh is also stopping IPv6 multicast. This output from “debug ipv6 all” on the mesh AP shows IPv6 multicast entries being dropped from the IPv6 FIB (I think):

Feb 08 08:01:41 2021: DPD2: 2021-02-08 08:01:41 sock.c:59 recv_ipv6_msg ()
Feb 08 08:01:41 2021: DPD2: 2021-02-08 08:01:41 default_router_selection.c:476 add_default_router_info router address (fe80::2f2:8bff:fe7f:e90), source: 1 preference: 0
Feb 08 08:01:41 2021: DPD2: 2021-02-08 08:01:41 default_router_selection.c:153 find_entry_by_addr router address (fe80::2f2:8bff:fe7f:e90)
Feb 08 08:01:43 2021: DPD2: 2021-02-08 08:01:43 fib6.c:992 del_ipv6_fib_entry (route = ff02:0:0:0:0:0:0:d, prefixlen = 128, next_hop = ff02:0:0:0:0:0:0:d, type = 1, nh_flag = 1)
Feb 08 08:01:43 2021: DPD2: 2021-02-08 08:01:43 fib6.c:992 del_ipv6_fib_entry (route = ff02:0:0:0:0:0:0:16, prefixlen = 128, next_hop = ff02:0:0:0:0:0:0:16, type = 1, nh_flag = 1)
Feb 08 08:01:43 2021: DPD2: 2021-02-08 08:01:43 fib6.c:992 del_ipv6_fib_entry (route = ff05:0:0:0:0:0:0:101, prefixlen = 128, next_hop = ff05:0:0:0:0:0:0:101, type = 1, nh_flag = 1)

I don’t know if there is a similar debug for IPv4.

Regards,

Chris.

T
Userlevel 3
Badge

Hello,

 

Do you have any firewall rules regarding multicast ? eg.:

BTW 7.5.1 seems to be buggy. 

 

regards,

Tomek

T
Userlevel 3
Badge

Hi, Please check also ipv4 acl rules, 

 

regards,

Tomek

Reply