ungleich-graphviz/ungleich-network.dot

66 lines
2.1 KiB
Plaintext

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
}