×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CSS11506 - First Circuit okay, 2nd doesn't work at all

Unanswered Question
Jan 29th, 2004
User Badges:
  • Bronze, 100 points or more

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.


Situation.


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 129.1.0.96/27 and assigned to "Circuit Vlan 56".

Portal 2 usses Adressspace 129.1.0.160/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.


------


Problem:


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 129.1.0.161.


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 (129.1.0.161), 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.


Question:

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!


---------------------------



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Roble Mumin Thu, 01/29/2004 - 06:32
User Badges:
  • Bronze, 100 points or more

Configuration and Infos' for above posting.

Hope the information is sufficient to get the picture.


Greetings


Roble




Attachment: 
Roble Mumin Mon, 02/02/2004 - 02:19
User Badges:
  • Bronze, 100 points or more

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.


case closed


Actions

This Discussion