Skip to content

Commit

Permalink
docs: document l2 pod interfaces and add details to multinet doc
Browse files Browse the repository at this point in the history
  • Loading branch information
hedibouattour committed Nov 17, 2023
1 parent 9bf9d9e commit 2af3c4f
Show file tree
Hide file tree
Showing 3 changed files with 38 additions and 2 deletions.
33 changes: 33 additions & 0 deletions docs/L2TapInterfaces.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
## We support L2 interfaces in pods

Pods use an L3 interface per default (tun interface in VPP). However, we also support having L2 interfaces (tap), via this [annotation](config.md#L99):

```yaml
apiVersion: v1
kind: Pod
metadata:
name: samplepod
annotations:
cni.projectcalico.org/vppInterfacesSpec: |-
{
"eth0": {"isl3": false },
}
```

This has a known limitation : the linux routing configuration is currently incomplete. A workaround for it is to have a cap admin capability on a privileged container:

```yaml
securityContext:
capabilities:
add: [ "NET_ADMIN"]
```
and to run these commands on the container to have connectivity:
```bash
ip link set dev eth0 down
ip link set dev eth0 address 02:00:00:00:00:01
ip link set dev eth0 up
ip neigh add 169.0.254.1 lladdr 51:53:00:17:34:09 dev eth0
ip route add 169.0.254.1 dev eth0
ip route add default via 169.0.254.1 dev eth0
```
3 changes: 2 additions & 1 deletion docs/config.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,8 @@ data:
"interfaceName": "eth1",
"vppDriver": "af_packet",
"mtu": 1400,
"rxMode": "adaptive"
"rxMode": "adaptive",
"physicalNetworkName": ""
}
]
}
Expand Down
4 changes: 3 additions & 1 deletion docs/multinet.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Calico/Vpp Multinet implementation is an attempt at fulfilling these requirement
### Network object

With Calico/Vpp Multinet, we introduce a new Kubernetes resource (as a CRD), called `Network`. A `Network` is defined by a `vni` (Virtual Network Identifier) which allows to identify the network in the dataplane.
It also contains a CIDR `range` that defines the IP addresses to assign to that network's pods. This optionally allows defining overlapping IP ranges for the different networks, provided the other selected components (ipam, etc…) allow this.
It also contains a CIDR `range` that defines the IP addresses to assign to that network's pods. This optionally allows defining overlapping IP ranges for the different networks, provided the other selected components (ipam, etc…) allow this. We also have `physicalNetwokName` field that corresponds to the physical Network defined within the uplinks definition ([config.md](config.md#L48)). If none is defined you can keep an empty string. This allows to have separated networks that communicate using dedicated uplinks. We currently only support vxlan for secondary networks (more information in `Active developments`)

```yaml
apiVersion: projectcalico.org/v3
Expand All @@ -26,6 +26,7 @@ metadata:
spec:
vni: 56
range: "172.19.0.0/16"
physicalNetworkName: ""
```
When a network is created, the `NetWatcher` component in the Calico/Vpp agent, will create a dedicated VRF in VPP to isolate the network’s routes.
Expand Down Expand Up @@ -168,6 +169,7 @@ Here is a link to a demo starring all these features.
This feature is still a work in progress. Here are a list of the topics we are actively focusing on :
- The encapsulation used for carrying the network identifier (VNI) between nodes defaults to VxLan, and expects the nodes to be connected with a single interface. We would like to give more flexibility to the cluster administrator here by making this part of the network specification.
- We would like to allow the BGP peering of multiple networks, with exported routes carrying the network identifier (VNI) they belong to.
- We do not support hostNetwork=true pod interfaces in multinet (secondary networks).
- The resulting ip and route configuration in the pod needs some refinement as well :
- Is there a default route, and if yes to which network ? Right now we kept the original behavior with a default route pointing to the default network.
- How are serviceIPs routed within the pods ? The same question applies for DNS & service resolution in case the configurations differ between networks.
Expand Down

0 comments on commit 2af3c4f

Please sign in to comment.