Files
gitea-pages/admin-guide/architecture/networking.rst

4.0 KiB

Networking

The PSI network is quite fragmented and traffic is often restricted between different subnets. As far as the Linux infrastructure is concerned we currently distinguish two network zones: external (DMZ, Extranet, Tier3) and internal (everything else).

Each 'zone' is supposed to have one instance of the Linux infrastructure systems, eg Yum repository. This is not entirely true at this point, but progress has been made towards this goal.

Within a zone all systems are allowed to connect to the respective infrastructure systems. This page lists the exact connectivity requirements.

Requirements

Configuration Management and Software Distribution

Eventually there should be a separate Puppet server in the DMZ, but for now we use the internal one.

Source Destination (internal) Destination (external) Ports Purpose
any puppet01 puppet01 8080, 8140 Puppet
any repo00 repo00 80, 443 Software Packages

Authentication

We use Active Directory for authentication, so Kerberos and encrypted LDAP connections must be allowed to the domain controllers:

Source Destination (internal) Destination (external) Ports Purpose
any {dc00,dc01,dc02} rodc{00,01} 88, 464, 636 AD authentication/joins

Deployment

For the successful deployment of Linux systems, the requirements below must be met. Systems are currently not deployed in external networks (DMZ, Extranet, Tier3), so this only applies internally.

In addition, the following:

Source Destination Ports Purpose
any boot00 UDP/69, 80, 443 PXE/Kickstart

Finally, having DHCP is helpful, but not necessary.

Monitoring/Reporting

Source Destination (internal) Destination (external) Ports Purpose
any influx00 influxdmz00 8086 Performance metrics
any rep N/A 443 Reporting (turned off)

Configuration

IPv6

Starting with RHEL 7 we do not disable IPv6 completely. We leave it on, but do not configure any addresses. The routers at PSI also don't send router advertisements, the DHCP server doesn't provide IPv6 addresses.

As a consequence, the network interfaces on these systems only have a link-local address and IPv6 isn't actually used in practice. The reason for leaving IPv6 enabled is to slowly gain experience with the protocol. So far we have run into two issues:

  • In one network the router did send router advertisements, but the route didn't actually work.
  • Some DNS names resolve to IPv6 addresses as well as IPv4 ones. Combined with the first issue, this caused deployment to fail on a console.