Side-by-side upgrade(AZURE), preserving old ip-addresses

Arskaz — Wed, 10 Jan 2024 10:17:18 GMT

Hi!

I have tested this multiple times:

- Install new GW to same resourcegroup/vnet/subnets as old gw using template from github.

- Move old external ip to new gw (and set new alias ip for external if)

- Change old gw internal ip(not external if) addresses of all interfaces to free ones(will not be used)

- Change new gw internal ip(not external if) addresses of all interfaces to be like in the old gw (both azure nic and at gaia side)

- New SIC for gw and install policy

Worked fine in lab environment.

Tested same in production, result: External if worked fine, one internal worked fine, but one internal did not work: From gaia side cppcap and tcpdump showed, that traffic exits new fw, but it was newer forwarded to destination as well as no traffic was received to that interface...

When set the new gw if address to the original (new addess), traffic worked fine...

Any ideas?

Or is there something, that changing internal addresses of Cloudguard in Azure is not supported officially?

The problematic interface (eth2) was added after installation to the configuration and the only difference seen is, that eth0 and eth1 have some kind of "link" to interfaces named enPxxxxxxxxx

dmesg doesn't have information about eth2:

Grepped eth from dmesg:

[ 24.138137] mlx4_en: Mellanox ConnectX HCA Ethernet driver v4.6-1.0.1
[ 24.151215] mlx4_core b914:00:02.0 eth3: joined to eth1
[ 24.151218] hv_netvsc 000d3aa9-a799-000d-3aa9-a799000d3aa9 eth1: VF registering: eth3
[ 24.161309] mlx4_core 88fa:00:02.0 eth4: joined to eth0
[ 24.161312] hv_netvsc 000d3aa9-a5ee-000d-3aa9-a5ee000d3aa9 eth0: VF registering: eth4
[ 60.281793] hv_netvsc 000d3aa9-a799-000d-3aa9-a799000d3aa9 eth1: Data path switched to VF: enP47380p0s2
[ 60.332827] hv_netvsc 000d3aa9-a5ee-000d-3aa9-a5ee000d3aa9 eth0: Data path switched to VF: enP35066p0s2

ifconfig says:

# ifconfig
enP35066p0s2 Link encap:Ethernet HWaddr 00:0D:3A:A9:A5:EE
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1467578 errors:0 dropped:0 overruns:0 frame:0
TX packets:1758889 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1843787252 (1.7 GiB) TX bytes:293705770 (280.0 MiB)

enP47380p0s2 Link encap:Ethernet HWaddr 00:0D:3A:A9:A7:99
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:581 errors:0 dropped:0 overruns:0 frame:0
TX packets:53214 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:118642 (115.8 KiB) TX bytes:11817062 (11.2 MiB)

eth0 Link encap:Ethernet HWaddr 00:0D:3A:A9:A5:EE
inet addr:10.10.10.37 Bcast:10.10.10.47 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1850207 errors:0 dropped:0 overruns:0 frame:0
TX packets:1758889 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1999816827 (1.8 GiB) TX bytes:286644420 (273.3 MiB)

eth0:1 Link encap:Ethernet HWaddr 00:0D:3A:A9:A5:EE
inet addr:x.x.x.x Bcast:z.z.z.z Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

eth1 Link encap:Ethernet HWaddr 00:0D:3A:A9:A7:99
inet addr:10.10.10.53 Bcast:10.10.10.63 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53465 errors:0 dropped:0 overruns:0 frame:0
TX packets:53214 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11890000 (11.3 MiB) TX bytes:11806436 (11.2 MiB)

eth2 Link encap:Ethernet HWaddr 60:45:BD:F6:15:BE
inet addr:10.10.10.69 Bcast:10.10.10.79 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:190 errors:0 dropped:0 overruns:0 frame:0
TX packets:510 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15932 (15.5 KiB) TX bytes:45272 (44.2 KiB)

EDIT: The old gw has similar view from gaia side, so those missing enPxxx interfaces should not be the reason. Old gw neither reports eth2 in dmesg, that is weird?

Re: Side-by-side upgrade(AZURE), preserving old ip-addresses

Arskaz — Thu, 11 Jan 2024 12:13:30 GMT

Reply to myself...IP forwarding has to be enabled at additional interface(Azure part of config), that is attached to FW. It's not enabled by default.

topic Side-by-side upgrade(AZURE), preserving old ip-addresses in Cloud Firewall

Side-by-side upgrade(AZURE), preserving old ip-addresses

Re: Side-by-side upgrade(AZURE), preserving old ip-addresses