Introduction to EoGRE
Ethernet over GRE (EoGRE) is an aggregation solution for grouping Wi-Fi traffic from hotspots. This solution enables customer premises equipment (CPE) devices to bridge the Ethernet traffic coming from an end-host, and encapsulate the traffic in Ethernet packets over an IP Generic Routing Encapsulation (GRE) tunnel. When the IP GRE tunnels are terminated on a service provider's broadband network gateway, the end-host traffic is forwarded and subscriber sessions are initiated.
Client IPv6
Client IPv6 traffic is supported on IPv4 EoGRE tunnels. A maximum of eight different client IPv6 addresses are supported per client. Wireless controller s send all the client IPv6 addresses that they have learned to the accounting server using the accounting update message. All RADIUS or accounting messages exchanged between controller s and tunnel gateways or RADIUS servers are outside the EoGRE tunnel.
EoGRE for WLAN
To enable EoGRE for a WLAN, the wireless policy profile should be mapped to a tunnel profile, which may contain the following:
-
AAA override: Allows you to bypass rule filtering for a client.
-
Gateway RADIUS proxy: Allows forwarding of AAA requests to tunnel gateways.
-
Tunnel rules: Defines the domain to use for each realm. They also define VLAN tagging for the client traffic towards tunnel gateways.
-
DHCP option 82: Provides a set of predefined fields.
EoGRE Deployment with Multiple Tunnel Gateways
The wireless controller embedded wireless controller sends keepalive pings to the primary and secondary tunnel gateways and keeps track of the missed pings. When a certain threshold level is reached for the missed pings, switchover is performed and the secondary tunnel is marked as active. This switchover deauthenticates all the clients to enable them to rejoin the access points (APs). When the primary tunnel come back online, all the client traffic are reverted to the primary tunnel. However, this behavior depends on the type of redundancy.
Load Balancing in EtherChannels
Load balancing of tunneled traffic over Etherchannels works by hashing the source or destination IP addresses or mac addresses of the tunnel endpoint pair. Because the number of tunnels is very limited when compared to clients (each tunnel carries traffic for many clients), the spreading effect of hashing is highly reduced and optimal utilization of Etherchannel links can be hard to achieve.
Using the EoGRE configuration model, you can use the tunnel source option of each tunnel interface to adjust the load-balancing parameters and spread tunnels across multiple links.
You can use different source interfaces on each tunnel for load balancing based on the source or destination IP address. For that choose the source interface IP address in such a way that traffic flows take different links for each src-dest IP pair. The following is an example with four ports:
Client traffic on Tunnel1 – Src IP: 40.143.0.72 Dest IP: 40.253.0.2
Client traffic on Tunnel2 – Src IP: 40.146.0.94 Dest IP: 40.253.0.6
Client traffic on Tunnel3 – Src IP: 40.147.0.74 Dest IP: 40.253.0.10
Use the show platform software port-channel link-select interface port-channel 4 ipv4 src_ip dest_ip command to determine the link that a particular flow will take.
EoGRE Configuration Overview
The EoGRE solution can be deployed in two different ways:
-
Central-Switching: EoGRE tunnels connect the controller to the tunnel gateways.
-
Flex or Local-Switching: EoGRE tunnels are initiated on the APs and terminated on the tunnel gateways.
To configure EoGRE, perform the following tasks:
-
Create a set of tunnel gateways.
-
Create a set of tunnel domains.
-
Create a tunnel profile with rules that define how to match clients to domains.
-
Create a policy profile and attach the tunnel profile to it.
-
Map the policy profile to WLANs using policy tags.
Note |
The EoGRE tunnel fallback to the secondary tunnel is triggered after the max-skip-count ping fails in the last measurement window. Based on the starting and ending instance of the measurement window, the fall-back may take more time than the duration that is configured. |
Method Name |
First Supported Release |
Mode |
---|---|---|
PSK |
17.2.1 |
Local/Flex (central authentication) |
Open |
16.12.1 |
Local/Flex (central authentication) |
LWA |
16.12.1 |
Local/Flex (central authentication) |
Dot1x |
16.12.1 |
Local/Flex (central authentication) |
CWA |
16.12.1 |
Local/Flex (central authentication) |