Hi all.
BRIEF DESRCIPTION OF MY PROBLEM:
We have earlier successfully configured vlan trunking (dot1.q) on a PIX interface with one vlan on physical interface and two vlans on logical IF's under same physical IF. (As in following dokument: http://www.cisco.com/en/US/customer/products/sw/secursw/ps2120/products_configuration_guide_chapter09186a0080172786.html#wp1113411) Those vlans was this particular system's testing environment vlans.
After a few days of testing we decided to move production environment to this PIX interface to be configured the same way but with other vlans and ip subnets.
It didn't work very well, the two vlans on logical IF's worked fine but the vlan on physical IF didn't. Strange since it worket fine with test environment vlans configured the same way.
In the PIX535 v.6.3(1) with UR-licence the [show interface] command showed nothing odd, IP address, netmask and vlan were correct, "interface xxx is up", "line protocol is up" and so on.
I entered the Cisco6509 switch in which the trunk terminates. [show trunk mod/port] verified that all vlans that shuold be permitted really was permitted on the trunk. [show cam dynamic VLAN-nr] and [show cam dynamic mod/port] found mac addresses to all hosts on the vlans and mac addresses to the two logical Pix IF's but not to the physical Pix IF. This is somewhat crazy since it works fine with another vlan, it smells like a bug to me...or!?
This must be some kind of layer2 problem in Pix. Under unknown/rare circumstances it seems that Pix doesn't advertise it's physical interface's mac address to the switch. Therefore layer 2 have no information on which switchport to throw packets destined to this interface on.
WORKAROUND - NOT A REAL FIX
We resolved our emediate needs by moving configuration for the not vorking vlan from physical to a third logical interface on the same physical IF. We also configured the physical interface with a non-used vlan other than vlan 1 since this is recommended by Cisco due to some attack called "jumping vlans"
Voila´! Now it works just fine!
Once again, this smells like a bug to me. I haven't found anything on Cisco.com that addresses anything like this. Is there anyone who have a clue about what the problem could be?
P.S. I will not bore you with long outputs from our Pix and switches but if someone is genuinely interested, I have them saved.
Best regards
Kjell Ohlsson
