The following tables show the VLANs and subnets that are currently used in the IBR network. IP address spaces- IPv4 host configuration MUST be done via DHCP. Never use static address configuration!
- IPv6 host configuration MUST be done via autoconf (preferably) or DHCP (alternatively). Never use static address configuration!
134.169.34.0/25 | 2001:638:602:1181::/64 | ibr-core | core services, hosts maintained only by IBR admins, ports and hosts located only in the IBR server room | 134.169.34.192/26 | 2001:638:602:1185::/64 | ibr-cip | subnet of computer pools G40 and 359 | 134.169.35.0/24 | 2001:638:602:1183::/64 | ibr-misc | known client hosts, registered with LDAP | 134.169.35.10-62 | | ibr-misc | known client hosts, registered with LDAP by MAC addresses, but using DHCP IPv4 address pool | 10.1.0.0/24 | | ibr-misc | anonymous hosts, DHCP IPv4 address pool | 10.1.1.0/24 | | ibr-misc | Georg's testbed hosts | 10.1.2.0/24 | | ibr-misc | other registered hosts with fixed private IPv4 addresses | 10.1.5.0/24 | | ibr-misc | Raspberry Pis managed by ibr-preppi | 10.1.9.0/24 | | ibr-misc | management nodes and BMCs in ibr-misc | 10.2.0.0/16 | | ibr-misc | cloud subnet maintained by DS group | 10.3.2.0/24 | 2001:638:602:1182::/64 | | OpenVPN UDP clients, via 134.169.34.9 | 10.3.3.0/24 | 2001:638:602:1182::/64 | | OpenVPN TCP clients, via 134.169.34.9 | 10.6.0.0/16 | | | StudentCloud Subnet for Nico, on ibr-misc | 10.7.0.0/16 | 2001:638:602:1f00::/56 | | subnets for "Praktikum Administration von Computernetzen", via 134.169.35.254 and fe80::5072:19ff:fe57:fd3b | 10.8.0.0/16 | | ibr-san | iSCSI SAN, isolated from all other subnets | 10.9.0.0/16 | 2001:638:602:118f::/64 | ibr-mgmt | management subnet, IPMI, iDRAC, etc. | 10.10.0.0/16 | | | management subnet for kvm proxy | 10.30.0.0/16 | | ibr-roce | isolated 10G VLAN (configured as PFC group for RoCE) used by DS |
If you consider to use a new IPv4 private subnet for your own work, please talk to Frank to get a unique and documented address prefix (e.g., 10.x.0.0/16). VLANs To be prepared for cases in which VLANs may span multiple floors of our building or even a wider range, VLAN-IDs have to be unique. Therefore, the VLAN ID namespace is managed by the GITZ. The following table lists the VLAN which are currently assigned to IBR: ibr-core | 136 | core services; attachments are restricted to the server room and to hosts which are maintained only by IBR admins | ibr-cip | 137 | pools (rooms G40 and 359) | ibr-lab | 138 | Lab VLAN (currently not is use, 2016-04) | ibr-misc | 139 | major VLAN to which any hosts may connect; almost all ports in IBR rooms are in this VLAN | ibr-mgmt | 140 | management VLAN (switches, BMCs, iDRACs) | ibr-roce | 141 | VLAN for RDMA over Converged Ethernet (RoCE) which is used by the DS group | ibr-ds | 142 | a VLAN to interconnect some servers of the DS group | ibr-san | 143 | a VLAN to interconnect iSCSI devices in room 104, 10G-only |
IPv6 Routing Don't worry, if you see multiple IPv6 default routes. As of 2017-02 we really have two routers: The Linux firewall and gateway router advertises itself with "low" priority, while the Mellanox switch/router advertises itself with "high" priority, because it is able to route much faster between the IBR subnets. Just in case, the Mellanox router fails, well behaved IPv6 clients should use the Linux router. Using Switches If you have to use multiple devices in a single room, you will most probably consider using a switch with an uplink to a room port. In this case you should keep these things in mind: - Generally, a "flat" topology should be preferred by us and is preferred by the GITZ staff. It allows for a higher summarized throughput and a more detailed monitoring and management, e.g. when malicious clients shall be disabled by the GITZ.
- As of end of 2019 there seems to be a default limit of no more than 10 clients attached to a single GITZ switch port with respect to "IP device tracking". When the GITZ switch detects more MAC addresses we should expect some of them getting wiped from an internal table of switched target addresses leading to annoying connection problems. Upon request via the IBR DV Koordinator (Frank) the GITZ networking group may increase this limit for some ports.
- The GITZ switches do not like switches with active spanning tree protocol connected to their ports, since many such devices showed annoying misbehiour in the past. Therefore, most GITZ switch ports get automatically deactivated completely(!) for some time, if you connect a spanning tree capable switch! As a compromise, in most IBR rooms each port labeled "1.1" should be configured to represent an exception to this rule. But don't rely on this in each and every case. It would be better to carefully avoid spanning tree.
- Of course, you should avoid loops.
DNS-based Ad-Blocking (Pi-Hole) You may wish to make your device use an (experimental) Pi-Hole DNS resolver by forcing your DHCP client to send a user-class option containing the string pihole . If you are using ISC dhclient, add this to your dhclient.conf (probably /etc/dhcp/dhclient.conf ): send user-class = "pihole"; |