digraph G { node [ shape=rect ]; label="Data Center Light networking/routing (2021-04-11)" {router1p5,router2p5}->sunrise; sunrise->igp [ label="Add sunrise on-link routes" ] netstream->igp [ label="Add netstream on-link routes" ] vpnserver->routers [ label="eBGP: Announce /40's (reprop)" ] apurouters->routers [ label="Announce (internal) /64's" ] apurouters->igp [ label="Announce internal on-link routes (these are /64's" ] k8s->apurouters [ label="Announce /122, /128 routes (iBGP/eBGP)" ] something->switches [ label="Re-Announce k8s routes for ECMP" ] # Questions: # Do VPN servers import routes? Probably not, can use default route # Do APU routers import routes? Yes from k8s # Do APU routers import routes from routers? Maybe. # Maybe not: can have default route to routers # Maybe yes: to learn k8s routes # Will announce k8s routes via eBGP, nexthop reset. not what we want # Can we use iBGP + separate table instead of ospf/babel? ###################################################################### # Switch interaction # Either OSPF or BGP # # Primary objective: ecmp routes for k8s nodes / pods # Secondary objective (maybe) routing for the switch # # BGP: f.i. connecting to a route reflector; or routes come in via # eBGP # BGP / maybe RR seems a bit more native # OSPF: MTU mismatch showing, automatic join, only internal routes ###################################################################### # # ###################################################################### # k8s # k8s systems could in theory peer with switches -> security # design not so eay # # k8s systems could peer with routers (multihop, iBGP) # # k8s systems could peer with apu-routers (direct, iBGP) # apu-routers would need to become route-reflector towards routers # # k8s systems could peer with apu-routers (direct, eBGP) # # routers can re-export to APUs as route reflectors # How do the routers reach k8s system? Need route from apu routers # probably via igb }