cfp/37315 bgp session default gateway #68
Conversation
|
cc: @cilium/sig-bgp |
| bgpInstances: | ||
| - name: "65001" | ||
| localASN: 65001 | ||
| autoDiscovery: true |
There was a problem hiding this comment.
I think we can make this a stanza under peers? We can put address family information under the new stanza as well.
peers:
- name: peer0
peerASN: 65000
peerConfigRef:
name: peer-config0
autoDiscovery:
mode: default-gateway
addressFamily: ipv4 // or ipv6There was a problem hiding this comment.
ya i agree. it will provide flexibility per peer. but i'm curious about the use-case. What is the use-case to use different discovery mechanisms for each peer OR auto-discovery for one peer and static ip for another?
There was a problem hiding this comment.
For example, using default gateway to peer with ToR and use static ip to peer with route reflector. Whether or not this is realistic, I'd prefer the option that gives the maximum leverage. The instance-level knob enforces users to use default gateway for all peers.
There was a problem hiding this comment.
okay i was wondering if there is an existing use-case.
but i agree with you. it provides flexibility for sure.
| In multi-homed environments (i.e., multiple default gateways leading to different ASNs), this proposal does not address which gateway belongs to which peer ASN. | ||
|
|
||
| example multi-homed config: | ||
| bgpInstances: | ||
| - name: "65001" | ||
| localASN: 65001 | ||
| peers: | ||
| - name: "65000" | ||
| peerASN: 65000 | ||
| peerConfigRef: | ||
| name: "cilium-peer" | ||
| - name: "65011" | ||
| peerASN: 65011 | ||
| peerConfigRef: | ||
| name: "cilium-peer" | ||
|
|
||
| If multiple default gateways exist, we cannot reliably match them to different peer ASNs. One workaround is to use same local ASN on both the ToRs for bgp sessions with the k8s node, and bgp cluster config will have one peer configured. | ||
|
|
||
| proposed multi-homed config: | ||
| bgpInstances: | ||
| - name: "65001" | ||
| localASN: 65001 | ||
| peers: | ||
| - name: "65000" | ||
| peerASN: 65000 | ||
| afi: ipv4 | ||
| peerConfigRef: | ||
| name: "cilium-peer" |
There was a problem hiding this comment.
I think as long as the selection is consistent, it is ok to select only one of them and use it. For example, we can use metric to compare them. In my understanding, Linux doesn't allow us to create two default gateway with the same metric. So, it should be possible prefer the route with the lowest metric for example.
Since we are anyways subscribing to the netlink, we can also do failover when one of them disappears.
There was a problem hiding this comment.
can you elaborate on this?
are you saying that in multi-homing, we will create a bgp session with default gateway of lowest metric? If that fails, we will create a bgp session with the other?
i'm not familiar with netlink. how will that help with failover?
There was a problem hiding this comment.
are you saying that in multi-homing, we will create a bgp session with default gateway of lowest metric?
Yes, right. Then, when the lowest one disappears, we'll be notified through statedb (statedb watches netlink, so we don't need to deal with it directly). Then now we can select the one left on the routing table (the higher one). As a result, we are failing over.
There was a problem hiding this comment.
okay got it. If you can send sample code or parts of cilium code that i can update to make this work, that would be helpful.
add code blocks for configs Signed-off-by: naveenachyuta <[email protected]>
This PR adds a CFP for Auto Peer Discovery for Cilium BGP cilium/cilium#37315