provide a separate path for underlay and overlay

[anubisg1]

As per title, when running path it would be good to see a separate path (and UI Diagram) for Overlay and for Underlay.

The overlay needs to consider the Distributed Anycast Gateway as a "hop" for example

[ddutt]

@anubisg1 Can you please say more. What part isn't working right now for you? We do display underlay and overlay but unified. What are the use cases for having them separate?

[anubisg1]

@anubisg1 Can you please say more. What part isn't working right now for you? We do display underlay and overlay but unified. What are the use cases for having them separate?

Today we only make a path for the underlay and we say "at this switch the packet is encapsulated" and "on this switch the packet is decapsulated". There is no view of the overlay.

let's take this example, this is what we do today , and this is what i consider an "underlay path"

this is what an "overlay path" would look like: (you can see the addional routed hop of the L3 vni, that matches the TTL decrements on the overlay packets)

the underlay path (what we do today), can be very powerful, as in the example above, or very much useless (as in the example below). Note that the overlay path in both examples would pretty much be the same:

(i think i even found a possible bug in the way we do path today, since you can see in both "paths" that the "outgoing" interface is not listed. In this example below, source and destination are connected to the same switch (different vlans, routed at the switch, but the previous path has the same issue.)

this is how the overlay path would look like. Also notice how this overlay path is different from the previous one as it fathefully rapresents the idea of the source and destination being "routed" at the same point here, where above, an L3 VNI routed hop was involved.

i hope that this now clarifies better what i'm after with this feature request