CSS11506 - First Circuit okay, 2nd doesn't work at all
I hope you guys have a clue regarding this really strange issue.
First of all im all new to the content switching topic and have no experience reagarding the CSS
Series. I usually work with CatOS or IOS based Cisco Devices and have a hard time with the strange CLI of the CSS.
Two Different Intranetwebsites we call them "Portal 1" and "Portal 2" are connected to two different CSS 11506. The Portal 1 Servers (7) are connected to the primary and secondary 11506 via a 16xFE Modules in Slot 3. Portal 2 Servers (8) are connected to 16xFE Modules in Slot 6 on each 11506.
We use Adapter Teaming on the Servers and configured the second NIC as standby connected to secondary CSS11506. The Primary NIC is connected to the primary CSS11506 and is configured as being the active Adapter.
Portal 1 uses Adressspace 126.96.36.199/27 and assigned to "Circuit Vlan 56".
Portal 2 usses Adressspace 188.8.131.52/27 and assigned to "Circuit Vlan 59".
Portal 1 is defined for Owner PP1 in two different Content Rules. Portal 1 is working fine currently.
Portal 2 is defined for Owner PP2 in two different Rules as well. Portal 2 is not working at all.
All servers connected to Module 6 are members of "Bridge Vlan 59" but are unable to communicate with their default GW or other members in VLan 59.
The default GW for circuit VL 59 ist 184.108.40.206.
show arp on the primary CSS does not list the connected servers. show arp on the secondary CSS
lists portal 2 servers learned via port 1/2 which is GE trunk. This is the first thing which
really confuses me!
Pinging the virtual GW Adress works only from the primary switch (220.127.116.11), secondary times out. Pinging the "physical" IP Adresses for the according circuit, works on both switches.
Pinging the servers for portal 2 works on neither content switch. Reaching the servers via ping for portal 1 works fine on primary and secondary.
The Servers connected to VLAN 59 are listing the circuit 59 default GW with an invalid MAC adress (arp -a).
This is the second thing which really confuses me! :)
The configuration for the circuits and vlans are similiar and IMHO correct as well. The only difference between Portal 1 and Portal 2 is the Software on the used 16x FE Modules.
Portal 1 - Module 3 - is using 7.20 Build 104
Portal 2 - Module 6 - is using 7.20 Build 206
Software on the CSS itself is 7.20 Build 104.
What i have done so far:
Tried connection without adapter teaming on servers, used a laptop with a different NIC.
Is it possible that the different softwarimages on IOM-16FE Modules are causing the trouble?
Some relevant command int the configuration missing?
I will attach configuration info in a second post.
If you guys can point me in the right direction i'll be glad to hear about!
Re: CSS11506 - First Circuit okay, 2nd doesn't work at all
Fixed my problem.
And i think it might be a bug in the software.
Before being moved to the CS the Portal2 Network was was announced/routed to a different layer3 device.
Ceating the VLAN59 on the content switch and removing it on the previous owner was fine for all other network devices. Routing was okay and the content switch was the endpoint for the moved Network. Unfortunatly allthough the Network for VLAN59 was local on the the content switch it still routed it to the uplink.
Routing table was showing okay but in some strange table it still had this VL as being remote.
What fixed it, was a simple reboot of the CSS.
This is one of the worst errors i encountered so far.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...