Interfaces do not restore to new hardware
-
Edit the backup file and replace the old interface names with the new.
Be careful you don't just s/re0/em0/g because there are probably instances of re0 in some of the base64-encoded objects.
Should take all of 5 minutes.
-
Edit the backup file and replace the old interface names with the new.
Be careful you don't just s/re0/em0/g because there are probably instances of re0 in some of the base64-encoded objects.
Should take all of 5 minutes.
Thanks for the suggestion. I did as you suggested and the restore no longer complained about missing interfaces. It rebooted and everything looks good. But now if I do a "ifconfig -u" all of the interfaces are listed as UP, even though there is nothing plugged into the NICs. The UP status persists even after reboots. Also, when I connect to a NIC there is no notifications on the console that the interface is going up or down. So its as if its stuck in a weird UP state.
-
What is not working?
-
-
Then you have to block it using firewall rules. This is completely normal.
Or disable the interface. It's not a Cisco.
-
Then you have to block it using firewall rules. This is completely normal.
Or disable the interface. It's not a Cisco.
Sorry, its not accessible from the new interface. didn't mean mean to say acceptable. Autocorrect :)
-
I have no idea what you're saying is not working. You'll probably have to be more specific.
-
I have no idea what you're saying is not working. You'll probably have to be more specific.
Replacing the old interface names in the backup file solved the issue with the restore. I can see that the IPs are properly configured to the proper interfaces. But the issue now is that the management UI is still not accessible via the new interface.
Additionally, which might be related to the above issue, if I do not connect any of the NICs to the network all of the interfaces still appear to be UP and not Down. When connecting and disconnecting the NICs there is also no console notification that an interface went up or down. So all of the interfaces appear to stuck in an UP position and not able to detect when a NIC is connected or disconnected to the network.
-
UP does not mean active. UP means not forced down.
This is with an IP configured and an interface enabled but not patched to a switch. Note the "no carrier"
em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 00:30:18:a4:ec:73
inet6 fe80::230:18ff:fea4:ec73%em1 prefixlen 64 scopeid 0x3
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
status: no carrierThis is the same interface disabled:
em1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 00:30:18:a4:ec:73
inet6 fe80::230:18ff:fea4:ec73%em1 prefixlen 64 scopeid 0x3
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
status: no carrierYou might be over-thinking things.
What firewall rules do you have on the interface that you can't access the webgui on?</performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></broadcast,simplex,multicast></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast>
-
UP does not mean active. UP means not forced down.
This is with an IP configured and an interface enabled but not patched to a switch. Note the "no carrier"
em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 00:30:18:a4:ec:73
inet6 fe80::230:18ff:fea4:ec73%em1 prefixlen 64 scopeid 0x3
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
status: no carrierThis is the same interface disabled:
em1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 00:30:18:a4:ec:73
inet6 fe80::230:18ff:fea4:ec73%em1 prefixlen 64 scopeid 0x3
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
status: no carrierYou might be over-thinking things.
What firewall rules do you have on the interface that you can't access the webgui on?</performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></broadcast,simplex,multicast></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast>
Well any rule that would be blocking access to the webgui would also be on the host that the backup was taken and blocking access to its webgui. This is not the case as the backuped host is online and accessible without issue.
Ill check the "no carrier" when i get into the office in the morning
-
You're messing something up.
-
You're messing something up.
I can confirm that the interface name in the config is correct and that interface is the one that is connected to the network. Ill reinstall and rerun the whole process one more time in the morning.
-
The root issue was resolved by reseating the NICs. For anyone else looking for a solution to a similar situation here are the steps that I took:
-
Export backup XML from originating firewall
-
Modify XML, replacing originating firewall interface names with interface names on the new firewall
-
Restore XML to new firewall. There should be no warning, if there are check that you got all of the names changed
-
Connect new firewall to the network
-
-
Helps when you can actually talk to the hardware. Glad you found it.
-
Modify XML, replacing originating firewall interface names with interface names on the new firewall
To be on the save side I would suggest to do this first with a copy of the .XML file so you will be able to start
even new if it fails until it is not failing anymore.