Looking at the VLAN assignments, I don't see VLAN76 listed in SCL1, but I believe that's what we're currently using for the windows test network to set up win64. Right now that subnet has a very s restricted set of ACLs that we need to open up to bring that VLAN into production. First a question, should we move off to a different VLAN since 76 is designated as sandbox? Secondly, the flows for the network. It should look exactly like VLAN48 (including access from the build-vpn) *except* for the fact that it should not have the dhcp helper IPs. This subnet will have a windows server managing it's own dhcp/install configuration network. If we're going to set up a new vlan and not use vlan76, it would be best to get all of the configuration done ahead of time so we can (hopefully) just cut over the machine currently on vlan76 (Matt, presumably you'll be able to change IPs on the windows boxes and change the subnet range for the dhcp pool the win server is managing?).

> First a question, should we move off to a different VLAN since 76 is > designated as sandbox? Yes. It's a somewhat-locked down Vlan for stuff that should only live in a sandbox and the elevate out at some point.

It would be helpful to understand what service is being moved so DNS labels can also be defined (which we associate to network device configuration).

The purpose of this vlan is to allow a microsoft server to control dhcp and automated installation for other windows hosts (using native tools instead of pxe booting to deploystudio). At some point active directory may or may not come into play. But specifically we need a separate broadcast domain for dhcp that is not controlled by the main infra servers.

All of the hosts in this network should still be in the build.scl1.mozilla.com domain as far as DNS goes.

(In reply to comment #4) > All of the hosts in this network should still be in the > build.scl1.mozilla.com domain as far as DNS goes. This makes me slightly sad. There's a 1:1 mapping between vlan and the vlan atom in the hostname, which makes me think that they should be winbuild.scl1. cname from build.m.o as usual.

Correct. How it is in MPT where there are 3 build vlans all under the same atom is an edge case. If this new vlan is exclusively for windows build hosts then that is a suitable label. I'll identify a vlan ID and begin the configuration.

I'm not a fan of splitting out the DNS info for the VLAN just because we need a separate broadcast domain, but the two of you are in agreement, so winbuild.scl1.mozilla.com it is.

Functionally the vlan will be different than all the other build ones that have dns and dhcp served by core infrastructure. By virtue of needing a distinct broadcast domain it gets a new dns label so we can identify that hosts in it are different than the traditional build one. Will a /24 be sufficient? If so do you expect it to go beyond a /24 with future growth?

In order to accommodate the possibility of moving all windows hosts in scl1 into this vlan, let's go with a /23.

If we want to plan ahead for scl3, we'd want a /22.

vlan40, 10.12.40.0/22 has been configured on the FW and policies match that of sandbox. I still need to plumb the vlan on the switches.

(In reply to comment #11) > and policies match that > of sandbox. In fact, the policies should match vlan48. (those may be the same thing)

Once this is ready I need wds1.build and dc1.build (running on geneti) to be moved over to the new vlan, Though before they are moved I need to power them down and change there IP's

The cores have been configured. All that remains are the individual rack switches to have 40 added to their trunk and then individual port moves. Security policy now matches vlan48. Vlan has been extended to the kvm hosts so work there will need to be done to bring up an interface.

Still cannot see vlan75 from vlan40 also still cannot rdp from boris vpn

The initial request was executed as requested. These are new flows and so deserve a new bug.

(In reply to comment #16) > The initial request was executed as requested. These are new flows and so > deserve a new bug. Both of the flows described in comment 15 work for vlan48: boris -> 10.12.48.0/22:3389 10.12.48.0/22 -> 10.12.75.0/24 If the security policy is the same for both VLANs, there's something else amiss.

I saw a lot of IRC conversation back and forth last week. Did this get solved (comment 17)?

Didn't mean to reopen this, just correct the summary to list the right vlan.