Tag Archives: FWSM

VLAN groups for fwsm and ace on 6513

Leave a reply

With the data centre move, I took the opportunity to clean up some of the 6513 config which had got out of control.

The original groupings looked all over the place:

svclc vlan-group 1 27,28,40,76
svclc vlan-group 2 44,45,48
svclc vlan-group 42 42
svclc vlan-group 43 43
svclc vlan-group 400 402
svclc vlan-group 427 427,428
svclc vlan-group 500 527,528,544,545,548
svclc vlan-group 600 612,614,618,620,621,622,623,624,625,626,628,632,636,699
svclc vlan-group 602 602
svclc vlan-group 700 720,721,724,725,732
svclc vlan-group 990 996,997
svclc vlan-group 999 9,999
svclc module 2 vlan-group 2,43,400,427,500,600,602,700,999,
firewall module 1 vlan-group 1,42,427,428,600,990,999,

….YUK. However I decided to break the FWSM and ACE’s visible vlans into groups with more meaning; specifically:

Group 1 = specific to FWSM
Group 2 = common to both
Group 3 = specific to ACE

In the end the config gets cleaned up and looks like:

svclc vlan-group 1 27,28,40,42,76,612,614,618,622,623,626,628,636,699,996,997
svclc vlan-group 2 9,427,428,620,621,624,625,632,999
svclc vlan-group 3 43,44,45,48,402,527,528,544,545,548,602,720,721,724,725,732

firewall module 1 vlan-group 1,2
svclc module 2 vlan-group 2,3

…much better ! A few of the other commands that got me out of a few dramas:

firewall autostate
firewall multiple-vlan-interfaces
svclc autostate
svclc multiple-vlan-interfaces

(The autostate command helps the devices track the loss of an access link).

Moved Data Centre

Leave a reply

The Data Centre move happened last weekend – all went well and we did it (a team of 11) in 24 hours. I had to look after the firewalls, ACEs, proxy, WAAS as a priority and chipped in whereever else when required. For a business that does several hundred million dollars of business through its web site (as one example) – It was a great effort to have the business back online 2 days prior to expectation. Some of the guys I work with really showed their expertise and planning skills.

One thing I learned was that if unsure, always bring up the standby FWSM or ACE when :

A. The primary unit is online and functional and is active.

B. The underlying network (vlans, switch configs etc) are up and stable.

I had a few dramas where the failover states of the FWSM or ACE seemed ok, but because a few things were changed during the move things started to go awry. In some cases both FWSMs or ACEs were up, but because of some underlying changes to the network they would both think they are active and the network can get turned into a banana. (eg. failover vlan removed!)

In hindsight, I should have left the secondary modules out until all other network work was completed. Just because you think the modules are working at one point in time doesn’t mean they will be behaving as expected at a later point if there are changes being made to the network.

No luck so far with the ACE log issue

1 Reply

I’ve sent more info to the TAC re that ACE logging issue – which has not shown up again for a few weeks. It stopped suddenly after the production rservers in the ‘correct’ context were finally started up (the context was prepared and active prior to server deployment). In any case, the TAC has escalated it to the engineering team for analysis. I agreed with one of Cisco’s engineers that said “this shouldn’t be possible”. Love it :)

We deployed a Cisco WAAS appliance to the Brisbane office – all seemed ok however the voice team said ‘at some stage after the WAAS was turned on’ they had messages-on-hold errors. Strange given that WAN optimisers ignore udp. Because the deployment is using wccp – it is likely something has gone wrong with the router – or it could be unrelated altogether.

Also, I learned a valuable lesson the other night – never gloss over the ‘clear xlate’ command on a FWSM. When messing around with static nats, hours can be saved troubleshooting by using that command … bah.