Frequently Asked Questions

83. What are your plans for a common client network configuration?

On BMC we have plenty of different client networks. See FAQ about VLANs at BMC.

We where hoping that the network investigation (2016) and the new Segerstedt building (2017) would solve some of this, but it has not. Maybe BMC is unique in having so many different department from different parts of the university in the same building.

1. Proposed solution: Use Wireless
2. Proposed solution: Continue using the wireless
   1. Option: Large and wide VLANs for all clients aka the Segerstedt model.
   2. Option: Use Private VLAN and PVLAN Edge
   3. Option: Use only Protected Ports.
   4. Option: Use Cisco software defined networks
   5. Option: Use automatically configured VLAN

• Minimize the time spent on activating and deactivating network ports and the time spent on changing VLANs.
• People and computers should be able to move though the university and get their network to work in a safe and reliable way, minimizing configuration.
• We would like to be able to give a person that is missing a computer a new computer which should start to work right away everywhere at BMC (or at the university) for that person. If a computer is broken - go get a replacement and continue to work right away.
• We would like to add all network sockets to a single configuration that works for most users.
  • When a department is moving out of a room, set all active network ports to this configuration.
  • When renovating a new corridor, set all ports to this configuration.
  • When building a new house, set all ports to this configuration.
• All computers should not be able to talk directly to each other. We would like to stop malware to spread directly between the computers. Somebody will plug in a home router with the a LAN-port attached to the LAN but this should not be able to take down the whole network.
• When a switch breaks down, it is a lot easier to get a working network again. Of course the patch cables should be in the patch cable database in order to track clients, but even if they are inserted wrong it will work anyway. Plugging the patch cables in any switch with the correct common client network configuration will work.
• The setup should be possible to use on both HP and Cisco and possibly other vendors. In particular the current model Cisco C2960X and the Cisco C2960S which it replaced should be be possible to use.

• We need to be able to identify users and omputers. This is done today with the UUIT services Netreg and NetDB together with local BMC service Arpwatch in order to track an IP/MAC to a network socket. We are missing a central way of documenting the patch cables and the fixed cables. (On BMC this is currently documented in Excel-documents.) But if every computer and computer is authenticated (like on Eduroam) that information may be used instead.

Possible problems with relying on only Eduroam or a protected ports / Private VLAN network:

• In a closed down wired network where all traffic will go up to the router even traffic that previously originated and terminated in the same switch now has to use the uplinks up to the router (L3). This is not an efficient way of using the network bandwidth. However we even today aim for keeping the servers on seperate VLAN which has to go up to the router.
• The academic freedom may be compromised. It is not as easy as it was before to start and use a new application that previously was open on the local department network. This may be both good and bad. Zero-configuration networking using multicasts DNS and DNS service discovery (Apple Bonjour) will stop working as it did before if L2-traffic directly between clients is blocked.
• Shared medium as wireless End-to-end encryption. It cannot be as secure as a L2-blocked wired network.

1. Possible solution: Use wireless

Let the new computers use Eduroam as the preferred network.

This may require a lot more rapid response in fixing coverage and capacity problems for the wireless network.

Cons: Shared medium. Easy to disrupt.

2. Possible solution: Continue using the wired network

• We would like to configure which computer should be able to connect and in what networks. This is possible via a whitelist in the DHCP-server. If we are to create a common new network for all clients, then hopefully it is possible to create an union of all whitelists and allow them to connect to that VLAN. In Bluecat a single MAC can only be added to one whitelist, but if all the whitelists are added to this VLAN then maybe it can work.

• Optional: Be able to block computers that steal the IP belonging to other computers - IP address spoofing. Blocking this may be done using DHCP snooping and Dynamic Arp Inspection.
  Reference: Catalyst 6500 Release 12.2SX Software configuration Guide Chapter - DHCP Snooping - Cisco
  Reference: Catalyst 6500 Release 12.2SX Software Configuration Guide Chapter - Dynamic Arp Inspection - Cisco
  Reference: IP Spoofing - Cisco
• Optional: Be able to fall back from the whitelist protected networks to the UpUnet-S (or some captive portal network) if not in the whitelists.
  • Change VLAN: How is this possible in Cisco?
    Reference: MAC Authentication Bypass Deployment Guide - Cisco
    Reference: Consolidated Platform Configuration Guide, Cisco IOS XE 15.2(6)E (Catalyst 2960-X Switch) - MAC Authentication Bypass - Cisco
  • Change resolver: Redirect DNS-lookups for unknown clients to use a separate DNS-resolver that redirect everything to an captive portal. There are workarounds at the client level by manually adding a resolver. (Check implementation at Rudbeck/UAS).
  • Change gateway: Use a seperate gateway for the unknown client that uses a captive portal. There are workarounds at the client level by manually setting the gateway.
• Optional: With Local Proxy ARP it should be possible to let the clients even though they are L2-separated talk to each other via the router.
  Reference: Local Proxy ARP - Cisco Support Community
• Optional: Be able to set static IPs on this network. This may be done via BlueCat. This may bot be needed and maybe it is best to keep everything clean and not enable this.

Use a few big VLANs and dont worry too much.

Perhaps use DHCP Snooping.

All clients are wide open to all other clients on the VLAN.

All existing subnets could also be put in this VLAN and then no clients needs to change any settings, but then again, no security on the L2-level even if L3-level router filters stop legitimate traffic.

2.B. Option: Use Private VLAN and PVLAN Edge

Read more about Private VLAN. Get a new generation of switches that support Private VLAN. The current generation C2960S and C2960X do not support Private VLAN. Only the single C2960XR do support it. Continue using older switches as edge switches using the PVLAN Edge feature.

It looks like the I-Port on an Private VLAN can only carry a single untagged VLAN. This means that even though the simpler switches with PVLAN Edge could carry many VLANs they cannot be combined with the Private VLAN I-Ports. (Perhaps except using multiple uplinks but I do not think we want to go there.) This needs to be confirmed by testing.

It may be possible to build a hybrid network combining a backbone of distribution switches (C2960XR C3750 C3560 etc) using Private VLAN with access switches (directly connected to clients) using PVLAN Edge (C2960X C2960S etc). Connect all clients to I-Ports directly or on a hybrid network via switches with PVLAN Edge ports.

   ======================C6500=router=========================================
         Etherchannel                Etherchannel                  I-Port
            trunk                       I-Port                       |
            |   |                       |   |                        |
   =====C2960XR=stack=====    =====C2960S==stack=(1VLAN)===          |
         Etherchannel                Etherchannel                    |
            |   |                     Protected                      |
            |   |                       |   |                        |
   =====C2960X==(1VLAN)==     ====C2960S====(1VLAN)==    ====C2960X==(1VLAN)===
    Protected   Protected       Protected   Protected     Protected  Protected
        |           |               |           |            |          |
    Computer1   Computer2       Computer3   Computer4     Computer5  Computer6
    

Only use PVLAN Edge (protected ports) feature to block traffic between clients. The problem with this solution is that because it cannot really be combined with multiple VLANs in the same uplinks unless it is used on the whole network using a switch topology with Protected Ports on the downlinks everywhere, but if this is possible on Cisco is unknown.

There is an L3-workaround for the L2-block by using local-proxy-arp, but probably not a good idea. That would in theory have been possible to run on all VLANS as is, but only L3. No L2 like zero-config networking (Apple Bonjour) will work.

See the background below for details on how to set it up. It is most probably not a practical solution.

Probably expensive, requires new equipment and is a bit more complicated than we need.

Reference: Cisco Identity Services Engine Data Sheet - Cisco

Cisco SD-Access Ordering Guide - SD-Access Platform Support Summary - Cisco

2.E. Option: Use automatically configured VLAN

Use MAC-address or login to automatically configure the VLAN on each edge switch port.

All which are in a whitelist somewhere at the university in Bluecat (but not on BMC) should go to a common work network with no captive portal but access to EduPrint etc.

Maybe it is possible to populate the database server (RADIUS) with MAC-addresses from the BlueCat whitelists using the API. Good with integration.

Pros:

• Minimize later switch port administration.
• Works with C2960X and maybe others.
• No need to change the patch cables in order to switch a network socket from the common client network to another one.
• Could be used all over the university.
• Could be used also for static IP on the client, no need for DHCP (like for DHCP snooping).
• The network configuration for a socket in used could be changed without affecting current usage which makes it possible to introduce in a smaller scale, step-by-step.

Cons:

• If only the MAC-address is used as a key then it can be faked easily. Maybe some networks can have both login and MAC.
• This will not get rid of the old VLAN structure. But maybe after a couple of years when almost all old computers has been replaced.
• Maybe one RADIUS-server for each campus-router is needed.

Unknowns:

• How to handle several campuses - must every campus have an extra RADIUS-server in order to get the list of local VLANs correct?
• It may be possible to also login with 802.1x authentication and pick a VLAN that way, but how to efficiently pick the right VLAN is not known.
• In theory multiple users could be added for access to a specific VLAN. As an example username jny25782@Vl664 could be used for me to connect to Vlan664.
• A special open VLAN could be created for users where the normal router filters do not work.
• Use USER-AD to login the computer and not the user.

Reference: MAC Authentication Bypass Deployment Guide - Cisco
Reference: Consolidated Platform Configuration Guide, Cisco IOS XE 15.2(6)E (Catalyst 2960-X Switch) - MAC Authentication Bypass - Cisco
Reference: Command Reference, Cisco IOS Release 15.2(2)E (Catalyst 2960, 2960-S, 2960-SF and 2960-Plus Switches) - authentication event - Cisco

Background: How does Protected Ports work on a multi-switch network

All uplinks must be normally configured as promiscuous. All downlinks must be protected. The network topology must be strictly hierarchical with all routers or servers connected via promiscuous ports on a single switch.

In this first example random clients port has been made protected. This does only work on a single switch - Computer1 and Computer2 cannot talk to each other since they are both on protected ports on a single Switch1. But protected ports on different switches can talk to each other because traffic may flow between protected and promiscuous ports on a single switch - Computer1 and Computer2 can both talk to Computer3

                     Router
                       |
         ===========Switch2===============
             |                    |
    =====Switch1=========   =====Switch3=====
     Protected  Protected      Protected
        |         |               |
     Computer1  Computer2      Computer3   

In the second example all downlinks are Protected. Traffic between Computer1 or Computer2 to Computer3 will be blocked on Switch2 because traffic cannot go between two protected ports on the same switch.

                     Router
                       |
         ===========Switch2===============
          Protected            Protected
             |                    |
    =====Switch1=========   =====Switch3=====
     Protected  Protected      Protected
        |          |              |
     Computer1  Computer2      Computer3   

Regarding the Cisco PVLAN Edge

It may be possible to use the protected ports feature on an EtherChannel group according to Configuring Protected Port for example the Cisco Catalyst C3850:

You can configure protected ports on a physical interface (for example, Gigabit Ethernet port 1) or an EtherChannel group (for example, port-channel 5). When you enable protected ports for a port channel, it is enabled for all ports in the port-channel group.

This would in theory make it possible to cascade down from a stack of distribution switch to a edge switch. However it does not seem like it is possible to use the Protected Port feature on a trunk port and not on a single VLAN in a trunk. There are two possible solutions for this:

• This may require a single VLAN for each cross connect cabinet - at least 18 VLANs BMC. This means going for one quite complicated configuration to another, although Proxy ARP for the use of transparent subnet gatewaying as defined in RFC1027 Using ARP to Implement Transparent Subnet Gateways could ease things up a bit. That would mean multiple VLAN (in order to seperate the physical network) but then joining them together with Proxy ARP for the purpose of inter communication and DHCP pooling (to minimize the need for micro management of the DHCP pool size). Also Inter-VLAN Bridging may be of interest. But this is probably not a good idea.

  
  Reference: En introduktion till IP - Chalmers tekniska högskola (Chalmers is running Proxy-ARP ... UU did recently too, maybe still somewhere if not everything has been cleaned up.)

• It may be possible as described above to use switches capable of Private VLAN as distribution switches and the older switches using only PVLAN Edge as access switches, connected to an I-Port. This is probably doable, but with only one VLAN, how is for example the management VLAN going to be reached?

            Router
               |
    ====Switch1=C2960S=C2960S==== (multiple VLANs)
     Pro.  Pro.  Pro.  Protected
      |     |     |   Etherchannel
    Comp1 Comp2 Comp3  |  |  |
                       |  |  |
    ======SwitchC2960S=C2960S==== (single VLAN)
     Pro.   Pro.
      |      |
     Comp4 Comp5

This entry network.8021x was last modified 2018-01-19