Features

When BYOD-redirect is enabled on a VLAN, the BYOD feature intercepts HTTP traffic and blocks all other traffic for which free rules are not enabled. Most BYOD-redirect implementation is platform independent, except installing free rules to mitigate risks.

Communication between clients and the IMC server is tunneled by the edge switch:

  1. A client request is read by the HTTP task.

  2. The HTTP task always redirects, after embedding client IP addresses, a URL trying to access the redirected URL.

  3. The redirect response includes URL parameters: user ip address andurl user is trying to access.

  4. The client receives a redirect response from the switch and makes an HTTP request to redirect the URL.

SNMP Interactions

BYOD updates server details using the BYOD VLAN map and TCAM rules from an SNMP communication, handling dynamic re-configuration events by BYOD task:

  1. To configure a BYOD server:

    Internal data structure is updated, including the server URL, server IP, port and other parameters.

  2. To enable BYOD-redirect on a VLAN:

    The following TCAM rules are installed:

    • Steal and hardware drop for http traffic (80).

    • Drop (IP traffic) all rules to be installed.

    • Install hardware forward rule for http packets to the BYOD server.

    • Allow ARP packets any to any.

  3. Configure free rules to allow traffic to DNS, DHCP and other traffic.

Interoperability with other switch features

The following rules can help avoid conflicts when BYOD-redirect has been deployed on a switch with other features:

  1. MAFR and BYOD-redirect are mutually exclusive – MAFR and BYOD-redirect solve similar problems.

  2. DNS sentinel and BYOD-redirect – When a DNS sentinel is enabled, the switch tunnels packets to the controller. Packets are re-injected to the switch only if the controller classifies DNS packets as permitted. When BYOD-redirect is enabled, the user should configure an ACL rule to pass through DNS packets to the switch. If SDN controller policy classifies a DNS packet originating from a client as drop, then BYOD-redirect does not work.

  3. IP sentinel and BYOD-redirect – When IP sentinel is enabled for the IP flows configured by the SDN controller, the switch tunnels the IP packets to the controller. The IP packets are re-injected to the switch only if the controller classifies the IP traffic as not malicious. If the SDN controller policy classifies the client’s IP traffic as malicious, then BYOD-redirect fails.

  4. OpenFlow and BYOD-redirect – If an OpenFlow instance is enabled on a VLAN, then all traffic is given to the OpenFlow packet processing task. BYOD-redirect requires intercepting IP (HTTP) packets. If BYOD-redirect inter-operates with OpenFlow, traffic should be copied to both Openflow and BYOD-redirect; otherwise, the switch cannot enable BYOD-redirect and OpenFlow on the same VLAN.

  5. Other TCAM rules – If any other user has configured TCAM rules that override TCAM entries installed for BYOD-redirect, BYOD-redirect does not work.

Interoperability with other vendors

Because BYOD policy integrates several logical components including MSM, UAM, and RADIUS, the redirected URL in the BYOD-redirect feature on a switch must include the byod-server-url and user-ip information to work with the IMC server.

BYOD-redirect configuration command syntax for ProVision software matches Comware server command syntax.

Restrictions

BYOD-redirect has the following restrictions:

  1. BYOD-redirect is a per-VLAN configuration; up to three VLANs can be enabled with BYOD-redirect.

  2. BYOD-redirect supports up to three redirection servers configured on a switch. When a redirection server URL is configured, the BYOD module maintains separate data structures to store the re-directed URL on the VLAN where BYOD-redirect is enabled. BYOD-redirect statistics are maintained for each server.