Red Hat Certified Specialist in OpenShift Networking exam Free Sample Questions

The macvlan CNI plugin in bridge mode creates sub-interfaces on the parent physical device (eth2), each with a unique MAC address. In bridge mode, traffic between endpoints on the same host interface is switched directly within the Linux kernel, preventing packets from looping out to an external physical switch. In contrast, private mode drops inter-endpoint traffic on the same host, vepa requires an external switch supporting IEEE 802.1Qbg Hairpin mode, and passthru dedicates the physical interface entirely to a single container.

The ipvlan plugin creates virtual network interfaces that share the exact physical MAC address of the master interface (ens2f1), satisfying upstream port security rules that permit only one MAC address. In mode: "l3", all Layer 2 broadcast and ARP processing is eliminated; the host networking stack routes packets directly at Layer 3 between the pod namespace and the physical interface. In contrast, macvlan creates distinct virtual MAC addresses for each pod, triggering port shutdown on the switch. ipvlan in l2 mode still acts as an L2 bridge (sharing the MAC), but does not route via the host kernel routing table. A Linux bridge with macspoofchk: true still exposes multiple MACs or drops frames.

OpenShift Container Platform does not provide an integrated DHCP server. To utilize external DHCP servers for secondary networks, the DHCP CNI plugin relies on a local node-level daemon. Administrators must enable the DHCP IPAM CNI daemon by modifying the Cluster Network Operator (CNO) configuration (network.operator.openshift.io/cluster), which deploys the required DaemonSet on cluster nodes to request, maintain, and renew DHCP leases for pod attachments.

The whereabouts CNI IPAM plugin supports defining network_name within its IPAM configuration, enabling multiple NetworkAttachmentDefinition resources to share the same dynamic IP address allocation pool. Furthermore, because whereabouts calculates IP offsets using 64-bit integers (uint64), IPv6 subnets with prefix lengths of /64 or shorter would exceed the 64-bit integer limit; therefore, narrower subnets (e.g., /119 or /120) must be used. whereabouts allocates IPs cluster-wide rather than strictly node-local, and its reconciler runs automatically as a DaemonSet managed by the CNO.

The whereabouts IPAM plugin uses 64-bit unsigned integers (uint64) internally to track address offsets. A standard /64 IPv6 subnet contains 2^64 addresses, which causes integer overflow in offset math. Therefore, Red Hat documentation explicitly mandates that IPv6 subnets for whereabouts must use prefix lengths longer than /64 (such as /119 to /128).

In OpenShift Container Platform 4.20, configuring a primary UserDefinedNetwork requires that the namespace be labeled with k8s.ovn.org/primary-user-defined-network: "" strictly when the namespace is created. OVN-Kubernetes does not support converting an existing default namespace to a primary user-defined network by appending the label after namespace creation.

Under spec.topology: Layer3, the subnets stanza is mandatory and requires defining both cidr (the total CIDR block assigned to the user-defined network across the cluster) and hostSubnet (the subnet mask length allocated to each individual node for pods on that node, e.g., 24 for IPv4 or 64 for IPv6). In contrast, Layer 2 UDN subnets only accept a list of CIDR strings without hostSubnet because Layer 2 forms a single broadcast domain across nodes.