Routing and Wireless Boot Camp Student Guide Version 2.0

Enterasys Educational Services
Routing and Wireless Boot

Camp
Student Guide
Version 2.0
Terms & Condition of Use:
Enterasys Networks, Inc. reserves all rights to its materials and the content of the
materials. No material provided by Enterasys Networks, Inc. to a Partner (or Customer, etc.)
may be reproduced or transmitted in any form or by any means, electronic or mechanical,
including photocopying and recording, or by any information storage or retrieval system, or
incorporated into any other published work, except for internal use by the Partner and except
as may be expressly permitted in writing by Enterasys Networks, Inc.
This document and the information contained herein are intended solely for informational use.
Enterasys Networks. makes no representations or warranties of any kind, whether expressed
or implied, with respect to this information and assumes no responsibility for its accuracy or
completeness. Enterasys Networks, Inc. hereby disclaims all liability and warranty for any
information contained herein and all the material and information herein exists to be used
only on an "as is" basis. More specific information may be available on request. By your
review and/or use of the information contained herein, you expressly release Enterasys from
any and all liability related in any way to this information. A copy of the text of this section is
an uncontrolled copy, and may lack important information or contain factual errors. All
information herein is Copyright Enterasys Networks, . All rights reserved. All information
contain in this document is subject to change without notice.
For additional information refer to:
http://www.enterasys.com/constants/terms-of-use.aspx
2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 2

The acquisition cost of an Enterasys S-Series system is on average 20% less expensive than a
comparable system from Cisco, and the S-Series includes many standard features the competition
will charge an additional premium for:
Every standard S-Series system includes dynamic IPv4 routing and Multicast routing as standard.
Other vendors usually charge an upgrade premium for these features.
All S-Series systems include line rate, unsampled NetFlow monitoring on every port at no extra
charge. Other vendors only provide rudimentary flow monitoring as standard or charge a premium for
additional hardware and software to support flow monitoring. A primary benefit of flow monitoring is
granular visibility into network communications, which eases troubleshooting, capacity planning, and
general network monitoring for application performance.
Integrated server load balancing is a standard included feature of the S-Series. It provides an easy
way to create server pools for applications without the need for external load balancing appliances.
Other vendors will offer costly external stand alone devices or specialized software and I/O modules
to support load balancing.

The show router limits command can be used to determine Layer 3 related system limits for S-
Series routers.

RIP v1/v2- Routing Information Protocol version 1 and 2
OSPF-Open Shortest Path First
BGP- Border Gateway protocol
IS-IS- Intermediate system to Intermediate system
DVMRP- Distance Vector Multicast Routing Protocol
PIM-SM- Protocol Independent Multicasts- Sparse Mode
IPv6- Internet Protocol version 6
IRDP- ICMP Router Discovery Protocol
VRRP- Virtual Router redundancy protocol
LSNAT- Load Sharing Network Address Translation
ACLs- Access Control Lists
PBR- Policy Based Routing
DoS Prevention- Denial of Service Prevention
DHCP Server- Dynamic Host Configuration Protocol server

A default preference for each type of route is listed, and the table notes
preference precedence between protocols. The lower the precedence value, the more preferred the
routes are.
A default precedence/distance for each type of route is listed, and the table notes
preference precedence between protocols. The lower the precedence value, the more preferred the
routes are.
Distance is configurable for each entry in table and for each individual static route.

Note:
For the OSFP route 2.2.2.2/32 [110/10] via 10.1.1.2, VLAN 10, shown above within the brackets, the
110 represents the route precedence, and the 10 is the actual path cost to reach the destination.

Equal cost multi-path implies multiple entries in the routing table with the same destination, mask,
and cost metric but different next hop. The router will attempt to utilize all available paths generated
by the ECMP algorithm.
Round robin will cycle through each available path with the possible loss of sequential packet
delivery.
Hashing will use the same path for all packets between the same source and destination.

In this module, we briefly review the routing features and functions, and discuss implementation and
configuration, if applicable, by product family. We will begin with those features and functions
supported on all the switch routers. As we progress through the module, you will note that the
Platinum DFE is the most feature rich.
While some definitions and explanations of concepts are provided here, it is assumed you are
familiar with basic routing concepts.

Routers perform two basic operations. The 1st is to forward packets towards their correct
destinations. The second is to maintain a routing table which allows the router to determine the
correct path. Lets examine how these processes work.
Forwarding:
Step 1:
A packet is received on router R1 from WS1 destined for WS2. The packets destination network
number is determined by examining the routing table.
Step 2:
Through examination of its routing table, R1 finds the outgoing interface and next-hop address that
the destination network (10.2.1.0) is reachable through. The next-hop address belongs to the next
router that the packet will be forwarded to, (in this case R2). Because the network connection
between the R1 and R2 routers is Gig-Ethernet (GE), R1 may have to ARP for R2s MAC address. If
traffic has previously been passed between R1 and R2, (which would have forced a prior ARP), a
new ARP exchange will not be necessary.
Step 3:
As a result of the sequence described in step 2, the packet initiated by WS1 is now forwarded to
next-hop router R2.

Step 4:
Through examination of its routing table, R2 finds the outgoing interface and next-hop address that
the destination network (10.2.1.0) is reachable through. The next-hop address belongs to the next
router that the packet will be forwarded to, (in this case R3). Because the network connection
between the R2 and R3 routers is Gig-Ethernet (GE), R2 may have to ARP for R3s MAC address. If
traffic has previously been passed between R2 and R3, (which would have forced a prior ARP), a
new ARP exchange will not be necessary.
Step 5:
As a result of the sequence described in step 3, the packet initiated by WS1 is now forwarded to
next-hop router R3.
Step 6:
Once WS1s packet reaches R3, a local delivery process is used. Through examination of its routing
table, R3 determines that the destination network number is associated with a directly connected
interface, (i.e., 10.2.1.0/24 is a directly connected route).
Step 7:
Since the connection between R3 and WS2 is Fast-Ethernet (FE), R3 may have to ARP for W2s
MAC address prior to delivering packet. If traffic has previously been passed between R3 and WS2
forcing a prior ARP exchange, a new ARP exchange will not be necessary and the packet can be
sent directly to WS2.

Prior to provisioning an Enterasys Switch for Layer 3 operation, several pre-routing considerations
must be taken into account.
Enterasys switches operate predominately as Layer 2 devices and are provisioned for Layer 3
services when needed. As a result, there are certain Layer 2 features that can adversely affect
routing behavior. Prior to configuring VLAN interfaces for routing, it may be necessary to turn off
specific switching features such as, Spanning Tree Protocol and dynamic VLAN capabilities (GVRP)
on the appropriate ports
As shown by the slide, disabling Spanning Tree can be accomplished by using the
set spantree disable
command to disable the Spanning Tree Protocol at a global level, or the
spantree portadmin [port string] disable
command, to disable the Spanning Tree Protocol on a port by port basis.

GVRP is used to dynamically create VLANs across a switched network. If GVRP is not currently in
use as part of your Layer 3 network design, it is recommended that the protocol be disabled. This
can be done by issuing the
set gvrp disable
command to disable dynamic VLAN capabilities (GVRP) at a global level, or the
set gvrp disable [port string] disable
command to disable the GVRP protocol at the port level.

The requirement to disable Spanning Tree Protocol in a routed environment results from the fact that,
during normal Spanning Tree operation, the protocol can negatively affect multi-path routing
functionality by blocking multiple physical paths in a network that would typically be available for
Layer 3 forwarding. As shown by the slide, if Spanning Tree was left in a functioning state, at least
one path in the routed core environment will block, eliminating ECMP routing capabilities within the
above network.

Before you configure layer 3 services in router configuration mode, you must first create VLANs in
switch configuration mode. The following steps are required:
Use the set vlan create <VLAN id> command to create the required VLANs. Once VLANs are
created in switch configuration mode, they will be available for layer 3 provisioning as IP, VLAN
interfaces in router mode.
Next, assign switch ports to your VLANs to provide physical connectivity for the layer 3 VLAN
interfaces. As shown by the slide, two methods for assigning ports to a VLAN can be used.
Enter the set port vlan [port string] [vlan id] command, and enter Y at the prompt to add the port to
a VLANs egress list as untagged and clear the existing PVID.
Append the modify-egress option onto the (set port vlan [port string] [vlan id]), command. Setting
modify-egress is equivalent of entering Y.
If you choose N when entering the set port vlan [port string] vlan id] command in step 3, you can set
the port to a VLANs egress list as untagged by using the command displayed in step 4.
Issuing the set vlan egress vlan id port string untagged command represents the equivalent of
setting modify-egress or entering Y.
Note: Adding a port to a VLANs egress list sets the port as eligible to transmit frames for a given
VLAN. The setting is required! If not set, the layer 3 VLAN interface will be unable to process traffic in
a bidirectional way.

Once the required VLANs have been added in switch configuration mode, it will be necessary to
separately configured them for IP routing operation. In order to do this, the Layer 3 VLAN interface
will need to created, assigned an IP address/subnet mask, and then enabled. Upon completion of
these steps, IP routing between VLANs can be implemented and the VLAN can be regarded as a
Layer 3 network link.
The commands needed to configure an Enterasys Switch for Layer 3 service are as follows:
From switch configuration mode, enter router mode by issuing the router command.
From router mode, enter Router privileged mode by entering the enable command.
From router privileged mode, access router configuration mode by entering the configure command,
(commands required for provisioning Layer 3 operation of the switch are accessible from this mode).
From router configuration mode enter interface configuration mode by issuing interface vlan [vlan id]
command. The interface vlan commands will enable VLANs 5 and 10 as a routed interfaces on the
switch, once you enter and IP address/subnet mask and enable the interfaces via the no shutdown
command.
Note that if you create a VLAN in switch configuration mode and do not define an IP interface for it in
router configuration mode, it will ONLY be capable of performing only Layer 2 forwarding.

With 7.11+ firmware, upon initial logon, you can access the Layer 3 configuration parameter set by
simply entering the configure command as shown on the slide above.
A device with a VLAN that does not have a corresponding IP interface defined for it will function as a
Layer 2 device only, regardless of the operation mode.
You must configure each VLAN separately for IP routing. Assign a layer 3 VLAN an IP interface
address and subnet mask to enable IP routing between VLANs. The Layer 3 VLANs can be thought
of as network links, rather than as a collection of associated end users.
Implement IP routing by creating IP interfaces on a configured VLAN. Use the set ip address
command to assign an interface IP and use the ip forwarding command to turn on IP routing for the
vlan interface.
Other than VLAN 1, VLANs must first be created.

You can use IP interfaces created on the router for in-band management. The loopback address is
meant strictly for in-band management use without the risk of reach-ability problems due to
disconnected ports.

Routing tables can be maintained either statically or dynamically. All the Enterasys switch routers
support static routes and at least one form of dynamic routing. Dynamic routing uses routing
protocols to maintain the routing table.
Static Routes
Static routes are manually configured by a network administrator for entry into a switchs routing
table, they are flagged as S which indicates static . Static routes point to remote network
destinations, and will take precedence over routes chosen by dynamic routing protocols pointing to
the same destination. Although easy to configure and use, a major drawback of static route
implementation on a large scale is that every time the network topology changes, the routing
information will need to be manually reentered into the route table. Therefore, static routing is not
suited to large, dynamic networks.
Dynamic Routes
Dynamic Routes are created using protocols (like RIP) to determine the best path between routers.
When network topologies change, Dynamic Routes will automatically recalculate the best possible
route. The methods for route recalculation vary between the protocols. Link State protocols (like
OSPF) typically detect and resolve topology changes faster than Distance Vector protocols, making
them much more suitable for deployment in large networks.

Routers use routing protocols to build and maintain their routing tables. Routing tables can be
comprised of directly connected, manually configured (static), and dynamically learned routes. All the
Enterasys Switch Routers support static routes as well as dynamic routing. Whereas dynamic
routing uses protocols such as RIP and OSPF to construct a routing table, static routes are manually
configured, and entered into a switchs routing table by a network administrator.
When configured, static routes take precedence over routes learned by dynamic routing protocols.
For example, if two paths exist to a remote Layer 3 (IP) destination, and one path was learned
dynamically (in this case via RIP), and the other path was statically configured, the statically
configured path would be chosen as the more preferred route to the destination.

To configure a static route use the ip route command from router configuration mode, where the:
Destination Prefix : specifies an IPv4 address as a single destination for which a static route is being
defined.
Mask: specifies the prefix mask for the destination network.
Next-Hop Address: specifies the next-hop router address for the static route.
Optionally, you can set the:
Distance: which specifies an administrative distance, (i.e. precedence) for this route. This value can
be in the range of 1 to 255, and it defaults to 1 if not specified.
For the network diagram displayed, setting ip route 10.10.1.0 255.255.255.0 192.168.5.2 inserts a
manually configured (static) route into R1s route table, and instructs router R1 to send IP traffic
destined to the 10.10.1.0 subnet to next-hop router R2s 192.168.5.2 interface for delivery.

Routers participating in RIP perform 2 tasks:
Route propagation: Inform neighboring routers of routes.
Route learning: Use information provided from neighboring routers to learn routes.
Route Propagation: How routers inform other routers of routes
Routers format RIP update messages (called RIP response messages but sometimes referred to as
update messages) to inform other routers of the contents of their own route table. Within the RIP
update message, the sending router formats route updates based on the content on the routers
local route table. Each route update contains a destination network and its associated metric (the
number of hops to that network from the sending router).
Route Learning:
Receiving routers use these updates to populate their local route table with the advertised routes.
This is called route learning. The router receiving the route update assumes the router generating the
message is the next-hop router (gateway is set), and sets the interface field for that rout to the
interface upon which the router received the update.
When a router receives a RIP update it changes (populates/removes routes from) its local route table
if it:
Receives a route to a destination the router does not know about
Receives a better route to a destination the router knows about
Receives information that a destination is no longer reachable
RIP uses timers to dictate how long a learned route is valid and how often routes need to be updated
through the domain.

Dynamic routes are created using protocols such as RIP, OSPF, and BGP to determine the best path
between routers. When network topologies change in a dynamically routed environment, (for
example, a link failure occurs), dynamic routing protocols, automatically and rapidly recalculate a
new best path to a destination.
The three forms of dynamic routing protocols that are most commonly used are Distance Vector,
(RIPv1 and RIPv2 fall into this category), Link State, (OSPF is defined as a Link State Protocol), and
Path Vector (BGP4 falls into this group). In this section of the routing configuration overview, we will
look at RIPv1 & RIPv2 operation and provisioning.
RIP is a standards based distance-vector routing protocol. Two versions of RIP are available. RIPv1,
as defined by RFC 1058, and RIPv2, as defined by RFC 2453. Routing decisions in RIP are based
on hop count. Within a routed RIP environment, each router represents a single hop. The best
route to a destination is determined to be the path with the least amount of hops Therefore the best
route to a destination would be the one that crosses the fewest number of routers.
RIP imposes a 15 hop-count limitation on traffic. That is, traffic forwarded to a remote network
destination cannot traverse more than 15 hops/routers. A destination greater than 15 hops is
considered unreachable, and the RIP router will fail to send data packets to the destination address.
This 15 hop-count limit imposes severe restrictions on how large a network can be, and is one of the
major reasons RIP not often used in larger network.

RIP is fairly easy protocol to configure making it ideal for use in small, less complex networks. To
enable the RIP routing process globally on an Enterasys Switch Router, access router config mode
and enter the router rip command.
For C Series Switch Routers enable rip on each vlan interface by accessing interface configuration
mode and issuing the ip rip enable command. The ip rip enable command sets the interface as
eligible for advertisement by the RIP routing process.
Optionally you can set RIPv2 operation for the interface by entering the ip rip receive version 2 and ip
rip send version 2 commands. Setting RIPv2 operation for an interface insures routing updates are
sent in multicast form, the updates are capable of carrying variable length subnet mask (VLSM)
information, and the interface can be setup for RIP neighbor authentication.
For all S/K Series Switch Routers to enable RIP advertisements on a per interface basis, use the
network command from router config mode. When you issue the network command from router
configuration mode you set the specified interface as eligible for advertisement by the RIP routing
process.

Based on the previous configuration, routers R1 and R2 have now been provisioned to pass RIP
routing updates. Entering the show ip route command on either device reveals they are now
exchanging RIP updates across the 192.168.5.0 network link. As can be seen from the route table
outputs, R1 and R2 have knowledge of remote networks 192.168.4.0 & 192.168.10.0 respectively.
Note that the routes are displayed with an R in each route table, indicating they have been learned
via RIP.

As part of this module we have examined and configured three types of routes: directly connected,
statically configured, and dynamically learned.
Connected routes are simply the networks associated with IP interfaces configured on a router. For
example, if you look at the route table being currently displayed, you will see routing entries for the
192.168.5.0 and 192.168.10.0 networks. These networks represent IP interfaces that have been
previously provisioned on the R1 router. Note that each route is flagged as C, which signifies that
the networks are directly connected to R1.
Static routes are manually configured by a network administrator for entry into a switchs routing
table; they are flagged as S which indicates static, . Static routes point to remote network
destinations, and will take precedence over routes chosen by dynamic routing protocols pointing to
the same destination. Although easy to configure and use, a major drawback of static route
implementation on a large scale is, that every time the network topology changes, the routing
information will need to be manually reentered into the route table. Therefore, static routing is not
suited to large, dynamic networks.
Dynamic Routes are created using protocols (like RIP) to determine the best path between routers.
When network topologies change, Dynamic Routes will automatically recalculate the best possible
route. The methods for route recalculation vary between the protocols. Link State protocols (like
OSPF) typically detect and resolve topology changes faster than Distance Vector protocols, making
them much more suitable for deployment in large networks.

The no form of this command removes a UDP port or protocol, disabling forwarding . UDP
Specifies UDP as the IP forwarding protocol.
Defaults
If port is not specified, default forwarding services will be performed as listed below:
Trivial File Transfer Protocol (TFTP) (port 69)
Bootstrap Protocol server (BootP) (port 67)
Domain Naming System (port 53)
Time service (port 37)
NetBIOS Name Server (port 137)
NetBIOS Datagram Server (port 138)
TACACS service (port 49)
EN116 Name Service (port 42)

53
2013 Enterasys Networks, Inc. All rights reserved. 54
55
ARP is a protocol used to map an IP address to a physical (MAC) address. Each IP device on a
network (end stations, routers, etc...) maintain address resolution (ARP), tables. IP devices use their
ARP tables to associate MAC addresses to IP addresses. When an IP host needs to communicate
with another IP device on a common LAN segment, and an IP address to MAC address mapping
does not exist in its ARP table, the device will issue an ARP request. If the destination device is on
line, it will hear the ARP broadcast request, recognize its IP address, and respond back to the
requesting host with its MAC address. Thereby, providing the requesting device the IP address to
MAC address mapping it requires to deliver data across the layer 2 LAN segment. This IP address to
MAC address mapping will then be maintained in the devices ARP table/cache for some
predefined/configurable period of time.
Note: The ARP function is critical in IP networks. If a network device can not obtain an IP-to-MAC
mapping of the device it is attempting to communicate with, they will be unable to exchange data
across the LAN. Insure proper ARP table entries are present via the show ip arp [ip-address]
command if a connectivity problem has been encountered.
On Enterasys routers, the ARP cache timeout is a global timer and is configurable for VLAN IP
interfaces. It is not for the host ARP cache.

For in-band management, IP interfaces created on the router can be used. The host port is meant
for out-of-band management use.
Any routed IP interface can be used to access the router/switch for management such as telnet, tftp,
snmp, etc.

Primary use of VLAN and port interfaces is to act as next-hop for neighboring routers and end station
in delivering data-grams.

Router functionality may be turned off through the CLI in router mode or through the MIB via IP
forwarding set to 0.
As a router, if an IP datagram is received and not addressed to any interface on system, it must be
forwarded to its destination through a single port as per instructions of the routing table. Inability to
forward requires the packet be dropped and transmission of an ICMP error message back to the
source with the reason why.
.

When off, the device is referred to as a multi-homed host. If a IP datagram is received that is not
addressed to this system, it will be silently dropped. No ICMP message will be sent.
Routers never flood datagrams!
Secondary IP addresses allow subnet to be co-resident on a common VLAN when adequate network
equipment is in short supply or physical topology constrains extending existing address space.

The switch address is set from the switching layer as interface host.0.1 and maintains its own routing
table and ARP cache. Behavior is analogous the VLAN IP interface that the host would be in except;
Primary and secondary address assigned to the VLAN interface must all be in different networks
from the host and each other.
Routing protocols run on that interface will not effect the host.0.1 routing table.
ARP will separate responses into two tables based on the interface making the request.
The default route in this table will only be used with the hosts source address

OSPF is classified as an Internal Gateway Protocol (IGP). This means that it distributes routing
information between routers belonging to a single Autonomous System. The OSPF protocol is based
on SPF or link-state technology. This is a departure from the Bellman-Ford base used by traditional
distance vector internet routing protocols.
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task
Force. It has been designed expressly for the internet environment, including explicit support for IP
subnetting, TOS-based routing and the tagging of externally-derived routing information. OSPF also
provides for the authentication of routing updates, and utilizes IP multicast when sending/receiving
the updates. In addition, much work has been done to produce a protocol that responds quickly to
topology changes, yet involves small amounts of routing protocol traffic.

OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group,
together with the routers that have interfaces to any one of the included networks, is called an area.
Each area runs a separate copy of the basic shortest-path-first routing algorithm. This means that
each area has its own topological database.
The topology of an area is invisible from the outside of the area. Conversely, routers internal to a
given area know nothing of the detailed topology external to the area. This isolation of knowledge
enables the protocol to effect a marked reduction in routing traffic as compared to treating the entire
autonomous system as a single SPF domain.
With the introduction of areas, it is no longer true that all routers in the AS have an identical
topological database. A router actually has a separate topological database for each area to which it
is connected. Routers connected to multiple areas are called area border routers. Two routers
belonging to the same area have, for that area, identical area topological databases.
Routing in the autonomous system takes place on two levels, depending on whether the source and
destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-
area routing is used). In intra-area routing, the packet is routed solely on information obtained within
the area; no routing information obtained from outside the area can be used. This protects intra-area
routing from the injection of bad routing information.

Every OSPF routing domain AS must have a backbone. The backbone is a special OSPF area that
must have an area ID of 0.0.0.0 (or simply 0). It consists of those networks not contained in any
specific area, their attached routers, and those routers that belong to multiple areas. The backbone
must be contiguous. Each router's interface that is configured in Area 0 must be reachable via other
routers where each interface in the path is configured as being in Area 0.
However, it is possible to define areas in such a way that the backbone is no longer contiguous--
where the continuity between routers is broken. In this case, you must establish backbone continuity
by configuring virtual links. Virtual links are useful when the backbone area is either purposefully
partitioned or when restoring inadvertent breaks in backbone continuity.

Router-LSAs (type 1) -- Router Link Advertisements are generated by each router for each area it
belongs to. They describe the states of the routers links and are only flooded within a particular area.
The Link State ID is the originating routers ID.
Network-LSAs (type 2) -- Network Link Advertisements are generated by DRs. They describe the set
of routers attached to a particular network. They are flooded in the area which contains the network.
The Link State ID is the ID of the DR.
Network-Summary LSAs & ASBR-Summary-LSAs (type 3 & 4) -- Summary Link Advertisements are
generated by Area Border Routers (ABRs). They describe inter-area routes. Type 3 describes routes
to networks; also used for aggregating routes. Type 4 describes routes to Autonomous System
Border Routers (ASBRs) and ABRs. The Link State ID is the destination network number for Type 3,
and the Router ID of the described ASBR for Type 4.
AS-External-LSAs (type 5) -- AS External Link Advertisements are generated by the ASBR. They
describe routes to destinations external to the AS. They are flooded everywhere, with the exception
of stub areas. The Link State ID is the external network number
Group-Membership-LSAs (type 6)-- Group Membership Link Advertisement are used to indicate the
location for multicast group members in MOSPF.
Type-7-LSAs -- NSSA Link Advertisement are used in NSSA areas to import a select limited set of
external information.
External-Attributes-LSAs (type 8) -- External Attributes Link Advertisement has been proposed to be
in use to carry BGP path information across an OSPF domain in lieu of Internal BGP.

Using the loopback interface as the router ID is the preferred method. Its major advantage is as
follows: If a real interface is used, any time that interface goes down the router must find another
Router ID. This causes all the other routers to learn the routers new ID number, and update their
databases. This would result in the router not processing OSPF packets during this time frame. As
long as the router is turned on and running, the loopback will never go away, so when a router
interface goes down it wont affect the other routers in the network.
OSPF packet type 1, these packet types are sent out of all interfaces, transmitted via multicast to
AllSPFRouters (224.0.0.5), a Form of keep alive, and used for Designated Router / Backup
Designated Router election.
OSPF packet type 2, exchanged when an adjacency being initiated, describes topology database,
and multiple packets may be used to describe a database.
OSPF packet type 3, requests pieces of the topological database from neighbor routers. These
messages are exchanged after a router discovers (by examining database-description packets) that
parts of its topological database are out of date.
OSPF packet type 4, implement the flooding of LSAs, several LSA may be included within a single
packet, response to Link State request packets, performs the database update, and acknowledged
by Link State Acknowledgement packets.
OSPF packet type 5, performs flooding acknowledgement for LSAs, sent either multicast to
AllSPFRouters, AllDRouters or unicast, packet format is similar to Data Description packets, and
packet body consists of a list of LSA headers.

OSPF creates adjacencies between neighboring routers to control the distribution of routing protocol
packets.
An adjacency is a relationship formed between selected neighboring routers for the purpose of
exchanging routing information. Topological databases are synchronized between pairs of adjacent
routers.
Not every pair of neighboring routers becomes adjacent. Instead, adjacencies are established with
some subset of the router's neighbors. Routers connected by point-to-point networks and virtual links
always become adjacent. On multi-access networks, all routers become adjacent to both the
designated router and the backup designated router.
Routing protocol packets are sent and received only on adjacencies. In particular, distribution of
topological database updates proceeds along adjacencies.

On multi-access networks such as Ethernet, attempting to synchronize OSPF databases between
every router on a LAN segment can result in excessive numbers of Link State Updates and
Acknowledgements being transmitted over the subnet, resulting in a inefficient use of the LANs
bandwidth. OSPF resolves this issue by electing a Designated Router for the LAN segment (i.e.,
subnet). All other routers keep there databases synchronized to the DR.
Using a Designated Router as the central mechanism for database synchronization on a broadcast
subnet significantly reduces OSPF database traffic, but introduces a single point of failure in the
database synchronization process. To overcome this limitation, OSPF uses a Backup Designated
Router to eliminate the single point of failure. The BDR is used to insure database synchronization
runs smoothly in the result of a DR failure.
For the current slide, R1 and R2 has been elected Designated Router (DR) and Backup Designated
Router based on priority (Priority 100 and Priority 75). A set of adjacencies for over the Gig-Ethernet
LAN segment as indicated on the slide. To demonstrate over a broadcast LAN how database
updates occur using a DR and BDR, router R5 receives a new LSA, it installs the LSA in its
database, and then floods the LSA, (LS Update) to the DR (R1) and BDR (R2) using 224.0.0.6
(AllDRouters) so only these routers receive the update.
The Designated Router (R1) then sends the LS Update back on to the Gig-Ethernet LAN segment
using address 224.0.0.5 (AllSFPRouters) updating routers R3 and R4. The BDR does not flood in
this case, and re-floods the LS Update ONLY IF, the Designated Router (DR) has failed to send the
update within the LSA transmission interval (usually 5 seconds).

OSPF supports a two level routing design through the use of Areas. OSPF areas are identified by an
area ID. The area consists of the network segments and routers that reside in the area. Each area
has its own link state database (LSDB) which is separate from LSDBs in other OSPF areas. The
LSDB consists of router-LSAs and network-LSAs which describes how the areas routers and
network segments are connected. Detailed information regarding the areas topology is hidden from
all other areas, (router-LSAs and network-LSAs are not flooded to routers outside the area and are
used for Intra-Area routing).
As a result of OSPF using area based routing, the positioning of routers with respect to these areas
represents a critical element in an OSPF routing environment. Within OSPF routers take on special
responsibilities depending on their topological orientation. All routers running OSPF on at least one
of its interfaces can be categorized into one of the following categories: ABRs, ASBRs, or internal
routers. Depending on what type of router is it, the router has different responsibilities in restricting
or allowing the propagation of certain types of LSAs.

Routers attached to two or more areas are called Area Border Routers (ABRs). ABRs flood IP
address information from one area to another using summary-LSAs. The passing of summary-LSAs
from one area to another allows routers in different areas to dynamically learn about network
destinations so that Inter-Area routing can occur.
OSPF uses Autonomous System Border Router (ASBRs), to import routing information from other
routing protocols (BGP, IS-IS, RIP, etc). Information learned from these protocols is considered
external to the OSPF routing domain and is imported into the OSPF routing domain in the form of
ASexternal-LSAs by the ASBR. LSAs are only generated on interfaces running OSPF and,
therefore ASBRs never propagate LSAs outside the AS.
Internal router: All interfaces reside in same area and router would maintain link state database
(LSDB) representative of the area.

Intra-Area routing is based on the fact that routers within a given area know exactly which network
segments are contained within the area through the use of router-LSAs and network-LSAs contained
within their link state database.
Inter-Area routing is achieved through the use of summary-LSAs that are passed from area to area
(via ABRs). summary-LSAs allow routers in the interior of an area to dynamically learn about
destinations in other areas, so they can to select the best path when forwarding packets to these
destinations.

Stub areas are typically implemented when routers with limited resources (small amounts of memory
or limited CPU processing capacity) must be deployed in an OSPF routing domain. To conserve
router resources, the link state database (LSDB) within a stub area is kept as small as possible. AS-
external-LSAs are not passed into the area. Routing to external destinations from a stub area is
accomplished by using a default routes originated by the areas ABR.
There are several requirements to take into consideration when configuring a stub area. All routers
participating the stub area must be configured to function as stub area routers. The area must use
default routes to reach external destinations even it the default route does not provide the optimum
forwarding path to the destination. The area can not have any virtual links configured across it, and it
must not be a source of external LSAs flooded by an Autonomous System Border Router (ASBR).

A Totally Stubby Area (TSA) is a variation of a stub area. For very large OSPF networks it is
sometimes necessary to limit the amount of routing information flooded into an area to an even
greater degree. In addition filtering AS-external-LSAs, a Totally Stubby Area filters Network-
Summary-LSAs as well, further reducing the volume of OSPF routing information present in the area.
A Not-So-Stubby Areas (NSSA) is a second variation of a stub area in which external routing
information (in the form of AS-external-LSAs) can be imported into the stub area via an Autonomous
System Border Router (ASBR) that resides in the NSSA. AS-external-LSAs from outside the area
(e.g., AS-external-LSAs from Area 0, are still not allowed access to the NSSA).

OSPF supports Equal-Cost Multi-Path (ECMP) routing. ECMP is a mechanism for routing packets
over multiple paths of equal cost in order to achieve almost equally distributed link load sharing.

Equal Cost Multi-Path (ECMP) routing scenario.

The network command is used to enable OSPF for interfaces on Enterasys S & K Series Routers.
The network statement uses a reverse mask to identify specific router interfaces that will participate
in the OSPF routing process. It also assigns the area that the interface will reside in.

Examples of these show commands will follow on the next few pages.

You must be in router mode to receive this display.

OSPF Router priority is an interface level command and is used to influence the election process for
the Designated Router (DR) and Backup Designated Router (BDR) in a broadcast LAN environment.
The routers with the highest priority interfaces will win the election process for DR and BDR on a
broadcast network segment. If two routers have the same priority, the router with the highest router
ID will be elected as the DR. Setting the interface to a priority of 0 precludes that router from
becoming a DR for the LAN segment.

Area 0 can be defined as 0 or 0.0.0.0
Area 2 can be defined as 2 or 0.0.0.2

The S & K-series routers require the additional setup under the OSPF instance configuration. Note
that simple authentication must be configured for the area prior to it being provisioned at the interface
level.

The S & K-series routers require the additional setup under the OSPF instance configuration. Note
that authentication must be configured for the area prior to it being provisioned at the interface level.

The minimum steps to enable OSPF on a router would consist of the following:
Create IP Interfaces
Add IP Address to IP interfaces
Create OSPF Instance
Add IP OSPF Networks and Areas

2012 Enterasys Networks, Inc. All rights reserved 99
2012 Enterasys Networks, Inc. All rights reserved 100
Network Address Translation (NAT) allows a router to modify the IP address information in the Layer
3 header of a packet as it crosses the router. It is most commonly used to allow multiple hosts in a
private IP address space to access the Internet using a single publicly valid IP address.
101
Every TCP/IP packet contains a source IP address, destination IP address, source TCP port, and
target or destination TCP port. NAT, of whatever type, works by mapping these four values in the
internal machine to their four corresponding values in the external machine.
103
Consider this example network. The client at 172.16.11.12 wishes to access the Google server at
74.125.224.72, and formulates an HTTP Get request directed to that IP address. The client includes
its current available TCP port number, 56123, in the source port field of the TCP header, and
includes port 80, the well-known HTTP port number, in the destination port field of the TCP header.
When the NAT router receives the Get request from the internal client, performs the Network
Address Translation, replacing the Source IP address of the client with its publicly valid IP address,
63.27.141.3. It then creates an entry in the NAT table that says, in essence, I need to remember
that any reply coming from 74.125.224.72 with a destination port of 56123 is really going to my
internal client at 172.16.111.12. When I get that reply, its going to be coming to my IP address of
63.27.141.3. Im going to have to replace that publicly valid IP address in the Destination IP address
field with the IP address of my internal client, 172.16.111.12, and send the packet along.
104
Enterasys Routers support three types of CONE NAT:
Full Cone NAT
Restricted Cone NAT
Port Restricted Cone NAT
105
106
Filter action of ACL rules is to drop or forward routed packets on ingress only. They do not apply to
switched traffic where policy profiles will apply.
Standard ACLs filter traffic based on source IP address only.
Extended ACLs filter traffic based on source or destination IP address, Authentication Header,
Encapsulated Security Protocol header, or Generic Routing Encapsulation header plus either :
IP protocol
ICMP type
TCP/UDP source port
Equal to
Not equal to
Greater than
Less than
Range
DSCP code point
IP precedence
ToS value
Numbered ACL Configuration:
For standard ACLs:
number- Specify the id for this access list. The value can be an integer between 1 and 99 for
standard ACLs.
ipv4-addr wildcard - Specify the IPv4 source address to be permitted or denied, with a wildcard that
specifies the bits to ignore in the source address. Note: The wildcard bits act in the inverse of an IP
network mask.
any - Specify that any IPv4 source address should be permitted or denied.
host ip4_addr - Specify a host IPv4 source address to be permitted or denied. Same as using a
wildcard of 0.0.0.0
For extended ACLs:
number- The value can be an integer between 100 and 199 for extended ACLs.
IP Protocol Number
The value of the Protocol field in the IP header not yet implemented.
UDP or TCP
The exact value of the layer 4 source port.
ICMP
The type and code of ICMP message not yet implemented.
Source & destination IP addresses
specified same as standard ACLs. If destination IP address is omitted, it is the same as
using any.
Rule hit counters or notifications are unavailable.
S/K-Series
The S/K-Series system allows a total of 5,000 access rules to be applied to Access Control Lists
(ACLs). Further, individual ACLs will support up to 999 access rules.
To define a standard IP access list, use the command ip access-group. By default, the valid access
list numbers for standard ACLs are 1 to 99. For extended ACLs, valid values are 100 to 199. To
configure extended ACLs, the advanced routing license is required.
The creation of a configuration file includes the configurations of all routers in a system. An individual
routers configuration cannot be created separately. Use any text editor to edit the configuration file if
you wish to create separate router configuration files.
ACL Manager in NetSight allows you to discover what ACLs are applied to what interfaces, and to
configure ACLs and push them to your routers.
Maximum 10 rules per ACL.
Rules are automatically numbered in sequence from 1 to 10 and renumbered when order is changed
or new rules inserted into a list.
How ACL Names are Determined on a Device
It is important to understand how ACL Manager allocates a new name for an ACL on a device. If you
create a new ACL named "new_acl" and assign it to an interface on a device, when you enforce, ACL
Manager determines that ACL "new_acl" needs to be copied to the device. If the device only
supports numbered ACLs, then "new_acl" would be an invalid name and ACL Manager must assign
a new name for the ACL on that device.
If the ACL is an extended ACL, then only ACL 100199 can be used. So, ACL Manager considers
using 100. If 100 is already in use, ACL Manager will consider 101. If 101 is excluded (via the
Exclude ACL Range option) then ACL Manager will consider 102, 103, 104 and so on, until it finds a
number that is not used and not excluded.
Create an ACL:
RouterA>(config)# access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.4.0 0.0.0.255
Create a route-map entry:
RouterA>(config)# Route-map 110
Check for an acl match:
RouterA>(config-route-map-pbr)# match ip address 101
Set the route for the match:
RouterA>(config-route-map-pbr)# Set next-hop 10.1.2.2
Go to the VLAN interface:
RouterA>(config)# interface vlan 10
Assign the route-map to that VLAN:
RouterA>(config(Vlan 10))# ip policy route-map 110
Receivers will send a IGMP host membership report for each group they belong to. The Host
Membership Report packets are recorded by each router and forwarded to the rendezvous point.
Then, PIM-SM routers can forward multicast traffic out all interfaces that lead back to the receivers
from the source and rendezvous point.
The unicast and broadcast transmissions techniques inefficiently utilize network resources because
of extra bandwidth required to transmit to the one to many, many to many, and many to one
scenarios. There are multiple multicast groups and end systems may be members of any number of
them. Routers must keep track of where members are located for all groups and forward packets
accordingly.
PIM dynamically builds a distribution tree for forwarding multicast data on a network. It is designed
for use where there may be many devices communicating at the same time, and any one of the
devices could be the sender at any particular time. PIM relies on IGMP technology to determine
group memberships and uses existing unicast routes to perform reverse path forwarding (RPF)
checks. RFP is, essentially a method that uses the unicast routing table created by IP protocols such
as OSPF, to determine the source address of a packet. PIM uses RPF to set up distribution trees for
multicast traffic.
The Internet Group Management Protocol (IGMP) is used between IP hosts and their local network
to support the creation of transient multicast membership groups, the addition and deletion of
members of a group, and the periodic confirmation of group membership.
A Server has no direct IGMP involvement, as it does not receive a multicast stream and only sends a
multicast stream.
A Querier periodically sends out queries in search of multicast Hosts on a directly connected
network. If multiple Queriers are present, the Querier with the lowest IP Address assumes the role.
An IGMP Querier need not be on every router, however there must be at least one Querier on each
locally attached network.
A Host communicates to a Querier by sending reports in order to receive the Servers multicast data
stream it is transmitting.
An IGMP Join (Report) message can be either solicited (requested by an igmp querier sent in
response to the receipt of an IGMP Query message) or unsolicited (when a host sends a join
immediately when it would like to join a IGMP group).
Configurable values defined:

IGMP enable used to enable IGMP on an interface and/or globally on a device.
Query-enable/disable used to enable or disable querying on an interface
IGMP version used to select the IGMP version to use choices are V1, V2 and V3
Max response time The maximum amount of time the device will wait to hear an IGMP Join from a
host
Query interval The amount of time to wait before sending an IGMP Query.
Robustness variable - Allows tuning for the expected packet loss on a subnet.
Last membership interval- The amount of time that must pass before a multicast router decides there
are no more members of group on a network.
IGMPv1 does not support unsolicited Joins or Leaves.

Group membership of hosts in driven by IGMP Queriers in IGMPv1, where host group membership is
started only after receiving and responding to an IGMP Query messages. Furthermore, a host
leaves a group by not responding to a generated IGMP Query message.
NOTE: In order for multicast routing to function properly, IGMP needs to be enabled on all Switches
and routers.
In this example, a single IP Multicast server is sending in a multicast stream into the network with no
directly attached receivers.
NOTE: The IGMP joins/leave timing can occur at any point.
The switch floods the multicast stream to all ports (because IGMP snooping is disabled, more on this
later).
Both routers received the multicast stream.
When the multicast stream reaches the router, the router will perform the same IGMP forwarding
check as well as check its individual multicast forwarding table to see if there are any hosts that want
to join the multicast group on its locally attached network. The router drops the multicast packets
until a host requests to join the group with an IGMP Join (Report) message.
To receive multicast traffic, the hosts must ask the router to receive a multicast stream by sending
either a solicited join (a host sends an IGMP Join in response to an IGMP Query produced by the
routers interface) or an unsolicited join (a host sends an IGMP Join without seeing an IGMP Query
first).
The terminology IGMP Join and IGMP report are synonymous
Once the router receives an IGMP Report packet for the multicast group, the router will forward the
multicast stream out the indicated interface.
If a host no longer wants to receive the multicast stream, the host can either send a IGMP group-
specific Leave or time out the IGMP entry by not responding to an IGMP Query.
The flooding of multicast data traffic out all ports of a layer 2 switch is not an ideal implementation of
multicast on layer 2. Therefore, it is possible to use the properties of IGMP to prevent this flooding
and selectively forward IGMP and multicast data traffic without flooding in the broadcast
domain. This is called IGMP Snooping, in which layer 2 device records which ports IGMP
packets are received on, depending on the kind of IGMP message, so multicast data traffic is
not flooded across every port on the VLAN when it is received by the switch.

When you configure an IGMP input filter, IGMP will check all incoming packets received from the
range of IP addresses specified in the
filters rules. The protocol action and flow action occur when an incoming packet matches an IP
address range. If an incoming packet matches a rules address range, the other rules in the filter
are not checked.
To activate the filter, you must assign the filter to a VLAN and enable the filter.
133
IGMP input filter parameters include:
filter-id: The ID of the filter. You can create up to 16 IGMP input filters. Each filter must have a unique
ID. Possible values are 116.
rule-id: The ID of a rule associated with the input filter. The rule ID sets the order in which multiple
rules check incoming packets. You can create up to eight rules for each input filter. Each rule must
have a unique ID. Possible values are 18.
start-ip ip-address: The starting IP address of the rules IP address range
end-ip ip-address: The ending IP address of the rules IP address range
protocol-action: The response to protocols in packets that match a rules IP address range:
deny Deny packets matching this rule
allow Allow packets matching this rule
flow-action: The response to flows in packets that match a rules IP address range:
drop Drop packets matching this rule
flood Flood packets matching this rule
allow Allow packets matching this rule
134
Version 3 adds support for source filtering: the ability for a system to report interest in receiving
packets only from specific source addresses, as required to support Source-Specific Multicast
(SSM or from all but specific source addresses, sent to a particular multicast address. Version 3
interoperates with Versions 1 and 2.
In IGMPv3 a Querying Router sends a "General Query" to learn the complete multicast reception
state of the hosts on the network upon which it sends the Query. In a General Query, both the Group
Address field and the Number of Sources (N) field are zero.
The Querying Router sends a "Group-Specific Query" to learn the reception state of hosts on the
network with respect to a single multicast address. In a Group-Specific Query, the Group Address
field contains the multicast address of interest, and the Number of Sources (N) field contains zero.
A Querying Router sends a "Group-and-Source-Specific Query" to learn if a host desires reception of
packets sent to a specified multicast address from any of a specified list of sources. In a Group-and-
Source-Specific Query, the Group Address field contains the multicast address of interest, and the
Source Address fields contain the source address(es) of interest.
Although configuration of a unicast routing protocol such as OSPF is required with PIM, PIM-SM is
protocol independent. That is, it does not rely on any one particular underlying routing protocol to
perform reverse path forwarding RPF checks. It can perform this function using protocolspecific
routes from, OSPF, RIP, static config.
PIM-SM relies on IGMP technology to determine group memberships and uses existing unicast
routes to perform reverse path forwarding (RPF) checks, which are, essentially, a route lookup on
the source. Its routing engine then returns the best interface, regardless of how the routing table is
constructed. In this sense, PIM is independent of any routing protocol. It can perform RPF checks
using protocolspecific routes (for example, OSPF routes), static routes, or a combination of route
type.
PIM-SM uses a shared-tree-type technology, which requires a rendezvous point. The rendezvous
point can be administratively assigned or dynamically elected on a specific router in the PIM domain.
Source devices have to register with the rendezvous point by forwarding a join message. Initially, the
source device may not know which router is the rendezvous point so a join message is used. The
multicast source initiates an IGMP join message to its default gateway. In this case, the sources
default gateway is known as the DR (Designated Router). The DR will forward the join message onto
the RP router. The RP router will respond building a path (tree) between the DR and itself.
Note: Within PIM-SM a Designated Router (DR) is a router that performs the function of forwarding
multicast traffic from a unicast source to the appropriate distribution (rendezvous point). A PIM-SM,
DR is different from an OSPF Designated Router (DR), and should not be interpreted as being the
same.
Note: All traffic from the source device must be forwarded to the RP router.
Once the RP router receives the multicast traffic, it will then forward traffic to the receivers. This may
cause some delay with multicast packets reaching their final destination since all packets must first
go through the rendezvous point.
Receivers will send a IGMP host membership report for each group they belong to. The Host
Membership Report packets are recorded by the last-hop router and forwarded to the rendezvous
point. Then, PIM-SM routers can forward multicast traffic out all interfaces that lead back to the
receivers from the source and rendezvous point.
Routers without multicast group members do not send messages to the RP router, therefore, no data
is distribute to downstream nodes that have not registered with the RP. When new members appear,
PIM-SM sends a join message to enable the path so that it is added to the distribution tree. PIM-SM
adopts reverse path forwarding RPF technology as part of its operation. Reverse path forwarding
(RPF) checks are, essentially, a route lookup on the source. Following a route lookup, the routers
routing engine will return the best interface to the multicast source. It is through RPF checks that the
shortest path is established.
Prune messages are sent up the distribution tree when multicast group traffic is no longer desired.
This permits branches of the shared tree that were created via Join messages to be taken down
when they are no longer required.
In the example shown above, the RP is receiving multicast data for group 224.4.4.4, from DR
172.14.1.2, on interface Vlan-14. The RP is forwarding the multicast data to registered multicast
receivers on outbound interface Vlan-2.
In the example shown above, the RP is receiving multicast data for group 224.4.4.4, from DR
172.14.1.2, on interface Vlan-14. The RP is forwarding the multicast data to registered multicast
receivers on outbound interface Vlan-2.
Rendezvous Point (RP): A router elected as a rendezvous point for a multicast group receives
requested multicast traffic from a DR and forwards it toward the multicast receiver(s) requesting the
traffic.
Designated Router (DR): A router performing this function forwards multicast traffic from a unicast
source to the appropriate distribution (rendezvous) point.
Bootstrap Router (BSR): A router elected to this function keeps all routers in a PIM-SM domain
informed of the currently assigned RP for each multicast group currently known in the domain.
Static Rendezvous Point (Static-RP): Traffic is forwarded in the same way, but all routers within the
domain are manually configured with RP address information.
PIM Domain: A contiguous set of routers that implement PIM and are configured to operate within a
common boundary.
Shortest Path Tree (SPT): The shortest path from the source DR through any intermediate PIM-SM
routers leading to the leaf router for the multicast receiver requesting the traffic for a particular
multicast group.
Reverse Path Forwarding (RPF): PIM-SM uses the unicast routing table created by IP protocols such
as RIP and OSPF to determine the source address of a packet. PIM uses RPF to set up a shared
tree for multicast traffic.
Hello These messages announce the senders presence to other PIMSM devices. The hello
packet includes options such as:
Hold time the length of time to keep the sender reachable.
Designated router (DR) priority used to designate which PIM SM devices will act on
behalf of sources and receivers in PIM domain
Register These messages are used by a sources DR to encapsulate (register) multicast data and
send it to the RP.
Register Stop Are used by the RP to tell the sources DR to stop registering traffic for a particular
source.
Join/Prune (J/P) - Contain information on group membership received from downstream routers.
Bootstrap These messages are sent by the PIMSM router that has been elected as the bootstrap
router (BSR) to inform all PIMSM routes of the RP/group mappings.
Candidate RP message - Are sent by the configured candidate RP routers to the BSR to inform the
BSR of its RP/group candidacy.
Assert - Used to indicate that a device has received a data packet on its outbound (receiving)
interface for the group. They report the metric or distance to the source or RP to help the device
identify the most direct path to the root of the tree.
A router directly connected to a receiver is often referred to as a leaf/last-hop router. The leaf router
is responsible for sending join/prune messages to the RP, informing the RP that the receiver is ready
to accept multicast traffic, or that the forwarding of multicast packets associated with a specific
multicast group should be stopped.
( *, G ), where:
* = a variable (wildcard) representing the IP address of any multicast
source
G = a particular multicast group address
( S, G ), where:
S = a particular multicast source
G = a particular multicast group address
( *, G ) is created as the result of an explicit join occurring
( S, G ), is created as the result of a join/prune message, or when a last-hop router switches to the
SPT.
149
By default, PIM chooses the first entry in the routing table when it calculates its Shortest Path Tree.
Consider the situation in this network. Our receiver is attached to the Last-Hop router, which has
learned three equal-cost paths to Source A through OSPF. In this case the Last-Hop Router learned
about Source A from Router 2 first, so Router 2 is the first entry in the routing table. PIM by default
will always choose to go through Router 2 to create its SPT back to Source A.
150
PIM Multipath allows you to manipulate how PIM uses the routing table.
PIM Multipath with the highest-nexthop argument sends all PIM traffic to the PIM neighbor with the
highest IP address. In our example, the Last-Hop Router would send all PIM traffic to Router 3.
PIM Multipath with the hash argument hashes on the source IP of the multicast source to determine
the path for this particular multicast flow. In this instance, the Last-Hop Router would hash the
172.16.111.101 IP address of Source A to determine the SPT.
Note that PIM Multipath with the hash argument does NOT distribute a given flow over multiple
paths. Each flow will only go to one next-hop router. However, in a network with multiple multicast
flows, PIM Multipath will give you rough load balancing of your multicast traffic.
151
152
153
The PIM specifications define several modes or methods by which a PIM router can build the
distribution tree. Enterasys devices support sparse mode (PIMSM), which uses only those routers
that need to be included in forwarding multicast data. PIMSM uses a hostinitiated process to build
and maintain the multicast distribution tree. Sparse mode routers use bandwidth more efficiently than
other modes, but can require more processing time when working with large numbers of streams.
PIMSSM is a subset of the PIMSM protocol. PIMSSM is not independent of PIMSM. PIMSM
must be enabled on all interfaces that use PIMSSM. PIMSSM is disabled by default and must be
explicitly enabled.
PIMSSM only builds source-based shortest path trees. Where PIM-SM always joins a shared tree
first and then switches to the source tree, SSM eliminates the need for starting with a shared tree by
immediately joining a source through the shortest path tree. This behavior means that PIMSSM
does not require an RP or BSR. Members of an SSM group can only receive from a single source.
This is ideal for applications like TV channel distribution, and for certain banking and trade
applications, but rules out SSM for applications such as multicast VoIP teleconferencing.
The Internet Assigned Numbers Authority (IANA) has reserved addresses for PIM-SSM in the
232.0.0.0/8 range for IPv4 and in the ff3x:0000/32 range, where (x = 4,5,8, or E), for IPv6. SSM
recognizes packets in this range and controls the behavior of multicast routing devices and hosts that
use one of these addresses. In PIMSSM, an IP datagram is transmitted by a source S to an SSM
destination address G, and receivers can receive this datagram by subscribing to channel (S,G).
A channel is a source-group (S,G) pair where S is the source sending to the multicast group and G is
an SSM group address. SSM defines channels on a per-source basis. In SSM, each channel is
associated with one and only one source.
In a mixed PIMSM and PIMSSM configuration you configure the RP and BSR only for the PIMSM
group address range. PIM-SSM does not use Rendezvous Points or Boot Strap Routers.
Enable IGMPv3 on all PIMSSM interfaces and enable IGMP querying on the PIMSSM receiver
interface. PIMSSM requires IGMPv3 and/or MLDv2 at the edge of the network to process the
sourcespecific IGMP and MLD joins.
PIM-SSM provides several key features:
Is easier to provision and maintain due to the single source address that a receiver can request data
from
Provides the ideal mechanism for multicasts that originate from a single source and go to multiple
receivers
Does not require unique multicast addresses; it depends upon the receiver request for the
destination address of the multicast
PIMSM and PIMSSM can coexist on a single router and are both implemented using the PIMSM
protocol.
Enterasys PIMSSM enabled devices use the following PIMSM message types:
Hello These messages announce the senders presence to other PIMSM devices. The hello
packet includes options such as:
Hold time the length of time to keep the sender reachable
Designated router (DR) priority used to designate which PIMSM device will act on behalf
of sources and receivers in the PIMSM domain
Join/Prune (J/P) These messages contain information on group membership received from
downstream routers.
PIMSM adopts RPF technology in the join/prune process. When a multicast packet arrives, the
router first judges the correctness of the arriving interfaces:
If the packet is a source address/multicast group (S,G) entry (on the shortest path tree
(SPT)), then the correct interface is the reverse path forwarding (RPF) interface towards the
source.
Assert These messages indicate that the device received a data packet on its outbound
(receiving) interface for the group. They report the metric or distance to the source to help the device
identify the most direct path to the root of the tree. If multiple routers claim to have the most direct
path to the source, each device sends its own assert message and the router with the best metric
wins.
The sources DR registers (that is, encapsulates) and sends multicast data from the source directly
to the RP via a unicast routing protocol. The RP deencapsulates each register message and sends
the resulting multicast packet down the shared tree. The receivers router sends a multicast group
(*,G) join message upstream to the RP, indicating that the receiver wants to receive the multicast
data. This builds the Rendezvous Point Tree (RPT) between the receivers router and the RP.
The receivers router then joins the shortest path tree (SPT) by sending an (S,G) join message to the
source. This builds the shortest path tree (SPT) between the source and receiver. As a result of this,
native multicast packets are now sent from the sources DR to the receiver on its SPT while
registered multicast packets continue to be sent from the sources DR to the RP. A prune message is
then sent from the receivers router to the RP. Once traffic is flowing down the SPT the path through
the RP is pruned for that given (S,G) and native multicast packets flow along the shortest path.
The sources DR registers (that is, encapsulates) and sends multicast data from the source directly
to the RP via a unicast routing protocol. The RP deencapsulates each register message and sends
the resulting multicast packet down the shared tree. The receivers router sends a multicast group
(*,G) join message upstream to the RP, indicating that the receiver wants to receive the multicast
data. This builds the Rendezvous Point Tree (RPT) between the receivers router and the RP.
The receivers router then joins the shortest path tree (SPT) by sending an (S,G) join message to the
source. This builds the shortest path tree (SPT) between the source and receiver. As a result of this,
native multicast packets are now sent from the sources DR to the receiver on its SPT while
registered multicast packets continue to be sent from the sources DR to the RP. A prune message is
then sent from the receivers router to the RP. Once traffic is flowing down the SPT the path through
the RP is pruned for that given (S,G) and native multicast packets flow along the shortest path.
End-hosts on a LAN segment are typically configured to send packets through the gateway defined
by a default route (or static routes) for remote destinations. Loss of the default router results in a
catastrophic event, isolating all end-hosts that are unable to detect any alternate path that may be
available. The Virtual Router Redundancy Protocol (VRRP) is designed to eliminate the single point
of failure inherent in the static default routed environment.
VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one
of the VRRP routers on a LAN.
The VRRP router controlling the IP address(es) associated with a virtual router is called the Master,
and forwards packets sent to these IP addresses.
The election process provides dynamic fail-over in the forwarding responsibility should the Master
become unavailable.
Any of the virtual router's IP addresses on a LAN can then be used as the default first hop router by
end-hosts.
The advantage gained from using VRRP is a higher availability default path that does not require
routing or router discovery protocols on end-hosts.
Load sharing can also be implemented by configuring multiple VRRP routers across multiple IP
routers, each IP router being the master of a different virtual router.
Before we go any further, lets get familiar with the terminology defined in RFC 3768:
VRRP Router - A router running the Virtual Router Redundancy Protocol.
Virtual Router - An abstract object managed by VRRP that acts as a default router for hosts on a
shared LAN. A VRRP router may participate in one or more virtual routers.
VRID Uniqueness is required on a LAN segment only
IP Address Owner - The VRRP router that has the VRs IP address(es) also as the real interface
address(es). This is the router that, when up, will be the master of the virtual router instance and will
respond to packets addressed to these IP addresses for ICMP pings, TCP connections, etc.
Virtual Router Master - The VRRP router that assumes the responsibility of forwarding packets sent
to the IP address(es) associated with the virtual router, and answering ARP requests for these IP
addresses.
Virtual Router Backup - The set of VRRP routers available to assume forwarding responsibility for a
virtual router should the current Master fail.
If the virtual router IP address is the same as the interface (VLAN) address owned by a VRRP router,
then the router owning the address becomes the master. The master sends an advertisement to all
other VRRP routers declaring its status, and assumes responsibility for forwarding packets
associated with its virtual router ID (VRID). If the virtual router IP address is not owned by any of the
VRRP routers, then the routers compare their priorities and the higher-priority owner becomes the
master. If priority values are the same, then the VRRP router with the higher IP address is selected
as the master.
The VRRP protocol design provides rapid transition from Backup to Master to minimize service
interruption, and incorporates optimizations that reduce protocol complexity while guaranteeing
controlled Master transition for typical operational scenarios.
All protocol messaging is performed using IP multicast datagrams, thus the protocol can operate
over a variety of multiaccess LAN technologies supporting IP multicast. Each VRRP virtual router
has a single well-known MAC address allocated to it. The virtual router MAC address is used as the
source in all periodic VRRP messages sent by the Master router to enable bridge learning in an
extended LAN.
Master_Down_Timer - The amount of time that a Backup router will wait before it becomes the new
Master. Therefore, the higher the priority, the faster a Backup router will detect that the Master is
down.
The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the
following format:
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
The first 3 octets are derived from the IANA's OUI. The next 2 octets indicate the address
block assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router Identifier.
Three types of ARP requests can be employed on a VRRP router:
Host ARP - Host ARP performs according to the following rules:
When a host sends an ARP request for one of the VR IP addresses, the master VR returns the
virtual MAC address (00-00-5e-00-01-VRID).
The backup VR must not respond to the ARP request for one of the VR IP addresses.
If the master VR is the IP address owner, when a host sends an ARP request for this address, the
master VR must respond with the virtual MAC address, not the real physical MAC address.
For other IP addresses, the VRRP router must respond with the real physical MAC address,
regardless of master or backup.
Gratuitous ARP - behaves in the following manner on a VRRP router:
Each VR sends gratuitous ARP when it becomes the master with virtual IP and MAC addresses. One
gratuitous ARP is issued per VR IP address.
To make the switch learn the correct VR MAC address, the VR master sends gratuitous ARP for
every virtual IP address in the corresponding VR every 10 seconds.
Proxy ARP
If used, the VRRP master router must bind the virtual MAC address to remote IP destination
addresses in proxy ARP replies.
S & K-Series
If the virtual router IP address is the same as the interface (VLAN) address owned by a VRRP router,
then the router owning the address becomes the master. The master sends an advertisement to all
other VRRP routers declaring its status, and assumes responsibility for forwarding packets
associated with its virtual router ID (VRID). If the virtual router IP address is not owned by any of the
VRRP routers, then the routers compare their priorities and the higher-priority owner becomes the
master. If priority values are the same, then the VRRP router with the higher IP address is selected
as the master.
When configuring the S/K-Series, in order to change VRRP parameters the VRRP instance must be
disabled prior to configuring and then re-enabled. Additionally, C-Series and G-Series Routers will
not establish a VRRP relationship with an K or S-Series router if the S/K routers have been
configured to run on v3-IPv4 VRRP. This will represent a VRRP version mismatch.
Available VRRP Interface Level Commands:
vrrp create
vrrp address
vrrp priority
vrrp accept-mode (set master-icmp-reply)
vrrp advertise-interval
vrrp critical-ip
vrrp preempt
vrrp preempt-delay
vrrp enable
vrrp authentication simple
vrrp authentication md5
ICMP Echo
The VRRP RFC specifies that a VR master that is not the IP address owner should not respond to an
ICMP ping associated with the virtual IP address.
This poses a problem for network management applications which determine reachability to a given
IP address using ICMP Echos. Best is to make it configurable for allowing non-owner as well.
Note the difference in CLI syntax in various platforms.
ICMP Redirects
When a default router finds another router on the same LAN (whose IP address is also on the same
subnet) provides a better first hop in the path to a destination, it sends an ICMP Redirect message to
the host to indicate that future packets to that destination can use the other router as the gateway.
Per RFC, ICMP Redirects may be used normally when VRRP is running between a group of routers.
This allows VRRP to be used in environments where the topology is not symmetric.
The IP source address of an ICMP redirect should be the address the end host used when making its
next hop routing decision. If a VRRP router is acting as Master for virtual router(s) containing
addresses it does not own, then it must determine which virtual router the packet was sent to when
selecting the redirect source address. One method to deduce the virtual router used is to examine
the destination MAC address in the packet that triggered the redirect.
It may be useful to disable Redirects for specific cases where VRRP is being used to load share
traffic between a number of routers in a symmetric topology.
Commands (C and G-Series Routers):
router vrrp: Use this command to enable or disable VRRP configuration mode
Address vlan vlan-id vrid ip-address owner: Use this command to configure a virtual router IP
address.
1 to indicate the router owns the address
0 to indicate the router does not own the address.
priority vlan vlan-id vrid priority-value: Use this command to set a priority value for a VRRP router.
preempt vlan-id vrid: Use this command to enable or disable preempt mode on a VRRP router.
enable vlan vlan-id vrid: Use this command to enable VRRP on an interface.
Router2 is the IP address owner for this VRRP instance 1, as shown by the VRRP priority setting of
255 with the show ip vrrp command. Router2s interface on VLAN 12 is the master of the VRRP
instance while Router3s interface on VLAN 12 is the Backup for the instance recognizing 10.1.2.2 as
the master.
Displaying the VRRP instance 4 on both devices, it is shown that Router3s interface, 10.2.1.3, has
become the master of this virtual router instance while the backup is Router2s interface, 10.2.1.1.
Interface Monitoring:
The critical-ip configuration feature (critical-ip vlan vlan-id vrid ip-address [critical-priority]) allows a
different router to act as the default gateway when a route through the current master VR is
unavailable. For example, an IP address of an interface connecting a master router to a router
configured for internet access would be considered a critical IP address for VRRP routing. Typically,
an interface of a VR (usually the intended master of the VR) is set to monitor another interface on the
same router, and will refrain from acting as the master of the VR if the monitored interface is down.
When the monitored path is down, the current master sends a lower priority ADVERTISEMENT.
(Note, the Advertised priority will equal the VRRP instance priority minus the critical-ips critical
priority). When path restores, so does the VR priority. When the monitored interface comes up
again, the interface may become the master VR again if preemption is enabled.
When the actual IP address owner of the Virtual IP address releases the master state of the VR, it
will no longer be able to receive packets destined for that address even though the interface is still
up. This may cause routing packets to not reach this interface and cause this interface to be
considered down by other routers. To avoid this situation when using Interface Monitoring, the Virtual
IP address configured should be different from the actual IP address of the interfaces.
Critical-IP Operation:
1. RouterA critical-ip interface is up, Router A is current Master
RouterA(su)->show ip vrrp
Codes: Pri = Operational Priority
V = Version of the protocol
T = Type ( M-Master IP Address, A-Associate IP Address )
A = Admin status of Associate address ( E-enabled, D-disabled )
O = Owner status of Associate address ( Y-yes, N-no )
Interface Vrid State Pri V T A O IP Address
----------- ---- ---------- --- - - - - ---------------------------------------
vlan.0.10 1 master 200 2 M - - 10.1.1.1
A E N 10.1.1.254
2. RouterA critical-ip interface fails as indicated by log message below, RouterA transitions to
Backup state as a result. Current priority for RouterA is now 99. (VRID priority 200 critical-priority
101=99).
RouterA(rw)->Router#<165>Aug 3 13:48:05 172.10.1.101 Router[1]router interface vlan 20, ip

10.1.2.0 is down
<165>Aug 3 13:48:05 172.10.1.101 VRRP[1]VRRP Event: Interface = 20, VRID = 1, CRITICAL IP
Interface 10.1.2.1 (priority: 101) is DOWN
RouterA(su)->show ip vrrp
Interface Vrid State Pri V T A O IP Address
----------- ---- ---------- --- - - - - ---------------------------------------
vlan.0.10 1 backup
99 2 M - - 10.1.1.1
A E N 10.1.1.254
3. RouterB has assumed Master state since its current priority 100 is greater than RouterAs
priority of 99.
RouterB(su)->router#show ip vrrp
Vlan Vrid State Owner AssocIpAddr Priority VirtMacAddr
10 1 Master 0 10.1.1.254 100 0000.5e00.0101
Note: If there are 2 Critical Interfaces configured, the sum of both critical interface priorities
must be large enough for VRRP to cause a failover. If a single interface fails, and the sum of its
priority is not large enough to reduce the Masters priority to a level less than the backups
priority, a VRRP switchover will not occur.

Note: Router A now advertises a priority of 99, this results from a critical-IP value of 101 being
subtracted from the VRRP priority of 200 set during the initial VRRP configuration on RouterA.
For C-Series, the VRRP instance with VRID 1 is configured on VLAN 10 by entering the VRRP router
configuration mode for the VLAN 10 interface. In this mode, the virtual IP address for the virtual
router instance is configured an set to the IP address which represents the network clients default
gateway (10.1.1.254). A flag of 0 has been set indicating that RouterB does not own the VIP of
10.1.1.254.
For RouterA, VRRP is configured at the interface level, by accessing interface vlan.0.10. Additionally
on RouterA, an interface IP address has been configured for monitoring (critical-ip) for VRRP
instance 1. As a result, if the interface associated with IP address 10.1.3.1 becomes non-operational,
RouterA will release the master status of VRRP instance 1 for VLAN 10.
Depending on implementation and router (S & K Series), non-owner master may respond to ICMP
Echo Request by a configuration option, (vrrp accept-mode 1). This option enables master-icmp-
reply for VRRP instance 1.
Authentication can help to guarantee that routing information is imported only from trusted routers. A
variety of authentication schemes can be used, but a single scheme must be configured for each
network. The use of different schemes enables some interfaces to use much stricter authentication
than others.
The two authentication schemes available are simple, and MD5. The authentication command
specifies the type of authentication and key values used in VRRP Authentication is used by VRRP to
generate and verify the authentication field in the VRRP header.
vrrp authentication simple: Use this command to set a VRRP authentication password on an
interface in clear test format
Example
This example shows how to set the VRRP authentication password to vrrpkey on VLAN 10 VRID1:
RouterA(su-config)->interface vlan.0.10
RouterA(su-config-intf-vlan.0.10)->vrrp authentication simple vrrpkey
ip vrrp message-digest-key vrid md5 password [hmac-96]: Use this command to set a VRRP MD5
authentication password on an interface.
Example
This example shows how to set the VRRP MD5 authentication password to vrrpkey2 on VLAN 20
VRID 2:
RouterA(su-config)->interface vlan.0.20
RouterA(su-config-intf-vlan.0.20)->vrrp authentication md5 vrrpkey2 hmac-96
RouterA is the master VRRP instance VLAN 10, VRID 1, based on priority (200) as shown by the
show ip vrrp command.
RouterB is the master VRRP instance VLAN 20 VRID 2, based on IP address ownership and priority
of 255.
Note: If VLAN/VRID priority is equal, the router with the highest IP address for the VLAN will assume
the master role.
In order to transmit data to remote Layer 3 destinations, end host systems on a LAN segment are
typically configured to send packets to a default gateway. If the router that is configured as the
default gateway becomes unavailable, then communication from hosts to remote destinations is cut
off.
VRRP is an election protocol that dynamically assigns responsibility for one or more virtual router(s)
to the VRRP router(s) in a network. This allows multiple routers to use the same virtual IP address.
A virtual router is an abstract concept. No physical router is defined as a virtual router. Rather, the
virtual router is an abstract entity that acts as a default gateway for local hosts, and is associated with
two or more physical routers running the VRRP protocol.
The virtual router is configured with a VRID, or Virtual Router Identifier. This VRID can range from 1
to 255 and is unique to each virtual router on a particular LAN segment. The VRID is used to define
the MAC address of the virtual router in the following manner:
00-00-5E-00-01-{VRID} (in hexadecimal notation)
In a LAN segment where VRRP is running, when a host ARPs for its default gateway, the above
address will appear in the hosts ARP table associated with the default gateways IP address.
When configuring multiple instances of VRRP, the router can only associate 9 or 4 (depending on the
device) different MAC addresses for each physical interface. Each time a VRRP instance is made, it
creates a virtual router with a virtual router MAC. For instance, creating "vrrp 1" creates a MAC
address of 00-00-5e-00-01-01. VRRP 2 would create a MAC with a final byte of -02, and so on.
This module is intended as a high level aid in identifying possible causes to various types of network
problems within a routed environment. Details on how to perform data network testing, use network
management platforms (such as NetSight), and 3rd party packet capture tools like Wireshark, as part
of the troubleshooting process are not covered in depth. Due to the vast number of potential
problems that can occur in a network environment, only the most common commands, tools, and
problems are covered.
Enterasys Systems modules or standalone devices may vary. For details on a select product, please
refer to the manual associated with the particular module or standalone device. Also, refer to these
manuals for information concerning problems that may occur during installation.
Show commands on Enterasys Systems platforms may vary. For details on a select product, please
refer to the manual associated with the particular module or standalone device.
show system utilization :
Matrix(rw)->show system utilization slot 1
CPU Utilization Threshold Traps enabled: Threshold = 80.0%
Total CPU Utilization:
Slot CPU 5 sec 1 min 5 min
---------------------------------------------------
1 1 3.6% 3.0% 3.0%
Process Utilization:
Slot: 1 CPU: 1
show port status :
Matrix(rw)->show port status ge.3.14
Port Alias Oper Admin Speed Duplex Type

(truncated) Status Status
------- -------------- ------- ------- -------- ------- -----------------
ge.3.14 up up 1 Gbps full 1000-SX MT-RJ
Note, within a routed network, it may be necessary to disable Spanning Tree. This results from the
fact that, during normal Spanning Tree operation, the protocol can negatively affect multi-path routing
functionality by blocking multiple physical paths in a network that would typically be available for
Layer 3 forwarding. If it appears that a Layer 3 forwarding path is not available, issue the show
spantree stats [port port-string] [sid sid] command to insure spanning tree is not enabled, and that
switch ports used within the forwarding path are not in a blocking state as a result of spanning tree.
Before configuring layer 3 services (IP Interfaces, Router Processes, etc.) on an Enterasys Switch
Router, VLANs must first be created. Once the required VLANs are created, verify via the show vlan
[vlan-list] or show vlan static [vlan-list] commands that the necessary ports have been added to the
VLANs egress list. By adding a port to a VLANs egress list, the port is set as eligible to transmit
frames for a given VLAN.
Note, adding a port to a VLANs egress list is a requirement! If not set, the layer 3 VLAN interface will
be unable to process traffic in a bidirectional way resulting in connectivity problems.
Use the show running-config command to view the router configuration. Insure that the correct
interfaces have been provisioned, and the correct protocols have been configured.
Use the show ip interface command to check the status of the routers interfaces. Verify that the
interfaces is up both administratively as well as operationally. Determine whether access lists or IP
Helper addresses have been set on a an interface.
The Address Resolution Protocol (ARP) is used in determining a network host's data-link layer or
MAC address when only its IP address is known. This function is critical in IP networks. If a network
device can not obtain an IP-to-MAC mapping of the device it is attempting to communicate with, they
will be unable to exchange data across the LAN. Insure proper ARP table entries are present via the
show ip arp [ip-address] command if a connectivity problem has been encountered.
Use the show ip route command to insure remote network destinations are in the routers active route
table.
Based on the configuration shown on this page,, routers R1 and R2 have now been provisioned to
pass RIP routing updates. Entering the show ip route command on router R1 reveals it is exchanging
RIP updates across the 192.168.5.0 network link. As can be seen from the route table outputs, R1
has knowledge of remote networks 192.168.4.0 via RIP, and 10.10.1.0 via a static route, therefore,
these networks should be reachable thru router R1.
Note that the RIP route is displayed with an R in indicating that is has been learned via the RIP
protocol. The static route is displayed with an S.
Issuing the show ip protocol command is a useful way to determine which routing processes are
running on your platform. The command will provide details on the networks the device is routing for
and routers that the device is exchanging routing information with.
Issuing the show ip traffic command is a useful way to collect IP traffic statistics. The command will
provide details on a variety of IP counters that can be used as part of the troubleshooting process.
Syntax
show ip traffic [softpath] (softpath (Optional) Displays IP protocol softpath statistics. This option is
used for debugging)
clear ip stats
Use this command to clear all IP traffic counters (IP, ICMP, UDP, TCP, IGMP, and ARP).
Syntax
clear ip stats.
Use the show support command to collect bulk troubleshooting information. The show support
command is a useful way to quickly gather system related configuration parameters and platform
status for the GTAC if needed.
Note: Logging messages can also be viewed by issuing the show logging buffer command. By
default, all log messages are directed to the log buffer. The log buffer is cleared on system reboot.
Additionally, Enterasys Switch/Router can be configure to log locally and log to a syslog server
simultaneously.
Application: A mnemonic abbreviation of the textual description for applications being logged.
Current Severity Level: Severity level (1 - 8) at which the server is logging messages for the listed
application.
Defaults: Default facility name, severity level and UDP port designation (as described below.)
IP Address: Syslog servers IP address.
Facility: Syslog facility that will be encoded in messages sent to this server. Valid values are: local0
to local7.
Severity: Severity level at which the server is logging messages.
Description: Text string description of this facility/server.
Port: UDP port the client uses to send to the server.
Status: Whether or not this Syslog configuration is currently enabled or disabled
Command Snytax:
set logging server index [ip-addr ip-addr] [facility facility] [severity severity] [descr descr] [port port]
[state {enable | disable}]
Parameters:
index Specifies the server table index number for this server. Valid values are 1 8.
ipaddr ipaddr (Optional) Specifies the Syslog message servers IP address.
facility facility (Optional) Specifies the servers facility name. Valid values are: local0 to local7.
severity severity (Optional) Specifies the severity level at which the server will log
messages. Valid values and corresponding levels are:
1 - emergencies (system is unusable)
2 - alerts (immediate action required)
3 - critical conditions
4 - error conditions
5 - warning conditions
6 - notifications (significant conditions)
7 - informational messages
8 - debug messages
descr descr (Optional) Specifies a textual string description of this facility/server.
port port (Optional) Specifies the default UDP port the client uses to send to the server.
state enable | disable (Optional) Enables or disables this facility/server configuration

Usage:
Three ICMP probes will be transmitted for each hop between the source and the traceroute
destination.
The above example shows how to use traceroute to display a round trip path to host 192.167.252.46.
In this case, hop 1 is an unnamed router at 192.167.201.2, hop 2 is rtr10 at 192.4.9.10, hop 3 is
rtr43 at 192.167.208.43, and hop 4 is back to the host IP address. Round trip times for each of the
three ICMP probes are displayed before each hop. Probe time outs are indicated by an asterisk (*):
Purpose:
Debug IP packet is an IP based packet monitor that allows for the monitoring of all IP traffic received
and transmitted from an S- or KSeries router forwarding engine. Debug IP Packet uses SYSLOG
messages to display packet information. Packet filtering takes place by assigning a router access
group to the debug ip packet command and is based on the groups ACL entries. This utility displays
matching frames for the defined signature being processed in the soft path of the router. It is
desirable that the number of rules assigned to the access group be limited so as to minimize the
impact on the forwarding system performance. By default the utility displays a subset of available
information. A verbose option provides detailed packet information. Options are available to both
throttle the number of packets per second and limit the number of packets per board.
Commands:
debug ip packet access-group
debug ip packet restart
debug ip packet arp
show debugging
no debug ip packet
Parameters:
accessgroup Specifies the name of the access group used to filter packets for this command.
throttle throttle (Optional) Specifies the number of filtered packets per second to be displayed. Valid
Values: 2 100
limit limit (Optional) Specifies the number of packets per board to be displayed. Valid Values: 0
1000 (0 = no limit applied)
verbose (Optional) Specifies detailed packet information level.
Defaults
throttle = 10, limit = 30.
MIB Tools lets you examine the MIBs supported by an active device on your network.
The menus in the Device Manager provide access to tools to accomplish configuration and
troubleshooting tasks.
The Enterasys NMS Event View lets you view alarm, event, and trap information for Console,
network devices, and other NMS applications. Each tabbed view in the Event panel lets you scroll
through the most recent 10,000 entries in the logs that are configured for that view. A Console tab,
showing Console events and a Traps tab that captures traps from devices modeled in the NMS
database are provided when Console is initially installed. The Syslog tab shows events from devices
that are configured to use the NMS Syslog Server. You can add your own tabs that capture local
logs. Local logs are not automatically polled, but can be manually refreshed using the Refresh
button.
The wireless solution includes a wide variety of access points, controllers, management capabilities,
security, as well as a unique open platform for application integration.
The Wireless Controller, Access Points and Convergence Software solution consists of the following
components:
Wireless Controllers
Wireless APs
Wireless Manager
Enterasys NetSight Console, Enterasys IPS, Enterasys SIEM & NAC
Depending on your deployment the solution may require three other components, all of which are
standard for enterprise and service provider networks:
RADIUS Server (Remote Access Dial-In User Service) or other authentication server
DHCP (Dynamic Host Configuration Protocol) Server for address assignment
Network Time Protocol (NTP) Server
VNS = Virtual Network Services
The Wireless Controller, Access Points, and Convergence Software system provides a scalable
solution based on the license and capacity of the controller. The Wireless Controller Data Sheet is
available on the Enterasys website at the following url:
http://www.enterasys.com/company/literature/wireless-controllers-ds.pdf
The wireless architecture allows a single Wireless Controller to control many Wireless APs, making
the administration and management of large wireless networks much easier.
There can be several Wireless Controllers in the network, each with a set of registered Wireless APs.
The Wireless Controllers can also serve as backups to each other, providing highly available
wireless networks.
The Wireless Assistant GUI is the Web-based interface for configuring, managing, logging and
monitoring of each individual controller. Because the Wireless AP does not have a user interface the
Wireless Assistant interface is used to configure and manage each AP.
To access the EWC connect a laptop directly to the management port using a cross-over Ethernet
Cable. Set a static IP address in the 192.168.10.0/24 subnet on the Ethernet port of your Laptop.
Launch a web browser and make a secured http connection to the Wireless Controller using the
factory default IP address of 192.168.10.1 and port 5825 (https://192.168.10.1:5825).
In the User Name box type the default username of admin and password abc123 and click the Login
button.
Once you log into the Wireless Assistant the Dashboard will appear. The dashboard provides a
graphical view of the wireless network health from the controllers perspective. For ease of use, the
live graphs and links provide a quick launch point to reports and configuration parameters for in-
depth troubleshooting, access to logs, reports, and configuration components are accessed via the
toolbar. Select the Wireless Controller Configuration option in the menu to continue the initial setup.
At the foot of the Wireless Assistant home screen, important information about the controller can be
seen including error and configuration messages.
[host name | product name | up time], for example, [EWC | V2110 | 12 days, 21:16]. If the Wireless
Assistant is running the V2110 license, the footer will display V2110.
Port Status is the connectivity state of the ports.
M represents the Management interface and the numbered lights reflect the data port
interfaces on the system.
Green indicates the interface is up and running.
Red indicates the interface is down.
F icon represents the flash drive status: green if the flash drive is mounted and red if the
flash drive is not mounted
The Dashboard is interactive, by clicking of the number of APs a separate dialog will display the AP
name, Serial Number and IP address of the Access Point.
Host Attributes screen allows configuration of the Host Name of the Controller, Domain Name and
DNS Servers. The DNS server list will be used for resolving hostnames for the Controller.
Physical network port topologies are pre-defined on most of the Wireless Controllers and cannot be
removed from the Wireless Controller configuration. The Topologies screen on the Wireless
Controller displays both physical network port and VNS topologies.
For the Virtual Controllers physical interfaces (topologies) must be created. Once created topologies
cannot be deleted while they are active either as a Physical port on the controller or a Virtual Network
Services (VNS) that is, referenced by a Policy. Topologies can be modified by selecting and clicking
the desired physical or VNS interface.
Note: the 172.31.0.0/24 Network should NOT be used because of the internal WC usage.
Support for static LAGs at the distribution layer (controller or virtual gateway) extends high-
availability and load balancing to the distribution/core physical connection. Grouping one or more
network interfaces into a single LAG between the controller and the distribution/core switch,
increases bandwidth capacity for centralized deployments. LAGs also provide physical redundancy
in case of a hardware failure at the link layer on the network.
Only ports that are not assigned to a topology can be added to a LAG, QoS scheduling is applied per
port, not per LAG. When a LAG is disabled no traffic is forwarded on the port, if the port Admin
status is down, the port remains a member of the LAG but no traffic is forward and the physical link
status is down. The LAG MAC address is the MAC address of the second physical port on the
system.
Link Aggregation L2 ports are configured via the L2 Ports screen or the CLI. To a create LAG, assign
Physical ports to LAG.
VLAN ID is used as a Controller wide identification of the topologies, however the VLAN ID is only
used for tagged topologies.
Note: When upgrading to V8.01 a VLAN ID needs to be configured for each interface.
VLAN tagging a Controller interface refers to the action of assigning a VLAN-ID to a particular esa
port of the controller. All native and routed traffic on this physical port will be tagged with the
assigned VLAN ID before leaving the interface.
The native and routed traffic on this interface is comprised of those packets which either originate on
the port itself (i.e. ARP, SSH or HTTPS management) or are the result of a Layer 3 forwarding
decision through that port (i.e. routed VNS topologies). Excluded are the packets of VNS topologies
which are configured as Bridge Locally at Controller, these bridged packets will have a VLAN ID tag
of their own.
For traffic to properly to transfer onto the Enterprise Network, the Switch port must be configured to
egress the configured VLAN tagged traffic, i.e. vlan egress 20 ge.1.13 tagged.
By default, all physical ports are set with multicast support disabled. Only one non-management
plane port can be enabled for the multicast when you are supporting VoIP (i.e. Vocera), Apple
Bonjour, IPTV network traffic on Routed VNS topologies. Otherwise, the Controller will drop the
multicast traffic.
Your enterprise's WLAN may have existing third-party access points (thick Aps only) that you would
like to integrate into the Enterasys Wireless Convergence Software WLAN solution. You can set up
the Enterasys Wireless Controller to handle wireless device traffic from third-party access points,
providing the same policies and network access control. When enabled, 3rd Party APs must reside
on a separate LAN segment that have the Controller as its default gateway.
Only one physical interface can be configured to support 3rd Party APs per controller.
A 3rd Party AP segment needs to be defined as a special VNS topology with its own IP address
space. For example, you can use the VLAN feature to bridge one SSID to the 3rd Party AP network.
Seamless roaming is not supported by the Controller between Enterasys APs and the 3rd Party APs.
Features such as Captive Portal, Guest Splash and QOS can all be configured for the 3rd Party AP
VNS.
This provides a feature-rich migration strategy for existing Thick AP environment.
The Layer 3 (L3) section of the Topology screen allows you to configure and modify IP address and
DHCP options parameters.
The Layer 3 IP address definition is only required for Physical port configuration and Routed
topologies. It is optional for Bridge Traffic Locally at Controller topologies. L3 configuration is
necessary if services such as DHCP, captive portal, etc., are required over the configured network
segment or if you intend to manage the controller through the interface.
Bridge Traffic Locally at AP topologies do not require the definition of a corresponding IP address
since all traffic for WLAN clients in that VNS will be directly bridged by the Wireless AP at the local
network point of attachment.
The Enterasys Wireless Controller provides a local DHCP server. The local DHCP Server is useful
for general purposes and small subnets. Once the DHCP box is selected the lower pane is
populated with standard DHCP parameters. This should be used with caution since this DHCP
Server will respond to all DHCP requests (including PCs) on that network interface.
To allow management access (SNMPv2/v3, SSH or HTTPS) on a topology select Management
Traffic to enable this feature. Once selected, the Internal Exception Filters will be populated to allow
management traffic to this Port.
AP Registration is used by the Wireless APs as part of the discovery method. Ensure that AP
Registration is enabled so that Wireless APs can use this port for discovery and registration as part
of the Service Location Protocol (SLP). A Wireless Controller configured as a Mobility Manager
should also enable AP Registration since SLP will be used by the Mobility Agents to discover the
Mobility Manager.
On the Wireless Controller, various Port Exception Filters are created and enabled automatically for
physical ports and VNS topologies that have Layer 3 enabled. These filters protect the Wireless
Controller from unauthorized access to system management functions and services via the Physical
port. For example, access from only specific IP addresses can be allowed, while blocking all other
IPs from reaching the data ports of the Controller.
The Enterasys Wireless Controllers data interfaces (both physical interfaces and VNS virtual
interfaces) prohibits invoking SSH, HTTPS, or SNMP. However, such traffic is allowed, by default,
on the Management Port.
Specific filtering rules can be added at the port level in addition to the built-in rules. Such rules
provide the capability of restricting access to a port for specific reasons, such as a Denial of Service
(DoS) attack. The filtering rules are set up by specifying an IP address: Port and protocol (UDP,
TCP, IPSec-ESP, IPSec-AH and ICMP), then either allowing or denying traffic to that address.
The new rules defined are prepended to the normal set of restrictive exception filters (indicated by
the rule label or I) and have precedence over the systems normal protection enforcement.
Open Shortest Path First (OSPF, version 2) (RFC2328) Use OSPF to allow the Enterasys Wireless
Controller to participate in dynamic route selection. OSPF is a protocol designed for medium and
large IP networks with the ability to segment routes into different areas by routing information
summarization and propagation. Static Route definition and OSPF dynamic learning can be
combined, and the precedence of a static route definition over dynamic rules can be configured by
selecting or clearing the Override dynamic routes option checkbox.
Enable OSPF by selecting the ON parameters from the OSPF Status pull down menu and ensure
that each interface that will be participating in the OSPF exchange has the Port Status field set to
Enabled. Although the Area Type, Default is selected or backbone area, you can also configure the
interface to belong in a Stub or Not-so-stubby area.
Note: Only clear text authentication is supported for OSPF.
The Reports Section contains the OSPF Neighbor table and OSPF LinkState table.
OSPF Neighbor Displays the current neighbors for OSPF (routers that have interfaces to a
common network)
OSPF Linkstate Displays the Link State Advertisements (LSAs) received by the currently running
OSPF process. The LSAs describe the local state of a router or network, including the state of the
routers interfaces and adjacencies.
A default route enables the Wireless Controller to forward packets to destinations that are not
present in the OSPF routing table. Dynamic routes take precedence over static routes unless
"Override Dynamic Routes" is checked when adding a static route.
The Wireless Controller supports Simple Network Management Protocol (SNMP) Version 1/2c or 3,
for retrieving Wireless Controller statistics and setting configuration parameters. The Simple Network
Management Protocol, a set of protocols for managing complex networks, is used by an SNMP
manager to send messages to different devices in an IP network. Devices on the network that are
SNMP-compliant, running an SNMP agent, store data about themselves in Management Information
Bases (MIBs) and return this data to the SNMP requesters.
SNMPv3 uses a User-based Security Module (USM), therefore before access is granted a security
user and its authentication and privacy keys must be verified by the devices SNMP engine based on
the Security Level. Every controller should have their own unique engine id.
Use the Add User Account to create users with the Security Level, Authentication Protocol, Privacy
Protocol and related passwords to match the device.
Note: Modification of the SNMP engine will cause all SNMPv3 users keys to be reset and will need to
be reconfigured.
The controller supports Local or RADIUS Authentication mode to authenticate users that will have
access to the GUI and CLI. Local Authentication mode is enabled by default.
Controller supports three user groups:

Full Administrator (full administrator access rights to the user)
Read-only Administrator (user allowed to see but cannot modify settings)
GuestPortal Manager (allows the user to manage Guest accounts only)
Note: Rescue mode (covered in the Controller Maintance Module) allows you to deal with forgotten
passwords and to make Authentication mode changes outside of the Wireless Assistant GUI/CLI.
The RADIUS Server that is configured via the VNS Global Setting page for clients on the wireless
network is the same Radius Server that can be used to authenticate users to access the Wireless
Controller Configurator.
Note: That once Radius authentication access has been configured and enabled, if the Radius
Server is unavailable or not configured properly you may not be able to login to the Controller. To
ensure that the Radius Server is configured properly use the Test command.
Dual Authentication methods are supported on the Wireless Controller. By default Local
Authentication is configured. To configure Radius Authentication or a combination of authentication
modes select the Configure button. Administrator users will be authenticated based on the order in
the table.
For RADIUS Authentication mode, the RADIUS Attribute Service-Type return in an RADIUS Access-
Accept message will determine the group rights for the user: Service-Type = Framed (Read-Only
Administrator), Service-Type = Administrative (Full Administrator) and Authentication Only (Guest-
Portal Manager).
Synchronizing the Controller to a universal clock will ensure accuracy in WLAN client session
information when you are using Fast Failover, Mobility Services and usage logs. Network time is
synchronized in one of two ways: Using System Time by manually setting the time on your Wireless
Controller or using Network Time Protocol (NTP), an Internet standard protocol that synchronizes
client workstation clocks. You can specify up to 3 different Time Servers to use or configure your
Wireless Controller to be the local NTP server on your network. The Wireless Controller
automatically adjusts for any time change due to Daylight Savings time.
Note: Changes to the NTP screen may cause the controller to reboot.
Ekahau Blink Mode Support and AeroScout support are available for Location-based Services.
You can deploy your Enterasys Wireless Controller and Wireless APs as part of an AeroScout or
Ekahau location-based solution.
On the Enterasys Wireless Controller, you configure the AeroScout/Ekahau server IP address and
enable the location-based service. The AeroScout/Ekahau server is aware only of the Enterasys
Wireless Controller IP address and is notified of the operational APs by the Controller. On the APs
that you want to participate in the location-based service, you enable the location-based service.
Once you have enabled the location-based service on the Enterasys Wireless Controller and the
participating Wireless APs (2.4GHz band), at least one of the participating Wireless APs will receive
reports from an AeroScout/Ekahau Wi-Fi RFID tag in the 2.4GHZ band. The tag reports are collected
by the AP and forwarded to the AeroScout/Ekahau server (for triangulation and location reporting)
by encapsulating the tag reports in a WASSP tunnel and routing them as IP packets through the
Enterasys Wireless Controller.
Note: Tag reports are marked with UP=CS5, and DSCP = 0xA0. On the Enterasys Wireless
Controller, tag reports are marked with UP=CS5 to the core (if 802.1p exists).
Once the Location-based Service is set, individual AP Advanced setting must be modified to Enable
location-based service field.
An APs tag report collection status is reported in the Wireless AP Inventory report. For more
information, see Viewing Reports. If availability is enabled, tag report transmission pauses on failed
over APs until they are configured and notified by the AeroScout/Ekahau server.
Ensure that your AeroScout/Ekahau tags are configured to transmit on all non-overlapping channels
(1, 6 and 11) and also on channels above 11 for countries where channels above 11 are allowed.
Refer to AeroScout/Ekahau documentation for proper deployment of the AeroScout/Ekahau location-
based solution.
The controllers communicate amongst themselves using a secure protocol. Among other things, this
protocol is used to share the data required for high availability. They also use this protocol to
communicate with NetSight Wireless Manager. The protocol requires the use of a shared secret for
mutual authentication of the end points.
By default the controllers and NetSight Wireless Manager use a well known factory default shared
secret. This makes it easy to get up and running but is not as secure as some sites require.
The controllers and NetSight Wireless Manager allow the administrator to change the shared secret
used by the secure protocol. In fact the controllers and Wireless Manager can use a different shared
secret for each individual end point to which they connect with the protocol. The shared secret
should be between 16-232 ASCII characters.
If you de-select Enable Weak Ciphers browsers that only do weak ciphers wont connect.
Note: The component Langley is the term for the inter-process messaging infrastructure on the
Enterasys Wireless Controller.
The Ping and Trace Route tools are available on the Wireless Controller Utilities section. This allows
you to test the connection to a target IP address from the controller.
The TCPdump management utility allows you to capture exception traffic that is sent to the
management plane. Exception traffic is defined as traffic that is sent to the management plane from
the data/control plane for special handing (i.e. DHCP, OSPF and TFTP traffic). The TCP dump utility
allows you to determine if packets are being dropped in the data/control plane.
The captured traffic is stored in a binary tcpdump-format file on local hard-drive. The captured file
can be exported to a local machine for packet analysis (Wireshark, etc.).
There are some limitations. Only one traffic capture is allowed on the system at a single time and
the controller does not permit the capture of any data plane traffic. Lastly, WDS, Mesh and Bridge-
at-AP captures are not supported.
After a capture has completed you have the ability to Export it to a file on your desktop that can be
opened by a traffic analyzer.
There are multiple reports that can display Statistics and Configuration for the controller
configuration and clients that are associated to individual APs and VNSs. The information presented
in these report can help you monitor the overall status of your wireless network.
The system stores configuration data and log files for both the Controller and the AP. These files
include event and alarm logs (triggered by events), trace logs (triggered by component activity for
system debugging, troubleshooting and internal monitoring of the software), and accounting files
(created every 30 minutes, to a maximum of six files). The files are stored in the operating system
and have a maximum size of 1 GB. The accounting files are stored in flat files in a directory that is
created every day. Eight directories are maintained in a circular buffer (when all are full, the most
recent replaces the oldest). The System Log Level for the Wireless Controller and AP are
configurable in the System Maintaince Screen.
The administrator will have the option of enabling the streaming of mobile station (MU) events to the
EWC event log and to NetSight regardless of the event reporting severity level setting in the EWC
GUI. Today many customers are setting the log level to INFO to collect this MU information and as a
result are having their logs flooded with largely uninteresting events.
The Wireless Controller generates three types of log messages:

Application Logs (including alarms) Messages that are triggered by events
Audits Files that record administrative changes made to the system (the GUI Audit displays
changes to the Graphical User Interface on the Wireless Controller)
Services Logs (including alarms) Messages that are triggered by events
If SNMP is enabled on the Wireless Controller, alarm conditions will trigger a trap an SNMP trap. An
SNMP trap is an event notification sent by the managed agent (a network device) to the
management system to identify the occurrence of conditions.
The Log messages contain the time of event, severity, source component, and any details generated
by the source component. The messages are classified at four levels of severity:
Informational - the activity of normal operation
Minor (alarm)
Major (alarm)
Critical (alarm)
The alarm messages (minor, major or critical log messages) are triggered by activities that meet
certain conditions that should be known and dealt with.
Examples of events on the Wireless Controller that generate an alarm message are: Reboot due to
failure, Software upgrade failure on the Wireless Controller, Software upgrade failure on the Wireless
AP, and Detection of rogue access point activity without valid ID.
The Tech Support function rolls up a collection of logs and system data into a single compressed
file. The process takes several minutes and may affect system performance.
Note: Because this will create additional system load, it is advised to run this only when needed or
requested by Enterasys technical support.
You can upgrade the Wireless Convergence Controller Software via the Wireless Assistant GUI.
Upgrading the WC will also update the Access Point images that are stored on the Controller.
The Wireless Convergence Software provides two upgrade options: locally using the image file that
is located either on the local drive or flash or remotely by using an image file that is located on an
external FTP/SCP server.
If you choose to upgrade remotely you have the choice of running the upgrade directly from the FTP
/SCP server via the GUI or downloading the image file from a remote server to the local drive of the
Wireless Controller, or the flash, and then run the upgrade locally.
Note: If the controller file does not exist the upgrade will not succeed.
Note: You need to install the .ova file when you first install the V2110. All subsequent upgrades can
be performed using the standard controller upgrade procedure to apply a .bge file to the V2110.
If you are upgrading to V8 from VR7, you will be given a grace period of seven days to license the
software with the permanent activation key. During the grace period, you will be able to use all the
features and connect as many Wireless APs to the Wireless Controller as you want, subject to the
controllers limit. If you do not install the appropriate license after the expiration of the grace period,
the Wireless Controller will start generating event logs every 15 minutes, indicating that the
permanent license key is required. In addition, you will not be able to edit the Virtual Network System
(VNS) parameters.
Controllers shipped from the factory will have the Demo Mode license installed, the Demo Mode
license has limited functionality.
New activation keys are not necessary when upgrading to a minor release within the same major
version (e.g. V8.01 -> V8.11).
Note: As of V8.01 External Captive Portal support is included with the Controller Activation key.
You can also perform the upgrade as a scheduled task, by selecting Schedule upgrade for: and then
selecting the Month, Day, Hour and Min of the scheduled upgrade. Once you select Schedule
Upgrade you will be prompted to verify the selection.
Once the upgrade process is completed the Controller will reboot.
Note: When you upgrade the Wireless Software, the previous SSL configuration file is replaced with
a new one. Therefore any manual edits that were made in the previous SSL configuration files are
lost.
Backing up the Wireless Controller database only involves creating a backup of specific content in
the Wireless Controller database. You can choose to back up the whole contents of the database or
specific components such as: configuration, logs, or audit information. When a Wireless Controller
database backup is processed, a .zip file is created. The contents of the .zip file will vary depending
on what type of database backup you process.
When you back up the Wireless Controller database, you can choose to do the following: Back up
the Wireless Controller database now (the file is written directly to the disk and the Available
Backups list is updated) or Initiate a scheduled backup. This feature gives you more flexibility in the
storage as well as the time of when to initiate a backup.
You can upload an existing backup file to an FTP server. When an existing backup is uploaded to an
FTP server for storage, the files can be viewed.
When you schedule a backup, you can either choose to save the backup to an FTP or SCP server
or have the scheduled backup saved on your system.
Schedule Backups only in a non busy hour. If backups are scheduled then the page will show what
will be backed up, the schedule on which it will occur and when the next backup is scheduled to
occur. Press the Schedule Backups button to configure scheduled backups. You can run a Backup
Now job and a scheduled backup concurrently but this is inadvisable. Changing a scheduled backup
has no impact on a backup in progress. Only full backups are supported.
Note: If you do not specify an FTP server in the Schedule Backups window when you define the
backup schedule, the backup is added to the Available Backups list on the Backup tab.
If you process a configuration information backup, one of the files included in the .zip file is a .cli file.
When the .zip file is stored on an ftp server, the .zip file contents can be extracted and the .cli file can
be edited.
This editable .cli file when imported to a Wireless Controller will reproduce the identical configuration
from which the original configuration was generated. This editable .cli file provides an easy method
for replicating identical Wireless Controller configurations on multiple controllers. The graphic shows
a sample .cli file. The .cli file contains CLI commands, which will replicate the configuration that the
backup was based on when the file is imported.
Only local Backups can be restored. Therefore, backups that have been stored on a remote FTP site
need to be uploaded to the Wireless controller before proceeding.
The Rescue Mode is available through console access, either via the DB9 (C25, C4100 and C5110)
or RJ45 (C5210). During the boot prompt you can make the selection either 0: Main Mode Starts
up normal system partition or 1: Rescue Mode Starts system into Rescue framework.
Using the Rescue Mode from the Console you have a choice of restoring the image from the local
drive, restoring from an FTP server or using an external device like the USB.
By selecting Force system recovery, you will get a list of backup images on the local drive. Select the
backup image you want to restore and start the process. Once the procedure is started it is
irreversible. Once the recovery completes reboot the Wireless Controller. After the reboot, the
Wireless Controller restores the backed up image with its original configuration.
The Wireless Convergence Software enables you to recover the Wireless Controller via the Rescue
mode if you have lost its login password or if you need to change the Radius Authentication back to
Local Authentication.
Depending on the Software version and Controller type you can restore image from the Wireless
Assistant GUI.
With an SSH client you will also be able to logon to the EWC:
enter EWC-IP-Address
Login: admin
PW: <password>
Please refer to the CLI reference guide manual for further information.
To access the Controller via a serial line the following SW/HW is used:
VT100 emulation (e.g. HyperTerminal)
Cross-over cable (null modem)
Connection port of the WC: DB9 serial port (COM1 port)
CLI commands for the initial setup are described in the appendix of the user guide.
Once logged in to the Controller the read-only user gets a limited command set - read only plus
some test tools - while the admin user gets a full command set.
The Wireless Controller allows customers to store upgrade and rescue backup images to USB
Storage. The flash memory is hot-pluggable, i.e. user can plug in a USB device at any time, and it
will be recognized as additional storage for the Controller. Detection may take up 5 seconds and
automatically mounts the device i.e. /mnt/flash.
To protect the Flash file system, removal must be preceded by explicitly un-mounting the Flash card
through the GUI or the CLI. This is similar to Safely Remove Hardware for un-mounting USB
devices in Windows systems.
If there is a USB present, the GUI or the CLI will be able to access and utilize this extra space for
controller upgrade images as well as rescue backups.
When a user chooses option 1 from the main menu to perform a system restore, there is a choice
provided from the FTP server or from a USB device. The same choice is offered if a user wants to
create a backup image.
Note: For flash memory to be visible in the rescue mode, it must be plugged in before the system is
reboots.
The Enterasys Wireless solution optimizes distribution of the processing load between Access Points
(APs) and Wireless controllers to deliver exceptional performance while providing ease of
management. Complex, time-sensitive functions such as QoS, encryption, policy enforcement and
dynamic channel selection are handled by the AP, while global functions like configuration, roaming,
security management, and policy control are centralized at the wireless controller.
The Wireless Access Points Data Sheet is available on the Enterasys website at the following url:
http://www.enterasys.com/company/literature/wireless-ap-ds.pdf
WS-AP2610, 2620, 2650 and 2660 are not available for sale (End-of-Sale 12/09) but are currently
supported with limited features.
The Wireless Solution provides both Thin and Thick access points. Thin access points are
managed by the wireless controllers. Dynamic decision making (encryption, QoS, RF management)
is performed at the access point while the controller centralizes management and coordinates
control. Thick access points operate in standalone mode, independently of wireless controllers, with
most of the intelligence and management performed at the access point. The thick AP will only
share the same features as the other APs only after they have been converted to thin.
Most of the Enterasys Wireless Access Points are considered to be a hybrid between thick and
thin since they can be configured to operate with the best features of both types of AP technology.
For this reason, they are referred to as Fit APs since they can provide intelligence at the edge
(encryption, QoS, filtering, local VLAN integration), maintain their operation and configuration without
a controller, and still be controlled and configured from a central system.
Once the Wireless AP is registered with a Controller can be configured. Since the first process of the
of the Wireless AP is to register, we need to configure the Wireless AP Registration options. These
options define the properties that are used for the AP discovery Process.
The approval process by the Controller is defined by the Security Mode, which defines how the
controller will handle all unknown AP devices: Allow all Wireless APs to connect or Allow only
approved Wireless APs to connect (also referred as secure mode).
Allow all If the Controller does not recognize the serial number of the AP, a new registration record
is automatically created for the AP (if it is within the license limit), then the Controller will download a
default configuration to the AP. If it recognizes the serial number, it uses the existing registration
record to authenticate the AP and existing configuration record to configure the AP.
Allow approved - If the Wireless Controller does not recognize the serial number of the AP, the APs
registration record is placed in the pending state (if within license limits) until it is manually approved
by the administrator. If the Controller recognizes the serial number, it automatically approves the AP
and downloads the configuration for that Wireless AP. Once a pending AP is approved the default
configuration will be downloaded to the AP.
Note: During the initial setup of a large network, it is recommended to select the Allow all Wireless
APs to connect option. This option is the most efficient way to get a large number of APs registered
with the Controller.
If the Wireless Controller is configured for the security mode (Allow only approved Wireless APs to
connect) and it does not recognize the serial number of the AP, the APs registration record is placed
in pending state. The administrator is required to select the pending AP individually or by type and
then manually approve it.
The pending AP receives minimum configuration, which only allows it to maintain an active link with
the controller for future state change. The APs radios are not configured or enabled and pending
APs are not eligible for configuration operations (WLAN Service Assignments, default configuration,
radio parameters) until approved.
When an AP boots, it automatically begins the discovery process. This process serves two functions,
to obtain an IP address so it can access the network; and the second to search for the IP
address/name of the EWC to which it can authenticate and register.
The Wireless Access Point initially is configured to use the Dynamic Host Configuration Protocol
(DHCP) IP address configuration method. Once the AP is powered on it will broadcast a DHCP
request on the network to obtain an IP address. If there is no DHCP response after 60 seconds, the
AP reverts to its factory default IP address (192.168.1.20). When the Wireless AP returns to its
default IP address mode you can establish a telnet or SSH session with the Wireless AP. After the
Wireless AP waits for 30 seconds in this default state, it starts the discovery process again to acquire
an IP address from DHCP.
Note: If the AP has been previously registered with another Controller, it may have a static IP
address defined, in this case the DHCP method may be disabled and the AP may need to be reset.
Once the Access Point obtains its IP address it will then attempt to discover Controllers to which it
can register and authenticate or if the AP was previously configured, it will check its configuration file
for a known Controller and attempt the connection.
If this fails it will try to obtain a Controllers IP Address using the following methods in parallel:
DHCP Option 78 (SLP Unicast)
Domain Name Service (DNS),
DHCP Option 60/43
Layer 2 Multicast (SLP) if L2 has Multicast enabled (Multicast and IGMP snooping should be
enabled on the switch).
The discovery process will be repeated until an IP Address of a EWC is found and the AP is
approved and authenticated. (3 minute cycle)
Once the Wireless AP has discovered the controller addresses, it sends out connection requests to
each of them. These requests are sent simultaneously. The Wireless AP will attempt to register only
with the first which responds to its request.
When the Wireless AP obtains the IP address of the Wireless Controller, it connects and registers,
sending its serial number identifier to the Wireless Controller, and receiving from the Wireless
Controller a port IP address and binding key.
The Static Configuration settings assist in the setup of branch office wireless APs, which are typically
installed in remote sites, while the Wireless Controller is in a central office.
For IP Address Assignment, the DHCP option is enabled by default. This can be change to a static
configuration once the AP has been approved by the Controller.
The Wireless Controller Search List defines the static list of Controllers that will manage this
Wireless AP. The Wireless AP attempts to connect to the IP addresses in the order in which they
are listed during the discovery process.
Note: Once the IP Address Assignment (Static Values) or Wireless Controller Search List is modified
on the AP, this will interfere with the default discovery process. If it is necessary to recover from this
situation, you will need to reset the AP to its factory default settings.
The Wireless APs require the capability to interact in both the local site network and the central
network. To achieve this a static configuration is used. VLAN Settings allow you to assign an AP to a
specific VLAN ID. Untagged is the default option for each AP. However, if the AP is connected to a
port on a switch that is egress tagged only packets, the AP is then required to also be in that same
VLAN.
If tagging is required:
Connect the AP to the Wireless Controller or to the network point that does not require AP VLAN
tagging. Once the AP is registered and approved, use the Static Configuration setting on the AP to
enable the appropriate VLAN and define the VLAN ID. Save the configuration on the AP. The AP
reboots and looses connectivity to the Wireless Controller. Disconnect the AP and attach it to its final
network location. If the VLAN settings match the network configuration, the AP will register with the
Wireless Controller successfully.
If the AP VLAN is not configured properly (wrong tag VLAN ID), connecting to the AP may not be
possible. To recover from this situation, you will need to reset the AP to its factory default settings.
If the Controller is configured to Allow only approved Wireless APs to connect, when the Controller
receives AP registration requests the first two requests are ignored. This is to allow the AP to try
other controllers in the network in order to be accepted by another controller.
When an AP is in the discovery process it will send registration requests to all controllers that it is
aware of (obtained either by DHCP, DNS, or Multicast). A controller needs to receive 3 registration
requests in order to proceed with acceptance. In the logs above you can see that the controller
received 3 registration requests and then it authenticates and approves the AP.
When the AP goes into the pending mode it will wait for 5 minutes for approval and then it reboots
automatically. Once the AP is approved and authenticated the software version is checked and the
AP configuration is sent to the AP.
An alternative to the automatic discovery and registration process is to manually add a Wireless AP
to the Controller database. This allows you to configure an AP prior to the approval process. When
the AP connects to the Controller for approval, its configuration will be downloaded including radio
and WLAN Assignment.
An Access Point is connected to Controller for the purpose of receiving configuration, sending back
statistics and logs, forwarding authentication (EAP) traffic, DHCP requests and performing software
upgrades.
The connection between the Wireless Controller and AP is a User Datagram Protocol (UDP) based
tunneling protocol, called WASSP (Wireless Access Station Session Protocol) aka CAPWAP Tunnel
Protocolv2 (CTP), to encapsulate the packets and forward them to the Wireless Controller except
when the Virtual Network Services (VNS) is topology is configured for Bridged Locally at AP.
The CTP is also created between Wireless Controllers in a Mobility domain to allow wireless clients
to roam to Wireless APs on different Wireless Controllers.
The CAPWAP protocol (Control And Provisioning of Wireless Access Points) is currently pre-
standard and a working group on the IETF. More information is available at:
http://www.ietf.org/dyn/wg/charter/capwap-charter.html
V8.11 introduces the ability to enhance the security for the CTP tunnel between the AP and the
Controller by using IKEv2 and IPSEC. This will allow connection to traverse the public internet for
use cases such as remote/cloud site controller operation or management of remote branch sites.
IKE is the key exchange mechanism for the Virtual Private Network (VPN)s. ISAKMP manages the
exchange of cryptographic keys, used to setup a secure, authenticated tunnel between two Security
Gateways (SG) or in this case the Wireless Access Point and Controller. This tunnel is called an
ISAKMP Security Association (SA).
The Security Associations or Access Point will offer several ISAKMP proposals, these proposals will
provide the means for ISAKMP SA to agree on which encryption, the hash algorithm (SHA), and
which Diffie-Hellman exchange pair will be used to protect the IPSEC tunnel.
IKEv2 does not have a mechanism for fragmenting large messages (in the case of X.509
certificates).
Enable Secure Tunnel. Click to Enable or Disable secure tunnel. This feature, when enabled,
provides encryption, authentication, and key management for data traffic between the AP and/or
controllers.
Encrypt control traffic between AP & Controller - Supports encryption between an AP and Controller
and/or between APs.
Note: Secure tunnel can only be enabled when a V8.11 compatible AP is added to the network.
Secure tunnel must be disabled for APs running previous versions.
Choosing an AP Zone creates or selects a Policy Zone for the specified AP. The Zone identifies a
logical AP groups, which in turn can be used for location-based policy assignments. Location-Based
policy allows existing Wired customers using RFC3580 assignment to extend into the Wireless
Environment, as well as to deploy the same roles across all sites, while maintaining the specific
topology.
For more information on configuring Location-Based Policy see the VNS Configuration.
Wireless AP models that support external antenna configuration required selecting the Antennas
Type for the AP. The model of the selected Wireless AP determines the available antenna options.
If an antenna type is not selected the AP will transmit data with a reduced Tx Power on a limited
number of channels.
A table of AP2620/AP3620 approved certified external antennas are listed in the Wireless Controller,
Access Points and Convergence Software Users Guide, Appendix.
Note: The antenna you select determines the available channel list and the maximum transmitting
power for the country in which the Wireless AP is deployed.
The LEDs can be configured to provide a visual indication of status: Normal (default settings), Off,
Identify (active blinking), and WDS signal strength. The WDS signal strength enables installers to
adjust the antennas to obtain an ideal alignment to maximize signal strength. The setting defined for
the AP are also persistent when an AP is converted to a Sensor.
The AP Default Settings will allow modification of default values for any APs that are initially
registered to the Controller to simplify the process of adding new APs to an existing deployment. The
values that can be set as default include the WLAN assignments, static wireless configuration
options common to all Wireless APs, and then setting for specific APs, like the Wireless Outdoor AP.
Once an Access Point is approved, default values can be modified for that specific AP by selecting
the specific AP or using the Multi-Edit function. The AP settings that are explicitly configured override
the default values. After an AP is registered, any changes to the default values do not affect those
APs that have been configured.
The Default Common Configuration and AP Specific Configuration may play a significant role in
Availability/Mobility.
Once a particular AP has been configured with all the settings that it needs to be deployed system-
wide, these settings can be used as the default settings that are downloaded to newly registered
Access Points by using the Copy to Defaults feature on an individual AP Properties tab. The Reset to
Defaults function enables APs that are already registered to use the new default settings.
This feature allows you to configure your first AP, test to ensure that the settings are appropiate, then
copy the settings to the default values when satisfied. It is in this way that each new AP registered to
that controller will have these same settings. APs that are already registered can be deleted, so
when they re-register they can pickup the new default settings.
The Multi-edit function allows you to configure multiple Wireless APs simultaneously. To configure
multiple APs simultaneously you need to select the Wireless APs by Hardware Type, and then select
the Wireless APs that match the hardware type individually. You can also select multiple hardware
type and individual Wireless APs by pressing the Ctrl Key and selecting the hardware types and
specific Wireless APs. When setting values any box or option that is not explicitly modified or
attributes that are not common to a specific AP will not be applied.
Multi-edit becomes extremely useful for configuring the Poll-Timeout value on all APs that are
involved with Fast Failover Availability.
To disassociate a selected WLAN client from its wireless AP on an individual basis, check the
appropriate box in the client list and click Disassociate. You can search for a specific WLAN client by
MAC address, IP Address or User ID by selecting the search parameters from the drop-down lists
and typing a search string in the Search box and clicking Search. Once Disassociate is selected the
clients session is terminated immediately.
At this time, the Search function under Client Management/Disassociate does NOT support
wildcards. Select the expression in the drop-down box contains to have similar behavior as a
wildcard.
Clients can also be disassociated from the Active Clients by VNS and Active Clients by Wireless AP
Reports.
Enabling Use broadcast for disassociation in the Advanced AP Settings will cause an AP to
broadcast a message when disconnecting all clients instead of disassociating each client one by one.
This will happen if the following conditions are met: If the AP is preparing to reboot, fails over to
another Controller when using Availability without Fast Failover, enters one of the special modes
[(DRM initial channel selection), or Auto Selection (ACS)] or if a BSSID is deactivated or removed
from an AP.
The benefits to this option is that is improves roaming time for the clients, provides better
broadcast/multicast performance and enhances the overall user experience. The feature also solves
the problem where clients stay associated with an AP even if there is no true data connectivity with
the AP.
This is disabled by default.
In order to protect your wireless network, add a wireless device's MAC address to a Blacklist of
WLAN clients that will not be allowed to associate with the Wireless AP. The Blacklist is maintained
by the WC but pushed to the Access Points (AP) to block the client at the edge. The Enterasys
controller also allows you to manage the Blacklist by providing the Import or Export function for a list
of MAC addresses in text format.
Note: Blacklist are not shared between Controllers. In an Availability or Mobility Configuration you
must use the Import/Export feature to exchange Blacklist information.
The Access Approval screen displays all the registered Wireless APs and their status. Actions can
be performed on Wireless APs in specific states, such as Pending, Delete, Reboot, Release or
Approve.
Change Status to Pending AP is removed from the Active list, and is forced into discovery
Release Release foreign Wireless APs after recovery from a failover
Reboot Reboot the AP without using Telnet or SSH to access it
Delete Releases the Wireless AP from the Wireless Controller and deletes the Wireless APs entry
in the Wireless Controllers database
Convert to Standalone Mode Converts a thin 802.11n AP (AP3630/3640) to Standalone Mode
The primary function of Client Balancing and Load Balancing is to distribute clients across multiple
APs covering an open area, typical deployment scenarios are classrooms, conference halls, and
other densely populated wireless user areas.
This feature is AP centric. Therefore, the load balancing process is transparent to the client.
Load Group AP, Client Rebalancing:
It is possible a Radio may go into an Over-Loaded state, if the average load for the group drops. This
can occur when one or more radios is brought on-line and added to the group. In an Over-Loaded
state, a radio reduces its load by disassociating some clients.
The number of clients removed is the amount that will bring the radio down to the Loaded state. The
selection of clients to disassociate is based on the following rules:
First remove any inactive clients
Then remove clients with the lowest signal strength
Once a client is removed, it will not be allowed to re-associate with the same radio for a period of 30
seconds. This will cause it to roam to another radio with a lower load.
Radio Preference load group performs both Radio band preference steering and Radio load
control. Band preference steering is a mechanism to move 11acapable clients to the 11a radio on
the AP, relieving congestion on the 11g radio.
Load control is disabled by default. A radio load group executes band preference steering and/or load
control across the radios on each AP in the group. Each AP balances in isolation from the other APs,
but all APs in the load group have the same configuration related to the band preference and load
control.
An APs response to a client request is determined by the load state of the AP and the roaming state
of the client. An AP radio can be in one of the following load states: Under-Loaded, Balanced,
Loaded or Over-Loaded.
Load Balance Group Association Rules:
AP always responds to, and accepts clients that are currently associated with that AP regardless of
the load balance state.
In a Under-Loaded State, an AP radio will respond to all Probe Requests, and accept associating
clients that are new to the group or are roaming.
In a Balanced State, an AP radio will not respond to probe requests from roaming clients, and will
reject association requests from roaming clients by responding with a unsuccessful reason code of
17 (AP is unable to handle associated STAs) in the Association Response. It will only respond to
probes and accept associations from clients new to the group.
In an Loaded (max load reached) or Over-Loaded state, the AP does not respond to any Probe
Request, and will reject (reason code 17) all association requests from new or roaming clients. It will
continue to reject the client until the 5 minutes timer has expired then it will treat the AP as a new
Client.
Note: A client is considered to be roaming if it is associated with a load group member and is probing
or attempting to associate with another member of the same group
A load group is created by providing: the type of Load Group (Client Balancing or Radio Reference),
a unique name for the group, Radio and a WLAN assignment.
Radio Assignment Rules:

Radio are assigned by clicking the Radio Assignment tab, and selecting the radios from a list
Radios already assigned to a different load group than the one being configured will be
indicated with an asterisk.
Selection of this radio is possible. If selected, the radio will be automatically removed
from the group it was previously assigned to
Each radio can be assigned to at most one load balance group
Multiple radios on the same AP do not have to belong to the same group
WLAN assignment for the Load Group is required because in order for the load balancing or Radio
Preference algorithm to work, all radios in the Load Group should have the same VNSs. Assigning a
WLAN to a load group will automatically assign it to every radio in the group.
Once a radio is assign to a load group, WLAN assignment can only be done through the load group
configuration page. It will be disabled from all other WLAN assignment pages (namely Wireless APs,
VNS Configuration). WLAN assignment from the Load Groups configuration page will override any
previous WLAN assignment.
Removing an radio from a load group will result in the WLAN assignment being un-affected. i.e., left
as it was configured while a member of the load group. After the radio is removed, WLAN
assignment will be re-enabled from all WLAN assignment pages.
For a Radio Preference load group the WLAN must be assigned to both 11a and 11bg radios.
The Active Wireless Load Groups lists all load groups and active AP-radios in the groups.
Statistics provided for each load group are:

Number of radio members
Total number of clients for all radio members (Load Balancing Only)
Average load for the group (Load Balancing Only)
Statistics for each member of the group is displayed depending on the type of Load Group
(Client/Load Balancing or Radio Preference & Load Control).
Note: The returned column in the Load Control indicates the number of clients declined at the second
association attempt.
Load balance group statistics are reported on the foreign controller when APs fail over with load
groups from a different controller indicated with an (F) following the load group name.
Load control is disabled by default. A radio load group executes band preference steering and/or load
control across the radios on each AP in the group. Each AP balances in isolation from the other APs,
but all APs in the load group have the same configuration related to the band preference and load
control.
Radio preference can now enforce # of max clients in strict mode, once the limit is reached no
additional clients will connect.
SSH access can only be configured in the individual Wireless AP Properties tab. The SSH
infrastructure is used to replace the unsecured TFTP with secure FTP (SFTP).
When connecting to the AP via SSH or console the default Username = admin and the default
password depends on the specific unit and it could be either e~=2.718 or new2day.
Note: Telnet access only pertains to the 2600 series APs. Telnet access to the AP are disabled by
default once an AP has registered with the Controller. Telnet access can be enabled using the
individual Wireless AP Properties, AP Multi-edit and AP Default Settings tabs.
An AP that is configured as a sensor performs scanning services and relays information to the
Wireless Advanced Services (WAS) Server. When an AP is approved as a Sensor, the AP severs its
connection to the Wireless Controller, registers with the Wireless Advanced Services (WAS) Server
and then performs scanning services (the AP no longer performs RF services for the Wireless
Controller).
Before APs can be configured as sensors, information such as Sensor Platform, TFTP Server,
Directory and Filename must be set to downloaded the Sensor image to WC for the AP, from a TFTP
server.
Enterasys Real Capture allows on-demand collection of over-the-air traffic for troubleshooting and
problem resolution. RF performance or connectivity problems are very dynamic and Real Capture
gives administrators additional visibility into the RF environment for quicker problem resolution and
improved customer satisfaction. Real Capture provides this functionality on servicing APs eliminating
the need to deploy dedicated sensors for this purpose.
Click Start to start real capture server on the AP. This feature can be enabled for each AP
individually. Statistics are captured using an external connection to a Windows Wireshark client. The
default capture server timeout is set for 300 seconds and the maximum configurable timeout is 1
hour.
Captures statistics are found on the Active Wireless APs reports.
When enabled and active, Real Capture runs a daemon on the AP to allow interfacing with
WireShark. Real Capture uses ports 2002 and 2003 and puts the AP radio into promiscuous mode
(receives all packets on wireless).
Once the Real Capture has started on the Access Point, open the Wireshark application on the PC.
In Wireshark, select the Capture Options. Enter the remote AP IP address and Port and the remote
daemon port of 2002. and Null Authentication and then select OK.
Once saved the Remote interface information will be populated. Click Start in the Wireshark Capture
Options window, the AP wireless information will be displayed.
The AP captures all the wireless traffic except for management traffic originating from the AP
(Beacons, Probe Resp, ACK, Data Frame Retries).
Note: The captured traffic is decrypted.
The AP Inventory Report provides will a consolidated summary of all Wireless APs registered and
configured in your domain. The AP Inventory report can be exported and save as an XML file.
Access Point Tracing under the Logs and Reports allows messages to be displayed by component
for system debugging, troubleshooting, and internal monitoring of software.
Traces are combined into a single .tar.gz file and can only be viewed by saving the file to a directory
on your computer.
Periodically, the software used by the Wireless APs is altered for reasons of upgrade or security. The
new version of the AP software is installed from the Wireless Controller. Part of the Wireless AP boot
sequence is to discover and install its software from the Wireless Controller. The Controller has a
build-in TFTP Server that is used for software upgrade.
The Wireless AP keeps a backup copy of its software image. When a software upgrade is sent to the
Wireless AP, the upgrade becomes the Wireless AP's current image and the previous image
becomes the backup. In the event of failure of the current image, the Wireless AP will run the backup
image.
The AP Maintenance section allows you to configure how the APs will install their software either
using the software from the controlled upgrade or by a specific image, which overrides the controlled
software.
Always upgrade AP to default image allows for the selection of a default revision level (firmware
image) for all APs in the domain. As the AP registers with the controller, the firmware version is
verified. If it does not match the same value as defined for the default-image, the AP is automatically
requested to upgrade to the default-image.
To retrieve images not currently stored on the controller use the Download AP Images to retrieve an
image from a FTP server.
Note: The choice of upgrade method is important when running in an availability scenario. Failover
response time can be delayed if an AP is required to be upgraded when it registers on the foreign
controller.
The Controlled Upgrade tab is displayed in the AP Maintenance tab only when the Upgrade Behavior
is set to Upgrade when AP connects using settings from Controlled Upgrade. Administrators decide
the version of software release that the Access Point should be running.
The Controlled upgrade allows you to individually select and control the state of an AP image
upgrade: which APs to upgrade, which image to upgrade to or downgrade to and when the upgrade
should be performed. When performing a bulk upgrade of Access Points the controller will perform
the upgrade in groups of 10-15 Access Points at a time.
Note: The system will prevent the wrong software being applied to the wrong platform. In the case of
forced upgrade, the correct image will be sent to the appropriate hardware platform.
The HWC:Logs shows the AP discovery process and the Wireless AP boot sequence. When the AP
registers with the controller, the firmware version is verified. If it does not match the value defined for
either the default-image the AP is automatically requested to upgrade to the correct image.
For NetSight management, the WC must have the appropriate SNMP configuration. Log into the web
management interface, under the Wireless Controller configuration, select the SNMP link on the left.
Select the appropriate mode at the top of this view to use either SNMPv1/v2c, or SNMPv3. If
SNMPv3 is used, select the Add User Account button and enter in v3 credentials in the dialog box
that appears. The same credentials will be used on the Enterasys NMS setup.
The controller supports Local or RADIUS Authentication mode to authenticate users that will have
access to the GUI and CLI. Wireless Manager uses the controllers CLI to retrieve required
information and to configure the managed controllers.
The first step to integrating Wireless Controller into NetSight is to Launch NetSight and integrate the
existing infrastructure device into NetSight Console via SNMP V3. It is critical that NetSight Console
is able to management all network devices involved in the lab network.
Begin by launching the NetSight Console application. Open a WEB browser directed to the following
URL:
http://<Netsight_Server_IP_Address>:8080
Select the Console link from the launch page to start NetSight Console and login.
In NetSight Console, the administrator must first define the SNMP & CLI (SSH) credentials, and then
define a Device Access Profile which uses those credentials. Access the Authorization/Device
Access component of NetSight to define these items.
Clicking on the Profiles/Credentials Tab will display the Credential information for SNMP and CLI.
The initial discovery of the Controller requires SNMP Credentials to be configured.
Create the CLI Credentials; the CLI credentials are associated to the device to retrieve required
information and to configure the managed controller.
When configuring CLI Credentials for Enterasys Wireless Controllers, you must add the username
and password Login credentials for the controller to the Add/Edit Credential window in order for
Wireless Manager to properly connect (SSH) to the controller and read device configuration data.
The Login password must be added to the Configuration password field instead of the Login
password field. The username and Configuration password specified here must match the username
and Login password configured on the controller.
Profiles are assigned to device models in the NetSight database. They identify the credentials that
are used for the various access levels when communicating with the device. When configuring
profiles for Enterasys Wireless Controllers, you must make sure that controllers are discovered using
an SNMPv2c or SNMPv3 profile. This profile must also contain SSH CLI credentials for the
controller. Wireless Manager uses the controller's CLI to retrieve required information and to
configure managed controllers.
Model the WC in the new domain by selecting Network Elements tab, then right click on the My
Network folder and then select Add Device. In the Add Device view, the administrator must
associate the proper profile to use for the Device. Enter the IP address of the WC and select the
proper profile.
Note: The SNMP Context is optional, if used in the Add Device window it MUST have been
configured in the SNMP parameters on the Wireless Controller.
Once the Device is added it will be displayed in the Details View, a green alarm icon next to the
device indicates that NetSight has been able to contact the WC (via SNMP).
The Inventory Manager is designed to automate a few particularly important tasks of Network
Management. The Enterasys Wireless Controller supports Configuration Downloads/Uploads (FTP
or SCP), and Timed Resets using NetSight Inventory Manager.
TFTP is packaged with the NetSight Server, but to perform Configuration Downloads on the Wireless
Controller you need to add your own unique FTP/SCP server.
The Inventory Manager options for FTP & SCP points to the local file system that NetSight installed
C:\tftpboot directory. Modify this screen to point to the IP address and location of the directory will
store Configuration files.
If you are using an FTP server on a remote system, use the Universal Naming Convention (UNC)
when specifying the root directory path. The UNC convention uses two slashes // (UNIX or Linux
systems) or backslashes \\ (Windows systems) to indicate the name of the system, and one slash or
backslash to indicate the path within the computer. For example, on a Windows system, instead of
using h:\ (where h:\ is mapped to the tftpboot directory on the remote drive) use
\\yourservername\tftpboot\
Each individual Controller needs the File Transfer Method changed from the default method of TFTP.
Archive Wizard will create the initial Archive Management information, this data can be modified
afterwards in the Archive Management tab.
Use the Reset Device Wizard to reset a single device, multiple devices, or even multiple device
groups. The Reset Device Wizard allows you to reset devices that support Timed Reset as well as
those devices that do not. Timed Reset gives you the flexibility to schedule your reset operation, so
that the actual device resets take place at a later time.
The Enterasys Wireless Controller supports both Initial and Delay reset.
NetSight OneView provides access to critical network information: web-based reporting, network
analysis, troubleshooting, and helpdesk tools.
The OneView wireless dashboard streamlines network monitoring with consolidated status of all the
devices and drill down ability for more details. State-of-the-art reporting provides historical and real-
time data for high level network summary information and/or details. The reports and other views are
interactive allowing users to choose the specific variables they need when analyzing data. Web-
based FlexViews enable real-time diagnostics.
OneViews search functionality is a powerful diagnostic tool. End systems are searchable by port,
MAC address and IP or IP/Port. The results page provides an interactive topology map consolidating
all the data sources available for that location such as performance data and network access control
data.
You can shorten or extend the period of time for which OneView will keep statistics by changing the
polling interval. By default, OneView polls your devices and interfaces every 15 minutes. You can
shorten this period for a more dynamic view of your network, or lengthen this period to extend
OneView's historical storage capability over a longer period of time.
OneView supports reporting on 20,000 objects as determined by the number of devices and
interfaces being monitored, along with polling interval and data storage periods.
The OneView Engine Advanced Settings window allows you to set your Data Archiving, Data
Aggregation, and Session Limits parameters.
OneView can be launched directly from the NetSight launch page of from any NetSight Component
by select OneView from the Applications menu bar.
The Reports tab offers you historical and real-time reporting, including both high-level network
summary information and detailed reports and drill-downs. The Reports displays a catalog of reports
that can be used to manage your Wireless deployment.
Console - The Flow Dashboard report provides Top N flow information by application, clients, server,
connected clients, and connected servers. The NetSight Dashboard report provides summary
NetSight data including top interfaces, AP Clients, AP Bandwidth and Netsight host statistics. Host
data is collected from network devices that support the Host Resource MIB, such as NetSight
appliances, Linux systems, and Windows PCs.
Devices The Device reports provides information on Wireless Controller, NAC Gateway alarms and
over devices resources (memory, CPU, disk usages) where applicable.
Custom Historical report that is fully customizable based on: APs, Controllers, interfaces,
timeframes and more.
Identity and Access Dashboard Providing an overview of end-system connection information.
Identity and Access System Providing system-level information for appliances and end-systems.
Wireless - A collection of summary reports providing information on your wireless network
components, including reports for AP groups, controllers, and mobility zones. Wireless reports also
provide data on wireless components ranked by bandwidth and clients, such as top APs by
bandwidth and top controllers by clients, as well as reports on APs and controllers that are down.
OneView reports include the following features (depending on the report selected):
CSV Export - Save report data to a CSV file to provide report data in table form.
Drill-down for Details - Link to summary reports containing more detailed information. For example,
in the Controller Summary report, clicking on a controller shows a detailed report for that controller
over time.
Interactive Tables - Manipulate table data in several ways to customize the view for your own needs:
Click on the column headings to perform an ascending or descending sort on the column
data.
Hide or display different columns by clicking on a column heading drop-down arrow and
selecting the column options from the menu.
Filter, sort, and search the data in each column in the table.
Interactive Charts - Use data-point rollovers for quick information on chart data. For example, in the
Controller Summary report, rolling over the value reported for Bandwidth provides additional
bandwidth statistics over time.
Sparkline Charts - View network trends in dense, succinct charts that present report data in an easy
to read, condensed format. A quick way to catch possible problems areas to be drilled into. Rollover
charts for additional information.
OneView provides you with the Custom report a powerful tool that allows you to create a historical
report with fully selectable parameters including Target, Statistic, and Data Options. Choose the
report target such as APs, controllers, or interfaces, as well as the statistics to report on, timeframes,
and field type. For example, you could use an Custom report to view historical utilization data on a
specific AP over the past month.
You can display your reports either as a chart or table. Each report you create can be bookmarked
for easy viewing at a later time or to share with others. Report data can also be exported to a CSV
file.
The Wireless Reports folder under the Reports sub-tab contains 15 different reports you can use to
gain information about the current state of your Wireless deployment.
Build-in PDF reports, generate summary reports of your current network configuration in PDF format
including a Console Report, Inventory, Identity and Access, Wireless Configuration, and Default
Policy Domain Report. These reports can be saved or sent to other users in the organization.
For convenience, most of the reports specified in the Reports Catalog can also view from their
respective toolbar tab.
To generate the Wireless Configuration Report PDF, click on Reports>PDF Reports, then select the
desired Reports. OneView opens your Wireless Configuration Report PDF in a new browser window.
The report contains complete information on your configurations by:
Summary
Controllers By Mobility Zone
Controllers
Radios Summary
Virtual Networks
Access Point Groups
Access Points
The Search tab provides a primary entry point for viewing PortView data. A device must be in the
NetSight Console database, or it must be a client of a device in the database for the function to work
properly. The search can be performed using a full MAC address, IP address, hostname, AP serial
number or username. Depending on the type of item that is being searched, the secondary
navigation bar will display one or more PortView tags, with information pertaining to the searched
item.
The Overview tab displays the physical topology for the information selected. By Right-clicking on the
different devices in the topology additional reports will be displayed.
Note: For client device information, client statistics must be enabled for the device.
Enable Interface Statistics Collection
To view OneView interface reporting data, you must enable statistics collection for your device
interfaces from either the OneView Devices tab, or the Console Port Properties tab or Interface
Summary FlexView.
In the OneView Devices tab, click on the device IP address link to open the Interface Summary
FlexView.
In the FlexView, right-click on one or more interfaces and select Collect Interface Statistics.
OneView will begin collecting data on the selected interfaces to use in its reports.
In the Console Port Properties tab or Interface Summary FlexView, right-click one or more interfaces
and select the OneView > Collect Interface Statistics, and enable collection. OneView will begin
collecting data on the selected interfaces to use in its reports.
With any of the OneView tables columns can sorted, move in a different order and customized. To
sort events on a specific column, click the drop-down arrow next to the column title and choose Sort
Ascending or Sort Descending. To move a column, click and drag it to the position you want it to
occupy in the table.
To filter results by a specific value, click the down arrow by the title of the column that contains the
information upon which you wish to filter. Click Filters and enter the value for which you are
searching. The Show Filters link will display the filters that have been applied to the search. The
Reset link on the bottom of the screen will remove all formatting and filters that have been applied.
Note: The Filter parameters will depend on the Column that is selected during the filter process.
The Alarm/Event tab display the current Alarms from all the managed devices in your network. You
can sort and filter relevant information for network troubleshooting and forensics. Use the drop-down
menu to display links to event logs by Event Type, i.e. NAC, Wireless. These Alarms and Events are
the similar to the events can be seen on the actual device, e.g. HWC: Events.
The OneView Wireless tab provides details, dashboards, Individual Reports, Client Event History and
Rogue APs, information to help you monitor the overall status of your wireless network.
The Wireless Dashboard displays a selection of reports that provide highly summarized information
about the wireless network. Use the Dashboard to get a quick overview of wireless data including
associated clients by controller, bandwidth by controller, top 10 APs by aggregate bandwidth, top 10
SSIDs by client count, Wireless Manager events, and a controller summary report. Interactive charts
allow administrators to display data over various time periods using various data rollups.
Controllers by Associated Clients - This report shows the average number of associated clients and
the percentage of total clients per controller, on an hourly and daily basis.
Controllers by Bandwidth - This report shows the average bandwidth (in bytes) and the percentage of
total bandwidth per controller, on an hourly and daily basis.
Use the drop-down menus to select the date, and whether to display Daily, Hourly, or Daily
to Raw data. Rest your mouse on the different pie slices to see a rollover that presents chart
data. Click a pie slice to see hourly data (for the Daily option) or raw data (for the Hourly and
Daily to Raw options) in graph format.
Wireless Manager Events - This report shows the last ten Wireless Manager Events. Click on the
column headings to filter and sort the events.
Controllers Summary - This report lists summary information for each controller. Click on the
Controller link to open a more detailed Controller Summary report in a new browser tab.
APs by Aggregate Bandwidth - This report lists the top ten APs by aggregate bandwidth, on an
hourly or daily basis.
SSIDs by Client Count - This report lists the top ten SSIDs by client count, on an hourly or daily
basis.
Use the drop-down menus to select the date, and whether to display Daily or Hourly data.
Reports are flexible and interactive allowing you to configure time ranges and data rollup values to
use for each report. The reports on the Wireless tab give you the same search and filter capabilities
as the reports on the Events Log tab do, to narrow down the data shown in the report tables. Click on
links in the reports to quickly drill down to more detailed information. In addition, some information
can be exported to CSV files to provide wireless data in table form.
Use the left panel tree to drill in a particular view.
The Details tab presents a top-level wireless network summary report along with additional reports
on wireless mobility zones, virtual networks, controllers, and AP groups. These context sensitive
reports include data-point rollovers and drill-down links to additional detailed reports, as well as the
ability to launch local management. Reports are presented in a familiar wireless component tree
structure similar to how components are displayed in Wireless Manager. Clicking on any node in the
tree will provide contextual information for that node. Use the Discover button at the bottom of the
tree panel to perform a discover operation that will look for any configuration changes on your
wireless controllers that have device statistics collection enabled. In addition, you can also use the
Discover button to rediscover a single controller. Select the controller in the tree, click the down
arrow next to the Discover button and select Discover Controller.
The Individual Reports tab provides data on wireless components ranked by bandwidth and clients,
such as top APs by bandwidth and top controllers by clients.
The Top Controllers by Clients report allows you to assess the relative client load on the controllers
in your network. The top section of the report allows to specify a time range to see the total number
of Clients and the top remote show the Client history based on the time frame that was selected
Other report scan be especially helpful when you suspect insufficient coverage exists in a heavily-
used part of your network, such as Top APs by Bandwidth.
Other Top N reports include summary reports for AP groups, controllers, and mobility zones, and
reports on APs and controllers that are down. For convenience, you can also view these reports from
the Reports tab.
The Client Event History tab shows all add, delete, and update events for clients on the wireless
network. Events are triggered by:
Client session start and end
Inter-AP roaming
IP address change
Authentication state change
Information such as bandwidth, RSS (signal strength) and packet statistic for the client will be
displayed.
Click on a client MAC address link to open a Client History report displaying bandwidth, RSS, and
packet statistics for that client. From the Client History window, you can click a button to
launch PortView, AP Summary or AP PortView for that client.
Note: In order for OneView to populate Client Event History, client data collection must be enabled.
The Access Points tab display summary information for all the Access Points on your wireless
network. Click on a single AP name link to open an in-depth AP Summary view for the selected AP.
Click on an AP status Icon to open a table listing the current alarms for the AP. Right-click on a single
AP to access a menu of AP reports.
380
OneView lets you create maps of the devices and wireless access points (APs) on your network.
Begin by selecting background image to serve as a map, such as a building or floor plan, and then
position your managed devices and wireless APs on the map.
The Maps tab Search Field can be used to locate a wireless client, if the client is connected to an AP
that has been added to a map. Enter a MAC Address, IP address, hostname, user name in the map
Search box and press Enter to start a search for a wireless client. The search uses RSS-based
(Received Signal Strength) location services to locate the wireless client and display the approximate
location of the client on the map. The map containing the AP will be displayed centered on the AP,
with a circle showing the possible area where the client would be located.
381
The Threats tab shows devices that have been detected by the Radar WIDS-WIPS system as threats
to the wireless network. The recognized threat type include:
Ad Hoc Device
Cracking
Denial of Service attacks
External Honeypot
Interference Source
Internal Honeypot
Performance
Prohibited Device
Spoofed AP
Surveillance
The data collection options for the Threats report are access from the Console OneView collector
options, under Client History and Threat options.
The Administration tab provides tools to monitor and maintain the OneView application and its
components, along with troubleshooting and diagnostic information.
Verify that the Configuration password in the CLI Credential being used for this device is properly
configured.
From NetSight Console, access Tools > Authorization/Device Access > Profiles/Credentials Tab.
Select the CLI Credentials sub-tab. Select the CLI Credential being used by the controller's Profile,
and click Edit. Verify the user name and password being used in the credential. For wireless
controllers, the Login password must be added to the Configuration password field instead of the
Login password field. The username and Configuration password specified here must match the
username and Login password configured on the controller. Verify the SSH connection type is
selected. Click OK.
Use this CLI Credential in the controller's Profile.
NOTE: When configuring profiles for Enterasys wireless controllers, you must make sure that
controllers are discovered using an SNMPv2c or SNMPv3 profile. The profile must also contain SSH
CLI credentials for the controller. Wireless Manager uses the controller's CLI to retrieve required
information and to configure managed controllers.
Verify that the following ports are accessible through firewalls for the NetSight Server and Wireless
Controllers to communicate:
SSH: 22
SNMP: 161, 162
Langley: 20506
Admin Mode Select On to enable the radio; select Off to disable the radio.
Radio Mode (Radio 1) Click one of the following radio options:

a Click to enable the 802.11a mode of Radio 1 without 802.11n capability.
a/n Click to enable the 802.11a mode of Radio 1 with 802.11n capability.
nstrict Click to enable the 802.11a mode of Radio 1 with 802.11n strict capability
Radio Mode (Radio 2) Click one of the following radio options

b Click to enable the 802.11bonly mode of Radio 2. If selected, the AP will use only 11b (CCK)
rates with all associated clients.
g Click to enable the 802.11gonly mode of Radio 2.
b/g Click to enable both the 802.11g mode and the 802.11b mode of Radio 2. If selected, the AP
will use 11b (CCK) and 11gspecific (OFDM) rates with all of the associated clients. The AP will not
transmit or receive 11n rates.
g/n Click to enable both the 802.11g mode and the 802.11nb mode of Radio 2. If selected, the AP
will use 11n and 11gspecific (OFDM) rates with all of the associated clients. The AP will not transmit
or receive 11b rates.
When thinking about RF considerations some of the most common items come in mind: Transmit
Power, Antenna Type, Environment and Frequency. These all can effect the operation of your
wireless network. Transmit Power is directly related to the distance the signal travels. Antenna Type
affects range: the tighter beams transmit farther, omni-directional beams reduce the range. The
Environment, wind can alter the position of the antenna thereby degrading the signal, and rain, snow,
hail, and fog can attenuate a 2.4 GHz signal by as much as 0.08dB per mile and a 5 GHz signal by
as much as 0.8dB per mile. Frequency is also a factor; a 2.4 GHz system can reach farther than a 5
GHz system.
The Dynamic Radio Management (DRM) functionality on the Wireless Controller is used to help
establish the optimum radio configuration for your Wireless APs so that it can adapt to environment
changes. DRM will automatically adjust the transmit power levels to balance coverage between
Wireless APs assigned to the same RF domain. This functionality will scan and coordinate with other
Wireless APs to select an optimal operating channel to ensure connectivity for all clients and thereby
increasing network reliability.
The DRM feature consists of three major components: Auto Channel Section (ACS), Dynamic
Channel Selection (DSC) and Auto Tx Power Control (ATPC)
Note: Dynamic RF functions do not replace a proper site survey; they enhance the ability of a
properly designed site to adjust minor changes in its environment.
RF Domain Type a string that uniquely identifies a group of APs that cooperate in managing RF
channels and transmission power levels. The maximum length of the string is 16 characters. This
parameter can be configured on each individual AP or Multi-edit or AP Default Settings screen.
Typically, APs will be placed in separate RF Domains based on building, floors, or specific areas
during the RF planning.
Admin Mode Select On to enable the radio; select Off to disable the radio.
Radio Mode (Radio 1) Click one of the following radio options:

a Click to enable the 802.11a mode of Radio 1 without 802.11n capability.
a/n Click to enable the 802.11a mode of Radio 1 with 802.11n capability.
nstrict Click to enable the 802.11a mode of Radio 1 with 802.11n strict capability
Radio Mode (Radio 2) Click one of the following radio options

b Click to enable the 802.11bonly mode of Radio 2. If selected, the AP will use only 11b (CCK)
rates with all associated clients.
g Click to enable the 802.11gonly mode of Radio 2.
b/g Click to enable both the 802.11g mode and the 802.11b mode of Radio 2. If selected, the AP
will use 11b (CCK) and 11gspecific (OFDM) rates with all of the associated clients. The AP will not
transmit or receive 11n rates.
g/n Click to enable both the 802.11g mode and the 802.11nb mode of Radio 2. If selected, the AP
will use 11n and 11gspecific (OFDM) rates with all of the associated clients. The AP will not transmit
or receive 11b rates.
Auto Channel Selection (ACS) ACS provides an easy way to optimize channel arrangement based
on the current situation in the field/RF. ACS provides an optimal solution only if it is triggered on all
Wireless APs in a deployment. ACS only relies on the information observed by the Access Points at
the time it is triggered.
ACS is triggered by a configuration change to the Request New Channel drop-down list, but it can
also be triggered by one of the following events:
A new Wireless AP registers with the Wireless Controller and the AP Default Settings channel is set
to Auto
A user selects Auto from the Request New Channel drop-down list on the Wireless APs radio
configuration tabs
A user selects Auto from the Channel drop-down list on the AP Multi-edit screen
Dynamic Channel Selection (DCS) is enabled in active mode and the DCS threshold is exceeded
A Wireless AP detects radar on its current operating channel and it employs ACS to select a new
channel.
When triggered, the AP will scan all available channels for that mode and select the best channel.
Once a Wireless AP has selected a channel, it will remain operating on that channel until the user
changes the channel or triggers another ACS. ACS will not occur during a power cycle or when
rebooting the AP.
ACS can be configured using the AP Multi-edit screen to ensure that all APs in the RF Domain are
configured consistently. When ACS activated on multiple Access Points, the APs will directly
synchronize and cooperate in the process of selecting channels. ACS can also be enabled on each
AP and radio individually, but it is highly recommended to enable it for all APs in a common area.
Once ACS is set, those values can be used in the AP Default Setting to specify a specific channel or
the Auto selection for new APs.
Note: Remember when making changes that ASC is triggered when making the change in the Multi-
edit or default page.
Channel Plan - If ACS is enabled, you can define a channel plan for the Wireless AP. Defining a
channel plan allows you to limit which channels are available for use during an ACS scan. For
example, you may want to avoid using specific channels because of low power, regulatory domain,
or radar interference. Depending on the radio used, you can either create your customized channel
plan by selecting individual channels or you can select a All Non-DFS Channels.
Note: Most US based clients will not support the new DFS channel ranges in the 802.11a bands. It is
suggested that the Channel Plan be changed from the default All Channels to All Non-DFS-
Channels.
You can use the channel plan to avoid transmission overlap on 40MHz channels of the Wireless
802.11n APs. To avoid channel overlap between Wireless 802.11n APs that operate on 40MHz
channels, configure the channel plan for the 5GHz radio band as follows: 36, 44, 149, and 157 or 40,
48, 153, and 161. This solution limits the available channels to half of the available channels. If using
half of the available channels is not an option for your environment, do not configure a channel plan.
Instead, allow ACS to select from all available channels.
Channel Plans are supported on all Radio types a/b/g/n.
DFS = Dynamic Frequency Selection
On Radio 2 you can either create your customized channel plan by selecting individual channels or
you can select a 3 or 4 channel plan.
3 Channel Plan ACS will scan the following channels: 1, 6, and 11 in the US, and 1, 7, and 13 in
Europe.
4 Channel Plan ACS will scan the following channels: 1, 4, 7, and 11 in the US, and 1, 5, 9, and 13
in Europe.
Auto ACS will scan the default channel plan channels: 1, 6, and 11 in the US, and 1, 5, 9, and 13
in Europe
Using the 3-Channel Plan ensures that Access Points that are located near each other will use one
of the non-overlapping channels which will reduce the effects of interference.
Auto Tx Power Control (ATPC) - ATPC guarantees that your LAN has a stable RF environment by
automatically adapting transmission power signals according to the coverage provided by the
neighboring Wireless APs. ATPC can be either enabled or disabled. ATPC is enabled separately
from ACS and/or DCS and works independently on each AP. Therefore, it does not trigger changes
on its neighbors. ATCP can significantly improve the reliability of the wireless network to compensate
for obstructing objects installed in a room or if an AP goes out of service.
Each Wireless AP with ATPC enabled will look at the closest (in terms of RF attenuation) Wireless
AP operating on the same channel with ATPC enabled, and will adjust Tx power depending on the
attenuation toward the closest Wireless AP.
Auto Tx Power Ctrl Adjust If you have an RF plan that recommends Tx power levels for each
Wireless AP, compare the actual Tx power levels your system has assigned against the
recommended values your RF plan has provided. Use the Auto Tx Power Ctrl Adjust value to
achieve the recommended values.
Note: ATPC should be disabled on the backhaul of the WDS and Mesh Network.
When you disable ATPC either on a per AP basis or by using the Multi-edit, you can elect when
prompted to maintain using the current Tx power setting ATPC had selected.
If you elect to maintain using the ATPC power setting from an individual Wireless AP edit screen, the
displayed Current Tx Power Level value becomes the new Max Tx Power value for that Wireless
AP.
If you elect to maintain using the ATPC power setting from the AP Multi-edit screen, for every
Wireless AP the Current Tx Power Level value in the database is used to set the Max Tx Power
value.
If you elect not to maintain using the ATPC power setting, the current Max Tx Power value is applied.
Note: When maintaining the current displayed Tx Power, it may be outdated with respect to the Tx
power used by the AP (since the last refresh or 30 sec.)
Dynamic Channel Selection (DSC) detects when the current channel becomes unusable due to
traffic load or noise levels that exceed the configured DCS thresholds, it sends an alarm and/or run
Automatic Channel Selection (ACS) to find another channel. It will not trigger changes on neighbor
APs. Usually a channel becomes unusable due to excessive 802.11 traffic and non-802.11
interference or noise. The Channel congestion and Noise exceeds thresholds limits are user defined
and the measurements are averaged over a user defined period (default 5 minutes).
DCS can operate in three modes:
Monitor - When DCS is enabled in monitor mode, if the traffic load or noise levels exceed the
configured DCS thresholds, an alarm is triggered and a log event (major) is generated. The DCS
monitor alarm is used for evaluating the RF environment of your deployed Wireless APs. If
Spectrum Analysis is enabled the Alarm will include the type and the frequency of the detected
source.
Active - When DCS is enabled in active mode, if the traffic load or noise levels exceed the configured
DCS thresholds an alarm is triggered and a log event (info) is generated. In addition, the Wireless AP
will cease operating on the current channel and ACS is employed to automatically select an alternate
channel. DCS will not trigger channel changes on neighboring Wireless APs.
Off DCS is disabled (default setting).
If DCS is enabled, DCS statistics can be viewed in the Wireless Statistics by Wireless APs display.
The AP36xx have three antennas: Left, Middle and Right. By default, transmission is performed on
all three antennas. However, you can restrict the Tx and Rx on a particular selection of antennas.
The Transmit Power calculation takes into consideration the number of antennas selected for
transmission.
Note: Any changes to the Antenna selection will cause the radio to reset.
Enhanced Rate Control provides a way to improve roaming behavior of the clients that do not
perform background scanning. It is interesting to note that most of the currently available clients
behave this way. Such clients would start scanning for a new access point only when the connection
with the current Access Point degrades so much that there is no actual connectivity even with the
minimum rate (1Mbps of 11b/g/n or 6Mpbs for 11a/n), hence the phrase sticky.
A sticky client may stay associated with a remote AP at the minimum rate even if it is brought
centimeters away from another fully operational AP. This affects the performance not only for that
client but also for other clients because of the poor use of the shared wireless bandwidth.
Modifying these settings can also be used to improve broadcast and multicast performance as these
traffic types are transmitted at the minimum basic rate. By setting the Min. Basic Rate (the minimum
data rate that must be supported by all stations in a BSS) to 2Mbps, when the rate reaches the
Minimum Basic Rate - in this case, 2Mbps - the client will be forced to search for a new AP. The
setting thereby forces the client to roam sooner that it would normally.
Multicast packets as seen with the use of Apple Bonjour protocol are sent using the lowest data rate
from the Access Point and received by all clients associated to the WLAN SSID without
acknowledgement. Therefore if the client doesnt receive the packet there are no retries. The
Multicast Settings can be used to optimize the delivery of traffic by converting the Multicast to
Unicast delivery and using the buffers to prioritize mcast packets for clients in Power Save (PS)
mode. The actual decision to convert Multicast to Unicast is based on consumed air time, where if
the air time consumed by the Multicast packets is more than air time consumed by the Unicast to
each client, multicast packets are converted to unicast.
Note: Conversion will not be performed with >30 clients on a given radio.
The Adaptive Rate for Multicast when enabled determines the minimum Tx rate per radio. The is
based on the capability of the clients that are connected to the radio, i.e. if all clients can supports
11n rate, the multicast and broadcast packets will be send as 11n rate. If all the client rates are low,
the AP will use the minimum basic rate.
Another feature of the Enterasys wireless solution includes Transmission Power Control (TPC),
Report and Power Constraint in Beacons and Probe Responses, the AP replies to TPC Requests
from clients with TPC Reports. The TPC Report helps 11h clients to operate properly and when
combined with power reduction the Power Constraint allows the 11h client to adjust their power to
match the AP thereby reducing the noise. Clients must support this feature to work properly.
Enable 11h support - Select to enable TPC (Transmission Power Control) reports. By default, this
option is disabled. It is recommended to enable this option.
Apply power reduction to 11h clients - Select to enable the AP to use reduced power (as does the
11h client). It is recommended to enable this option.
IEEE 802.11h-2003, or just 802.11h, refers to the amendment added to the IEEE 802.11 standard for
Spectrum and Transmit Power Management Extensions. It solves problems like interference with
satellites and radar using the same 5 GHz frequency band. It was originally designed to address
European regulations but is now applicable in many other countries. The standard provides Dynamic
Frequency Selection (DFS) and Transmit Power Control (TPC) to the 802.11a MAC. It has been
integrated into the full IEEE 802.11-2007 standard.
DFS ensures that channels containing radar are avoided by an Access Point (AP) and energy is
spread across the band to reduce interference to satellites. TPC ensures that the average power is
less than the regulatory maximum to reduce interference to satellites.
The 802.11 station periodically performs scan operations to detect basic service set (BSS) networks
that are within radio range of the network interface card (NIC).
When scanning, the 802.11 station detects a BSS network by receiving 802.11 Beacon or Probe
Response frames transmitted by an access point (AP) or peer station. The Beacon and Probe
Response frames contain information elements (IEs) to advertise their capabilities such as a service
set identifier (SSID), which identify the BSS network, network name, cryptographic capabilities and
rates. The 802.11 station will use these IEs when performing a connect or roaming operation.
Process client IE requests when enabled the AP accepts the IE requests sent by clients via Probe
Request frames and respond by including the requested IEs in the corresponding Probe Response
frames. This is useful for compatible clients to retrieve IEs that are not included in Probe Responses,
i.e.. DTIM IE. By default this option is disabled and it is recommended to enable this option.
A Virtual Network Service (VNS) provides a binding between Topologies, Class of Service, Policies
and WLAN Services for WLAN devices. These unique set of components can be created
independently but are only applied to the WLAN connection when defined in an active VNS
configuration.
These unique sets of policies that are applied to the WLAN connection include but are not limited to
the following:
Topology (Routed, Bridge Locally at Controller, Bridge Locally at AP, Multicast filtering, Exception
Filtering, Layer 3 addressing and Layer 3 services; DHCP, Next Hop Routing)
Class of Service: Ingress / Egress Rate Profiles, 802.1p, IP DSCP/TOS , Transmit Queues
Policies (Filter Rules, CoS, and Topology)
WLAN Services (Authentication (802.11i/802.1x, PSK, open, CP, external CP), Encryption Methods
(802.11i/AES, WPA, WEP), Radio Information (SSID name, IE types, .11h, suppression), QoS
(802.11e/WMM, U-APSD and Flexible Client Access)
Topology defines the traffic behavior for the VNS, answering the question of how the data is going to
be transferred between the Wireless Client or Mobile Unit (MU) and the rest of the network. The
topology (Routed, Bridge Locally at Controller, Bridge Locally at AP) decision will depend on the
current network.
Consideration must be taken when implementing a VNS. For example, Guest Network access via a
routed or bridged locally at the controller topology allows traffic to be tunneled to a single controller to
by-pass the core network and be deposited in the DMZ. Another consideration is the location of the
users and the number of controllers in the deployment. For example, for wireless access in a remote
site it does not make sense to tunnel all the traffic to a central controller and then back to a remote
site. A bridged at AP topology makes more sense in this situation.
The IP Range for a Routed VNS topology normally is different from the IP addressing of the wired
network connecting the AP and the Controller. Thus, all Routed VNS packets are encapsulated and
transmitted over the CTP tunnel to/from the AP to the Wireless Controller. For a better
understanding it works similar to a VPN tunnel.
A VNS port/virtual interface is created automatically on the Wireless Controller when a new L3 IP
address is defined for a topology and selected in a Policy.
Each VNS is independent to each other VNSs. VNSs are not routable between each other within the
controller. Therefore, in a Routed VNS environment you must either configure the controller to
participate in Dynamic Routing (OSPF), or configure static routes on the controller.
If OSPF routing protocol is enabled, the Wireless Controller advertises the VNS (Layer 3) subnet as
a routable network segment to the wired network and will route traffic between the wireless devices
and the wired network.
With the Wireless Controller Bridge Traffic Locally at the WC topology, the WLAN becomes a natural
extension of a VLAN. WLAN client traffic is encapsulated and transmitted over the CTP tunnel
to/from the AP and WC where packets will undergo the enforcement of system policies or filtering.
Once the filtering is enforced the PVID that is defined for the VLAN ID is assigned to that traffic and
bridged through the configured interface. A particular VLAN ID can only be used once per Controller.
To support that configuration, you must define which VLAN the VNS should bridge the traffic to. The
network port on which the VLAN is assigned must be configured on the switch, and the
corresponding Wireless Controller interface must match the correct VLAN.
Bridged Traffic Locally at the AP WLAN client traffic is directly bridged to a VLAN at the AP network
point of access (switch port). Bridged Locally at AP VNSes provide link persistence in the event of
loss of connectivity to the controller.
In the Multiple tagged environment where one or more Bridged Locally at AP VNS topologies with
VLAN tagging are configured, the Wireless AP has to be connected to a VLAN aware L2 switch
Trunk Port that is segmenting the network.
Configuring two untagged VNSes to the same AP but on different radios is permitted.
Note: Enterasys Wireless supports IPv6 wireless communications, IPv6 wireless clients
communicating natively to IPv6 servers in bridge Locally @ AP mode configurations. This first phase
of IPv6 support addresses basic IPv6 connectivity requirements for early adopters of IPv6
communications and provides the foundation for future expanded IPv6 network services support.
Enterasys Wireless supports IPv6 wireless communications, IPv6 wireless clients communicating
natively to IPv6 servers in bridge Locally @ AP mode configurations. This first phase of IPv6 support
addresses basic IPv6 connectivity requirements for early adopters of IPv6 communications and
provides the foundation for future expanded IPv6 network services support.
In event of a link loss with the controller, the Branch Mode AP will remain active and continue to
provide bridged services to existing associated WLAN clients. However, AP logging, software
upgrades and configuration changes will be unavailable until the link is re-established.
During this state the AP will stop sending Poll_Req messages and it will stop checking for replies, but
it will try to re-discover the Wireless Controller in the background.
The users EAP packets request for network access along with login identification or a user profile is
forwarded by the Wireless Controller to a Radius Server, therefore roaming is not allowed in a 802.1x
environment.
* 802.1x support for Roaming and new Client Assocication are only supported when the APs are
grouped in a Sites Configuration.
Maintain client session in event of poll failure Selecting this option in the AP Properties tab will
ensure that the Wireless AP will remain active in the event of a link loss with the controller. This
option is enabled by default on all APs.
The Restart services in the absence of the controller should also be checked in case the AP reboots
and the controller is still unavailable. When enabled the AP will maintain the Bridge at AP VNS even
if the controller is still down.
Topology configuration is independent of the WLAN services or Policies that are defined in the
system. It is accessible from either Wireless Controller Configuration, Virtual Network Configuration
option of the Wireless Assistant main menu or from the VNS Policies component screen.
VNS Topologies properties such as the VLAN ID or the Routed subnet are not created and activated
until they are referenced by a Policy. Topologies cannot be deleted while they are active (referenced
by a Policy).
On the Topology configuration page, the key field is the Mode, which determines the other factors of
the topology. When the topology mode has been selected, the remaining VNS tabs will be displayed.
The parameters related to network topology are defined based on the topology mode selected:
VLAN Settings (VLAN ID)
ARP Proxy
Layer 3 (L3) interface presence (IP address and subnet range)
DHCP Configuration (Local or DHCP Relay)
Management Traffic
Multicast support & filter definition
Exception filter definition
The topology decision should be made based on the existing network (L2 vs. L3) and physical
deployment area (one floor vs. one building vs. many building on a campus) and end-system device
types.
VLAN tagging a VNS topology refers to the action of assigning a VLAN-ID to all using this particular
VNS topology before leaving the interface (either the Controller or the AP).
ARP Proxy is enabled by default for Bridge Traffic Locally at HWC, V8.21 offers ARP Proxy
capabilities for Bridge Traffic Locally at AP topologies on an AP. This feature minimizes the need of
sending ARP requests over the air to improved performance. The AP will respond to ARP request for
the particular MAC if it is known on the behalf of the client.
The Layer 3 (IP) address definition is mandatory for Routed topologies and optional for Bridge Traffic
Locally at Controller topologies. An IP Address is necessary if services such as management
access, DHCP, Captive port, etc. are required over the configured network segment.
When the Wireless Controller creates this VNS, it also creates a virtual IP subnet for that VNS where
user traffic is tunneled to the Wireless Controller. Packets will undergo the enforcement of system
policies or filtering before finally being VLAN tagged and bridged through the configured interface. In
a Routed VNS, this will be the address that the controller will advertise to the network, so that
packets can be routed to the network.
The None option for DHCP is used for WLAN clients that have a statically defined IP address or if the
DHCP Server is directly available on the network the Controller is connected to.
The local DHCP Server on the Wireless Controller can be used if there isnt a DHCP Server on your
network. The local DHCP Server is useful as a general purpose DHCP Server for small subnets; this
DHCP Server is for the WLAN clients only. The DHCP setting window is displayed when selecting
the Configure button.
If the Topology mode is configured for Bridged Locally at AP, the Wireless Controller's DHCP server
option is not available for the WLAN clients. In this case you will have to rely on the enterprise
networks DHCP server to provide the client IP addresses.
For a Routed or Bridge Traffic Locally at the HWC mode, the enterprise network's DHCP server can
provide the IP addresses for your WLAN clients by enabling DHCP Relay or None. The assigned
addresses must be within the range of the VNS definition and the controller must be defined in the
network as the path for traffic delivery to the WLAN clients.
A mechanism that supports multicast traffic can be enabled as part of a topology definition; this will
allow multicast traffic to be forwarded to and from the tunneled Routed or Bridge Locally at HWC
VNS. This mechanism is provided to support the demands of VoIP and IPTV network traffic, while
still providing the network access control.
For each group defined, you must enable Multicast Replication otherwise the default behavior is to
drop the packets.
In a Routed Topology this feature is tied to the physical interface for the use of multicast relay,
therefore you need to enable multicast on the physical interface.
Note: Wireless Replication prevents Multicast/Broadcast messages from being sent between
Wireless Clients.
Note: The multicast packet size should not exceed 1450 bytes.
Next-hop routing Use next-hop routing to specify a unique gateway to which (unicast/broadcast)
traffic on a VNS is forwarded. Defining a next-hop for a VNS forces all the traffic in the VNS to be
forwarded to the indicated network device, bypassing any routing definitions of the controller's route
table similar to Policy Based Routing (PBR). In a switching environment the 802.1Q tagging can be
set by the Switch/Router.
The Next Hop Feature can be configured under the Advanced Settings in the Topology Tab of the
DHCP Configuration for a Routed Mode VNS.
Policy Assignment defines how the WLAN client traffic is handled (topology, filtering rules and Class
of Service (CoS)). Each VNS is configured with two Policy assignments, the Non-Authenticated and
the Authenticated. When a WLAN client associates to an SSID, it will be assigned the Non-
Authenticated Policy associated to that VNS until it is Authenticated by the Controller. Once the
WLAN client is authenticated it will receive either the same Policy or a different policy based on the
Authenticated Policy assignment defined for the VNS. The WLAN client will maintain the same
authentication/privacy and QOS parameters that were defined in the WLAN service for that VNS.
If a RADIUS Server is used for authentication (such as in 802.1x, MAC Authentication or Captive
Portal) the Filter ID value defined in the Remote Access Dial-in User Service (RFC2865) response
from the RADIUS Server can be used to override the default Authenticated Policy assignment. If a
Filter-ID value is returned with the RADIUS Access-Message to the Controller and matches a
configured Policy, the controller will assign the specified policy to that user.
Class of Service (CoS) refers to a set of attributes that define the importance of a frame while it is
forwarded through the network relative to other packets, and to the maximum throughput per time
unit that a station or port assignment to a specific policy is permitted.
In general, Class of Service (CoS) refers to a set of attributes that define the importance of a frame
while it is forwarded through the network relative to other packets, and to the maximum throughput
per time unit that a station or port assigned to a specific policy is permitted. The CoS defines actions
to be taken when rate limits are exceeded.
All incoming packets may follow these steps to determine a CoS:
Classification identifies the first matching rule that defines a CoS.
Marking modifies the L2 802.1p and/or L3 ToS based on CoS definition.
Rate limiting (drop) is set.
The system limit for the number of CoS profiles on a controller is identical to the number of policies.
For example, the maximum number of CoS profiles on a C5110 is 1024.
The EWC is pre-populated with 9 Class of Service configurations similar to the Class of Service
Configurations defined in Policy Manager.
Rate Control is part of CoS definition, the user can specify (default) policy that includes Ingress and
Egress rate control. Ingress rate control applies to traffic generated by wireless clients and Egress
rate control applies to traffic targeting specific wireless clients.
Bandwidth control limits the amount of bidirectional traffic from a mobile device. A bandwidth control
profile provides a generic definition for the limit applied to certain wireless clients' traffic. A bandwidth
control profile is assigned on a per policy basis. A bandwidth control profile is not applied to multicast
traffic.
For the purpose of Rate Control, the frames are classified as being associated to different flows that
are determined by the actual wireless client session. The meter checks compliance to a defined
traffic profile and passes results to policer to trigger appropriate actions for in- and out-of-profile
packets. The policer drops the out-of-profile packets, so that traffic maintains compliance with a
defined traffic policy. In-profile frames are forwarded to the network.
Note: EWC does not perform rate shaping.
The bit-rates can be configured as part of globally available profiles which can be used by any
particular configuration. A global default is also defined.
Bandwidth control limits the amount of traffic from a mobile device. A bandwidth control profile
provides a generic definition for the limit applied to certain wireless clients' traffic. A bandwidth
control profile is assigned on a per policy basis. A bandwidth control profile is not applied to multicast
traffic.
Committed Information Rate (CIR) Rate at which the network supports data transfer under normal
operations. It is measured in kilo bytes per second(Kbps).
The Global VNS setting Bandwidth Control (traffic control) allows the configuration of Rate Profiles
which determine the amount of bidirectional traffic allowed to be transmitted to/from a client on a
VNS. Multiple Profiles can be created, each with their own unique Committed Information Rate
(CIR). Once these Profiles are created they can be associated to individual VNSs.
Policy configuration defines the binding of a Topology, Filter Rules, Ingress Rate and Egress Rate
Profiles applied to the traffic of a WLAN client. The VLAN & Class of Services component of a Policy
is created by selecting the Topology from the configured topology pull down list, which includes the
Global Default topology (Bridged at AP untagged or no change) and the Ingress/Egress Rate
Profile, or the Class of Service.
From the Policy screen both new Topology and Rate Profiles can be created from the Policy screen
by selecting the New button.
Policies can also be created using the Enterasys NetSight Policy Manager and pushed to the
Wireless Controller for use by VNSes.
The VNS provides a technique to apply policy to allow different network access to different groups of
users based on packet Filtering Rules. The EWC supports up to 2048 filters, 64 filters per Policy.
When a filter is added to the list it is placed as the first rule. The filtering rule sequence must be
arranged in the order that you want them to take effect.
The final rule in any filter list should act as a catch-all for any traffic that did not match a filter.
Therefore it should be either allow or deny all traffic, depending on the requirements for network
access. A default rule of deny all is automatically created by the system for initial filter definitions.
The administrator can change the action to allow all, however the rule cannot be removed.
Filtering provides the ability to create bidirectional filters. As traffic enters either the AP or Controller
parts of the IP header are examined for a match. For example, a deny filter rule with the IN: src, Out:
dest will allow a Wireless Client to access a DNS Server but not to be a DNS server on the network.
When filtering at the Wireless AP is enabled, Wireless APs obtain client filter information from the
Wireless Controller. Applying filter rules at the Wireless AP helps restrict unwanted traffic at the
edge of your network. The 2600 series and mix environment (2600/3600 or 3700) Wireless APs can
support up to a maximum of 32 filters rules per topology. The 3600 and 3700 Wireless APs will
support up to 64 rules.
Filtering at the Wireless AP can be configured with the following VNS types:
Bridge Traffic Locally at the AP - If filtering at the Wireless AP is enabled on a Bridge Traffic Locally
at the AP VNS, the filtering is applied to traffic in either direction: In - Into the network from the
Wireless Client, or Out To the wireless device from the network.
Routed and Bridge Traffic Locally at the HWC - If filtering at the Wireless AP is enabled on a Routed
or Bridge Traffic Locally at the EWC VNS, the filtering can be configured in either direction. The
filters applied at the Wireless AP can be the same or different from filters applied at the Wireless
Controller.
In addition, direct inter-Wireless AP communication allows Wireless APs to exchange client filter
information as clients roam from one Wireless AP to another. This allows the system to achieve a
very fast roaming time. To take advantage of inter-Wireless AP communication, you should configure
the network so that Wireless APs in the mobility domain can communicate with each other through
the Wireless APs Ethernet interfaces. Also, multicast traffic with an IP address of 224.0.1.178 should
be allowed between Wireless APs.
Additional filters that are only applied on the AP can be configured by selecting the Custom AP
Filters checkbox; select the AP Filters tab and then add additional filters. Custom AP Filter rules are
useful for creating filters to not allow wireless Clients to communicate to each other in a Bridged
Locally at the AP SSID. When the Custom AP Filters checkbox is removed all the unique filters will
also be removed.
The WLAN service represents unique RF, authentication, encryption and QOS attributes of a
wireless access service (802.11) for the VNS. Using the SSIDs as a service differentiation for
wireless client to connect to, APs have the ability to advertise several SSIDs. Each AP supports up
to 16 SSIDs per Access Point, 8 per Radio.
The WLAN Service can be one of four basic types. Once the Service Type is selected and Saved the
other tabs for this WLAN Service will be displayed based on the Service Type selected.
Standard A conventional service. Only APs running Wireless software can be part of this WLAN
Service. This type of service is useable as a Bridged Locally at Controller, Bridged Locally at AP, or
Routed VNS.
Third Party AP A wireless service offered by third party APs.
WDS/Mesh This represents a group of APs organized into a hierarchy for purposes of providing a
Wireless Distribution Service/Mesh Network. This type of service is in essence a wireless trunking
service rather than a service that provides access for stations. As such this type of service cannot
have policies attached to it. It allows APs to use RF to provide both network access and data
backhaul to locations without cable or fiber.
Remote - A service that resides on the edge (foreign) Wireless Controller. This service is paired with
a remotable service on the home Wireless Controller and should have the same SSID name and
privacy as the home remotable service.
A WLAN service uses the topology and CoS of the policy assigned to the VNS. There may be cases
where a default topology or CoS will be used for a specific SSID by-passing the Authenticated
Topology or Cos Assigned by the Radius Server. This allows Policies (Filters/Cos) to be applied
without assigning a topology. This provides a better integration with NetSight Policy Manager,
therefore the topology is assigned based on the WLAN Service or SSID that the end-system
associates to.
Note: The Policy must be equal to no change for the Default Topology to take place.
The Service Set Identifier (SSID) will be the name of the Broadcast Service Set Identifier (BSSID).
The BSSID is a 48-bit binary identifier that distinguishes it from other BSSes throughout the network.
The BSSID is the MAC address of the wireless interface in the access point creating the BSS.
The WLAN Services tab displays the list of APs that have been registered and approved on the
Wireless Controller. If two controllers have been paired for availability, each EWCs registered
Wireless APs are displayed as foreign in the other EWCs AP list. This list is used for the
assignment of WLAN services to individual APs, as well as to radios on each AP (Individual
BSSIDs).
Once the configuration has been written to the AP, the VNS SSID (BSSID) assigned to an AP Radio
is displayed in the Wireless AP Radio settings.
The Advanced Settings of the WLAN Services for Timeout parameters define the following
components:
Idle: (pre) The amount of time in minutes that a WLAN client can have a session on the controller in
pre-authenticated state but no active traffic is passed. The session will be terminated if no active
traffic is passed within this time. The default value is 5 minutes.
Idle: (post) The amount of time in minutes that a WLAN client can have a session on the controller
in authenticated state but no active traffic is passed. The session will be terminated if no active traffic
is passed within this time. The default value is 30 minutes. This value also represents the amount of
time the PKMID is cached on the AP.
Session The maximum number of minutes of service to be provided to the user before termination
of the session.
The Advanced Settings of the WLAN Services for RF define the following behaviors:
Suppress SSID Select to prevent this SSID from appearing in the beacon message sent by the
Wireless AP. The wireless device user seeking network access will not see this SSID as an available
choice, and will need to specify it.
Enable 11h support Select to enable TPC (Transmission Power Control) reports. Apply power
reduction to 11h clients Select to enable the Wireless AP to use reduced power (as does the 11h
client). By default this option is disabled. It is recommended to enable this option.
Process client IE requests Select to enable the Wireless AP to accept Information Element (IE)
requests sent by clients via Probe Request frames and responds by including the requested IEs in
the corresponding Probe Response frames.
Energy Save Mode Select to reduce the number of beacons the AP transmits on a BSSID when
no client is associated with the BSSID. This reduces both the power consumption of the AP and the
interference created by the AP when no client is associated.
More information on the Advanced RF setting is covered in the RF Considerations Module.
Egress filtering controls improve compatibility with NetSight Policy Manager (PM) for seamless role-
based enforcement across wired and wireless infrastructures. Egress rules in PM are synonymous
with the out rules in Enterasys Wireless; with this enhancement PM can be used to define both in
(ingress) and out (egress) rules.
When combined with QoS controls, egress rules ensure that high-priority and return traffic is marked
at the controller (for Bridged Locally @ HWC and Routed VNS) deployments ensuring that critical
services have appropriate access to network resources.
The Advanced Settings of the WLAN Services for Client Behavior and 802.1d define the following
components:
Block MU to MU traffic checkbox prevents two devices associated with this SSID and registered as
users of the controller from talking to each other. The blocking is enforced at the L2 (device)
classification level.
802.1D Base Port number in the 802.1D area is the port number by which NetSight recognizes the
SSID. It is a read-only value.
The Wireless Controller provides basic standard wireless network security authentication methods
for WLAN clients for protection such as IEEE 802.1x, Captive Portal, MAC Authentication or Guest
Portal. Authentication method will depend on multiple criteria, such as roaming, Availability, Mobility,
Network Access Control (NAC) or Guest Access Services.
The Auth & Acct defines the parameters to setup the Authentication and Accounting for a WLAN
Service. If the network assignment is 802.1x authentication, the users request for network access
along with login identification and a user profile are forwarded by the Wireless Controller to a
RADIUS Server. The following types of authentication methods are supported: Extensible
Authentication ProtocolTransport Layer Security (EAP-TLS), EAP with Tunneled Transport Layer
Security (EAP-TTLS), and Protected EAP (PEAP).
Note: The RADIUS server must support RADIUS extension (RFC2869) for 802.1x Authentication.
MAC-based authentication enables network access to be restricted to specific devices by MAC
address. The Wireless Controller queries a RADIUS server for a MAC address when a wireless
client attempts to connect to the network.
To set up a RADIUS server for MAC-based authentication, you must set up a user account with
UserID=<MAC address> and Password=MAC (or a password defined by the administrator) for each
user configured on your RADIUS Server. If the Password box is left empty, the MAC address will act
as the default password.
MAC-based authentication responses may indicate to the Wireless Controller what VNS policy
should be assigned to the user when used with the Filter-ID RADIUS attribute.
Enable MAC-based authorization on roam, if you want your clients to be authorized every time they
roam to another AP. If this feature is not enabled, and MAC-based authentication is in use, the client
is authenticated only at the start of a session.
Privacy is a mechanism that protects data over wireless and wired networks, usually by encryption
techniques. Wireless Controller, Access Points and Software supports:
Wired Equivalent Privacy (WEP) - WEP encrypts data sent between wireless nodes. Each node must
use the same encryption key.
Wi-Fi Protected Access Privacy (WPA v.1 and v.2) - Encryption is by Advanced Encryption Standard
(AES) or by Temporal Key Integrity Protocol (TKIP).
Two modes are available
Enterprise - Specifies 802.1x authentication and requires an authentication server
Pre-Shared Key (PSK) - Relies on a shared secret. The PSK is a shared secret
(pass-phrase) that must be entered in both the Wireless AP or router and the WPA
clients.
The PSK is a shared secret (pass-phrase) that must be entered in both the Wireless AP or router and
the WPA clients.
The selection and options are based on the WLAN Authentication selection. To achieve the strongest
encryption protection for your VNS, it is recommended to use WPA v.1 or WPA v.2.
Note: Regardless of the Wireless AP model or VNS type, a maximum of 112 simultaneous clients,
per radio, are supported by all of the data protection encryption techniques listed above.
Privacy is a mechanism that protects data over wireless and wired networks, usually by encryption
techniques. The Wireless Controller provides five privacy mechanisms to protect data over the
WLAN.
None
Static Wired Equivalent Privacy (WEP) Keys for a selected VNS, so that it matches the WEP
mechanism used on the rest of the network. Each AP can participate in up to 50 VNSs. For each
VNS, only one WEP key can be specified. It is treated as the first key in a list of WEP keys.
Dynamic Keys (WEP) The dynamic key WEP mechanism changes the key for each user and each
session.
Wi-fi Protected Access (WPA) - WPA v.1 with encryption by temporal key integrity protocol (TKIP)
and/or WPA v.2 with encryption by advanced encryption standard with counter-mode/CBC-MAC
protocol (AES-CCMP)
Wi-Fi Protected Access (WPA) Pre-Shared key (PSK) Privacy in PSK mode, using a Pre-Shared
Key (PSK), or shared secret for authentication. WPA-PSK is a security solution that adds
authentication to enhanced WEP encryption and key management. WPA-PSK mode does not
require an authentication server. It is suitable for home or small office.
If WPA is selected and the RADIUS Server has not been configured in the Auth & Acct section a
warning message will be displayed and the WLAN Service will be disabled.
WLAN Service configuration now receives additional validations to ensure that SSIDs and pre-
shared keys do not suffer from security weaknesses. The administrator will be allowed to configure
services with weak keys and SSIDs but will be warned that stronger ones should be considered.
Voice over Internet Protocol (VoIP) and other WLAN devices using 802.11 wireless local area
networks require constant transmission rates and timely packet transmission.
The Enterasys wireless solution provides end to end packet prioritization using Quality of Service
(QoS) capabilities in order to provide voice data or time sensitive traffic types priority over all other
traffic. Examples of this include: Wireless QOS mode WMM (Wi-Fi Multimedia), 802.11e, 802.1p or
DSCP (Diffserv Codepoint).
QoS policies are configured for each WLAN Service and it can be applied to most all VNS topology
types. That means that every WLAN client is treated with unique QoS settings based on the WLAN
Service to which they associate even from the same AP.
The WLAN distinguishes between two levels of QoS treatment applied to the client traffic: wireless
and wired. Wireless QoS is applied at the APs, while the wired QoS is applied at both the APs and
the Wireless Controller. QoS definition and configuration are part of the WLAN Services
specifications.
On the wired side, a class of service can define DSCP and IP/TOS markings that can overwrite the
markings in the ingress frame. A class of service can specify the transmission queuing behavior that
is applied to frames. Rate limiting can also be considered part of overall QoS specification. Rate
limiting/control is applied to all traffic assigned to a policy.
QoS policy is configured for each VNS and it can be applied to routed, bridged locally at the AP and
bridged locally topolgy. Therefore every user associated with the VNS there will be a different
behavior on the wireless traffic depending on the client that is connected.
Quality of Service (QoS) management is also provided by: Assigning high priority to an SSID,
Adaptive QoS and support for legacy devices that use SpectraLink Voice Protocol (SVP) to
prioritizing voice traffic.
The ToS/DSCP field in the IP header of a frame indicates the priority and QoS for each frame. The IP
TOS and/or DSCP is maintained within CTP tunnel by copying the user IP QoS information to the
CTP header this is referred to as Adaptive QoS. DSCP classifications are configured on a per
WLAN Service basis.
Packets that come into the VNS are typically given specific handling according to their DSCP value
and how it maps into the Priority Processing table available under the QoS tab in the WLAN Service
configuration. The exception is the case of bridged/tagged VNSs where the 802.1p field is used.
All 64 DSCP (6 Bits) code-points are supported, divided in 8 CS/UP, VNS handle packets according
to their DSCP or 802.1p values. Of the 8 levels of user priority, 6 are considered low priority levels
and 2 are considered high priority levels. The IETF defined codes are listed by name and code. The
table above shows the default DSCP service class classification.
Traffic classification and prioritization is performed at the point of entry (AP for wireless-to wired and
controller/AP for wired-to-wireless). The AP supports five queues that are configurable per radio,
Voice (VO), Video (VI), Background (BK), Best Effort (BE) and Turbo Voice (TVO). Classification is
enabled if any of the QoS modes are enabled (Legacy, WMM and 802.11e), if the classification is
disabled all traffic is mapped to BE (Best Effort).
The prioritization of the traffic on the downstream (for example, from wired to wireless) and on the
upstream (wireless to wired) is dictated by the configuration of the VNS and the QoS tagging within
the packets, as set by the wireless devices and the host devices on the wired network. Both Layer 3
tagging (DSCP) and Layer 2 (802.1p) tagging are supported, and the mapping is in conformance with
the WMM specification. If both L2 and L3 priority tags are available, then both are taken into account
and the chosen AC is the highest resulting from L2 and L3. If no priority tag is present, the default
queue AC_BE (Best Effort) is chosen.
WMM clients have the same five AC queues. WMM clients will classify the traffic and use these
queues when they are associated with an WMM-enabled AP. WMM clients will behave like non-
WMM clients (map all traffic to the Best Effort (BE) queue) when not associated with WMM-enabled
AP.
Note: The Wireless 802.11n AP does not support the Turbo Voice option.
Packet Fairness is the default 802.11 access policy whereby clients are provided with equal
opportunity to send a packet, regardless of their bit rate capabilities. Therefore slower clients will
occupy the RF channel for longer durations than faster clients, causing the throughput on faster
clients (802.11n) to be reduced.
Flexible Client Access ensures equal airtime for all clients, as opposed to equal number of packets.
This is essential for achieving the best performance of 802.11n client on a VNS WLAN Service that
supports both 802.11n and legacy clients on the same network.
Once enabled, Flexible Client Access (FCA) comes into play once traffic/load exceeds the medium
capacity on an 11n AP.
Airtime Fairness 802.11n clients will see the same throughput that they would if it they were
connected to an 802.11n only network and legacy clients will behave as if connected to a legacy
network because client are provided with equal channel usage.
Flexible Client Access (FCA) can adjust the client access policy in multiple steps between packet
fairness and airtime fairness. FCA can be enabled or disabled for any given WLAN Service in its
QoS Settings tab. The level at which it is applied (between 100% Airtime Fairness and 100% Packet
Fairness) is a global parameter that is set under VNS Configuration -> Global -> Wireless QoS.
FCA should not be enabled on WLAN services that is configured to use 802.11e/WMM voice queue
to preserve the quality of Voice over WLAN.
Priority override allows you to define the desired DSCP/SC priority level on a per VNS configuration.
Priority override can be used with any combination. You can configure the service class (L2
override) and the DSCP values (L3 override values).
When Priority Override is enabled, the configured service class overrides the queue selection in the
downlink direction, the 802.1p user priority for the VLAN tagged Ethernet packets, and the UP for the
wireless QoS packets (WMM or 802.11e) according to the mapping in the table above.
If Priority Override is enabled and the VNS is not configured for Bridge at AP then the configured
DSCP value is used to tag the IP header of the encapsulated packets. The AP does not override the
DSCP in the IP header of the user packet. For example, the UP for the CTP tunnel Protocol frames
(if field exists) that is sent by the AP is set or the DSCP values for CTP frames sent by the AP.
Note: Use with caution since all traffic of the VNS will over overridden.
The VNS binds the WLAN Service and Policies. When creating a VNS, a single overall filtering policy
applies to all the wireless devices within that specific VNS configuration. The filtering selection will
depend on the type of filtering that will be applied to that VNS and at what state (Non-Authenticated
or Authenticated). For example, with Guest Portal and Captive Portal (Internal/External) the Non-
Authenticated Policy will be applied to the users before authentication. Once the user has been
authenticated the user will be assigned the Authenticated Policy that is assigned to the VNS or a
Policy that is returned in the Filter-ID from a RADIUS server.
Global Settings contain global default settings that can be applied to VNS components, such as
RADIUS configuration, Dynamic Authorization Server support, Wireless QOS, Bandwidth Control
and Default Policies.
The Authentication component includes the definition of the RADIUS servers on the enterprise
network. The controller supports up to 3 RADIUS Servers. The servers defined here will appear as
available choices when you set up the authentication mechanism for a WLAN Service. During the
configuration a Hostname (FQDN) for a RADIUS server is allowed. However, you must configure
the Host Attributes setting for your reachable DNS server.
When using MAC Authentication, the MAC Address Format can be selected to match how the entry
is created on the RADIUS Server.
Strict Mode enabled the ability to change the RADIUS server setting per WLAN service.
Note: The Wireless Controller must be configured properly via NetSight, i.e. SNMPv3 and CLI
access.
Dynamic Authorization Server (DAS) helps secure the network by forcing the disconnection of any
WLAN device on the network. If an unauthorized WLAN device is detected on the network, the DAS
client sends a disconnect message (RFC3576) containing a MAC address. The controller then
disconnects that WLAN device, forcing it off the network.
When integrated with NAC, the DAS client can be utilized to disconnect the client, so that it can be
assigned a different policy assignment.
The Global Default Policy definition provides a placeholder for completion of incomplete policies for
initial default assignment. If a policy attribute is defined as no change, the attributes are inherited
from Default Global Policy definitions.
The Wireless Controller ships with a Global Default Policy that specifies a default Topology, Filter
Rule and Rate Profile.
The Global Default Policy parameter values are:

Topology = Bridged at AP untagged
Rate Profile = Unlimited or no rate control
Filter Rules = Deny All filter
The attributes of the Default Global Policy can be modified to define more permissive filter sets or a
more restrictive Rate Control profile or a different topology.
In this example the second Policy defined has a Topology setting of no change. However, we can
determine by looking at the Global Default Policy that the topology for this Policy will be Bridge at AP
untagged based on the Global Default Policy.
The All Active Client, Active Clients by Wireless AP and Active Clients by VNS reports show similar
information about the clients that have been associated to the AP via the SSID.
Encryption Cracking Attempts to recover an encryption key or encryption key stream. Allowing
transmission of messages into the authorized network.
Denial of Service - Sending a flood of de-authentication messages to a station or AP. These attacks
prevents the victim from giving or getting service.
Ad-Hoc Networks Device forwards unauthorized packets between networks, wireless to wired or
wireless and wireless.
Surveillance Surveyor, like Radar, that listens (Passive) and transmits (Active) 802.11 frame to
discovers network.
Honeypot AP that advertises an SSID belonging to the authorized network without authorization
(Internal) or an AP that advertises a popular SSID that stations have a high probability of searching
for and associating to (External), i.e. default SSID Linksys or a HotSpot SSID.
Spoofing Where a device pretends to be another, by advertising a BSSID (MAC address) of an
authorized AP, or another authorized station or Client.
471
It is important to understand that a stations network access will only be removed
automatically in the event that removing access thwarts the attack. This is most effective
against active encryption cracking since it can prevent the station from discovering the
encryption key. In most cases blacklisting the attacker is not done because doing so would
not mitigate the attack.
Log messages will be generated when the threat is first detected and when the threat stops or it is
aged.
All options selected and configured in the Sites will be applied to all APs defined within the Sites.
Advanced Features such as Load Control and Tunnel Encryption are also defined on a per Sites
basis.
AP Assignments tab allows selection of APs to join the site; APs can only belong to one Site.
WLAN Assignments define the VNS that will be broadcasted by the Site; the details of the VNS are
configured using the individual tabs on the left pane.
Authentication controls the access of connecting end systems to the network based on supplied
credentials. For Enterasys Wireless, the controlling of access to the network is more than
authenticating users that are connected based on the passing or failing of authentication by an end
system. Authentication methods vary in order to cater to the types of devices that may connect to the
network. For example, although PCs allow humans to input personal credentials such as username
and password through a keyboard (Captive Portal, 802.1x (PEAP)), an IP Phone may not provide the
same interface for a human to input personal credentials, i.e. 802.1x w/Certificate or MAC based
Authentication.
Upon passing authentication, Enterasys Controllers and APs (V8.11) have the capability to properly
allocate network resources to authenticated users/devices aligned with their business role.
Therefore, authentication is used in conjunction with the granular control of network resources
supported through Enterasys policy implementation to automatically allocate network resources to an
authenticated user/device independent of their location.
Captive Portal and 802.1x authentication has evolved from a means to authenticate a user onto the
network to provide dynamic network assignments (Topology/VLAN) and packet filtering
(Policies/ACLs). RFC 3580 specifies the standard attributes currently used for VLAN assignment
(tunnel-type, tunnel-medium-type, private-tunnel-group-id) and for ACLs/Policies (filter-id) and
Quality of Service information.
A high level overview of how Enterasys Wireless Devices accomplish this goal is explained as
follows:
An authentication method is implemented between the user device connecting to the network and the
Network Access Server (NAS) in order to acquire credentials from the user/device for validation on
the network.
The Wireless Controller or the Access Point (when configured using Sites) acts as the NAS. The
NAS is responsible for communicating via a RADIUS Access-Request, the authentication
credentials from the user device along with a number of RADIUS Attribute Value Pairs (AVP) and
Vendor-Specific Attributes (VSAs) that can be used to help the RADIUS server with its decision on
how to handle the authentication. The RADIUS server authenticates/validates the credentials, the
Server contains a database of valid users and corresponding credentials, it can either accept or
reject the based on the comparison of the credentials. If the credentials are correct, a RADIUS
Access-Accept is returned to the NAS, and if the credentials are invalid, a RADIUS Access-Reject is
returned to the NAS.
The RADIUS Attribute Value Pairs (AVP) and Vendor-Specific Attributes (VSA) carry data in both the
request and the response for the authentication, authorization, and accounting transactions. These
Attributes can determine: a) how the user is authenticated, i.e. authentication method supported; and
b) Attributes returned via the authentication process, i.e. Filter-ID, VLAN attributes, and the
Organization Group that the end-system is defined as belonging to in the Active Directory database.
Mobile IAM/NAC gateways require that the SSID Attribute be selected if the NAC Rule uses the
Location SSID.
If the Zone is configured for either Sites or Location-Based Policy, the Zone name can be used as a
Called Station ID attribute that is sent with the Radius Accept message.
In Microsoft IAS/Network Policy Server (NPS) the Radius Attributes can be used for Conditions that
must be matched for a particular Policy. For example, the Wireless Controller sends the Access-
Request Message to the RADIUS server, the Attribute Value Pairs are specified including the Vendor
Attributes or VSA. In the Network Policies defined in the Network Policy Server, this particular
request is going to match the Authorized Wireless Users Policy , where the conditions are the User
Groups (Locally defined on the RADIUS Server, the Attribute User-Name is compared to the
Employees User Group), and the NAS Port Type is equal to Wireless IEEE 802.11. Based on the
match, the Settings are further defined and returned to the NAS; this includes the Authentication that
is supported as well as Attributes such as Filter-ID and VLAN-ID attributes. If this same user
attempted to be authenticated by a Switch or Wired Network device this Policy would not be used.
RFC 3580 Attributes can be returned in the RADIUS Access-Accept packet to the NAS during the
authentication process. Therefore, each user configured on the RADIUS server can be associated to
a NSP policy that is configured with either a RADIUS Filter-Id that matches the name of the Policy
Profile on the Controller that the user will be assigned for the proper allocation of network resources
or VLAN Attributes to defined the network or Topology or both.
VLAN assignment allows an end-user device to be dynamically placed on a VLAN based on the
response from the RADIUS server. The Enterasys Controller supports the Tunnel-Private-Group-ID
(81) which defines the topology name of the VLAN, i.e. Engineering. When the Controller or AP
receives this response it will tag all incoming traffic to that particular VLAN defined in the Topology.
The RFC3580 (ACCESS_ACCEPT) Options defined how the Controller or AP (Sites configuration)
will assign the Policy and Topology for the Controller. This is a Global Setting, therefore it is applied
to all VNSes that are created.
The RADIUS Filter-ID attribute is the default value and the VLAN ID Policy Mapping table will not be
displayed. If both RADIUS Filter-ID and Tunnel-Private-Group-ID attributes are selected the VLAN
ID Policy Mapping table should not contain any entries, otherwise the VLAN ID returned from the
RADIUS server will be matched to the VLAN ID Policy Mapping table and not the Filter-ID that is
returned in the RADIUS-Access-Accept message.
Zones are used to define APs to a specific location. When used in conjunction with the WLAN Auth &
Acct settings for a particular SSID this in turn tells the RADIUS server where the AP is located based
on the Calling Station ID and allows it to assign policy or policy & topology based on that specific
location.
Policy Manager integration allows network administrators to centrally define and distribute policies for
both wired and wireless users from a central Application.
Policy Manager can be used for the following configurations:

RADIUS server
Create and Assign Policies to Topologies
Rate Limit Profiles
Class of Service
Due to the differences between switches and the Wireless Controller, it is recommended that the WC
considerations be reviewed first. These are outlined in the Policy Manager Help docs.
Note: Policies created by Policy Manager cannot be deployed onto a Controller that has been
previously configured via the GUI.
Policy Manager can be used to retrieve RADIUS server information from the Controller or configure
RADIUS servers for the WC.
Using the RADIUS sub-tab at the Network Elements level, click the Add button. A RADIUS server
can be specified for both authentication (WLAN users/devices attempting network access or user
attempting management access to the device itself) and accounting.
When the configuration is deployed in Policy Manager, the default Protocol for the Radius Server will
be MS-CHAP.
On the Wireless Controller (WC), the Policy binds the Topology, Class or Service and Filter Rules.
Default Actions/Access Control option sets both the WC Filter Rules & topology assignment for that
Role/Policy.
A topology cannot be created on the Netsight Policy Manager; the Topology MUST be created on the
WC before it can be assigned to a Role by the Policy Manager.
Note: In NetSight Policy Manager, the Policy is called a Role and Filters are Services.
The WC has a limited form of VLAN Containment support. Normal support for this feature is that a
rule specifies a VLAN so if there is a traffic match it gets tagged with the specified VLAN. Traffic that
does not match a rule can also optionally be tagged with the VLAN specified as the Default Access
Control for the Role. The Enterasys WC allows rules that are matched to be contained to a VLAN,
but it must be the same VLAN for all rules in the Role.
To handle this, the VLAN specified as the Default Access Control for the Role is the VLAN that traffic
is tagged with that matches a Permit Rule. An admin may still however want traffic that does NOT
match a defined rule to be dropped. Normally this would be done by setting the Default Access
Control to Deny Traffic, but that field has already been used. Instead, there is a WC specific setting
on the Role tab called Discard Unmatched Traffic. Checking this will drop traffic not matching a rule
while still containing traffic that does hit a rule.
Careful planning must be undertaken when using Policy Manager to configure Topologies on the
Controller. Policy Manager only understands VLANs therefore Bridge Locally at AP (untagged),
Bridge Locally at HWC (untagged) or Routed VNS topologies cannot be assigned a Role/Policy from
Policy Manager without issues.
For example, if a Role was created for a Routed VNS topology, and enforced by Policy Manager, a
policy would be created with the Default Filter and the no change topology. Using the Wireless
Assistant GUI the administrator then needs to assign the Routed VNS topology for this policy in the
WLAN Services component by setting the Default Topology to the Routed VNS topology and then
use the VNS to bind the Topology and Policy and WLAN Service.
Class of Service (Rate Limits) for the Controller defines the maximum throughput per time unit that a
WLAN client is assigned to that policy. Rate Limit profile actions are taken when the bandwidth of
the media is exceeded.
WC / Policy Manager support Role-based rate limits and Class of Services that are tied directly to
roles and/or rules.
The following QOS attributes are not supported on the Wireless Controller:
TCI Overwrite
Rate Shaping
Naming Conventions between Policy Manager and the WC are not maintained during an import or
enforcement from Policy Manager. The rate limit names are defined on the WC based on the index of
the SNMP set from the Policy Manager.
Port Ranges in Policy Manager are created using bitmasks to represent port ranges and are limited
to powers of 2 while the Controller has the ability to create a rule with an arbitrary port ranges. Care
must be taken when creating Port Range Rules using Policy Manager. A single rule created with
Policy Manager can turn into many rules when created on WC, which will cause issues when rules
are written to an AP where only 32 rules are supported.
Captive Portal deployments enable WLAN clients by allowing them to obtain an IP address and to
associate to their respective AP. Upon initial AP association, the client session is said to be in a non-
authenticated state, and the client receives the treatment specified by the Non-Authenticated Policy.
While in this state, users are typically allowed to browse a small subset of sites that advertise
products or services local to that area. This is referred to as the client being in a walled garden
since it is an area that users are forced to play in what is considered safe from the point of view
regarding the security of the network. Once the user attempts to access an area outside of the
walled garden, the user is then redirected to another site that forces the user to authenticate to the
network in order to move outside the secure environment.
The Enterasys Wireless Controller (EWC) ships with an 802.1x, Internal and External Captive Portal
service.
One of the requirements for implementing Captive Portal is communication to a RADIUS server. The
RADIUS Server configuration information is found under the Global Settings of the VNS
Configuration.
There are four authentication types supported for Captive Portal authentication:
Password Authentication Protocol (PAP)
Challenge Handshake Authentication Protocol (CHAP RFC2484)
Window-specific version of CHAP (MS-CHAP RFC2433)
MS-CHAP v2 (Windows-specific version of CHAP, version 2 RFC 2759)
The Shared Secret or key on the client (Controller) must be the same as the one configured on the
RADIUS server. The shared secret consists of up to 15 printable, non-space, ASCII characters. The
key itself is used to encrypt data within the RADIUS packets.
Captive Portal is only available on Routed or Bridge Locally at Controller topologies due to its
requirement to have a Layer 3 IP address for Web redirection.
The initial mechanism used by the internal captive portal solution is a component called the
redirector. The job of this component is to evaluate data streams originating from unauthenticated
client sessions and watch for HTTP GET commands from the WLAN client. For the redirector
component to function properly the clients original destination site needs to be blocked by the filter
set for non-authenticated sessions.
Further, since most user homepages are stored as URLs and not IP addresses, the WLAN client
also requires the ability to resolve DNS names. If the internal captive portal uses external html links,
then the server hosting those files must also be available in the filter set.
Lets assume for this example that the topology L3 IP address (gateway) is at 10.170.1.15 and the
external HTML files are also hosted on the machine at 10.170.1.15.
The first rule allows standard DNS lookups to occur. The second rule allows access to an external
html link residing on the 10.170.1.15 machine via HTTP (port 80 only). Lastly the VNS L3 IP address
(gateway) is added as a Local Interface filter (T). This is needed once the WLAN client is redirected
to the WC for the built-in captive portal web page. All the remainder of the traffic is blocked until after
successful authentication.
Note: Use the IP function of the Select Filters so in an Availability Configuration when
synchronization occurs the Filters will be updated properly between the 2 new controllers.
The Internal Captive Portal feature utilizes an integrated web server, including several options
customizable by the system administrator, that provides simple authentication against an existing
external RADIUS database. Complex portal requirements that utilize multiple RADIUS attributes or
heavy customization are best handled by the External Captive Portal feature.
Authentication is performed to collect user information, have the user agree to a set of terms and
conditions, or to gather payment for the service. Attempts to direct traffic outside the walled garden
results in traffic being dropped or web sessions returning to the login/payment page. The walled
garden may also provide a series of help pages to assist the user in signing up for or paying for the
service. Once the user has passed whatever criteria is established for access to the service they are
moved to the authenticated state.
The Authenticated Policy will define the Filters/Rules that the WLAN client will obtain once
authenticated on the Network. A different Authenticated policy can also be defined by the Filter-ID
returned by the RADIUS authentication request message. The Filter-ID must match a Policy that is
pre-defined on the Controller.
Note: When applying CoS to a filter, AP Filtering must also be enabled.
When the WLAN client associates to the network it receives an IP address according to the topology
of the Captive Portal VNS. The users initial filter set is called non-authenticated. This filter set is
defined in such a way to allow the WLAN client access to the portal page and to DNS resolution but
little else. By default, all non-authenticated users that are participating in a network that are using
either the internal or external captive portal have their blocked traffic checked by a module called the
redirector. This component reads the clients stream of data, specifically looking for a HTTP GET
request to a resolvable IP address. When this is located, the client is redirected to the web server
that will be used for authentication.
In the case of the internal captive portal, once at the redirected site the WC integrated web server will
present the user with a form that is accessed through HTTPS. The user is prompted to enter its
credentials and submits them to the web server, where they are then passed to a Network Access
Server (NAS) located within the WC. In turn, the NAS sends a RADIUS Access Request (which
includes the WLAN clients credentials) message to the primary RADIUS server configured on the
Controller. The RADIUS server validates the credentials and in response it sends either a RADIUS
Access-Reject message or RADIUS Access-Accept message to the NAS. The client is then bound
by the Default authenticated policy (topology/filter rules) defined for the VNS. At this point the client
is typically sent to their original destination or to a Redirection URL.
The RADIUS server could potentially return the RADIUS FILTER-ID attribute in the Access-Accept
message back to the WC, which would when specify a different Policy (topology/filter rules) that
would be applied to the WLAN client.
In the Auth & Acct tab screen the RADIUS server that was created under the VNS Global setting, will
be used as part of the authentication process. Selecting the Configure button will display the
information that will be used to contact the RADIUS Server, such as the authentication type,
Authentication port and NAS information. The NAS information can be used in the RADIUS server as
attributes to determine how the RADIUS Server processes the RADIUS Accept message.
On the Auth & Acct tab select Configure after selecting Internal in the Authentication Mode drop-
down box. Select either to upload the Captive Portal content or select Manual Setting for the Web
Page formatting. The Captive Portal Settings page prepares the Web Page that will be presented to
the WLAN client for authentication.
Some important configuration requirements include:
References to images within an external html files need to be formatted like this: <img
src=http://10.170.1.15/mypicture.gif> in order for them to operate correctly when used in
conjunction with the captive portal page. The html file must only contain html code. Javascript,
redirects or dynamic CS is not permitted.
Note: If Fully Qualified Domain Names (FQDNs) are used within the external html file then the WCs
primary and/or secondary DNS settings must be set under the Wireless Controller Host Attributes
Settings or the WC will not be able to resolve the hostnames.
Configuration informational and error messages can be customized. All URLs referenced in the
Captive Portal setup must also be specifically identified and be allowed in the VNS default non-
authenticated filter.
The elements that make up the Captive Portal Web Page (Login and Index, Topology Changes),
allow administrators to customize the internal Captive Portal page, this same Editor can be used for
Guest Portal and Guest Splash.
Note: The Captive Portal Editor page supports one administrator editing a captive portal page at one
time.
Once the Captive Portal configuration has been completed, it can be displayed to view how the
Captive Portal web page will look to users by clicking on the Preview button in the Design
Management section.
The Message Box will be displayed above the Login box to greet the user. The message could
explain why the Captive portal page is appearing, and provide instructions for the user or support
information.
Create the VNS, which pulls together all the components that make up this Captive Portal VNS.
Once the WLAN Service, Non-Authenticated Policy, and Authenticated Policy are selected from the
down-down boxes, Save the configuration. Once the VNS is saved the configuration will be
propagated to the selected APs configured within the WLAN Server. The SSID will then be
broadcasted to available WLAN clients and the Virtual Interface will be created and assigned the
Layer 3 IP address which was defined in the topology section.
As part of the RADIUS Accept message there are several standard attributes that can be returned
which can assist in altering a WLAN clients behavior after the authentication process has concluded.
Filter-ID (RADIUS standard option 11) the Filter ID attribute can be returned by the RADIUS server
to assign the authenticated session a filter/policy other than Default. The return value is an ASCII
string that matches a Policy Name defined in the VNS configuration. For example, the Filter-
ID:Employees or Filter-ID: Enterasys:version-1:policy=Employees will assign the Topology and Filter
Rules that correspond to the Employee Policy.
Session-Timeout (RADIUS Standard option 27) the session timeout variable can be returned by the
RADIUS server to place an absolute time limit on the status of authenticated on the WLAN client.
After time (in minutes) has expired the client session is automatically marked as non-authenticated;
their filter set changes back to Non-Authenticated and they are subject to captive portal
authentication again.
In the example above, the WLAN client had requested a web site outside of the non-authenticated
filter and has been redirected to the Internal Captive Portal page for authentication where the WLAN
client credentials are entered for authentication purposes.
Reports: Active Clients by VNS shows that the WLAN client was given an IP Address and assigned
the Non_Authenticated Policy, the non-authenticated filter.
Note: If DNS is not able to resolve the requested Web site the redirection will not occur.
As displayed within this example, the Enterasys WC: Events Logs display user Student was properly
authenticated and was assigned the default authenticated filter Authenticated therefore the user will
be able to access the network with restrictions. The Report: Active Clients by VNS shows that the
Auth/Priv is equal to Int. Captive Portal (CP), the authenticated user Student and the Policy
Authenticated, the Default Authenticated Policy defined for the Captive Portal VNS.
As displayed within this example, the WC: Events and Report: Active Clients by VNS show that the
user Trainer was authenticated successfully and the Filter-ID Employees was returned from the
RADIUS server during the authentication process. The WLAN client is able to access the network
without any restrictions.
GuestPortal is similar to internal Captive Portal, where it provides WLAN clients temporary guest
network services, except that User Account information is stored in a database on the Controller
instead of an external authentication server. The database is administered through a simple, user-
friendly graphical user interface that can be used by a non-technical staff member.
When the WLAN client associates to the network it receives an IP address according to the topology
of the Guest Portal VNS. The users initial filter set is called non-authenticated. This filter set is
defined in such a way to allow the WLAN client access to the portal page and to DNS resolution but
little else. By default, all non-authenticated users that are participating in a network that are using
either the internal or external captive portal have their blocked traffic checked by a module called the
redirector.
This component reads the clients stream of data looking specifically for a HTTP GET request to a
resolvable IP address. When this is found the client is redirected to the web server that will be used
for authentication.
In the case of Guest Portal, once at the redirected site the WC integrated web server will present the
user with a form that is accessed through HTTPS. The user enters their credentials and submits
them to the web server, which passes them to the WC for authentication. If the WLAN client
credentials are successfully authenticated, the client is then bound by the Default authenticated
policy (topology/filter rules) defined for the VNS. At this point the client is typically sent to their
original destination or to a Redirection URL.
The GuestPortal administrator is assigned to the GuestPortal Manager login group by the
Administrator. The GuestPortal administrator can only create and manage guest user accounts. Any
user who logs on to the Wireless Controller and is assigned to this group will only be allowed access
to the GuestPortal Guest Administration page of the Wireless Assistant if there is a GuestPortal
WLAN Service configured.
A GuestPortal administrator cannot access any areas of the Wireless Assistant and CLI other than
the GuestPortal User Administration Page. From the GuestPortal Guest Administration page of the
Wireless Assistant you can add, edit, configure, and import and export Guest Accounts.
GuestPortal account ticket can be viewed and printed from the GuestPortal Guest Administration
screen. A GuestPortal account ticket is a print-ready form that displays the guest account
information, system requirements, and instructions on how to log on to the guest account.
The Enterasys WC is shipped with a default template for the GuestPortal account ticket. The
template is an html page that is augmented with system placeholders that display information about
the user.
A customized GuestPortal ticket page can be uploaded to the Wireless Controller. When designing
your customized GuestPortal ticket page, be sure to use the guest account information placeholder
tags that are depicted in the default Guest Portal ticket page.
Only one template can be active at a time. The template cannot contain Javascript or Executables,
and the HTML (.html) file must be able to be printed from the browser.
Note: The GuestPortal account information placeholders used in the html code are preceded by the !
character.
The GuestPortal Virtual Network Service (VNS) can be created as a new VNS or can be configured
from an already existing VNS. The Wireless Controller is allowed only one GuestPortal-dedicated
VNS at a time. Under the Guest Portal configuration section of the VNS you can perform the
following functions outside of configuring the page itself:
Manage Guest Users - allows you to add and configure guest user accounts.
Configure Ticket Page - allows you to upload a custom GuestPortal ticket template, which is
the ticket that is printed and given to the guest.
Guest portal limit for concurrent sessions per account
The option is configured globally for the guest portal
Can define between 1-10 or unlimited concurrent sessions
Reduces the number of non-authenticated portal connections on the Guest Portal, a symptom with
Apple devices that have multiple connections before authentication.
HTTP requests coming from non-authenticated clients are redirected to the internal/external/guest
portal page if and only if the HTTP "User- Agent" header data field in the request contains a keyword.
Maximum Concurrent Session can also limit the number of devices a Guest can authenticate onto
the network.
By selecting the Add Guest Account button the Add Guest User screen is displayed. Create the
credentials for the user including the Username, User ID, Password and description. A User ID prefix
is added to all guest account user IDs. The default is Guest and the password is auto-generated;
however, the default password and User ID prefix can be modified.
Other values of interest include the Account Lifetime, which specifies the number of days that the
account will be active. Maximum Session Lifetime is the allowed cumulative total in hours spent on
the network during the account lifetime (0 indicates there is no session lifetime restriction).
Lastly, specify a Start time for the session for the new guest account and the End Time. For example,
in a Hotel environment this would be the check-in date and the check-out date for a guest.
A Guest Account must be enabled in order for a wireless device to use the guest account to obtain
guest network services. When a guest account is disabled, the account will continue to remain in the
database. However, the account will not provide access to the network.
When creating the .csv file for importing use the format above, Columns A D are the User
Credentials (User ID, User Name, Password and Description), Column E specifies the Account
Activation Date, and Columns F and G are reserved for the Account Lifetime (Days) and Session
Lifetime (Hours). The data in Column H will enable or disable the account and other parameters also
include the (I) Time of Day, start time, and (J) Time of Day, duration.
The Values of Column K to L are reserved for the Controller, so these values should be left as (0).
To help administrators manage large number of guest accounts, you can import and export .csv
(comma separated value) guest files with the Wireless Controller. To import the .csv files select the
Import Guest File from the GuestPortal Guest Administration screen. In the File Management
Section, click to Import Guest files. The Import Guest File dialog will be displayed; browse to
navigate to the location of the .csv file and select it to Import.
To export a guest file, select File Management, Export Guest File and click Save As or Save. The
default, exported file is named exportguest.csv.
GuestPortal and Availability are both supported to allow guests to access the network when the
home controller fails. The guest accounts are synced automatically between the availability pair if
Synchronize Guest Portal Account is enabled.
The GuestPortal VNS and accounts must be similar to prevent overwriting of account records. If on
one controller the GuestPortal VNS is removed it will be removed on both Controllers when
Synchronized Guest Portal Account is enabled.
Once you select the Auth and Acct tab, in the Authentication Mode drop-down list, select
GuestPortal, then Save the configuration. Once the settings have been saved you can then
Configure the Captive Portal/GuestPortal setting for access.
The configuration screen allows the administrator to create the Web Page using the Captive Portal
editor or a .zip file can be updated.
When uploading custom Captive Portal content via a .zip file, the contents of the zip must adhere to
the following file format and structure.
The zip file must have a flat structure and cannot contain any sub-directories.
The Captive portal login page must be in a file named login.htm
The Captive portal index page must be in a file named index.htm
The number of graphics and the size of the graphics is unlimited, and can be either .gif, .jpg,
or .png.
Once the zip file has been Save, remember to Save the setting on the Auth and Acct page to save
the information that was applied in the Captive Portal Settings screen to the WLAN Service.
Create the GuestPortal VNS by specifying the VNS Name WLAN Services Portal_VNS, the Non-
Authenticated Policy Non_Authenticated and the Authenticated Policy Guest. Enabling the VNS
will add the VNS to the database and VNS information will be pushed down to the APs for WLAN
Client services. A Wireless Controller is allowed only one GuestPortal dedicated VNS at a time.
The WLAN client in this example has selected a website (http://www.enterasys.com). A FQDN can
be used if DNS is properly configured in your environment, otherwise the Controller will not redirect
to the login screen. The default certificate installed on the Wireless Controller will display a security
warning. To avoid this install a customized certificate on the Controller. Once the Controller redirects
to the internal web site, enter the Login and Password information that was given by the
Administrator.
Guest Splash provides minimal authorization. Login information is not required, however an email
address can be collected to provide identify information about the user, when the user is re-directed
to the authorization Web page. The user is only required to select a button to agree to the terms and
conditions to be allowed access to the network.
The Authentication request is logged by the Controller. Here you can see that the user Guest-jdoe
has authenticated successfully. GuestPortal start and end sessions are logged. The logs are only
available to Controller administrators; Guest Manager administrators do not have access to this
information. The GuestPortal login events are displayed in chronological order.
The Active Clients report shows the User that has been authenticated.
The wireless system allows multiple Wireless Controllers (up to 12) to discover to each other and
exchange information about a client session for true mobility. This feature enables a wireless device
to roam seamlessly between different wireless APs on different Wireless Controllers. Mobility is
especially important in a routed environment where the user will be able to roam and continue to use
the original IP address that it received from its Home Controller.
The wireless device retains its Policy assignment (topology, IP address, rate profiles and filtering
rules) it received from its home Wireless Controller - the Wireless Controller that it first connected to.
The VNS components on each Wireless Controller must have the same SSID and RF privacy
parameter settings so that it can be supported in a Local or Branch Office Setting and it easy to
deploy on an existing IP network.
The goal of Mobility is to provide the user with a seamless mobility experience in a Multiple Controller
deployments by sharing session registration information.
The solution introduces the concept of a Mobility Manager and Mobility Agents. One Wireless
Controller within the network is designated as the Mobility Manager and all others are designated as
Mobility Agents.
The Mobility Manager is a single system identified by the administrator that will manage the state of
the mobility domain. Once identified, the Manager will accept Mobility Control session connection
attempts from Mobility Agents. The Manager is responsible for the management, aggregation and
distribution of client session information to all Agents.
Once configured, the Mobility Agent will locate the Manager either using SLP Unicast or a static
configuration and will establish a Mobility Control session (TCP port 60606) with the Manager. The
Agent also processes the client session updates provided in the regular heartbeat messages sent by
the controller so that it can build a complete list of controllers in the mobility domain by
membership/location. The Backup Mobility Manager runs as an agent, but monitors the Mobility
Control Session to the manager status.
Once the Mobility Session is established the Agent will then retrieve the list of all other controllers in
the domain and proceed to set up the mobility data network by initiating a Data Tunnel (13910/UDP)
to each one of its peers. This data network will become a full-mesh once the mobility domain is up
and will be used as a tunnel to forward a roaming clients packets between the foreign and home
controller.
In an Intra-Controller Roaming scenario, when a user roams on the same SSID across APs on the
same Controller, the control plane simply updates the Mobile Unit (MU) session referencing the new
AP or Radio Unit (RU). All the session information such as VNS, authentication, IP address, and
Policy remains intact. The Intra-Controller roaming latency is measured at around 8ms.
In addition to managing roaming activity across APs associated to a single controller, mobility
extends this service to multi-Controller deployments or the Inter-Controller Mobility scenario.
When a MU (MU1) starts a new session with a mobility domain, the first controller it connects to is
identified as its Home Controller (Controller1).
When an Mobility Agent (Controller 2) receives a new MU/wireless association request, it will first
check in its local table to determine if the MU already has a session and then determines whether
this client belongs to a controller within the mobility domain and determines its Home Controller. If a
session does exist, the Mobility Agent accepts the client and then updates the Mobility Manager with
the new whereabouts over the Mobility Control Session tunnel and begins tunneling the clients data
to and from its Home Controller over the CTP tunnel that is established between the Controllers.
The WLAN client/MU will continue to maintain its network point of presence and all of its session
properties (VNS, IP, authentication state) and all traffic will flow through the Home Controller.
If an Agent fails, the Manager drops its wireless clients from the Mobility Information Tables and
updates the remaining Agents. Since there is no longer a Home Controller where to tunnel the
clients data, these clients will be disassociated by their current Controller. The dropped clients will
have to associate again and become local on that new Controller.
If the Manager fails, the Backup Manager, if defined will assume the role of the Mobility Manager.
The TCP control tunnels will be renegotiated between the Backup Manager and the Agents. Once
the Primary Manager comes back online, the Backup Manager will go back to its Agents role.
If there is not Backup Manager, the Agents will freeze their current copies of the Mobility Information
Tables and proceed to drop/disassociate the clients homed on the Manager. The remaining clients
included in the mobility tables will continue to have roaming capabilities since the data tunnels
between the agents are still operational even though the control tunnels to the manager are down.
Any new client received from this point will only be local to that Controllers domain and not be able
to roam within the mobility domain.
Because of the tight interaction between the Mobility Controllers, different versions of software are
NOT supported. This means that all Wireless Controllers in the mobility domain must be running the
same Wireless Convergence Software release and the Controllers in the Mobility Domain should
also be using a common source for time synchronization (an NTP server).
At least two controllers at a minimum are needed to set up a mobility domain. One of them should
be setup as the Mobility Manager and the other a as Mobility Agent. The Mobility settings in the GUI
are found under the Wireless Controller > Mobility Manager. To enable Mobility check the Enable
Mobility checkbox on the potential Mobility Manager.
On the Mobility Manager, select This Wireless Controller is a Mobility Manager option. Select the
Port (esa0 10.170.200.10) through which to listen for Agent connections. Select the Security Mode
to Allow all mobility agents to connect, then save your settings. Mobility will be activated.
In a protected domain, select Allow only approved mobility agents to connect. When new Agents
attempt to connect to the Mobility Manager they are placed in the pending state until they are
approved by the administrator; you can also add new Agents manually during configuration time.
Administrators may also remove any controllers from the domain by deleting the record from the
Permission List.
Note: Care should be taken to load balance the Wireless APs and Mobility through the same port.
For large deployments, balancing Wireless AP/Client traffic, Mobility Tunnel traffic, gateway/internet
traffic through the different available esa/PC ports requires the analysis of network usage forecasts
(or current traffic statistics) against port line rates in order to determine the best configuration.
To enable Mobility check the Enable Mobility checkbox on the potential Agent. On the Mobility Agent
check the Enable Mobility checkbox, select This Wireless Controller is a Mobility Agent option.
Select the Port (esa0 10.170.200.11) through which to reach the mobility Manager. Then select the
Discovery Method to be Static Configuration and enter the Mobility Manager Address 10.170.200.10.
Save your settings. The Mobility Subsystem will be activated and a tunnel will be created between
the Manager and Agent. If a Backup Manager is configured by the Mobility Manager it will be
displayed.
Centralized mobility is a means of ensuring that a single specific controller in a mobility zone hosts
the sessions of all stations accessing the network via a specific WLAN Service/SSID. This is useful in
cases in which you do not want to offer the back-end portion of the service on multiple controllers in
the mobility zone or when you cant do so. Centralized mobility is particularly useful for guest portal
services in a mobility zone, since you only have to maintain the guest registrations on one controller.
Centralized mobility and standard mobility both work with bridged at AP, bridged at controller and
routed topologies. The choice between centralized and standard mobility has no effect on whether a
stations traffic is tunneled back to the controller, only the choice of topology determines that.
Note: If using any type of Captive Portal with centralized mobility, be sure that the number of
concurrent sessions expected on the remotable WLAN Service is no greater than the controllers
session system limit.
An administrator designates one or more WLAN Service on one or more controllers as remotable,
thereby making a VNS available for centralized mobility instead of for standard mobility.
The Mobility Manager in the mobility zone gets the list of remotable WLAN Services (SSIDs) from
each controller in the mobility zone. The Mobility Manager pushes/updates the consolidated list to
each Mobility Agent in the mobility zone.
The administrator will then define a remote WLAN service on each Mobility Agent that will provide
APs for the remotable service:
Administrator assigns privacy & QoS settings to the WLAN Service locally
Privacy settings MUST match across all WLAN services on which the service is remote
QoS settings should match across all WLAN services on which the service is remote
The administrator then picks the SSID for the remote WLAN Service from the list of remotable WLAN
Services maintained by Mobility Manager.
After saving, configure the remote settings, the settings must match those of the remoteable WLAN
Service on the host WC.
- Assign APs
- QoS
- Privacy
- Advanced Settings RF Settings (Suppress SSID, Enable 11h support, Process client IE
requests or Energy Save Mode)
Auth & Acct options are not available, since they can only be configured on the home controller
A Remote WLAN Service can be in an active or inactive state, a service becomes inactive when the
connection to the mobility zone is lost. When the service is inactive, it is removed from APs to avoid
creating a black hole for roaming clients. When a tunnel becomes available the service is re-
activated at the WC and APs.
The Remotable VNS Information list all SSID exported as remotable by any controller in the mobility
zone.
When a Wireless Controller has been configured as a Mobility Manager, an additional reports appear
as options on the Reports and Displays screen, the Client Location in Mobility Zone, which displays
the active wireless clients and their status.
Mobility Tunnel Matrix provides a cross-connection view of the state of inter-controller tunnels, as
well as relative loading for user distribution across mobility domain.
Green The mobility manager is in communication with an Agent and the data tunnel has
been successfully established
Yellow The mobility manager is in communication but the data tunnel is not yet
successfully established.
Red The mobility manager has no communication with an Agent and there is no data
tunnel.
This report also provides a view of the tunnel uptime, the number of the clients roamed and the
Mobility membership list.
Combining the Mobility feature with the Active Backup capabilities allows for interleaved
deployment of the AP. It also provides for an alternate blanket of coverage in the event of an outage
associated with one controller. The second controllers resources provide backup connectivity and
RF blanket for users.
In the Scenario above the two controllers are in Active Backup with Mobility enabled. During
normal operation, users can roam seamlessly between controllers, however, on failover users
connected via an unavailable controller (including those that had roamed across a mobility domain)
must re-register and re-authenticate with the Foreign controller (clients will need to negotiate a new
IP address). Users connected locally via the Foreign controller remain unaffected.
In a typical failure AP to WC communication is interrupted, by either the failure of the network or by
WC failure. Depending on the topology of the VNS configuration, once the connection has been
determined to be down the AP will start the discovery process. The discovery process will continue
for 5 minutes and if there is no success in connecting to the controller the Wireless AP will reboot
and all WLAN client sessions will terminate, as shown in the case of AP1.
If the AP is configured for a VNS with a Bridge traffic locally at AP topology associated to it, and if the
Maintain client sessions in event of poll failure option is enabled in the Advanced AP Properties or
AP Default Settings screen, all client sessions will be maintained and traffic will continue to flow for
that specific AP; in this case AP2.
If the AP is configured for a VNS with either a Bridge Locally @ Controller topology or a Routed
topology associated to it, all client sessions in those VNSs will fail.
The purpose of the Availability feature is to provide a controlled means for Access Points to find an
alternate controller in the event of controller or network failure. The Access Point will connect to the
alternate controller and restore the service with minimal disruption to a WLAN client.
All thin APs monitor the status of their CTP tunnel connection to their home/local controller. However,
if the connection to the controller fails the AP will establish a new data channel or CTP tunnel to the
secondary or foreign controller.
There are two types of Availability supported on the Controllers:

Legacy or Normal Availability
Fast Failover with Session Availability
The choice of availability implemented in your environment will depend on several factors, such as
the Network Infrastructure, bridged vs. routed VNS topologies, type of failover scenarios you
anticipate, location of the controllers, and the types of WLAN clients.
After a loss of three CTP polls the Wireless AP will move into the failover state and attempt to
connect automatically to one of the interfaces that were exchanged by the Availability Tunnel.
The two Controllers in an Availability Pair provide backup for each others Access Points (APs). One
controller is defined as the Primary and the other as the Secondary or Backup Controller. The
Primary controller is the owner of the Availability tunnel and is responsible for establishing
communication to the Secondary Controller. This tunnel is used to pass control and configuration
information (information on all registered APs and about each interface that is active), thereby
synchronizing Wireless AP membership information between the two controllers. Heartbeat
messages are also communicated over the tunnel. As Wireless APs are added or deleted from each
Controller, updates are synchronized between the controllers.
The Availability tunnel connection is usually established through one of the routable interfaces
(esa/PC) but the management interface can also be used.
Note: The port selected should be chosen based on the most reliable link between the two
controllers. The Availability protocol is light on the use of bandwidth with an average load of 1
packet/sec and will not affect a load-sharing network design.
During the failover event, Foreign APs and Sensors do not count as Active APs in regards to the WC
license. The maximum number of failover APs the secondary controller can accommodate is equal to
the maximum number of APs supported by the hardware platform, not the value of the installed
license for the Local Controller. Controller Deployments with un-matched controller attributes (Max
AP capacities) may cause problems.
Software versions on controllers and AP must match, otherwise, failovers may result in automatic AP
firmware upgrades which will introduce a significant service interruption.
For maximum deployment flexibility and lower deployment costs, cross-regulatory domain
redundancy is supported. Allowing a controller deployed in the US with an FCC regulatory domain
license the ability to back up a controller located in Germany with an ETSI regulatory domain license.
This flexibility allows for disaster recovery designs that can expand across the globe while reducing
CAPEX/OPEX costs by as much as 50%.
Note: Foreign Aps cannot be reconfigured and continue to operate with the powers/channels
prescribed from the home controller
Using a Bridged Locally at HWC topology with the same VLAN ID on both Local and Foreign
controller reduces the impact of a fail-over event. WLAN clients will retain their IP addresses as their
DHCP scope is the same.
To ensure that Failover will work properly without impacting users you will need to ensure network
accessibility for the Availability tunnel (UDP 13911) between the two Controllers. Also, to ensure that
the failover performs seamlessly, configure the DHCP server in the environment with the DHCP
Option 78 (SLP) configured to include the IP addresses of the physical interfaces on both the local
and foreign Wireless Controllers.
In a Legacy Failover (no Fast Failover or Session Availability), after a loss of three CTP polls the
Wireless AP will move into the failover state and attempt to connect automatically to one of the
interfaces that were exchanged by the Availability Tunnel.
An availability interface lists identifies the local active interfaces on the primary/local controller and
backup controllers. The list is sorted by top-down priority. If the active link is lost (poll failure), the
Wireless AP automatically scans (pings) all addresses in its availability interface list. The Wireless
AP will then connect to the highest priority interface that responds to its probe.
Once the APs have connected to the secondary/backup Wireless Controller, they are either assigned
to the WLAN Service that is defined in the systems default AP configuration or to a WLAN service
that was manually configured by the administrator. The WLAN clients log on again and are
authenticated on the secondary Wireless Controller. If you want the WLAN clients session to be
maintained, you must use the Fast Failover with Session Availability feature that enables the primary
controllers Wireless APs to failover to the secondary controller fast enough to maintain the session
availability (user session).
Note: Network equipment failures may lead to situations when AP loses connectivity with active
controller but the controllers themselves are unaffected. AP will not be allowed to register with the
failover controller in this case and will be forced to re-register with its Local controller. This prevents
inadvertent registration with Foreign controller
In Fast Failover Scenario the AP stores the configuration from the Home Controller and the Foreign
Controller. The Wireless APs connect to both the primary and secondary Wireless Controllers. The
connectivity to the primary Wireless Controller is via the active tunnel; the connectivity to the
secondary Wireless Controller is via the backup tunnel.
The Wireless AP establishes the active tunnel to connect to the primary Wireless Controller. The
Wireless Controller sends the configuration to the Wireless AP. This configuration also contains the
port information of the secondary Wireless Controller. On the basis of the secondary Wireless
Controllers port information, the Wireless AP connects to the secondary controller via the backup
tunnel. After the connection is established via the backup tunnel, the secondary Wireless Controller
sends the backup configuration to the Wireless AP. The Wireless AP receives the backup
configuration and stores it in its memory to use it for failing over to the secondary controller. All the
while, the Wireless AP is connected to the primary Wireless Controller via the active tunnel. The
deployment is designed in such a way that the services provided to the Wireless Client (such as
DHCP services) should not be dependent on the Wireless Controller the APs associate with.
Therefore service downtime can be reduced significantly, independent of the number of APs. This
deployment will provide a failover fast enough to preserve voice calls.
The fast failover feature will not support the deployment in which the two Wireless Controllers in
availability mode are connected via a WAN link. The fast failover feature works optimally in fast
networks (preferably switched networks).
Note: when Secure Tunnel enabled the tunnel key information is not shared between the Primary
and Foreign Controller.
Fast failover works equally well in network and controller failures. If the Primary or Local Controller
goes down, the Foreign controller detects the loss (Link Timeout) of its Availability Peer and sends a
WASSP-PEER-DOWN packet to the AP.
If the Link between the Primary and Local Controller goes down, the AP will wait until the Poll
Timeout expires. The AP will then initiate the Failover without the help of the Foreign Controller.
In both cases once the AP receives the WASSP-TNL-ACTIVATE-RESP the AP applies the backup
configuration and starts sending data.
Session Availability feature preserves client sessions (e.g. voice calls) through a failure of the
controller in an availability pair. In session availability, users do not have to have to re-authenticate
after the failover and they retain their IP addresses.
Session availability is enabled automatically when Fast Failover is enabled between the primary and
backup controller. The Session Availability feature is an attribute of a VNS; therefore it is configured
in the topology section of the VNS. Only the Bridged VLAN configuration is recommended for use
Session Availability because during a failover scenario the client will not have to obtain a new IP
address. DHCP addresses should be provided by the external DHCP server and both VNS
topologies must be mapped to the same VLAN on both controllers.
You must always use the following authentication mechanism for the fast failover w/ session
availability configuration:
Wired Equivalent Privacy (WEP)

Wi-Fi Protected Access Privacy-Pre-Shared Key (WPA-PSK)
On both Wireless Controllers, setting the Registration Mode to Allow only approved wireless APs to
connect creates a secured environment so that no Wireless APs can register unless they are
approved by the administrator.
Note: If two Wireless Controllers are paired and one has the Allow all wireless AP to connect option
set for Wireless AP registration, all Wireless APs will register with that Wireless Controller.
The Availability Screen allows the administrator to manually configure availability or to use the
Availability Wizard. On the Availability screen under the Wireless AP tab, set the Controller settings
to Paired. This will enable the availability pair and create the availability tunnel between this
Controller and the IP Address specified in the Wireless Controller IP Address. Selecting the Current
Wireless Controller is primary connection point and indicates that this controller will send a
connection request to the non-primary Controller.
The Global Synchronize Option Synchronization System Configuration, if enabled, will push the VNS
components from the primary controller to the peer controller when VNSs are configured. To change
this default behavior on a per VNS definition basis uncheck the Synchronize box in the individual
VNS component.
The Synchronize Guest Portal Accounts will synchronize Guest Portal Accounts when modifications
are made to the User database (Add, Edit, Delete).
The Global VNS Sync Summary screen provides an overview of the synchronization status of paired
controllers. The screen is divided into 4 sections: Virtual Networks, WLAN services, Policies and
Topologies. Each section lists the name of the corresponding configuration object, its synchronization
mode, and the status of last synchronization attempt.
Sync Summary option is only displayed in the Global VNS Configuration when Availability is enabled.
The Synchronize Status Field can have one of the following options: Synchronized, Not
Synchronized, Failed, Conflict (with a button called Resolved).
Conflict status will be displayed if there was an update on a controller, but the availability link was
down between the controllers. The Resolve button lets you choose which version of the object
should be taken, local or remote, once the availability link is active.
The Administrator can also change the global Synchronize System Configuration parameter and the
Synchronize option on a per VNS component.
Availability relies on the Poll Timeout configured on the AP Properties. When the Poll Timeout
expires the AP will then re-attempt to establish a link to the primary Wireless Controller.
The Detect link failure value specifies the time period within which the system detects Availability link
failure after the link has failed.
To obtain the optimum results in Failover, the timeout used for APs should be in range of 1.5-2 times
of Availability Detect link failure timeout.
If the Poll Timeout value is less than 1.5 to 2 times the Detect link failure value, the Wireless AP
failover will not succeed because the secondary controller will not be 'ready' to accept the failover
APs.
On the other hand, if the Poll Timeout value is more than 1.5 to 2 times of Detect link failure value,
the Wireless APs failover will be unnecessarily delayed, because the Wireless APs will continue
polling the primary controller even though the secondary controller is ready to accept them as
failover APs.
The quick deployment and matching of APs to VNS Assignments can be accomplished through the
use of AP Default Settings to ensure the same set of corresponding VNSs on both controllers. The
default AP Settings template is used to provide initial configurations for APs.
If a system default AP configuration does not exist for the controller (and the administrator has not
assigned the failover Wireless APs to any VNS), the APs will not be assigned to any VNS during the
failover.
When the failed Wireless Controller recovers, each Wireless Controller in the pair goes back to
normal mode. The exchange information includes the latest lists of registered Wireless APs. The WC
administrator controls the fail-back You must release the Wireless APs manually on the
secondary/backup Wireless Controller, so that they may re-register with their home Wireless
Controller. Wireless users will experience a short interruption while their session is reestablished on
the Local Controller.
Foreign APs can be released at once by using the Foreign button on the Access Approval screen to
select all foreign APs, and then clicking Release. In a load balancing situation, Foreign APs may also
go back to the Local Controller if there was a failover situation that occurs on the Foreign controller.
Note: The Controller system has been optimized to react quickly in the event of a failover. The
release of APs after the fail-over is expected to be a supervised operation and may take noticeably
longer time than the fail-over.
At start-up both Wireless Controllers will move into failover mode temporarily while the systems finish
booting and all application services are started. The primary Wireless Controller periodically re-polls
the secondary Wireless Controller and will re-establish the connection when both systems become
operational. However, if Wireless APs have roamed to a foreign controller during this brief interval
manual intervention is required to send them back to their home connection point Wireless
Controller.
To verify the Availability feature is configured correctly: From the main menu of either of the two
controllers, click Reports and Displays. The Reports & Displays screen is displayed. From the
Reports and Displays menu, click Wireless AP Availability. The Wireless Availability Report is
displayed.
When looking at the Report if the statement reads Availability Link is Up, the availability feature is
configured correctly and both Controller are active. If a Controller goes down the status will change
to Availability Link is Down. Information about each AP that is connected to the Primary and
Secondary Controller is displayed, as well as the AP Name, Serial Number, MAC Address, IP
Address and Uptime of the AP.
Fast Failover maintains an active and backup tunnel. Therefore, when Fast Failover is enabled
tunnel connections are displayed in the reports. The larger pane of the box respresents the state of
the tunnel that is established to the current WC (local). For example, the Wireless AP Availability
report is showing that all APs are currently being managed by their Local Controllers and have
connected backup tunnels. In a non-failover situations Foreign APs should have a Blue box; a Green
box would indicated a Failover situation.
If the Availability Link is Down then the status to the backup/secondary conntroller will display no info.
Keeping in mind that only Controllers that have active tunnels to the AP can display the statistics of
APs and their WLAN connections. During a failover situation the Active Wireless APs Report will
display statistics from both the Local and Foreign Access Points and their client connections.
If one of the Wireless Controllers in a pair fails, the connection between the two Wireless Controllers
is lost. This triggers a failover mode condition, and a critical message appears in the information log
of the remaining Wireless Controller: Availability: Moving into failover mode.
Availability can be configured by using the Availability Wizard or by manually creating the availability
pair. Start the Availability Wizard on the Controller that will be the primary connection point in the
Availability Tunnel.
The benefit of using the Wizard is that you can configure both controllers at the same time, select the
interface to use for the availability link, synchronize the configuration and Guest Portal database if
necessary. This reduces the chance of misconfiguration between controllers.
The Wizard will mirror the VNS components on the Controller Peer and modified the Layer 3 IP
addresses to match the values that were created using the Wizard.
Fast Failover the Link Detect timer and AP Poll Timeout can be set be set as low as 2 seconds for
the Link Detect and 4 seconds for the AP Poll Timeout. This value may need to be adjusted based on
the size of the network, the location of the controllers and APs.
Dynamic Mesh, a proprietary solution aligned with 802.11s Hybrid Wireless Mesh Protocol (HWMP) ,
non-register, proactive mode but is not fully 802.11s compliant, is extension of the WDS capabilities.
Static Mesh or Wireless Distribution System (WDS) is part of the IEEE 802.11 specification that
allows APs to use RF to provide both network access and data backhaul, making it possible to
extend the traditional network to less traditional locations without installing additional cable or fiber.
The AP supports links on either the 5 GHz or 2.5 GHz frequency bands. Therefore they can be
leveraged, yielding better overall performance and creating a far more scalable network. The Mesh
network is secure as it automatically negotiates pair-wise master keys to encrypt data using AES and
to secure links between each node so that data is never transmitted in the clear. Lastly, it is
completely integrated into Wireless framework (VNS, Availability, etc.)
Note: Dynamic Mesh is supported on all AP3xxx models only, excluding the AP3605. WDS or Static
Mesh is supported on all APs with the exception of the AP2605/AP3605.
IdentiFi Wireless Estimator Tool is good place to gain insight of the max distance between 2 APs in a
point to point configuration, it employs the compliance table that is loaded into the controller software.
Simply select the country, the AP type, the mode/band/link rate/channel and it will report the
distance. The assumption here is that the receiving end is another AP. It will report the max TX/data
rate that the AP can transmit to.
The Estimator Tool can be found in the Extranet under the Tools and Resources tab for Access
Points.
https://extranet.enterasys.com/downloads/Pages/WirelessAccess.aspxp
A Simple Mesh configuration is used when a Wireless AP is installed in a remote location and cant
be wired to the distribution system (DS). A Root or Mesh Portal Wireless AP is connected to the
distribution system via an Ethernet link. This intermediate Wireless AP forwards and receives the
user traffic from the remote Wireless AP, also called a Satellite or Mesh AP, over a radio link.
If there is a Wireless AP between the Root/Mesh Portal and Satellite/Mesh AP, it is used to relay the
user traffic; this AP acting as a Repeater. A Repeater AP relays the user traffic between the
Root/Mesh Portal and the destination Mesh AP/ Satellite AP is acting as both a child and a parent,
thus increasing the WLAN range. When configuring WDS in a Wireless Repeater configuration, you
should limit the number of repeaters to 3 for optimum performance.
In the Wireless Bridge configuration, the traffic between wireless APs that are connected to two
separate wired LAN segments is bridged via a Mesh link; this is also referred to Workgroup Bridge.
To avoid loops, make sure that it the remote wired LAN is a truly isolated segment with no other
connections to the wired network since the Mesh solution does not offer protection from loops.
Mesh AP is connected only to one parent/Root AP at a time, a Repeater and Satellite AP may
connect an isolated Ethernet segment to the wired network, limiting the number of hops in the tree
reduces the latency and provides better performance because packets are duplicated on each hop.
Note: For WDS it is recommended to limit 8 APs per tree (including the root) for DATA and use only
2 APs per tree (including the root) for VOICE.
Note: The limit of APs participating in a Mesh tree is 50..
The Wireless APs in a Mesh Network configuration form a tree-like structure. The tree builds in a top
down manner with the Root / Mesh Portal Wireless AP being the tree root, the Mesh AP / Satellite
Wireless or Repeaters being the tree leaves. The Wireless AP that provides the Mesh service to the
other Wireless APs in the downstream direction is called a parent. The Wireless APs that establish a
link with the Wireless AP in the upstream direction for Mesh service are children. The Controller can
be set up with either a single WDS/Mesh VNS or multiple WDS/Mesh VNSs. If a VNS shares a single
WDS/Mesh, it uses the same SSID and a single pre-shared key for the links. The tree can have
multiple roots. In a multi-Mesh environment two independent WDS/MESH trees will be created and
each tree will operate on separate SSIDs and use separate pre-shared keys.
The Parent AP enables WDS IE in the beacon once it is connected to the Controller and announces
its AP Name using a proprietary IE (SSID is not suppressed). The child AP scans for the preferred
parent and/or backup parent on the radio defined in the WLAN Service. When found it will connect to
the parent AP using a proprietary protocol and establish a WDS/Mesh link.
When an AP starts the discovery process in a Mesh environment the AP will obtain its IP address
using a DHCP Request that is broadcasted through the link until it reaches the controller. The DHCP
response will be transmitted down through the Mesh link until it reaches the AP. The AP will register
to the Controller over the Mesh link and then the Controller manages the Mesh AP as any other AP.
The Repeater AP tunnels traffic through the Mesh bridge, not through its own tunnel to the Controller.
Once the Mesh/WDS link has been established between the parent and client, the link is monitored.
In a WDS environment, heartbeat messages are exchanged in the form of Poll_Req messages are
sent from the client AP to the parent AP. The parent is responsible for responding to the polls with a
Poll_Resp. The parent AP will disconnect the WDS link if no traffic or no Poll_Requests are received
for 20 seconds. Once the link is broken between the parent and child the child will attempt to
automatically discover its backup parent by performing a full scan of the (2.4 or 5GHz) band. In the
Static Mesh configuration or WDS, if a backup parent is not defined, the child AP will be left stranded.
Mesh AP uses the Beacons from the parent to detect its presence. Mesh AP monitors other potential
parents while connected to the current parent. Mesh AP changes to another parent either because
parent is lost (Consecutive Beacon loss) or there is a parent with significantly better link quality (self-
healing). In the both cases, the Mesh AP transfers to the new parent without a need for a full scan.
The Mesh AP does a full scan if there is no other available parent or on the startup.
During the transition from parent to backup parent service to clients is lost.
Mesh can co-exist with WDS WLAN (used with statically defined).

Routing and Wireless Boot Camp Student Guide Version 2.0

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Routing and Wireless Boot Camp Student Guide Version 2.0

Enviado por

Direitos autorais:

Formatos disponíveis

Enterasys Educational Services

Routing and Wireless Boot

For additional information refer to:

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 2

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 18

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 19

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 23

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 24

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 25

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 26

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 28

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 29

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 30

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 31

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 32

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 33

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 34

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 35

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 36

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 37

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 38

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 39

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 40

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 41

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 42

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 43

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 44

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 45

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 48

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 56

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 57

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 58

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 59

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 60

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 61

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 65

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 66

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 67

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 68

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 69

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 70

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 71

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 72

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 73

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 74

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 75

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 76

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 78

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 79

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 83

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 84

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 85

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 93

Area 2 can be defined as 2 or 0.0.0.2

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 94

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 96

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 97

2013 Enterasys Networks, Inc. All rights reserved Enterasys Confidential 98

Configurable values defined:

IGMPv1 does not support unsolicited Joins or Leaves.

2013 Enterasys Networks, Inc. All rights reserved. 132

( *, G ) is created as the result of an explicit join occurring

RouterA(rw)->Router#<165>Aug 3 13:48:05 172.10.1.101 Router[1]router interface vlan 20, ip

2013 Enterasys Networks, Inc. All rights reserved. 186