Configuring and Managing VLANs : Why configure VLAN interfaces on a Silver Peak appliance?

Why configure VLAN interfaces on a Silver Peak appliance?
It may be desirable to deploy a Silver Peak appliance into a network that’s using 802.1q tagging.
An appliance can be inserted in-line between a LAN router/switch and a WAN edge router to bridge an existing VLAN trunk.
In an out-of-path (Router mode) deployment, you can choose to have a trunk between the router and the Silver Peak appliance to preserve traffic segregation (as in an ISP), or to provide a redirect IP address in a VLAN’s domain so as to redirect VLAN tagged traffic.
An appliance deployed with no VLAN configuration can “see” all VLAN tags, and make route-policy decisions accordingly. It can also bridge pass-through traffic, keeping VLAN tags intact. However, without configuration, the appliance has no way of tagging the packets it generates, or tagging decapsulated packets received from the remote-side appliance. Since neighboring routers may drop untagged traffic if a native VLAN is not configured, this creates for both directions of traffic.
The Issues
Outbound LAN-to-WAN Traffic
To optimize traffic, the appliance uses GRE, UDP, or IPSec encapsulation to create a packet that uses IP addresses configured on the appliance. By default, these IP addresses are configured on the bvi0 or wan0 interfaces, and those interfaces reside in the native, or untagged, space. These packets will leave the appliance without an 802.1q tag in the outbound L2W direction.
Inbound WAN-to-LAN Traffic
When inbound tunnel packets are received from the remote appliance in the W2L direction, the inner packet has no VLAN information about the local side. The appliance would normally transmit the packet to the LAN side, untagged. If the inner packet is destined for a subnet residing on a particular VLAN, a method of tagging the packet is required. The appliance determines how to tag the packet based upon routing — using either the subnet IPs of the local VLANs we’ve configured, or ip datapath routes.
The Solutions
To address these issues, you can create Layer 3 VLAN interfaces on the Configuration - Deployment page by specifying IP addresses and VLAN tags, which in turn create underlying logical interfaces (for example, lan0.100, wan0.200) capable of tagging packets.
Tagging Outbound LAN-to-WAN Traffic
Tunnels may built off of any logical interface on the appliance.
A tunnel built off of a VLAN interface transmits its encapsulated tunnel traffic toward the default WAN next-hop IP configured for the VLAN interface. This traffic is sent on the VLAN interface’s logical WAN interface (for example, wan0.100). Consequently, the traffic is tagged with the tag associated with the VLAN interface (for example, 100).
Therefore, to set VLAN tags in tunnel packets outbound for the WAN, create a tunnel using the VLAN IP address as an endpoint.
Tagging Inbound WAN-to-LAN Traffic
Inbound tunnel packets received from the remote appliance are encapsulated with a GRE/UDP or IPSec header, and contain no L2 information. Once decapsulated, the LAN-bound traffic needs to be directed to the proper VLAN. This can only be accomplished on the Silver Peak appliance through the use of L3 routing.
The appliance may deliver the untagged packets on a native VLAN to an L3 router on the LAN-side (or even WAN-side), if that router is then capable of tagging the packet appropriately and routing between the VLANs.
However, you can create a local L3 interface that resides within a VLAN’s subnet. If this local interface is used to route packets, the underlying logical interface on the LAN side (for example, lan0.100) can tag the packet with the proper VLAN tag.
Subnet and default gateway datapath routes pointing at a LAN next-hop residing in an appliance’s local VLAN subnet may also be used to tag traffic.

Please send comments or suggestions regarding user documentation to techpubs@silver-peak.com.