Hello,
I am currently trying to bring SMs from a network we bought from another company into our management system.
These SMs are running NAT
NAT Private Network IP Address: 192.168.200.1
with the untagged ingress VID set to 1 (NAT public IP 10.44.0.0/16) and the management VID set to 1 (Radio Public IP 192.168.0.0/16).
What I want to do is change the management VID to 2 (Radio Public IP 10.0.0.0/16) and leave the untagged ingress VID at 1 for the time being.
If I happen to make this change to a customer’s SM they seem to experience a very intermittent connection. I just got off the phone with one customer and they claim it may work for 30 seconds and then quit for 30 seconds, etc, etc…
Is VID 1 the native vlan in Canopy equipment?
Any thoughts on what might be going on here.
I have some SMs swtiched to bridge mode with management VID set to 2 and untagged ingress set to 200 and they seem to work great. I’m working on getting all the NATing out of the network.
I have done some testing on one of our other tower sites and I am able to make the above setup work. SMs connected to the other site are still experiencing the same issue.
One thing I find strange is that the NAT table in the SM contains entries even when the customer seems to experience no connectivity.
I can’t see any significant differences between APs at the different sites other than the fact that Prizm manages the AP at the site where I can make the setup work.
We do the exact same thing on some tower sites. We set the management vlan ID to 2 and leave untagged ingress VID to 1.
We’ve had lots of NAT/DHCP problems no matter if the MVID is 1 or 2.
We typically move customers that are having problems to their own private vlan or to a shared vlan, with NAT/DHCP off in both cases. On all vlans we filter multicast and on shared vlans we filter bootp server and SMB.
It’s interesting that your problems occur only with MVID 2. I bet they are more widespread than that.
The last time I talked to Motorola reps and whined about NAT/DHCP brokenness, their best answer was "don’t use it!!!"
They have fixed a lot of problems with their implementation but they have not fixed all.
I suspect that our scheme of moving all customers to their own private vlans is a decent approach. The Moto rep thought we were setting ourselves up for a management nightmare but so far it has been very smooth. We do NAT/DHCP on the customer’s behalf, using a reliable implementation (OpenBSD if_vlan+pf+dhcpd with nsh as a management interface and flashdist distribution on read-only flash)
I drove up to the site over the weekend, setup an SM in the car. Set the untagged ingress to 1 and the management to 2 everything worked perfect. I tried it on a 2.4 P9 running 7.3.6 and a 900 P10 running 8.2.7 with no problems. I even added a dlink router into the mix with no issues
As soon as I configure a customer’s SM in the same way it does not seem to pass user traffic.
After trying to change another user today running 7.3.6 on a P9 2.4 I noticed that the SM had handed out an IP via DHCP but the lease time seemed to be reseting back to 30 days every couple of minutes. Had the user reboot their router etc… with no luck.
I’m stumped.