VIP Redundancy and Management interface

If two CSS's have been configured as active and standby (VIP redundancy), and one of the interfaces of the active CSS goes down, and say the backup becomes active, I lose total connectivity to the Active box via the management interface IP. Once it regains back the active status, i can reconnect. Is this a "feature" or a "bug"...??

I think the software version is 6.14 build 107..I will post the configs soon..i dont see anything wrong with the configuration, its all straight forward configuration. I will post the boot config and the running config soon.

Similar Messages

Any advantages to setting the AP-Manager and Management interface to an untagged vlan?

Any advantages to setting the AP-Manager and Management interface to an untagged vlan? Currently, our controllers have their management and ap-manager interfaces on the same untagged vlan. Would it be wise to change this? Are there any gotchyas I should be aware of?

No really, there won't be a problem. Management an AP-manager can be on different vlans.
The vlan you chose to untag is the vlan you should declare as native on the switch, that's it.
No advantage in having interfaces configured in a way or another.
Some people want the management to be in a "management" subnet and the ap-manager will be in the subnet with all the APs. Some others have several AP subnets so the ap-manager is in the same as management ... no importance whatsoever as long as the config is coherent.
The only thing that is worth considering is the size of AP subnet to me. If you give a /16 for APs and have 1000 APs in a single subnet, ARP and broadcast storms will be hitting the fan. But the vlan tag/untags that you chose are not important
To rate an answer, click on the stars below it. 1 for not so useful and 5 for very useful.
Nicolas
===
Don't forget to rate answers that you find useful.

Redundancy and load sharing on more than 2 CSS's

Hello,
I have configured VIP, virtual interface and ASR on a pair of CSS's before. Currently, I have some VIP on CSS1 and some other VIP on CSS2 for resilience.
Because of performance issue (actually a fear for performance issue instead of real) I am looking into scaling up to 3 or more CSS's. I think I can have VIP and virtual interface redundancy on 3 or more CSS's but not ASR. Is it true?
Any advice will be welcomed.
CT Yau
Hong Kong

normally vip redundancy and asr are for pair of css only.
I think you can do vip redundancy with more than 2 CSS but it is officially not supported.
You can however have multiple VRRP group per interface and therefore combine your CSS by pair [a-b,b-c,a-c]
ASR is definitely not going to work with more than 2 CSS.
Regards,
Gilles

LAP registration with ap-manager interface only

Hi, is it possible to register an APs with no visibility of the management interface? The WLC would have a separate ap-manager interface but in a different vfr then management interface. APs can see the ap-manager interface one but not the management one.

I don't mind to use for example service port for the isolated management. But i heared the service port has restrictions under HA design.
Exactly what firmware or model of WLC are you using?
You can't use ther Service Port for production. This port is primarily used for Out-of-Band-Management and for HA SSO.
The document is dated five years ago and describes the 4.0 SW. My question was if there is any trick or possibility to arrange it under present HW & SW.
The document may be five years old, but when you are dealing with WLC 4400, WiSM or 2000/2100 then it's still valid. The APs talk to the controller using the AP-manager interface. This is the main reason why AP-manager interface and management interface IP addresses is recommended to be in the same subnet. It will work if either one is on a different subnet but you'll need to do some routing work done.

CSS One Arm Configuration with VIP(non-shared)/IP Interface Redundancy

With Reference to the following CCO documentation;
1). "How to Configure the CSS to Load Balance Using 1 Interface"
In this example, the Real Server's (10.10.10.2 etc) gateway are pointed to the router's gateway(10.10.10.1) and used the 'add destination service' command to NAT the RealServer's IP address back to the VIP (10.10.10.6).
2). "Understanding and Configuring VIP and Interface Redundancy on the CSS11000".
In the interface redundancy configuration, the gateway of the Real Server are configured as the CSS11000's Interface Redundancy Address (192.168.1.1), not the Router's gateway.
Can anyone help to advise on the preferred one arm configuration with VIP/IP redundancy?
(i). Is the reason for configuring the gateway of the Real Server to CSS11000's Interface Redundancy Address in 2) same as using 'add destination service' command in 1)? That is to make sure that the return path from Real Server back to Client passes through the CSS and is NAT back to the VIP.
(ii). To configure VIP(non-shared)/IP Interface redundancy(Active/Backup Mode) in a one arm configuration, my understanding is that there are 2 methods of configuration. Is it correct? Which method is preferred?
Method a)
1.Configure the Real Server's gateway to Router's Gateway
2.Configure 'add destination service' command on the CSS to NAT the RealServer's IP address back to the VIP
3.Configure VIP(non-shared) redundancy for the VIP on the CSS
4.IP Interface Redundancy on the CSS is not required as the Real Server's gateway is already pointing to the Router's gateway. (Assuming that HSRP redundancy is already running on the Router)
Method b)
1. Configure the Real Server's gateway to the CSS's IP Interface Redundancy IP Address
2. Configure IP Interface Redundancy on the CSS (as the Real Server's gateway)
3. Configure VIP(non-shared) redundancy for the VIP on the CSS

if you use method a) (server gateway is the router) you need the CSS to nat
the source ip address of the client in order to force the server to send traffic back to the CSS.
The issue then is that the server does not see the IP address of real client.
The server only see connections with source IP address = CSS ip address.
With method b) you don't have the above problem, but connection initiated by the servers are sent to the CSS that will then send it to the router.
You have a performance issue because the traffic will cross 2 times the one-armed interface.
If this is a new design, it is strongly recommended not to use one-armed setup.
Regards,
Gilles.

Interfaces: AP-Manager and Management - function

Hi,
I've read that from the point of view of the WLC, the interface which the LWAPP tunnel is terminated on is the AP-Manager Interface, right?
If so, why does DHCP option 43 dish up the Management Interface IP address and not the AP-Manager IP address?
Thanks

Hi Jake,
You're obviously a guru in this!
Please tell me what APM is.
I got a capture of LWAPP traffic.
Here's what I observed,
LWAPP Control packets use management or AP-Manager interface depending on the exact packet type
Management Interface
- Discovery_REQUEST
- Discovery_REPLY
- PRIMARY_DISCOVERY_REQ
- PRIMARY_DISCOVERY_RES
AP-Manager Interface
- JOIN_REQUEST
- CONFIGURE_REQUEST
- CONFIGURE_RESPONSE
- various other CONFIGURE packets
- ECHO_REQUEST
- ECHO_RESPONSE
- STATISTICS_INFO
- STATISTICS_INFO_RES
Regards, mh

AP Manager interface and Virtual Interface

What do each of these interfaces do on the 526 WMAC? I am not sure I understand the functionality and did not find the answer to this in the documentation.
Thanks

Well from a WLC, the management is used to access and manage the wlc. It is also used for communication with the mobility group. AP-Manager is the interface the wlc and the ap's use and the virtual interface is used by internal dhcp, mobility group, webauth, etc. The virtual interface is not routable in your network, it is mainly used by the wlc's for various features.
Here is from a Cisco Doc:
The management interface is the default interface for in-band management of the controller and connectivity to enterprise services such as AAA server. If the service port is in use, the management interface must be on a different subnet than the service port.
The AP-Manager interface is used as the source IP address for all Layer 3 communications between the controller and the lightweight access points. The AP-Manager must have a unique IP address and should be on the same subnet as the management interface.
The virtual gateway interface is used to support mobility management, DHCP relay, and embedded Layer 3 security, like guest web authentication and VPN termination. The virtual interface must be configured with an unassigned and unused gateway IP address. If multiple controllers are configured in a mobility group, the virtual interface must be the same on all controllers for seamless roaming.
The service-port interface is mapped only to the physical service port. The service port interface must have an IP address on a different subnet from the management and AP-Manager interfaces. A default-gateway cannot be assigned to the service-port interface, but static routes can be defined through the controller command-line interface for remote network access to the service port.

CSS11501 commit vip redundancy script failure

Hi all,
recently when i run the commit vip redundancy script, i encountered the following error. This script has never failed in the past. Upon checking the backup CSS, i did notice that my most recent changes were actually synced. The following is the debug i have captured while running the script. Can someone please help to look at it? Thanks!
active-lb# script play commit_vip_redundancy "local 167.168.165.10 remote 167.168.165.9 -a -d"
active-lb#
Checking available disk space on systems ...
Checking the disk space locally before continuing with the script.
Verifying that another local session is not running the script.
Creating script/vipr_config_sync_lock file.
Verifying app and redundancy configs ...
Verifying that app session is up with backup switch.
Making sure app session is up.
Seconds to wait before calling it quits:    60
Checking the disk space remotely before continuing with the script.
Checking local and remote switch versions ...
Storing the running code versions of the local and remote switch.
Storing the local switch's version.
Retrieving the remote switch's version.
Checking remote version for 4.0
Checking if switch is BACKUP for any virtual routers and if
the state is 'No Service'.
Checking vip redundancy state....
Checking if backup switch is Master for any VRIDs.
If it is, either a local interface that once held redundant vips
has been removed or the Backup is a Master for another vip-redundant
relationship.
Checking compatibility of systems......
LOCAL switch is a css11501,7
REMOTE switch is a css11501,7
Mode: INTERFACE - Checking to see if interface Ethernet-Mgmt exists on remote system.
Mode: INTERFACE - Checking to see if interface e9 exists on remote system.
Mode: INTERFACE - Checking to see if interface e8 exists on remote system.
Mode: INTERFACE - Checking to see if interface e7 exists on remote system.
Mode: INTERFACE - Checking to see if interface e6 exists on remote system.
Mode: INTERFACE - Checking to see if interface e5 exists on remote system.
Mode: INTERFACE - Checking to see if interface e4 exists on remote system.
Mode: INTERFACE - Checking to see if interface e3 exists on remote system.
Mode: INTERFACE - Checking to see if interface e2 exists on remote system.
Mode: INTERFACE - Checking to see if interface e1 exists on remote system.
Working
Saving Master running-config to startup-config and archiving startup-config.
Copying running-config to startup-config.
Archiving startup-config.
Swapping Master and Backup ip addresses in tmp.cfg for app
and redundancy interface.
Checking for multiple APP sessions between redundant peers.
App Session IP: 167.168.165.9, Local IP address: 167.168.165.10
Checking IP Address size differences : <167.168.165.9> <167.168.165.10>
Adding APP session IP length difference to LOCALCONFIG byte size : 1
Adding APP session IP length difference to REMOTECONFIG byte size : 0
Removing CIRCUIT and INTERFACE modes from tmp.cfg.
Checking for ips with matching subnets for circuit sync.
Checking IP Address size differences : <167.168.165.10> <167.168.165.9>
Replacing local system VRID priorities and preempt settings with remote settings.
Local IP: 167.168.165.10 VRID: 40 PRIORITY: 254 PREEMPT: True
Remote IP: 167.168.165.9 VRID: 40 PRIORITY: 1 PREEMPT: False
Checking Number length differences : <254> <1>
Checking IP Address size differences : <167.168.165.132> <167.168.165.131>
Replacing local system VRID priorities and preempt settings with remote settings.
Local IP: 167.168.165.132 VRID: 41 PRIORITY: 254 PREEMPT: True
Remote IP: 167.168.165.131 VRID: 41 PRIORITY: 1 PREEMPT: False
Checking Number length differences : <254> <1>
Checking IP Address size differences : <167.168.166.3> <167.168.166.2>
Replacing local system VRID priorities and preempt settings with remote settings.
Local IP: 167.168.166.3 VRID: 42 PRIORITY: 254 PREEMPT: True
Remote IP: 167.168.166.2 VRID: 42 PRIORITY: 1 PREEMPT: False
Checking Number length differences : <254> <1>
IP addr bytes to add to LOCAL BYTE COUNT : 1
IP addr bytes to add to REMOTE BYTE COUNT : 1
Checking for SSL configuration ...
Working
Using rcmd to copy tmp.cfg to a file on Backup switch.
Archiving copy to Backup's startup-config.
Archiving Backup's current startup-config.
Restoring startup-config (new copy) to startup-config.
Clearing running-config.
Script playing the copy script of the Master's running-config.
Checking to make sure backup App goes down
Making sure app session is down.
Seconds to wait before calling it quits:    9168
Copy success being verified by comparing byte sizes of archived running-
     configs of the Master switch and the Backup switch.
Making sure app session is up.
Seconds to wait before calling it quits:    9108
Waiting for completion signal from remote switch ...
Verifying running-config copy success ...
Comparing the byte count now.
Accounting for preempt configurations.
Adding 0 bytes to LOCALCONFIG byte count
Adding 24 bytes to REMOTECONFIG byte count
Accounting for priority value length differences.
Adding 0 bytes to LOCALCONFIG byte count
Adding 6 bytes to REMOTECONFIG byte count
Accounting for IP address size differences.
Adding 1 bytes to LOCALCONFIG byte count
Adding 1 bytes to REMOTECONFIG byte count
File copy Vipr Config Sync Failed. Commit unsuccessful!
localconfig: 218346 bytes
remoteconfig : 218320    bytes

Hi Daniel,
According to this output, the synchronization process goes well, but it fails when it has to verify what it synchronized. If you look at the last two lines, you will see that the size of the original local configuration is slightly bigger than the remote one. That's causing the validation to fail.
The first thing we need to confirm is whether the configuration really got properly replicated (you will have to check line by line to make sure it's the same). If so, we would just need to figure out why the file sizes are different.
There were some cases in the past in which the hard drive on the secondary device was failing, and as a result, the file was getting corrupted, leading to the size mismatch, so that's a possibility we need to take into account. Anyway, it would probably be better to open a TAC case to have it investigated in more detail.
Regards
Daniel

5508 WLC HA pair - change management interface settings

Hi,
We have a pair of 5508 WLC's in a HA configuration that is working well at the moment, however I have noticed that the management interface is configured as untagged. I would like to change this to tagged and change the attached switch to trunk for these devices but if I try and edit the management interface through the GUI the VLAN and IP address section is greyed out and cannot be changed. While I could attempt it through the CLI and am comfortable doing that, the fact that it cannot be changed through the GUI implies that this should not be changed and so I am after further information. I don't have any lab equipment other than the HA pair in production so I cannot try changing it through the CLI at the moment.
The WLC's are in LAG mode if that makes any difference. I realise there may be downtime required for making this change but I am trying to work out the steps to get this done without having to drastically reconfigure things.
Any assistance would be appreciated.

Introduction of New Interfaces for HA Interaction
Redundancy Management Interface
The IP address on this interface should be configured in the same subnet as the management interface. This interface will check the health of the Active WLC via network infrastructure once the Active WLC does not respond to Keepalive messages on the Redundant Port. This provides an additional health check of the network and Active WLC, and confirms if switchover should or should not be executed. Also, the Standby WLC uses this interface in order to source ICMP ping packets to check gateway reachability. This interface is also used in order to send notifications from the Active WLC to the Standby WLC in the event of Box failure or Manual Reset. The Standby WLC will use this interface in order to communicate to Syslog, the NTP server, and the TFTP server for any configuration upload.
Redundancy Port
This interface has a very important role in the new HA architecture. Bulk configuration during boot up and incremental configuration are synced from the Active WLC to the Standby WLC using the Redundant Port. WLCs in a HA setup will use this port to perform HA role negotiation. The Redundancy Port is also used in order to check peer reachability sending UDP keep-alive messages every 100 msec (default timer) from the Standby WLC to the Active WLC. Also, in the event of a box failure, the Active WLC will send notification to the Standby WLC via the Redundant Port. If the NTP server is not configured, a manual time sync is performed from the Active WLC to the Standby WLC on the Redundant Port. This port in case of standalone controller and redundancy VLAN in case of WISM-2 will be assigned an auto generated IP Address where last 2 octets are picked from the last 2 octets of Redundancy Management Interface (the first 2 octets are always 169.254).

CSS 11151 VIP Redundancy - Link State Redundancy/Keepalive

I have a pair of CSS 11151 each connected to a pair of cross-connected 3550 switches,I've configured VIP & Interface Redundacy,either VLAN1 interface or VLAN2 interface is shut down will cause the virtual router switchover. Recently I met some problem with CSS switchover when just one VLAN1 interface shutdown, and I was told that "type redundancy-up" should not work with VIP redundant mode, so I am trying to configure a critical service with a keepalive ap-kal-pinglist and ping all the circuit vlan's ip address on the CSS itself. but I am still confuse with some aspects.
1. Should I configure two separate virtual router for two circuit VLANs?
2. How to configure the service IP address? Because two 3550 have separate vlan ip address, and did not configured HSRP.
3. The script on my CSS is different with document, can I edit a new ap-kal-pinglist script to replace it?
Here's my config...
!************ INTERFACE *********************
interface 2
bridge vlan 2
!**************** CIRCUIT **************************
circuit VLAN1
ip address 10.0.2.33 255.255.255.128
ip virtual-router 1 priority 100
ip redundant-interface 1 10.0.2.29
ip critical-service 1 sw1-up-down
ip critical-service 1 sw2-up-down
circuit VLAN2
ip address 10.0.2.133 255.255.255.240
ip virtual-router 1 priority 100
ip redundant-interface 1 10.0.2.129
ip redundant-vip 1 10.0.2.132
ip critical-service 1 gateway
!************************** SERVICE
service gateway
ip address 10.0.2.130
type redundancy-up
active
service sw1-up-down
ip address 10.0.2.30
type redundancy-up
active
service sw2-up-down
ip address 10.0.2.31
type redundancy-up
active

I would recommend an upgrade to version 7.40 in order to get the 'reporter' functionality.
http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_command_reference_chapter09186a008028fe6c.html
A reporter let you define which ports you want to monitor and when to failover [all ports down or any port down].
If you can't use 7.40, here is an answer to your question :
1. it does not matter. The vrid is used to differentiate other instances of VRRP that could exist on the same VLAN.
2. if you plan to use an ap-kal-pinglist, the service ip address really does not matter. The keepalive will use the ip addresses that you will pass to the ap-kal-pinglist function
3. you can modify the script and upload it back to the CSS. However, I would recommend using a different name in case you need the original script in the future.
Regards,
Gilles.

What causes the VIP to failover when using VIP redundancy?

I am trying to setup VIP redudancy and would like to understand what circumstances cause a failover for the VIP. An example of what I would hope it does is if a redundant interface were to failover the VIP could be associated with it and failover as well or be configured to do so. Thanks in advance.

the CSS master is responsible to advertise itself on the interface you have Vip redundancy configured.
If the backup does not hear the master it will take over mastership.
another reason would be the lost a critical service.
You can define a service to be critical, and if it goes down, the active CSS will stop advertising itself as master forcing failover to the backup.
Gilles.

How to implement uplink redundancy and spanning tree in SFP-300 switches

We have several Small Business 300 Series Managed Switches, the 10/100 ones with PoE, the first generation ones.
We've been advised to implement uplink redundancy and spanning tree on these switches.
I'm sure spanning tree is a checkbox somewhere in the web interface.
How does one implement uplink redundancy besides interconnecting the switches plus turning on spanning tree (RSTP)??
Thank you, Tom
P.S. I also tried to file a service request but it does not work, I get: "Error 500: Request processing failed; nested exception is java.lang.NullPointerException"

Hello Thomas,
Thanks for using the Cisco Small Business eSupport Community. I've looked through the articles that are available in our Knowledge Base and found a few that I hope will be able to assist you in setting up spanning tree and link redundancy on your SFP300s:
In regards to link redundancy, the following article on LAG can hopefully provide some guidance:
Link Aggregate Group (LAG) Configuration on 200/300 Series Managed Switches
And for your question on setting up STP, here are a few articles with additional information:
Configure Spanning Tree Protocol (STP) Status and Global Settings on 200/300 Series Managed Switches
Setup Spanning Tree Protocol (STP) on a Interface on the 300 Series Managed Switches
I hope that this information helps! Please remember to mark your question as answered and rate if this solves your problem.
Best,
Gunner

WLC-2106 and multiple interfaces on the same network

Hi there,
I recently created a TAC request to the Cisco support regarding our WLC-2106, but they could not help me. Basically I just learned that you can create new interfaces for the wireless LAN controller and then dedicate them to a given wireless network (SSID). This way I could more effectively utilize network bandwidth also. Problem is that all of the interfaces have to be in a different network segment in order to work, which is not what I want. I specifically want to have several interfaces on the same network segment.
Has anyone tried to accomplish the same?

Basically what I've misunderstood is that all the traffic generated by our wireless clients have been going through the single 100Mbit/s ethernet port on the wireless LAN controller (management interface), and to mitigate this I thought I could create new interfaces (ports) and dedicate those to given WLAN networks.. I see now that this is not supported. Not inside the same network at least.
So, by reading further and consulting my best friend Google I learned about a setting called "AP Mode". Changing that from Local (the default) to H-REAP the APs should not route their traffic anymore through the management interface on the wireless controller, but instead route all the client traffic directly to the local LAN. This way you effectively remove the 100Mbit/s bottle-neck when all the APs were using the management interface both for configuration and client data traffic.
It seems you also have to enable H-REAP Local switching from a given WLAN network in addition to changing the AP Mode of your access points to H-REAP. I'm still in the testing phase here so should anyone have any insight to this, I'd be greatful to hear more.

Home Hub 3.0B Management interface unresponsive.

This month (2 weeks ago) I upgraded to Infinity 2 and got a new Home Hub 3.0 Type B.
I was able to get it all working as I wanted to - home network using 172.16.0.1/23 (because of conflicts with vpning into work which already routes 192.168./16 and 10./8)
However, often, very often, trying to access the Hub web interface on 172.16.0.1 or via bthomehub.home simply fails to respond. Regardless of the browser, or me using telnet to simulate a HTTP call.
#host bthomehub.home 172.16.0.1
Using domain server:
Name: 172.16.0.1
Address: 172.16.0.1#53
Aliases:
bthomehub.home has address 172.16.0.1
# telnet 172.16.0.1 80
Trying 172.16.0.1...
Connected to 172.16.0.1.
Escape character is '^]'.
GET /
And it just hangs.
Even though the web management interface is unresponsive, the internet seems to work ok, though wifi is sporadic.
Rebooting the hub doesn't seem to help. I read some reports of badly fitted heatsinks on these Type B's - so could mine be over heating and causing this lock up? If I leave it and try again in a few hours it may work again. Yesterday the internet connection dropped twice and when I was able to login to the web interface, the Event log showed that the hub had spontaneously rebooted itself.
Do I have a bad home hub?

Hi pgregg,
Have you tried a full reset of the hub yet? Not just a reboot?
Chris
BT Mod Team.
If you like a post, or want to say thanks for a helpful answer, please click on the Ratings star on the left-hand side of the post.
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.

WLC Duplicate IP address detected for AP-Manager Interface

I am getting an error log in the WLC saying, its IP address is duplicate by another machine with MAC address A.B.C.D
But this MAC address A.B.C.D is the MAC address of the AP-Manager Interface in the same controller.
Model No.                   AIR-WLC2106-K9
Software Version                 7.0.116.0
%LWAPP-3-DUP_IP: spam_lrad.c:27626 Adding client 58:b0:35:83:72:86 to exclusion list due to IP Address conflict with AP 'AP_DUXO_3'
%LWAPP-3-DUP_AP_IP: spam_lrad.c:27612 Duplicate IP address detected for AP AP_DUXO_3, IP address of AP 10.184.1.224, this is a duplicate of IP on another machine (MAC address 58:b0:35:83:72:86)
Cisco AP Identifier.............................. 1
Cisco AP Name.................................... AP_DUXO_3
Country code..................................... US - United States
Regulatory Domain allowed by Country............. 802.11bg:-A     802.11a:-A
AP Country code.................................. US - United States
AP Regulatory Domain............................. 802.11bg:-A    802.11a:-N
Switch Port Number .............................. 1
MAC Address...................................... cc:ef:48:1a:e4:af
IP Address Configuration......................... Static IP assigned
IP Address....................................... 10.184.1.224
IP NetMask....................................... 255.255.0.0
Gateway IP Addr.................................. 10.184.20.2
Domain...........................................
Name Server......................................
NAT External IP Address.......................... None
CAPWAP Path MTU.................................. 1485
Telnet State..................................... Enabled
Ssh State........................................ Disabled
Cisco AP Location................................ DUXO_BOX
Cisco AP Group Name.............................. default-group
Does anyone have an issue like this ?

Are you sure this MAC address 58:b0:35:83:72:86 isn't some type of Apple device? Its OUI is registered to apple. How do clients get ip addresses DHCP? It appears that the IP 10.184.1.224 is statically assigned to your ap-manager and that this client 58:b0:35:83:72:86 is either getting that same IP from DHCP or the client is statically assigning it themselves.

VIP Redundancy and Management interface

Similar Messages

Maybe you are looking for