How to update docker0 IP in Airwave

[esupport]

Requirement:

With Airwave 8.2.3 release we have a new feature with respect to the interfaces. Docker0 interface has been introduced and used for the purpose of bridging in virtualization concept. One might face issues in their network since the "docker0"  interface will pick an IP address from within the specified pool (172.17.0.0/16) which might match some other device in the same network. Hence communication between Airwave and devices in 172.17.0.0/16 subnet might fail.

Solution:

To fix this we can disable or delete the docker0 interface. However instead of permanently disabling it we can change the IP address to a loopback IP address or any other non-routable IP. This would ensure that current network devices are not impacted and you can still use the docker interface if needed.

Configuration:

We can run the following commands from support shell of airwave:

Stop the service

• service docker stop

Bring the interface down

• ip link set dev docker0 down

Delete the interface

• brctl delbr docker0

Modify the configuration to use the new IP address

• vi /etc/sysconfig/docker
• add: --bip=x.x.x.x/xx to the other_args=”” line so it looks like this now:
  other_args="--bip=10.1.1.1/24"

Start the service

• service docker start

ifconfig to confirm docker0 has been changed.

We can also choose to delete this interface based on requirement:

[root@localhost mercury]# sudo ip link delete docker0 type bridge

[root@localhost mercury]# service network restart

Verification

Example output:

Note: In case you decide to delete the interface then the docker0 would not show up in the output for ifconfig -a

[root@localhost mercury]# ifconfig -a

docker0   Link encap:Ethernet  HWaddr 0E:64:FF:8A:79:B1

          inet addr:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.0.0

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

eth0      Link encap:Ethernet  HWaddr 00:0C:29:83:F0:A1

          inet addr:10.9.211.155  Bcast:10.9.211.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe83:f0a1/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:73216 errors:0 dropped:0 overruns:0 frame:0

          TX packets:46023 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:22175910 (21.1 MiB)  TX bytes:24732844 (23.5 MiB)

eth1      Link encap:Ethernet  HWaddr 00:0C:29:83:F0:AB

          inet addr:192.168.1.135  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::20c:29ff:fe83:f0ab/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:15489 errors:0 dropped:0 overruns:0 frame:0

          TX packets:184 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1185883 (1.1 MiB)  TX bytes:13383 (13.0 KiB)

[mnagle]

The solution is incomplete. After adding the loopback address to docker0, the engineer had to delete the previous 172.17.x.x address with the following steps:

Discover the IP address assigned to docker0: ip addr show dev docker0

Delete the 172.17. address from docker0 with: ip addr del 172.17.x.x/16 dev docker0

What is the logic behind Aruba Networks using an address for docker0 that would conflict with address space already used in a network? Why not use 169.254.x.x space or the loopback address from the start.

After a recent upgrade my IAP sites suddenly appeared as DOWN in the 172.17.0.0/16 space. Not only did this become an unnecessary waste of time troubleshooting, without CLI access the problem is impossible to find or correct yourself. (Did someone at HP think it was a good idea to use 172.17.0.0/16 for docker0?) Please add netstat commands to the show techsupport file.

[martinpoulin]

This issue also affects ClearPass when upgrading to 6.6.0 release from earlier releases. docker0 is part of ClearPass extensions, and even though extensions aren't enabled, the interface is created and the address 172.17.0.1 is hard-coded. In my customer's case, 172.17.0.1 is the SVI for their CORE SWITCH. So upgrading ClearPass took out their core network. Needless to say it was a tough one to troubleshoot and required escalation in TAC to get to the root shell. Why on earth did anyone think that hard-coding an IP address into an interface would ever be a good idea?

[mnagle]

I don't care as much about the hard coded IP address as using an address range that is commonly used and likely to create a conflict for some networks. That is a really bad decision by HP. I wonder how many networks they are going to cause outages in before HP cares enough to change this. HP could have safely reserved a /24 out of their public address space for this, or used 169.254.0.0/16 as mentioned in my previous post. 

[mnagle]

Our version upgrade for airwave changed Docker0 to the 172.17 address and broke management to our Aruba devices in the 172.17.0.0/16 address space. This is ridiculous. Can someone at Aruba/HP get this really bad decision fixed and change the address of the docker0 interface to its loopback or a 169.254.x.x as previously mentioned in the thread?

You  have removed our CLI access that prevents us from using the directions above and resolving this ourselves.

[mattGeorge]

@mnagle: I have updated the KB with better steps. Unfortunately, these steps needs CLI access through TAC. Airwave 8.2.6 now permits users to enter some common troubleshooting commands which is an improvement over AMP 8.2.4.x and 8.2.5.x. However the commands to update docker IP is not part of the permitted commands. Could you file a feature request for the same so that product management can prioritize this.

@martinpoulin. Clearpass 6.7.x allows the user to specify the subnet while creating extensions.

[martinpoulin]

@mattGeorge, thanks for the info. Unfortunately the problem came up without us creating or enabling extensions. It just happened when upgrading. We had no notification that this address would be used in any way, and no way of knowing that it came up until it brought down the VLAN.

[mnagle]

@mattGeorge  I have an open case with a request to fix this in Airwave. I think the better request is either Aruba dedicates a /24 public network within their IP Space for docker0 or create a second loopback address with a 127.0.0.x. Either works and neither will create problems in the customer network. .)