Need mechanism for overlay/underlay isolation

[taspelund]

With support being added for IPv6 in the overlay, we need to ensure that there is proper isolation of the underlay and overlay networks.

The concern is that the switch would allow the following scenario:

1. Instance sends packet with DIP in underlay IPv6 prefix
2. OPTE uses IPv6 default external route
3. OPTE encaps packet, sends to switch
4. Switch decaps packet
5. Switch does v6 route lookup on inner packet (DIP == underlay ip)
6. Switch routes inner packet via backplane link to the host that owns the underlay ip

If this flow is possible, it could allow arbitrary instances to send arbitrary payloads to the host OS.
This may turn out to be a non-issue due to an implementation detail I'm not aware of, but it's a property of our sidecar implementation that needs to always be upheld.

This was a non-issue when the overlay was IPv4 only, since the overlay/underlay isolation was provided by the two being separate address-families. With IPv6 in the overlay, there is no such implicit separation.

[taspelund]

At a high level, I think this could be solved with the logical design of having underlay routes in a separate LPM table.
e.g.
System routes in table id 0 (populated by ddm), External routes in table id X (populated by mgd).

This could be implemented in different ways (e.g. actual separate tables in P4 vs adding a table-id key to the existing LPM table).