We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now

x

6500 with FWSM  - Vlan shows as "down" in the FWSM module

Medium Priority
4,167 Views
Last Modified: 2012-05-06
We have two cisco WS-C6509-E with respective FWSM modules in each.
It's been working great, until recently, when we add more vlans to the "firewall vlan-group 1", the vlan's have stopped showing up in the "show vlan" command in the FWSM system.

on the 6400:
firewall multiple-vlan-interfaces
firewall module 7 vlan-group 1,
firewall vlan-group 1  76, 55, 44, 66

on the FWSM (system):

FWSM# show vlan
76, 55, 44 (where is 66??)

If I manually create a SVI (interface Vlan66) on the FWSM, the line protocol is down, but on the 6500 if I do "show firewall module 7 state", it clearly shows that it is trunking the vlan to the FWSM module.

I can confirm that we have "interface vlan66" on the 6500 that are line protocol up...

Has anyone else experienced something like this?
Comment
Watch Question

Commented:
Are new VLANs not working or old VLANs stopped working when you added ne VLANs. Also have you gone through and looked at http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00808b4d9f.shtml Section 2? it has the guidelines for adding VLANs to a FWSM.

hope this helps,

-t

Author

Commented:
The old VLANs are still working, I'm just not able to make new ones work!
Yes I've looked at the guide you linked to.

--> On the 6500 the new VLANs that I'm trying to trunk are active and UP:
6500#show ip int brief | incl 66
Vlan66                192.168.66.2 YES manual up                    up      

Commented:
in the ASA code you have to name an interface before you can see it as a live interface. have you named all of your vlans?

what does "sho run in vlan 66" produce in contrast to "sho run int vlan 55"

Author

Commented:
On the FWSM:
Actually, "interface Vlan66" doesn't create itself, but I can create it manually, but then the line protocol is down.

This is a normal interface on the FWSM:
FWSM# show interface Vlan55

Interface Vlan55 "", is up, line protocol is up
  Hardware is EtherSVI
        Available for allocation to a context
        MAC address 001e.beba.8a00, MTU not set
        IP address unassigned

FWSM# show run interface Vlan55
!
interface Vlan55

This is an example of any new VLAN that I'm trying to trunk to the FWSM:

FWSM# show interface vlan66
Interface Vlan66 "", is down, line protocol is down
  Hardware is EtherSVI
        Available for allocation to a context
        MAC address 001e.beba.8a00, MTU not set
        IP address unassigned

FWSM# show run interface vlan66
!
interface Vlan66
FWSM#
FWSM#
FWSM# show vlan
76, 55, 44 (still no 66!! Strange, huh??)

-- >As you can see, I have allocated the vlan to a context, and given the interface a name inside the context, and the configuration is simple and normal:

FWSM# changeto contextx TEST
FWSM/TEST# show run int vlan66
interface Vlan66
 nameif TEST
 security-level 50
FWSM/TEST#

--> And if I do "show interface Vlan66" within the context, it appears as down... even though it is enabled:

Interface Vlan66 "TEST", is down, line protocol is down
        MAC address 001e.beba.8a00, MTU 1500
        IP address x.x.x.x, subnet mask 255.255.255.0
  Traffic Statistics for "TEST":
        0 packets input, 0 bytes
        0 packets output, 0 bytes
        0 packets dropped

--> Here are some show commands from the 6500:

interface Vlan66
 ip vrf forwarding TEST
 ip address x.x.x.x 255.255.255.0
 standby 66 ip x.x.x.x
 standby 66 timers 1 4
 standby 66 priority 50
 standby 66 preempt
 standby 66 authentication 66test

6500#show run interface Vlan55
interface Vlan55
 ip vrf forwarding TEST55
 ip address x.x.x.x 255.255.255.0
 standby 55 ip x.x.x.x
 standby 55 timers 1 4
 standby 55 priority 50
 standby 55 preempt
 standby 55 authentication 55test


6500#show vlan id 66

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
66 TEST                             active    Te3/2, Po1, Po311

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
66 enet  100066     1500  -      -      -        -    -        0      0  

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------

6500#show firewall vlan-group 1
Group    Created by      vlans
-----    ----------      -----
    1          FWSM      
1  76, 55, 44, 66

--> I have alot of other contexts running, and nothing is wrong with them. I have done the procedure of creating contexts many times, and I feel like I haven't done something wrong, but still I have a hunch that this might be some kind of configuration error, because I have the same symptom on the neighbor 6500 with the same standby configuration, if I trunk a vlan to the fwsm it doesn't show when I do FWSM# show vlan. These two FWSM modules are in pseudo-standby by the way, so they don't replicate any config, that is why I think it is some kind of configuration error....

Commented:
just for kicks try to put an interface on the chassis on vlan 66 and see if that brings it up.

Author

Commented:
Now I've configured an interface on the 6500 into vlan355, and connected a laptop to it.

Still no difference on the FWSM, the vlan doesn't appear when I write

FWSM# show vlan

...and on the context the vlan is "protocol down" (no link) still....

Commented:
I've assigned a ticket to Cisco TAC - Looks like this is some kind of bug, and not a configuration error.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Commented:
thanks for letting us work with you. please let us know if there is a Cisco bugid associated with the behavior that you are seeing, or if TAC helps you with the resolution.

-t

Author

Commented:
of course, I'll let you guys know once we get to the bottom of this.

Commented:
Thanks, I think others would benefit from this exchange.

-t

Author

Commented:
Cisco has just registered a bug ID on this problem...

The bug will be documented here:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsy03447

Commented:
That bug ID does not exist but I am having the same problem, can you check the bug ID# for me?
Thanks

Author

Commented:
Check again, the URL is correct, they just took a while to register the data to the bug page.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.