Windows overlay backend depends on external HNS network

[benmoss]

Expected Behavior

The Windows overlay backend assumes you have created an external HNS network, and fails if it can't find one. This isn't very clearly documented and we had to dig into Microsoft's SDN code to find reference to what this backend is expecting. This also has the unfortunate consequence of requiring users to import Microsoft's hns.psm1 library to add the Add-HNSNetwork function to Powershell. If it were just part of Flannel it could use hcsshim to do the same thing.

It would be better and more intuitive if the overlay backend would just create this itself. I don't know if there's a reason it can't do that.

Possible Solution

Create the external network if it doesn't already exist.

@ksubrmnn

[ksubrmnn]

Hi Ben,

In Overlay, the vxlan0 network is created by FlannelD here

However, you need to create a separate Overlay Network for vxlan0 to be layered on top of as is done here

Note that this is also done for L2Bridge (this is so that the host won't lose connectivity as the cbr0 network is created/torn down). For L2Bridge, Flannel will still work properly without that External network.

The reason that you need the External for Overlay is because in Windows, the DR NIC is created when an Overlay network is present. This NIC's MAC address is needed in the subnet lease attributes. So we create an Overlay network called "External" to get that DR MAC. Then when we have the subnet lease, we can create the vxlan0 network.

I agree with you that it is preferable to not have to depend on that external network.

Can you edit this issue to reflect what I've explained above? Regarding the actual backend network, both implementations will either reuse an existing network or create a new one. The only difference is that Overlay has a hard dependency on that external network.

In the meantime, I'll look into changing this and will update this issue soon.

[benmoss]

Thanks Kalya, I started digging in more and realized it is the external network and not the container subnet as it is on L2Bridge. I updated my issue to try to describe the problem better.

[ksubrmnn]

@madhanrm @daschott FYI

[ksubrmnn]

@zawachte-msft