7

My initial problem: I’ve run out of physical ports on my ASA 5525-X

My initial solution: Create sub-interfaces on a port-channel and use a switch to aggregate my VLANs

The subsequent issue: How do I move the names assigned to the original interfaces to the new sub-interfaces while keeping the rest of my configuration in place?

If I issue a ‘no nameif’ directive on the original interface prior to reassigning the name, the ASA will delete every configuration element that referenced that name.

If I reissue the ‘nameif’ directive to rename the interface to something temporary prior to reassigning the original name, all of the configuration elements that referenced the original name will be updated to reflect the new name. In the end, I’m no closer to my goal.

The only solution I’ve fund so far is the obvious one - edit the startup-config offline and reload the firewall with my changes already in place. What I don’t like about this is the reload time – the ASA doesn’t boot quickly. I won’t be able to sneak the downtime into a small maintenance window at the end of the day (is the internet down? Huh, it’s back up now - must have been me). Instead, I’ll will have to schedule a longer maintenance window.

Update: Please check out the related question, Cisco ASA startup-config command ordering for sub-interfaces.

Is there another way to ‘move’ a name from one interface to a new interface while keeping everything else in place?

3

5 Answers 5

2

Leave the physical port you are using as the untagged VLAN. You can direct that traffic to a VLAN# on your switch by setting the Native VLAN the VLAN# you want that traffic to be on.

Then for every new VLAN you are adding to your ASA, make that a sub interface.

I don't have an ASA to validate this code, but it will look something like this:

interface gig0/0
  nameif ORIGINAL-NAMEIF
  security-level 100

interface gig0/0.20
  vlan 20
  nameif NEW-VLAN-2
  security-level 20

interface gig0/0.30
  vlan 30
  nameif NEW-VLAN-3
  security-level 30

etc. It should allow you to add new sub interfaces without making any changes to your original interface. The "root" interface doesn't include a VLAN tag, so that traffic is unchanged.

You can run it this way indefinitely, or change it so everything is using VLAN tags at a later date when its more convenient for you to bring the network down.

1
  • Good suggestion @Eddie. I'll probably end up using a combination your suggestion and something similar to that suggested by @massimo-baschieri (a straight show run | i interface name misses various context elements). Commented May 27, 2015 at 16:04
1

This is how I did the same thing.

First I changed all of my interface names to have "_REPLACE" at the end.

This ensured that I woudl only select the actual places where the interface was present.

Several items will default to being named with default interface name at the time they are created, but will not change if you rename the interface later. Further, you may have objects you named with the interface name yourself at some point, which could also be confused.

EG: Arbitrary_Net interface became Arbitrary_Net_REPLACE

Then I created a Port-channel across a couple of interfaces and created VLAN Interfaces Below these, putting the VLAN ID as the subinterface number and appended to the Interface name that woudl move there.

EG: "Arbitrary_Net" interface is on VLAN 173, so PortChannel1.123 was assigned VLAN ID 123, and given the name "Arbitrary_Net_123"

However, doing it again I would amend this process to simply have "_NEW" at the end instead of as "Arbitrary_Net_NEW" as this could allow me to make changes much more quickly.

I ensured that the Interfaces had their MAC addresses setup for HA etc and that the port channels were working and some arbitrary temporary VLAN I create don the ASA and the switch showed the ASA could ping the switch and the Switch could ping the ASA to ensure there was already connectivity.

I also changed the HTTP and SSH to use LOCAL instead of AAA until changes completed Iwhen I woudl change them back, and I added and tested management access from a host on a separate network from my normal management network so that I could move that network first then complete the changes from it after confirming I still had management access.

Then I just TFTPed down the config copy run tftp://[hostIP]/[Path]/FW_Cluster A_Primary_Active_Original.asa and opened this in Notepad++ to edit.

To be cautious I just Searched all of the "_Replace" statements and placed them in a separate file (let's call this "Main File"

I reviewed these and if any were not flush to the left side I checked that area to make sure I grabbed outer commands needed from the TFTPed file.

Note: I could have done that with AAA setups but I figured it was much easier to just to let ASDM take care of making sure to re-write the commands exactly on those as AAA has to be completely removed and readded and I had half a dozen setups. So I just discarded the AAA items until later.

Likewise, I discarded commands such as nameif and MTU that were not changing.

This left mostly a bunch of NAT rules, the ACE to interface associations, Cyrptomaps, and some routes etc. in the Main File

The Routes, I MOVED to a separate File (call it Penultimate File), here I doubled them, put no route to the old interface and then route to the new interface and grouped them by the interface.

WebVPN and HTTP Redirect I COPIED to Penultimate File as well, and I prefixed all of these with no appended to them.

I added a few more odds and Ends to Penultimate File which needed to be removed and then added again such as:

no management Arbitrary_NET_REPLACE
management Arbitrary_NET_NEW

When I went back to the MAIN File and was satisfied there was none of that sort of stuff left in it

So I just did a search for _REPLACE and Replaced with _New (or if you were following along I actually did a bunch of these because I was using VLAN IDs on the interfaces)

I pulled all of the NAT Rules out into an Excel as well and Ran a sh run nat | in _REPLACE On the ASA

I put the output of that command in one set of Cells and the New versions of the commands in the other set, and reviewed to make sure they were matched up.

I then used Excel to Split off the NAT Rule Numbers from the first set of Cells and add it to the second just before the "Source" keyword

IE I put the results of the show into column B, the NATs from the Main File into Column C and then** in Column E I did a substitution using excel =SUBSTITUTE(C1, source ,LEFT(B1," "&FIND(" ",B1)&"source ")) This took the rule numbers and stuck them in right before source which is what is needed to place them in the correct order.

(**TBH before doing the substitution in column E, I used Column D to run a compare against Column B and C looking at the NAT rules from the word source onwards but I don't feel like writing in that equation at the moment from scratching my head, and the results all 8 times were as expected so my visual inspection was accurate enough)

Then in Column A, I added this Formula to get the rule numbers =LEFT(B1,FIND(" ",B1)-1)

Then I selected Columns A through E, hit Filter, and Sorted them to reverse the order of the NAT rules so they would be applied from highest number to lowest number.

I then Copied these back into the MAIN File replacing the NATs that had been there before.

Finally, I went back to the TFTPed File and copied the Interface Commands for the Old Interfaces into a Final File

These I changed the IP on them to a network completely outside the normal range, lets say the Original networks were all 10.1.x.y, I changed these all to 10.2.x.y I changed all of the Monitor statements to no monitor and added a shut at the end

I then Copied all of the New Interface commands in, and put int he correct IP addresses and subnet masks, and I added monitor keywords for each.

I then paired each old interface with the new so I could do these one set at a time just in case I missed some issue.

Lastly, I copied the original commands again for these original interfaces, and only retained the interface gi0/0 command and the nameif command and appended no to each nameif so they were all no nameif, and placed this in a separate file for later, just in case.

FINALLY I was Ready.

I applied the changes from the Mian file.

Now I had all my ACLss associated with both the new and old interface, and all of the NAT rules were duplicated to them as well (which is not a problem because it only mattered once traffic woudl pass the given interface.)

I could review the NAT rule sin CLI or ASDM and see the new and old rules next to each other correctly which was also very helpful in confirming no issues.

I then applied the changes from the Penultimate file and Final file ONLy for the interface which I had set up alternate access sin to for ASDM and SSH, I then confirmed all was well and logged into t SSH and ASDM there to make the remaining changes.

I now applied all of the remaining changes from Penultimate file, and then All of the Changes from the FInal File.

This left me with the original interfaces still there, the ACLs and NATs still applied to them, and all of it able to be turned back on and start working with only a minor set of changes.

Once I was satisfied a few hours later that the changes were good

I Moved all of the AAA settings overusing ASDM (thank you ASDM!) and then I ran the no nameif commands I had saved in a separate file for later, and all of the remaining entries for anything to do with those interfaces were removed from the firewall cluster.

Doing this you could feasibly do the average firewall in a day or two of work once you are comfortable with the process, but I found that I was much more cautious and only the firewalls cluster with practically no NATs and VPNs seemed "quick" at all.

In part, because you are going to want to tripel check everything and even having done so you may likely forget some small thing.

However, I can say that leaving the interface changes till the very last step allowed me to deal with little gotchas well before that step so that when traffic actually moved over there was often only ping or two lost if that, usually just a little latency.

0

edit the startup-config offline and reload

That's the only way. Internally, the name is tracked with a unique ID. There's no way to "move" the name to a different interface.

One possible alternative would be to update the startup-config, then remove the names and "copy start run" to put everything back. But you're asking for a major mess, and it will still break every existing connection. (I'd give it 1 in 5 of crashing the system in the process.)

As for the time to reload, I've never seen an ASA take more than a few minutes (under 5) to reload.

3
  • Thanks for the post. I too thought about using copy offline-config run (offline-config would be a configuration file I've modified offline and uploaded to the ASA) followed by clear conn all, but wasn't sure what the effect might be... I figured it might be messy. Commented May 27, 2015 at 16:31
  • Copying to run on IOS devices is a merge operation. I'm not sure what it does on an ASA, but messy would be the nicest description I can think of.
    – cpt_fink
    Commented Jun 4, 2015 at 5:00
  • 1
    no nameif would delete a great deal of the configuration in the process. So then copying the startup into running might work. But using anything from 8.3 on will NOT work as the config cannot be parsed top to bottom.
    – Ricky
    Commented Jun 4, 2015 at 7:38
0

That's my way: Issue a show run | include "interface name" Paste to notepad all the lines with "interface name" Add on top the commands to move the name to the new interface Since now you worked offline, so no running config change at all Now starts the real game, copy and paste the whole lines to asa, configuration is changed and new one is running in a few seconds However you need to double check the configuration lines prior to start and be sure not to loose the asa once you delete the name on the original interface.

1
  • Thanks for the suggestion. I'll probably end up using some technique similar to what you've suggested. Unfortunately, simply executing show run | include interface name will miss various configuration elements. For example, object nat requires a global command + a sub-command, but only the sub-command references the interface name. Commented May 27, 2015 at 16:25
0

Another thing you can do is copying the output of more system:running-config to a notepad, make the interface changes. Remove the checksums and copy it back to the flash of the asa using ftp or tftp. Then do clear configure factory-default. After this, do copy disk0:/modified-config running-config. This will preserve all configuration and just changes the interfaces. (Don't forget to unshut the interfaces and do a configuration comparison with Notepad++ Compare or other tool.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.