BGP是互联网上一个核心的去中心化自治路由协议，它通过维护IP路由表或“前缀”表来实现自治系统AS之间的可达性，属于矢量路由协议。不过，考虑到并非所有的网络都能支持BGP，以及Calico控制平面的设计要求物理网络必须是二层网络，以确保 vRouter间均直接可达，路由不能够将物理设备当作下一跳等原因，为了支持三层网络，Calico还推出了IP-in-IP叠加的模型，它也使用Overlay的方式来传输数据。IPIP的包头非常小，而且也是内置在内核中，因此理论上它的速度要比VxLAN快一点 。Calico 3.x的默认配置使用的是IPIP类型的传输方案而非BGP。
Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择，但Calico以其性能、灵活性而闻名。Calico的功能更为全面，不仅提供主机和pod之间的网络连接，还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能。
Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico在每个计算节点都利用Linux Kernel实现了一个高效的虚拟路由器vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。
上面并不是什么严重的问题。但是有一点，Calico控制平面的上述设计中，物理网络最好是L2 Fabric，这样vRouter间都是直接可达的，路由不需要把物理设备当做下一跳。如果是L3 Fabric，控制平面的问题就来了：物理设备如果要存32位的路由，路由表将变得巨大无比。
因此，为了解决以上问题，Calico不得不采取了妥协，为了支持L3 Fabric，Calico推出了IPinIP的选项，用作cross-subnet下容器间通讯，但是有一定性能损耗。另一种方案是回退到L3 Hierarchy（calico目前支持），如果对容器迁移保持IP不变的需求不大，可以选择这种，这也是我们最后选择的方案。不过，对于使用L2 Fabric、没有多租户需求的企业来说，用calico上生产环境应该最理想选择。
Calico最理想的部署方式是基于L2 Fabrics的，官方也有相应说明（[Calico over an Ethernet interconnect fabric](http://docs.projectcalico.org/ ... abric "Calico over an Ethernet interconnect fabric")），这里就不做详细说明了。由于我们数据中心规模比较大，显然L2 Fabrics不是理想的选择。事实也是如此，我们多个数据中心组成的网络是以BGP为控制层面组成的L3 Fabrics。每个数据中心为一个AS。这里不讨论跨数据中心的问题，大家只需知道我们跨数据中心在L3上是互通的便可以。