Loading...

Follow Netprojnetworks Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Root bridge config:

SSID:

dot11 ssid BRIDGE
vlan 11
authentication open eap EAP-METHODS
authentication key-management wpa version 2
dot1x credentials EAP-FAST
dot1x eap profile EAP-FAST
infrastructure-ssid
!

5GHz radio config:

interface Dot11Radio1
no ip address
!
encryption vlan 11 mode ciphers aes-ccm
!
ssid BRIDGE
!
antenna gain 0
peakdetect
no dfs band block
traffic-stream priority 5 sta-rates nom-12.0 nom-24.0
traffic-stream priority 6 sta-rates nom-12.0 nom-24.0
speed basic-54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.
power local 14
power client local
packet retries 20 drop-packet
packet max-retries 3 0 fail-threshold 100 500 priority 5 drop-packet
packet max-retries 3 0 fail-threshold 100 500 priority 6 drop-packet
packet speed 12.0 24.0 priority 6
channel width 40-below
channel 5805
station-role root bridge
distance 1
dot11 qos class video local
admission-control
admit-traffic signaling infinite
!
dot11 qos class voice local
admission-control
admit-traffic narrowband max-channel 75 roam-channel 6
!
dot11 qos class video cell
admission-control
!
dot11 qos class voice cell
admission-control
!
!
interface Dot11Radio1.11
encapsulation dot1Q 11 native
bridge-group 1
bridge-group 1 spanning-disabled
!
interface Dot11Radio1.12
encapsulation dot1Q 12
bridge-group 12
bridge-group 12 spanning-disabled
!
interface Dot11Radio1.97
encapsulation dot1Q 97
bridge-group 97
bridge-group 97 spanning-disabled
!
interface Dot11Radio1.98
encapsulation dot1Q 98
bridge-group 98
bridge-group 98 spanning-disabled
!
interface GigabitEthernet0
no ip address
duplex auto
speed auto
bridge-group 1
!
interface GigabitEthernet0.11
encapsulation dot1Q 11
bridge-group 11
!
interface GigabitEthernet0.12
encapsulation dot1Q 12
bridge-group 12
!
interface GigabitEthernet0.97
encapsulation dot1Q 97
bridge-group 97
!
interface GigabitEthernet0.98
encapsulation dot1Q 98
bridge-group 98
!
interface BVI1
mac-address c84c.7547.1ed5
ip address 10.0.11.44 255.255.255.192
ipv6 address dhcp
ipv6 address autoconfig
ipv6 enable
!
ip default-gateway 10.0.11.1

Site A and B radio configs are identical with the exception of the station-role command (non root bridge)

SSID:

dot11 ssid BRIDGE
vlan 11
authentication open eap EAP-METHODS
authentication key-management wpa version 2
dot1x credentials EAP-FAST
dot1x eap profile EAP-FAST
infrastructure-ssid

interface Dot11Radio1
no ip address
!
encryption vlan 11 mode ciphers aes-ccm
!
ssid BRIDGE
!
antenna gain 0
peakdetect
traffic-stream priority 5 sta-rates nom-12.0 nom-24.0
traffic-stream priority 6 sta-rates nom-12.0 nom-24.0
stbc
speed basic-54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15. a1ssnone a2ssnone a3ssnone
power local 14
power client local
packet max-retries 3 0 fail-threshold 100 500 priority 5 drop-packet
packet max-retries 3 0 fail-threshold 100 500 priority 6 drop-packet
station-role non-root
dot11 qos class video local
admission-control
admit-traffic signaling infinite
!
dot11 qos class voice local
admission-control
admit-traffic narrowband max-channel 75 roam-channel 6
!
dot11 qos class video cell
admission-control
!
dot11 qos class voice cell
admission-control
!
!
interface Dot11Radio1.11
encapsulation dot1Q 11 native
bridge-group 1
bridge-group 1 spanning-disabled
!
interface Dot11Radio1.12
encapsulation dot1Q 12
bridge-group 12
no bridge-group 12 spanning-disabled
!
interface Dot11Radio1.97
encapsulation dot1Q 97
bridge-group 97
no bridge-group 97 spanning-disabled
!
interface Dot11Radio1.98
encapsulation dot1Q 98
bridge-group 98
no bridge-group 98 spanning-disabled
!
interface Dot11Radio1.315
encapsulation dot1Q 315
!
interface GigabitEthernet0
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0.11
encapsulation dot1Q 11 native
bridge-group 1
no bridge-group 1 spanning-disabled
!
interface GigabitEthernet0.12
encapsulation dot1Q 12
bridge-group 12
no bridge-group 12 spanning-disabled
!
interface GigabitEthernet0.97
encapsulation dot1Q 97
bridge-group 97
no bridge-group 97 spanning-disabled
!
interface GigabitEthernet0.98
encapsulation dot1Q 98
bridge-group 98
no bridge-group 98 spanning-disabled
!
interface GigabitEthernet0.315
encapsulation dot1Q 315
!
interface BVI1
mac-address 003a.7de0.0618
ip address 10.0.11.21 255.255.255.192
ipv6 address dhcp
ipv6 address autoconfig
ipv6 enable
!
ip default-gateway 10.0.11.1

Site A and B form EIGRP neigborship and receive the routes from the core switch

EIGRP-IPv4 Neighbors for AS(13)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.11.2 Vl11 14 01:18:20 12 200 0 1644

SITEA#show ip route eigrp
192.168.13.0/32 is subnetted, 2 subnets
D 192.168.13.1 [90/130816] via 10.0.11.2, 01:18:23, Vlan11
D 192.168.13.3 [90/130816] via 10.0.11.2, 01:18:23, Vlan11
155.1.0.0/24 is subnetted, 9 subnets
D EX 155.1.146.0 [170/282112] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.23.0 [170/307712] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.13.0 [170/282112] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.0.0 [170/26880512] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.5.0 [170/307712] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.58.0 [170/307712] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.45.0 [170/307712] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.37.0 [170/307712] via 10.0.11.2, 01:18:23, Vlan11
D EX 155.1.67.0 [170/307712] via 10.0.11.2, 01:18:23, Vlan11
169.254.0.0/24 is subnetted, 1 subnets
D EX 169.254.100.0 [170/282112] via 10.0.11.2, 01:18:23, Vlan11
10.0.0.0/26 is subnetted, 28 subnets
D 10.0.10.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.8.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.9.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.14.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.15.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.12.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.13.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.2.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.0.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.4.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.5.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.18.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.19.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.16.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.17.0 [90/3072] via 10.0.11.2, 01:18:23, Vlan11
D 10.0.39.0 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.72.0 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.66.0 [90/3328] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.0.64 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.6.64 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.98.0 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.97.0 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.0.128 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.4.128 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
D 10.0.0.192 [90/3072] via 10.0.11.2, 01:18:24, Vlan11
13.0.0.0/32 is subnetted, 1 subnets
D 13.10.10.4 [90/3104] via 10.0.11.2, 01:18:24, Vlan11
14.0.0.0/32 is subnetted, 1 subnets
D 14.10.10.4 [90/131072] via 10.0.11.2, 01:18:24, Vlan11
150.1.0.0/32 is subnetted, 6 subnets
D EX 150.1.6.6 [170/282164] via 10.0.11.2, 01:18:24, Vlan11
D EX 150.1.5.5 [170/410112] via 10.0.11.2, 01:18:24, Vlan11
D EX 150.1.4.4 [170/410112] via 10.0.11.2, 01:18:24, Vlan11
D EX 150.1.3.3 [170/410112] via 10.0.11.2, 01:18:24, Vlan11
D EX 150.1.2.2 [170/410112] via 10.0.11.2, 01:18:24, Vlan11
D EX 150.1.1.1 [170/3104] via 10.0.11.2, 01:18:24, Vlan11
SITEA#

Routes not in the routing table are sent to the default gateway

SITEA#show ip route 10.0.20.18
% Subnet not in table
SITEA#show ip ce
SITEA#show ip cef 10.0.20.18
0.0.0.0/0
nexthop 10.0.11.1 Vlan11
SITEA#

Site B switchport config

SITEB#show cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
D – Remote, C – CVTA, M – Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
non-root-bridge-kid2-room.non-root-bridg
Fas 0/2 163 T B I AIR-AP114 Gig 0
SITEB#show run int fa0/2
Building configuration…

Current configuration : 182 bytes
!
interface FastEthernet0/2
switchport trunk encapsulation dot1q
switchport trunk native vlan 11
switchport mode trunk
ip arp inspection trust
spanning-tree portfast trunk
end

subnets

10.0.11.17
10.0.59.6
10.0.20.18

Site A switchport config

SITEA#show cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
D – Remote, C – CVTA, M – Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
non-root-bridge.non-root-bridge.local
Gig 0/1 178 T B I AIR-SAP37 Gig 0
SITEA#show run int g0/1
Building configuration…

Current configuration : 185 bytes
!
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 11
switchport mode trunk
ip arp inspection trust
spanning-tree portfast trunk
end

10.0.11.9
10.0.31.15
10.0.30.15

connectivity test – there’s reach ability between the sites.

SITE A to B

SITEA#PING 10.0.59.6 source vlan 31

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.59.6, timeout is 2 seconds:
Packet sent with a source address of 10.0.31.15
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms
SITEA#PING 10.0.59.6 source vlan 315

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.59.6, timeout is 2 seconds:
Packet sent with a source address of 10.0.30.15
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms

SITEA#ping disney.co

Translating “disney.co”…domain server (10.0.0.5) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 76.223.18.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/15/17 ms
SITEA#ping cnn.com

Translating “cnn.com”…domain server (10.0.0.5) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 151.101.129.67, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 17/20/25 ms
SITEA#

remote connection from switch/user at site A to site B switch

SITEA#telnet 10.0.59.6 /source-interface vlan31
Trying 10.0.59.6 … Open

User Access Verification

Username: lab
Password:
SITEB#exit

traceroute from site A to site B

SITEA#traceroute
Protocol [ip]:
Target IP address: 10.0.20.18
Source address: 10.0.30.15
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.0.20.18

1 10.0.11.2 8 msec 0 msec 8 msec
2 10.0.11.17 8 msec * 0 msec
SITEA#

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Defining Upstream and Downstream Traffic Flow

At this point, it is important to clarify some terms that are used throughout the wireless QoS chapters:

Upstream: Indicates the flow of packets from the mobile wireless device to the wired network infrastructure, including the following:

Radio upstream: Refers to traffic sent by the WLAN clients and traveling to the AP. WMM provides upstream QoS for WLAN clients over the air. Each IP packet also has an internal DSCP marking that is used for prioritization over the IP network.

Network upstream: Refers to traffic leaving the AP, traveling to the WLC. This traffic is encapsulated within CAPWAP. The DSCP value on the CAPWAP tunnel may differ from the inner packet’s DSCP value. Wired campus QoS policies provision upstream QoS.

Downstream: Refers to the flow of packets from the wired network infrastructure to the wireless devices, including the following:

Network downstream: Refers to traffic leaving the WLC traveling to the AP. This traffic is encapsulated within CAPWAP. Wired campus QoS policies provision downstream QoS.

Radio downstream: Refers to traffic leaving the AP and traveling to the WLAN clients. WMM provides downstream QoS for WLAN clients.

reference -End-to-end Qos Network Design – cisco press

QoS for Wireless LANs Compared to QoS on Wired LANs

The QoS implementation for wireless LANs differs from QoS implementations on other Cisco devices. With QoS enabled, access points have the following behavior:

They do not classify packets; they prioritize packets based on the Dynamic Host Configuration Protocol (DSCP) value, client type (such as a wireless phone), or the priority value in the 802.1q or 802.1p tag.

They do not match packets using access control lists (ACL); they use only Modular QoS CLI (MQC) class maps for matching clauses.

They do not construct internal DSCP values; they support mapping only by assigning IP DSCP, Precedence, or Protocol values to Layer 2 Class of Service (CoS) values.

They carry out Enhanced Distributed Coordination Function (EDCF) like queueing on the radio egress port only.

They do only First In First Out (FIFO) queueing on the Ethernet egress port.

They support only 802.1q/p tagged packets. Access points do not support Inter-Switch Link (ISL).

They support only MQC policy-map set cos action.

They prioritize the traffic from voice clients (such as Symbol phones) over traffic from other clients when the QoS Element for Wireless Phones feature is enabled.

They support Spectralink phones using the class-map IP protocol clause with the protocol value set to 119.

Precedence of QoS Settings

When you enable QoS, the access point queues packets based on the Layer 2 class of service value for
each packet. The access point applies QoS policies in this order:

1. Packets already classified—When the access point receives packets from a QoS-enabled switch or
router that has already classified the packets with non-zero 802.1Q/P user_priority values, the access
point uses that classification and does not apply other QoS policy rules to the packets. An existing
classification takes precedence over all other policies on the access point.

Note Even if you have not configured a QoS policy, the access point always honors tagged 802.1P
packets that it receives over the radio interface.

2. QoS Element for Wireless Phones setting—If you enable the QoS Element for Wireless Phones
setting, dynamic voice classifiers are created for some of the wireless phone vendor clients, which
allows the wireless phone traffic to be a higher priority than other clients’ traffic. Additionally, the
QoS Basic Service Set (QBSS) is enabled to advertise channel load information in the beacon and
probe response frames. Some IP phones use QBSS elements to determine which access point to
associate to, based on the traffic load.
You can use the Cisco IOS command dot11 phone dot11e command to enable the future upgrade
of the 7920 Wireless Phone firmware to support the standard QBSS Load IE. The new 7920 Wireless
Phone firmware will be announced at a later date.

3. Policies you create on the access point—QoS Policies that you create and apply to VLANs or to the
access point interfaces are third in precedence after previously classified packets and the QoS
Element for Wireless Phones setting.

4. Default classification for all packets on VLAN—If you set a default classification for all packets on
a VLAN, that policy is fourth in the precedence list.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
StackWise-480 Connectivity for HA

A CT5760 HA Pair is a special case of a switch stack that can have up to two CT5760 controllers connected through their StackWise-480 ports. The stack members work together as a unified system

A third CT5760 cannot join the switch stack or HA pair. A switch stack always has one active controller and one standby controller. If the active controller becomes unavailable, the standby assumes the role of the active, and continues to the keep the stack operational.

The active controller controls the operation of the HA pair, and is the single point of stack-wide management. The term switch is loosely used in the document to refer to the CT5760 WLC for this reason.

StackWise-480 has a stack bandwidth of 480 Gbps and uses SSO to provide resiliency within the HA Pair. The Active CT5760 WLC creates and updates all the wireless information and constantly synchronizes that information with the standby controller.

If the active WLC fails, the standby WLC assumes the role of the active WLC and continues to the keep the HA Pair operational. Access Points continue to remain connected during an active-to-standby switchover.

AP SSO and 5760 HA-SKU
  • The 5760 HA-SKU provides support for up to 1000 APs when Active controller Fails over to HA-SKU unit.
  • The following notification is generated on the HA-SKU controller when a Standby non HA-SKU is lost:

“The current stack does not support the applied AP License Count. Reconnect a Catalyst 5760 SKU running valid AP License Count within 90 days.”

  • Two 5760 HA-SKU units cannot be connected to be paired in an SSO pair.
  • Licenses cannot be added to a 5760 HA-SKU unit.
  • The 5760 HA-SKU has a PID AIR-CT5760-HA-K9 to indicate that it is a HA-SKU unit.
  • A non HA-SKU 5760 controller cannot be converted to a HA-SKU by configuration.
Feature Intersection with AP SSO
  • Switchover during AP Pre-Image download causes the APs to start image download all over again from the new Active controller.
  • Rogue APs and clients are not synced to Standby and are re-learnt upon switchover.
  • Infrastructure MFP key is not synced to the Standby controller and is re-learnt upon switchover.
  • New Active controller re-learns the shun list from IPS and other MCs, and redistributes it to the MAs.
  • wIPS information is not synced to the Standby unit and is re-learnt upon switchover.
  • Clean Air detected Interferer devices are re-learnt after switchover.
  • Net Flow records are cleared upon switchover and collection starts fresh on the new Active controller.
  • Mobility paths and tunnels to the MO and other peer MCs are not disrupted upon switchover. However the Client state is cleaned up on the MO under which the HA pair exists and is re-learnt from the new Active controller when the client re-associates.
  • Roamed clients that have their data path going through the Mobility Tunnel Endpoint (MTE) “become Local” in case of L2 with Sticky Anchoring and L3 Roam. L2 Roamed Clients are not affected except when roaming occurs between CUWN and CA controllers.
  • RRM related configurations and the AP neighbor list in the Leader HA pair is synced to the Standby controller.
  • Upon Guest Anchor controller switchover, mobility tunnels stay active, APs remain connected, clients rejoin at MA or MC, and are anchored on the new Active controller.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Configure

The first method of web authentication is local web authentication. In this case, the WLC redirects the HTTP traffic to an internal or external server where the user is prompted to authenticate. The WLC then fetches the credentials (sent back via an HTTP GET request in the case of an external server) and makes a RADIUS authentication. In the case of a guest user, an external server (such as Identity Services Engine (ISE) or NAC Guest Server (NGS)) is required because the portal provides features such as device registering and self-provisioning. The flow includes these steps:

  1. The user associates to the web authentication Service Set Identifier (SSID).
  2. The user opens the browser.
  3. The WLC redirects to the guest portal (such as ISE or NGS) as soon as a URL is entered.
  4. The user authenticates on the portal.
  5. The guest portal redirects back to the WLC with the credentials entered.
  6. The WLC authenticates the guest user via RADIUS.
  7. The WLC redirects back to the original URL.

This flow includes several redirections. The new approach is to use CWA. This method works with ISE (versions later than 1.1) and WLC (versions later than 7.2). The flow includes these steps:

  1. The user associates to the web authentication SSID, which is in fact open+macfiltering and no layer 3 security.
  2. The user opens the browser.
  3. The WLC redirects to the guest portal.
  4. The user authenticates on the portal.
  5. The ISE sends a RADIUS Change of Authorization (CoA – UDP Port 1700) to indicate to the controller that the user is valid, and eventually pushes RADIUS attributes such as the Access Control List (ACL).
  6. The user is prompted to retry the original URL.

The setup used is:

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

LWA Process with the ISE Guest Portal

1.The browser tries to fetch a web page.

2. The WLC intercepts the HTTP(S) request and redirects it to the ISE.
Several key pieces of information are stored in that HTTP redirect header. Here is an example of the redirect URL:
https://mlatosieise.wlaaan.com:8443/portal/PortalSetup.action?portal=27963fb0-e96e-11e4-a30a-005056bf01c9#&ui-state=dialog?switch_url=https://1.1.1.1/login.html&ap_mac=b8:be:bf:14:41:90&client_mac=28:cf:e9:13:47:cb&wlan=mlatosie_LWA&redirect=yahoo.com/
From the example URL, you can see that the user tried to reach “yahoo.com.” The URL also contains information about the Wireless Local Area Network (WLAN) name (mlatosie_LWA), and the client and access point (AP) MAC addresses. In the example URL, 1.1.1.1 is the WLC, and mlatosieise.wlaaan.com is the ISE server.

3. The user is presented with the ISE guest login page and enters the username and password.

4. The ISE performs authentication against its configured identity sequence.

5. The browser redirects again. This time, it submits credentials to the WLC. The browser provides the username and password that the user entered in the ISE without any additional interaction from the user. Here is an example GET request to the WLC.
GET /login.html?redirect_url=http://yahoo.com/&username=mlatosie%40cisco.com&password=ityh&buttonClicked=4&err_flag=0
Again, the original URL (yahoo.com), the username (mlatosie@cisco.com), and the password (ityh) are all included.

Note: Although the URL is visible here, the actual request is submitted over Secure Sockets Layer (SSL), which is indicated by HTTPS, and is hard to intercept.

6.The WLC uses RADIUS in order to authenticate that username and password against the ISE and allows access.

7.The user is redirected to the specified portal. Refer to the “Configure external ISE as the webauth URL” section of this document for more information.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
DFS in RAP The RAP performs the following steps as a response to radar detection:
  1. The RAP sends a message to the controller that the channel is infected with radar. The channel is marked as infected on the RAP and on the controller.
  2. The RAP blocks the channel for 30 minutes. This 30-minute period is called the nonoccupancy period.
  3. The controller sends a TRAP, which indicates that the radar has been detected on the channel. A TRAP remains until the nonoccupancy period expires.
  4. The RAP has 10 seconds to move away from the channel. This period is called the channel move time, which is defined as the time for the system to clear the channel and is measured from the end of the radar burst to the end of the final transmission on the channel.
  5. The RAP enters the quiet mode. In the quiet mode, the RAP stops data transmissions. Beacons are still generated and probe responses are still delivered. The quiet mode exists until the channel move time is over (10 seconds).
  6. The controller picks up a new random channel and sends the channel information to the RAP.
  7. The RAP receives the new channel information and sends channel change frames (unicast, encrypted) to the MAP, and each MAP sends the same information to its lower children down the sector. Each mesh access point sends the channel change frames once every 100 msecs for a total of five times.
  8. The RAP tunes to the new channel and enters into the silent mode. During the silent mode, only the receiver is ON. The RAP keeps scanning the new channel for any radar presence for 60 seconds. This process is called channel availability check (CAC).
  9. The MAP tunes to the new channel and enters into the silent mode. During the silent mode, only the receiver is ON. The MAP keeps scanning the new channel for any radar presence for 60 seconds.
  10. If radar is not detected, the RAP resumes full functionality on this new channel and the whole sector tunes to this new channel.
DFS in MAP The MAP performs the following steps as a response to radar detection:
  1. The MAP sends a radar seen indication to the parent and ultimately to the RAP indicating that the channel is infected. The RAP sends this message to the controller. The message appears to be coming from the RAP. The MAP, RAP, and controller mark the channel as infected for 30 minutes.
  2. The MAP blocks the channel for 30 minutes. This 30-minute period is called the nonoccupancy period.
  3. The controller sends a TRAP, which indicates that the radar has been detected on the channel. The TRAP remains until the nonoccupancy period expires.
  4. The MAP has 10 seconds to move away from the channel. This is called the channel move time, which is defined as the time for the system to clear the channel and is measured from the end of the radar burst to the end of the final transmission on the channel.
  5. The MAP enters the quiet mode. In the quiet mode, the MAP stops data transmissions. Beacons are still generated and probe responses are still delivered. The quiet mode exists until the channel move time is over (10 seconds).
  6. The controller picks up a new random channel and sends the channel to the RAP.
  7. The RAP receives the new channel information and sends channel change frames (unicast, encrypted) to a MAP, and each MAP sends the same information to its lower children down the sector. Each mesh access point sends the channel change frames once every 100 msecs for a total of five times.
  8. Each mesh access point tunes to the new channel and enters into the silent mode. During the silent mode, only the receiver is ON. There is no packet transmission. An AP keeps scanning the new channel for any radar presence for 60 seconds. This process is called the channel availability check (CAC). The MAP should not disconnect from the controller. The network should remain stable during this one-minute period.

DFS functionality allows a MAP that detects a radar signal to transmit that up to the RAP, which then acts as if it has experienced radar and moves the sector. This process is called the coordinated channel change. This functionally can be turned on or off on the controller. The coordinated channel change is enabled by default.

To enable DFS, enter the following command:

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

An HA deployment consists of two Prime Infrastructure servers: a primary and a secondary. Each of
these servers has an active database and a standby backup copy of the active database. Under normal circumstances, the primary server is active: It is connected to its active database while it manages the
network. The secondary server is passive, connected only to its standby database, but in constant
communication with the primary server.

The Health Monitor processes running on both servers monitor the status of its opposite server. Oracle
Recovery Manager (RMAN) running on both servers creates the active and standby databases and
synchronizes the databases when there are changes, with the help of Oracle Data Guard Broker running
on the primary server.

When the primary server fails, the secondary takes over, connecting to its active database, which is in
sync with the active primary database. You can trigger this switch, called a “failover”, either manually,
which is recommended, or have it triggered automatically, You then use the secondary server to manage
the network while working to restore access to the primary server. When the primary is available again,
you can initiate a switch (called a “failback”) back to the primary server and resume network
management using the primary.

reference : Cisco.com

****************************************************************************************************

In any Prime Infrastructure HA implementation, for a given instance of a primary server, there must be
one and only one dedicated secondary server.

Typically, each HA server has its own IP address or host name. If you place the servers on the same
subnet, they can share the same IP using virtual IP addressing, which simplifies device configuration.

Once HA is set up, you should avoid changing the IP addresses or host names of the HA servers, as this will break the HA setup (see “Resetting the Server IP Address or Host Name” in Related Topics).

*******************************************************************************************************

File and Database Synchronization

Whenever the HA configuration determines that there is a change on the primary server, it synchronizes
this change with the secondary server. These changes are of two types:

1. Database: These include database updates related to configuration, performance and monitoring
data.

2. File: These include changes to configuration files.
Oracle Recovery Manager (RMAN) running on both servers creates the active and standby databases and
synchronizes the databases when there are changes, with the help of Oracle Data Guard Broker running
on the primary server.

File changes are synchronized using the HTTPS protocol. File synchronization is done either in:

• Batch: This category includes files that are not updated frequently (such as license files). These files
are synchronized once every 500 seconds.

Near Real-Time: Files that are updated frequently fall under this category. These files are
synchronized once every 11 seconds.

By default, the HA framework is configured to copy all the required configuration data, including:
• Report configurations
• Configuration Templates
• TFTP-root
• Administration settings
• Licensing files

*****************************************************************************************************

If there is a firewall configured between the primary and the secondary servers, ensure that the
firewall permits incoming and outgoing TCP/UDP on the following ports:

– 8082: Used by the Health Monitor process to exchange heartbeat messages
– 1522: Used by Oracle to synchronize data

• If you plan on using Operations Center with an HA implementation of Prime Infrastructure: Ensure
that all of your HA-enabled Prime Infrastructure servers (both primary and secondary) have fully
resolved host names.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Resource Reservation Control

As more and more users begin to utilize video in the workplace on Wi-Fi endpoints, the ability to gracefully manage and scale a continuous, and high-quality experience for fluctuating groups of users at any given time or location is critical.

The controller and access points have a crucial decision making algorithm, that is Resource Reservation
Control (RRC) provides enhanced capabilities to manage admission and policy controls. Admission and policy decisions are made based on the radio resource measurements, statistics measurement of the traffic, and system configurations. The controller initiates RRC requests to the access points for the IGMP join. The accesspoint will process the request for all the parameters listed in this diagram:

In the above response all the parameters passed the policy configuration on the controller. The IGMP join request from the client on that access point will be admitted. If the RRC request had a response as shown below, the join request will be investigated and the RRC algorithm will be checked for the policy configuration again. The client will be admitted but as a Best effort client. However, on several attempts of RRC check it will be admitted with a better QoS priority.

RRC is initiated on a client at IGMP join to a stream and can be configured for periodic check. Due to any changes in the wireless characteristic if the RRC metric reply varies considerably the client will be denied to the stream.

RRC provides bandwidth protection for the video client by denying requests that would cause over-subscription. Channel utilization is used as a metric to determine the capacity and perform admission control.

Multicast to Unicast

By enabling 802.11n data rates and providing packet error correction, multicast-to-unicast capabilities of Cisco VideoStream enhance the reliability of delivering streamingvideo over Wi- Fi beyond best-effort features of traditional wireless networks.

A wireless client application subscribes to an IP multicast stream by sending an IGMP join message. With reliable multicast, this request is snooped by the infrastructure, which collects data from the IGMP messages.

The system checks the stream subscription and configuration, then collects metrics and traffic policies for the requested stream. If the requested stream is allowed by the policies, a response is sent to the wireless client attached to the access point in order to initiate reliable multicast once the stream arrives.

The system also looks for available bandwidth and configured stream metrics to determine if there is enough airtime to support the new subscription. In addition, the system considers the prevailing load on the radio and the health of the media before making the admission decision. After all the above criteria are met, a join response is sent to the access point. This is when the access point replicates the multicast frame and converts it to 802.11 unicast frames. Finally, a reliable multicast service delivers the video stream as unicast directly to the client.

The Call Admission Control (CAC) configuration stops the oversubscription of the channel and guarantees configured media bandwidth. The CAC configuration will also stop new media users, hence safe-guards the current users from being affected when oversubscribed. The CAC configurations for VideoStream is a key tuning point that balances the voice, video and data users on a wireless media.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
VideoStream

VideoStream provides efficient bandwidth utilization by removing the need to broadcast multicast packets to all WLANs on the AP regardless if there is a client joined to a multicast group.

In order to get around this limitation, the AP needs to be able to send multicast traffic to the host via Unicast forwarding, only on the WLAN that the client is joined and do so at the data rate the client is joined at.

Stream Admission and Prioritization

As mentioned earlier while video is an efficient, high-impact means of communication, it is also very bandwidth intensive, and as is seen, not all video content is prioritized the same. From earlier discussion it is clear that organizations investing in video cannot afford to have network bandwidth consumed without any prioritization of business critical media.
Stream admission will empower the network administrator to have control over all the multicast video streaming in the network. Stream admission will facilitate network administrator to use pre-defined templates for input multicast streams. There are few predefined templates for stream bandwidths of 300Kbps, 500Kbps, 1Mbps, 3Mbps and 5
Mbps.

It is necessary to have a basic understanding of streaming video characteristic before configuring. For example, consider the above two configurations. If the video bit rate is around 4Mbps you need to manually add the configurations instead of using any of the above two templates. If Stream-Less3Mbps is used, the quality of video will be bad due missing video frames. It is observed there is pixelation of video and constant freeze of video on a wireless client.

If Stream-Less5Mbps is used, the number of video clients will be less as every wireless client is guaranteed of 5Mbps while the video bitrate is only 4 M bits. If you had ten wireless I clients the aggregate client bandwidth
should be around 40Mbps. Using the Stream-Less5Mbps the controller will be using 50Mbps, hence depriving 3 wireless clients of video.

Stream Priority can configure the media stream with different priority based on importance within the enterprise network. RRC Priority comes to play only when there is acongestion or contention in the wireless access point.
When

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview