Calico can be configured to allow pods to communicate with each other with or without  IP-in-IP tunneling. IP-in-IP adds an additional header for all packets as part of the  encapsulation, but containers can communicate on its overlay network through almost any  non-overlapping underlay network. In some environments where the underlay subnet address  space is constrained and there is no access to add additional IP Pools, like on some public  clouds, Calico can be a good fit.  However, in environments that do not require an overlay, IP-in-IP tunneling should be disabled  to remove the packet encapsulation resource use, and enable any physical routing  infrastructure to do packet inspection for compliance and audit. In such scenarios, the  underlay network should be made aware of the additional pod subnets by adding the underlay  network routers to the BGP mesh. See the discussion about this in “Calico components”. The calico network is created by the following 3 components: node agent, CNI, and  kube-controller. This entity has three components: felix, bird, and confd. The CNI plug-in provides the IP address management (IPAM) functionality by provisioning IP  addresses for the Pods hosted on the nodes. The calico/kube-controller watches Kubernetes NetworkPolicy objects and keeps the Calico  data store in sync with the Kubernetes. calico/node runs on each node and uses the  information in the Calico  etcd  data store and program the local  iptables  accordingly. When nodes are on different network segments, they are connected using a router in the  underlay infrastructure network. The traffic between two nodes on different subnets happens  through the router, which is the gateway for the two subnets. If the router is not aware of the  pod subnet, it will not be able to forward the packets between the hosts. There are two scenarios that can be used to the Calico communication: Calico components Calico/node agent  Calico/cni Calico/kube-controller Calico network across different network segments GLYPH<SM590000> Felix’ s primary responsibility is to program the host’s  iptables  and routes to provide the  wanted connectivity to and from the pods on that host. GLYPH<SM590000> Bird  is an open source BGP agent for Linux that is used to exchange routing information  between the hosts. The routes that are programmed by felix are picked up by bird and  distributed among the cluster hosts. GLYPH<SM590000> Confd  monitors the  etcd  data store for changes to the BGP configuration, such as IPAM  information and AS number, and accordingly changes the bird configuration files and  triggers bird to reload these files on each host. The calico/node creates veth-pairs to  connect the Pod network namespace with the host’s default network namespace. GLYPH<SM590000> Calico can be configured to create IP-in-IP tunnel end points on each node for every  subnet hosted on the node. Any packet originated by the pod and egressing the node is  encapsulated with the IP-in-IP header, and the node IP address is utilized as the source.  This way, the infrastructure router does not see the pod IP addresses.  The IP-in-IP tunneling brings in extra resource use in terms of network throughput and  latency due to the additional packet resource and processing at each endpoint to  encapsulate and decapsulate packets.  260  IBM Cloud Private System Administrator’s Guide