- Article History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Alert a Moderator
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Alert a Moderator
How to update docker0 IP in Airwave
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)
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
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.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
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?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
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.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
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.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
@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.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Alert a Moderator
@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. .)