-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow n-hop routing #393
Comments
|
Flows for n-hop routingNetwork layout
Finalized Hop Flows
Verify that reflection remains set. For non-vnet gateway on a network, an external interface must be created and its routes added. Dropping eth_src/dst in T_R_EGRESS_INTERFACE and T_R_HOP_NETWORKWhen a packet is passed to T_R_HOP_NETWORK, it is known to only pass through L3 routing. The original L2 addresses will not leak when it exits the last gateway, nor can any L2 address translations happen. This means that the mac addresses of the src/dst gateways during hops do not matter. Route priority unique db entriesNote that the priorities of flows depend on their subnet prefix value, which is '20 + prefix'. We might have overlap if multiple interfaces on the same network share the exact same route subnet+prefix. Thus we need routing priorities, such that the flow priority will be '20 + prefix + (priority * 40)'. Routes db table include the network column, so we would add a priority column. The [network,subnet,prefix] columns would be unique. T_R_HOP_NETWORK Handling External RoutesIn the case of network with routes for virtual gateways adding hops is simple. This is not the case for network with non-vnet gateways. When the next gateway on a network is an physical/unmanaged interface, we currently rely on a simple config option in 'vna.conf' and hacked up arp lookup. This means we need to introduce a route type that applies to external physical interfaces, where eth_src/dst is properly set and the packet is passed to network dst handling. Note: The packet will already be egressing from a pre-determined datapath as gateway interfaces on physical networks are tied to one and only one datapath. Avoiding route reflectionIn TABLE_ROUTE_HOP_NETWORK there may be cases where a packet is routed back down the route it came from. To avoid this we should use value_pair metadata with 'network_id,previous_route_id' and have a dropflow if both are matched. These dropflows would be one priority higher than the regular route flow. While this does not guarantee the flowtable to be loop-free for loops with 2-steps and above, the limit on hops ensures these edge-cases do not cause harm. It might even be reasonable to skip the above safe-guard for 1-step loops. |
Currently we only support 1-hop routing due to the limitations of the current route link implementation.
Expand this to allow for 2-, and n-hop routing between networks.
The text was updated successfully, but these errors were encountered: