cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1492
Views
35
Helpful
5
Replies

UCCX 12.5(1) Docker Engine blackholes customer networks

gkuzmowycz
Level 1
Level 1

I'm posting this as a "discussion," even though my issue has been resolved, to possibly help the next customer who is surprised by this and (maybe?) to get someone at Cisco to notice this.

 

The UCCX 12.5(1) install/upgrade happens to install the Docker Engine - which rates precisely three words in the 698-page UCCX Administration and Operations Guide. That install also builds a Docker "bridge network" without any input from the customer/installer, and according to Docker docs, "It randomly chooses an address and subnet from the private range defined by RFC 1918 that are not in use on the host machine, and assigns it to docker0. By default it chooses a 16-bit netmask..." Based on what I've seen, "random" is a lie. If your UCCX happens to be in 172.17.0.0, this install will take 172.18.0.0/16 for itself. If you have the misfortune of using 172.18.0.0 for your user networks, well, it sucks to be you, as all those networks will be unreachable. Again, to emphasize, the install does not notify you it's doing this, let alone offer an option to disable this or to modify the address range, and you end up with this

 

admin:show network route

default via 172.17.0.nnn dev eth0 proto static metric 100

172.17.0.0/24 dev eth0 proto kernel scope link src 172.17.0.nnn metric 100

172.18.0.0/16 dev docker0 proto kernel scope link src 172.18.0.1

 

Really nice surprise to find when you go live and can't figure out what's happening to your traffic, then eventually find this and realize that you can't delete the route. There is apparently a COP file that's supposed to resolve this, but the install fails more than it succeeds, so time for TAC to get root access and fix this for you. If you find yourself in this situation, open a P1 case, reject the COP file advice and insist on the "root" workaround. Do not release the call until this is done.

 

As to the question of who at Cisco, a company that has been at the forefront of networking standards and best practices for over three decades, would allow a system install to blithely commandeer user networks without any notice nor any opportunity to reject or modify this behavior, I am truly at a loss. Hey, let's just grab a /16 that's not in use on this particular box as if this box doesn't have connectivity beyond its own subnet. I'm at a loss for words.

 

 

5 Replies 5

jim-j
Level 3
Level 3

@gkuzmowycz wrote:

The UCCX 12.5(1) install/upgrade happens to install the Docker Engine - which rates precisely three words in the 698-page UCCX Administration and Operations Guide. That install also builds a Docker "bridge network" without any input from the customer/installer, and according to Docker docs, "It randomly chooses an address and subnet from the private range defined by RFC 1918 that are not in use on the host machine, and assigns it to docker0. By default it chooses a 16-bit netmask..." Based on what I've seen, "random" is a lie. If your UCCX happens to be in 172.17.0.0, this install will take 172.18.0.0/16 for itself.


This didn't happen to me (that I noticed at least).  I upgraded a UCCX HA pair from 11.6.2. to 12.5.1 and then immediately installed ES03.  I just checked my routing and I don't have any extra secondary network (see below).  Are you referring to 12.5.1 or 12.5.1 SU1?

 

admin:show version active
Active Master Version: 12.5.1.10000-31
Active Version Installed Software Options:
ciscouccx.1251.ES03.93.cop

admin:show network route
default via 192.168.7.1 dev eth0 proto static metric 100
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.71 metric 100

admin:utils service list
Docker Engine[STARTED]

 

jim-j
Level 3
Level 3

I already replied once about 30 minutes ago, but I noticed my reply has disappeared. Not sure if that was an oops or if there was some reason for the removal of my reply or if I'll end up with two posts. To briefly re-post what I posted before, I upgraded a UCCX HA cluster from 11.6.2 to 12.5.1 and then immediately installed ES03 and didn't have this problem. Are you referring to 12.5.1 or 12.5.1 SU1?

 

admin:show version active
Active Master Version: 12.5.1.10000-31
Active Version Installed Software Options:
ciscouccx.1251.ES03.93.cop

admin:show network route
default via 192.168.7.1 dev eth0 proto static metric 100
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.71 metric 100

admin:utils service list
Docker Engine[STARTED]

Thanks for contributing. This is straight 12.5.1.10000-31, no COPs.

If it helps, it looks like this is now documented in defect https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt19771/?rfs=iqvred

jebrooker
Level 4
Level 4

Just installed CER 14.0 and the 172.17.0.0 docker network now exists on it. Disappointing that this "feature" is spreading to more products.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: