Moving configuration best way !!

You haven't indicated even the manufacturer's name, let alone the model.

Based upon your reference to ASDM, and your use of subinterfaces, it would appear you are using either a Cisco PIX running 7.x software, or a Cisco ASA55x0 running 7.x software ? If so, then comp.dcom.sys.cisco would be a better location to ask in.

Not on a PIX it wouldn't. The PIX 'nameif' statement just gives a friendly name to an interface, but the internal configuration is all stored in terms of the hardware interface name. For example, if you were to use no nameif dmz followed by nameif FinanceDMZ and then were to display the configuration, then everywhere that used to have dmz would now have FinanceDMZ

On the other hand, removing the IP address from an interface -does- have impacts.

You asked about the "best" way. That depends upon exactly how you are connecting to the device. Generally speaking, one of the better ways is to upload the configuration to a tftp server, make a copy of the file on the server and edit the copy, then on the device, clear the configuration and put back just enough configuration to be able to talk to the tftp server again, and then download the modified configuration from the tftp server.

Many thanks for your quick reply

You are right i miss the model it's a PIX 525 with 7.0 and ASDM 5.0

i am a new user of this forum i will try the cisco forum

ok for the nameif but you mean that when you remove a nameif the configuration has still orphans lines ?

So for my modification i use telnet connection and a tftp server, no problem for that, is it better to do that in the running or startup config ??

My other question is how can i keep in the configuration only the lines for that interface, I'm talking about access-lists INBOUND and OUTBOUND and the NAT too because with ASDM i created group object but there is nothing that says for which interface it is, i tried : SH RUN | include "Routed networks" and SH RUN | include DMZ

Regards,

So, where exactly is your problem? One does usually create the configuration from some simple configuration files via a script/preprocessor. Changing a configuration simply means editing the $IF0 variable and running the script again, outputting the new configuration.

i have no problem i am just wondering how to do because the configuration is not simply and i want to be aware of anything before doing something.

so for you the steps are :

- Upload running to tftp

- on CLI i do : - (physical) ethernet1 --> no nameif DMZ --> no ip address

10.10.10.10 - (subinterface) ethernet1.1 --> nameif DMZ --> ip address 10.10.10.10

- with a text editor i remove lines where ethernet1 has got the old nameif and the ip address COPY IT

- on CLI in conf terminal and PASTE IT

is this right ?

So far yes, but potentially error-prone, and you need to make sure that the old configuration is actually removed (so that your edited configuration is not added to, but replacing the existing runtime configuration).

But How can i remove the old configuration ? You are talking of the whole configuration or only the lines to be added

Depends on how you do it. Usually the PIX will automatically clean up unassigned configuration entries, but to make sure I would command it to reapply the current configuration from new.

The whole configuration.

sorry but what is the command in the V7 to erase the running configuration ?

Are you sure there is no difference between running and startup ?

Regards,

'reload' (invokes reboot and reloads the configuration from flash memory, ignoring all old invalid rules) and then 'write memory'

As you can read in the documentation, any configuration done by 'configure memory' (because 'configure terminal' writes to the memory) is _merged_ with the current configuration. Your old rules refering to the then non-existent ethernet1 would remain until someone removes them or the configuration is reloaded and rewritten.

At startup, there is no runtime configuration until it's loaded from somewhere. When doing 'configure terminal' or editing a configuration floppy, this will not change the runtime configuration until you load it from there.

Many thanks for you help, i have just done my operation and everything seems to be ok, my only trouble has been resolved it was about vlan and trunk and now it's ok.

So what i did is to upload the running config by tftp and modify the interface configuration with no for the physical and a new one for the virtual interface save it and do a copy tftp to running i had a lot of errors for duplicated lines but everything was ok so...

I don't want to disturb once again but for security reasons i want to know what is the commande on my catalyst to allow only vlan's on the PIX port and for the subinterface created, for the moment i have a config port with trunking so it meens that this PIX port is in all the VLAN's and i want to reduce it.

regards,

That's how it should be. Now, if you don't save the current clean configuration back to memory, you'll get these errors everytime the configuration is reloaded.

And well, that's exactly why I prefer always being able to create a clean configuration (of configuration script) from a way simpler, maybe even graphical configuration (like ShoreWall). This also allows easily creating a complete reconfiguration script.

Short: Doesn't work. You need to create two subinterface, the first one being assigned to some unused VLAN, receiving all traffic from unassigned VLAN and untagged traffic just to discard it. The second one is your real subinterface for the actual VLAN (with an ID != 1).

shorewall does it work on Windows ?

for your cisco link it talk about 6.3 and i can't see where to configure vlan's on physical interface, i forget to say to you that i'm in failover mode.

No. It's just a very well-known example for many graphical firewall management products.

At least I can't remember this thing being changed in v7, but well, the v7 documentation seems to be down today.

VLANs are always logical interfaces. VLAN on a physical interface is forwarded to the first defined logical interface or VLAN-ID 1.

Shouldn't matter that much for this behaviour.