Bruce, As the MTU needs to match on both the Controller and Access Points it can only be applied to all devices currently. This is really not much of an issue as most MINT packets are small so having a lower MTU will not impact the operation of the system. Worst case you will see the ocasional large MINT packet being split into two pieces instead of being sent as one packet. Is the customer pushing back on this - if so what is there specific concearn? Regards, Kevin

I remember seeing in one of the WiNG5 release notes (think 5.4.1) and also with a customer, where with Juniper Routers you would have to disable IGMP Snooping. Looks like enabling this can cause the Juniper routers to drop our multicast packets.

IGMP snooping / pruning will drop un-known multicast traffic by default. The whole purpose of the feature is to only permit multicast traffic when members on the VLAN send a group membership report explicitly requesting the multucast group. If no host requests the group the multicast traffic is pruned! Regards, Kevin 

Thank you Kevin for the additional detail and tool to assist in understanding and analyzing. My feedback to this information, based on your point of this being relatively common.  If this is the case, knowledge on the topic is nearly non-existent within any Installation, NOC how-to's or best practice documents, as well as our customers and partners first line of support appears wholly un-aware of this as a common situation.

Kevin, Bruce, I've recently found this in another customer, where just one of their many stores has an MTU restriction.  Do you know if it is possible to set the MTU between a defined group of APs and the controller, or does it have to be globally?   Chris

There are some switches that don't bridge Ethertype 0x8783 depending on config. However, going by your topology, the AP is L3 adopted, hence all Mint packets between the controller will be over IP/UDP and no 0x8783 packets will be exchanged between the two. If indeed you're using L3 adoption: It is possible you have an MTU related issue, especially as you mention. > RFS 7000 sees the AP6532 as 'online' but is not able to push changes to it This suggests that smaller mint packets (required for adoption) go through but not the larger packets used for config push. Try this: Obtain the AP's mint id (on the AP, 'show mint id') Use mint ping to verify connectivity between the AP and controller. On the controller execute mint ping size 10000 If the first succeeds and the second fails it's likely you have an MTU issue. To change the mint MTU, in config mode mint-policy global-default mtu 1300 Both the AP and the controller must have the mint mtu configured correctly ('show mint config' will display the MTU value in use) If that gets things working for you, note that 1300 is an extremely conservative value and you should check what value closest to 1500 works for you (too small a value will unnecessarily generate additional IP fragments for mint traffic)

Trevor you are correct. I had my suspicions on the MTU when I identified the WAN link was via VPN tunnel, but support kept waving me off on the topic. I believe generally speaking a VPN tunnel doesn't cause this issue, but rather the combination of our RFS and the Juniper SSG5 simple does not share the same interpretation or approach to packet fragmentation and reassembly. Some follow up details: The mint ping

Bruce, This is actually a common issue and its not uncommon for us to have to reduce the MINT MTU to get adoption working in MPLS or VPN envrionments. A good tool to test with is a Windows utility called mtupath.exe ( http://www.iea-software.com/products/mtupath.cfm) which can quickly tell you the maximum MTU supported by each device in the path. Regards, Kevin