• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3900
  • Last Modified:

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

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?
0
Allianse
Asked:
Allianse
  • 7
  • 5
1 Solution
 
decoleurCommented:
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
0
 
AllianseAuthor 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      
0
 
decoleurCommented:
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"
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
AllianseAuthor 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....
0
 
decoleurCommented:
just for kicks try to put an interface on the chassis on vlan 66 and see if that brings it up.
0
 
AllianseAuthor 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....

0
 
AllianseAuthor Commented:
I've assigned a ticket to Cisco TAC - Looks like this is some kind of bug, and not a configuration error.
0
 
decoleurCommented:
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
0
 
AllianseAuthor Commented:
of course, I'll let you guys know once we get to the bottom of this.
0
 
decoleurCommented:
Thanks, I think others would benefit from this exchange.

-t
0
 
AllianseAuthor 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
0
 
z26oCommented:
That bug ID does not exist but I am having the same problem, can you check the bug ID# for me?
Thanks
0
 
AllianseAuthor Commented:
Check again, the URL is correct, they just took a while to register the data to the bug page.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now