If we want to know what VNI a given port operates on, opteadm won't really help us figure this out. The actions which are guaranteed to know this all reside in the overlay layer:
BRM42220057 # opteadm dump-layer -p opte1 overlay
Port opte1 - Layer overlay
======================================================================
Inbound Flows
----------------------------------------------------------------------
PROTO SRC IP SPORT/TY DST IP DPORT HITS ACTION
Outbound Flows
----------------------------------------------------------------------
PROTO SRC IP SPORT/TY DST IP DPORT HITS ACTION
Inbound Rules
----------------------------------------------------------------------
ID PRI HITS PREDICATES ACTION
0 1 98 * "Static: Decap"
1 2 0 * "Meta: mcast-vni-validator"
DEF -- 0 -- "deny"
Outbound Rules
----------------------------------------------------------------------
ID PRI HITS PREDICATES ACTION
0 1 117 * "Static: Encap"
DEF -- 0 -- "deny"
However, Static: Encap tells us nothing about what the action is programmed to do, what its parameters are, etc.
It would be nice if actions on a rule could list out their fixed propertes, analogous to dladm show-linkprop (potentially with a view towards being machine-readable if requested). In this scenario, we would want to query overlay/out/0:vni.
We could probably extend this to ports themselves having a K/V map to hold various optional facts the control plane may want to stash for other diagnostic tools to make use of. Generally we want to make things work such that we're not putting oxide-vpc specfic information into opteadm.
If we want to know what VNI a given port operates on,
opteadmwon't really help us figure this out. The actions which are guaranteed to know this all reside in the overlay layer:However,
Static: Encaptells us nothing about what the action is programmed to do, what its parameters are, etc.It would be nice if actions on a rule could list out their fixed propertes, analogous to
dladm show-linkprop(potentially with a view towards being machine-readable if requested). In this scenario, we would want to queryoverlay/out/0:vni.We could probably extend this to ports themselves having a K/V map to hold various optional facts the control plane may want to stash for other diagnostic tools to make use of. Generally we want to make things work such that we're not putting
oxide-vpcspecfic information intoopteadm.