The inconvenience has to do with the complexity of the Medellín Metro customer network. Where there are several network segments, isolated by VLANs in different locations. These
VLANs are properly propagated to the access switches, at each location,
to the Vlan 4 "Servers" segment where the VMs of the vSZ-H controller
are housed and a data plane in order to "Tunnel" the traffic Of some WLANs like WLAN METRO 2 (and I will explain the reason for this tunnel). Each VLAN has an associated WLAN as follows:
to. SSID "Wlan Metro 2": Dynamic Vlans, auth. By 802.1x EAP with a Radius on an Active Directory server. It receives the authentication requests from the controller and
dynamically assigns, depending on the credentials, individual parameters
for each client, exactly VLANS access.
B. SSID "Visitors": Vlan 2500, Guest Access Authentication with tokens.
C. SSID "Movil Metro": Vlan 2500, integrated captive gateway authentication of the controller, associated with an LDAP server.
At
the beginning of the implementation of the virtual controller and its
WLANs, the experience of using the wireless networks was at least
unstable. This
means that some user terminals were connected and others were not, at
the beginning of the day they connected and then no, Sundays were
connected without problems, but on weekdays not, as if they affected the
number of customers or the time on day. It should be noted that these WLAN scenarios as described above were
simulated in a controlled environment in the Ticline lab and there were
no problems, ie the WLAN configurations were tested and guaranteed in
their operation.
What
could be detected during these days of diagnostics, is that even though
the WLANs were correctly configured, they did not receive a valid IP
LAN to provide the DHCP (all 3 wlans), or if they were too slow, Forcing them to manually use a read / renew on the PC. According
to what we discovered, the DHCP broadcast requests flooded the VLAN
network segments through the subway access SW and backhaul SW, to the
Router or other equipment that was in charge of doing the routing
between VLANS. The DHCP servers are within the VLAN segments 4 and 2500. The DHCP of the VLAN 2500 is configured in a firewall, as we are told.
The
delay produced by searching the DHCP servers for the broadcast
transmissions of the user terminals produced the unstable network
experience. Therefore, according to the documentation found, a DHCP Relay could solve the problem. What
happens is that to implement this relay in a vSZ-H, it is necessary to
tune the WLANs to a DATAPLANE by means of a Ruckus GRE tunnel, so that
the dataplane is in charge of performing the DHCP relay to the specific
IP addresses of the DHCP servers, which in summary was to convert the DHCP broadcast to
unicast, directing them exactly to the servers as if it were
intermediary of these transmissions.
However,
once the data plane was implemented, for example the WLAN of dynamic
vlans "Wlan Metro 2", it started to offer IPs of VLAN 4 nothing else, as
if it did not take into account the dianamic configuration of vlans,
and it would deliver IPS according To their segments. What
we believe, is that the data plane, is misplaced, since according to we
understand it must be to the extreme of the segments of broadcast, in
this case of VLANs. Currently
it is in the segment of servers Vlan 4 (in its two interfaces,
management and DATA), but we hope this afternoon, to move it to the VLAN
segment 24 or "network equipment management", specifically its DATA
interface, which is The one that exchanges messages with the APs.
We would appreciate some comments about this scenario, which can help
us to rule out possible faults that may be occurring, including if the
measures taken are correct, such as the dataplane and the location of
it.
You
may also see the following forum entry, something similar to what we
are showing:
https://forums.ruckuswireless.com/ruckuswireless/topics/ruckus-dhcp-relay-cisco-hp-dhcp-relay