Invalid input trying to configure FWSM int

Answered Question
Oct 24th, 2008
User Badges:

Hello all,

I'm building a brand new FWSM running 3.2(2) and have already configured for failover and verified communications between the two. I have also put them both into mode multiple and created 3 contexts. I also assigned the vlan interfaces from the switch to each vlan group as needed. Finally, I went into the admin context and allocated the interfaces to the proper context.


The problem now is when I go to any context and type:

conf t

interface xyz

I get "invalid input" back. If I do interface ? it shows me the names of all my interfaces. If I do interface x and hit tab, it autocompletes the right name. But no matter what, i can't get into interface config mode. Any ideas?


Thanks in advance for the help!




Correct Answer by ajagadee about 8 years 5 months ago

Matt,


The bug is present in 3.2 and is fixed in 3.2.3 and higher. So, upgrading the FWSM to 3.2.3 or higher should fix the issue that you are running into.


Regards,

Arul


*Pls rate if it helps*

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
ajagadee Fri, 10/24/2008 - 17:35
User Badges:
  • Cisco Employee,

Matt,


Can you post the outputs of the system context where you have assigned the interfaces for the specific context and also the exact outputs when you try to configure the command.


In the meantime, look at Bug ID CSCsk32932 which is a close match of the issue that you are experiencing.


http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/release/notes/fwsmrn31.html


Regards,

Arul


*Pls rate if it helps*



MATTHEW BECK Mon, 10/27/2008 - 06:24
User Badges:

Hi Arul,


It does sound similar but I'm running 3.2(2) and that bug was fixed back in 3.1x. Here's the show run I've put together so far.


FWSM/Prod/act(config)# sho run

: Saved

:

FWSM Version 3.2(2)

!

hostname Prod

names

!

interface tocore

no nameif

no security-level

no ip address

!

interface Infra

no nameif

no security-level

no ip address

!

interface OXI

no nameif

no security-level

no ip address

!

interface OXE

no nameif

no security-level

no ip address

!

interface OXWeb

no nameif

no security-level

no ip address

!

pager lines 24

logging buffer-size 16384

logging buffered informational

no asdm history enable

arp timeout 14400

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 1:00:00 h225 1:00:00 mgcp 0:05:00

timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout sip-invite 0:03:00 sip-disconnect 0:02:00

timeout uauth 0:05:00 absolute

no snmp-server location

no snmp-server contact

telnet timeout 5

ssh timeout 5

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map global_policy

class inspection_default

inspect dns maximum-length 512

inspect ftp

inspect h323 h225

inspect h323 ras

inspect netbios

inspect rsh

inspect skinny

inspect smtp

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

!

service-policy global_policy global

Cryptochecksum:xxx

: end


Thanks again for the help!


Matt

Correct Answer
ajagadee Mon, 10/27/2008 - 11:58
User Badges:
  • Cisco Employee,

Matt,


The bug is present in 3.2 and is fixed in 3.2.3 and higher. So, upgrading the FWSM to 3.2.3 or higher should fix the issue that you are running into.


Regards,

Arul


*Pls rate if it helps*

MATTHEW BECK Mon, 10/27/2008 - 13:11
User Badges:

Hello again,


Yeah, I opened a TAC case and they gave me a work-around so I could upgrade the code. I'm now running 3.2(8) and the problem doesn't occur.


FWIW, the work-around involved not providing an alias while allocating interfaces in the system context. For example, my original config said:


allocate-inter vlan50 tocore


This has the affect of hiding the VLAN tag from the context and just showing "tocore" as the interface. I took out that command and put it back in as:


allocate-inter vlan50


After doing that, I could configure that interface in the context, get an IP on there and upgrade the image. Once I reloaded with the new image all my other aliases worked just fine because, as you mentioned, the problem was resolved in 3.2(3).


Thanks for your input and enjoy your week!


Matt

Actions

This Discussion