TU BRAUNSCHWEIG
| Carl Friedrich Gauß Faculty | Department of Computer Science
Informatikzentrum

IBR Netzwerk

AuthorFrank Steinberg
Keywordsnetwork

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/252001:638:602:1181::/64ibr-corecore services, hosts maintained only by IBR admins, ports and hosts located only in the IBR server room
134.169.34.192/262001:638:602:1185::/64ibr-cipsubnet of computer pools G40 and 359
134.169.35.0/242001:638:602:1183::/64ibr-miscknown client hosts, registered with LDAP
134.169.35.10-62ibr-miscknown client hosts, registered with LDAP by MAC addresses, but using DHCP IPv4 address pool
10.1.0.0/24ibr-miscanonymous hosts, DHCP IPv4 address pool
10.1.1.0/24ibr-miscGeorg's testbed hosts
10.1.2.0/24ibr-miscother registered hosts with fixed private IPv4 addresses
10.1.5.0/24ibr-miscRaspberry Pis managed by ibr-preppi
10.1.9.0/24ibr-miscmanagement nodes and BMCs in ibr-misc
10.2.0.0/16ibr-misccloud subnet maintained by DS group
10.3.2.0/242001:638:602:1182::/64OpenVPN UDP clients, via 134.169.34.9
10.3.3.0/242001:638:602:1182::/64OpenVPN TCP clients, via 134.169.34.9
10.6.0.0/16StudentCloud Subnet for Nico, on ibr-misc
10.7.0.0/162001:638:602:1f00::/56subnets for "Praktikum Administration von Computernetzen", via 134.169.35.254 and fe80::5072:19ff:fe57:fd3b
10.8.0.0/16ibr-saniSCSI SAN, isolated from all other subnets
10.9.0.0/162001:638:602:118f::/64ibr-mgmtmanagement subnet, IPMI, iDRAC, etc.
10.10.0.0/16management subnet for kvm proxy
10.30.0.0/16ibr-roceisolated 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-core136core services; attachments are restricted to the server room and to hosts which are maintained only by IBR admins
ibr-cip137pools (rooms G40 and 359)
ibr-lab138Lab VLAN (currently not is use, 2016-04)
ibr-misc139major VLAN to which any hosts may connect; almost all ports in IBR rooms are in this VLAN
ibr-mgmt140management VLAN (switches, BMCs, iDRACs)
ibr-roce141VLAN for RDMA over Converged Ethernet (RoCE) which is used by the DS group
ibr-ds142a VLAN to interconnect some servers of the DS group
ibr-san143a 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";


last changed 2019-11-12, 13:15 by Frank Steinberg
printemailtop