Wired Intelligent Edge

As I read, you can terminate vxlan not just to loopback interfaces but to any L3 interface. Since access switches already have an IP on VLAN 1 (which is in this case the in band management IP), can the VXLAN be deployed between the in band management IP of VLAN 1? This way, if we have L2 switches that have in band management IP on one of the VLAN that is already routed in the network, and have a trunk port to a central firewall doing the routing (static default gateway, since L2 switches don't take part in the routing process), then we don't have to add extra routing for L0 interfaces, but just add tunnels between the VLAN 1 IP addresses. Is this a possible idea? I keep seeing that the recommended is the L0 interface, but can this type of setup work too? Thanks!

------------------------------
Daniel KATAI
------------------------------

It sounds like what you're asking for is static L2 VXLAN, which we can do, but it can be hard to troubleshoot and scale out across a large network.  

Our architecture guides recommends using OSPF and EVPN/MP-BGP with VXLAN for better scalability and troubleshooting like the following:

https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAttachments/E197F883-1871-4792-811D-8B41CF332C24-5-Dynamic%20Segmentation%20-%20Virtual%20Network%20Based%20Tunneling%20(VNBT).pdf

Is this just a single branch-like site with a smaller amount of devices?  I'm gathering that you'd want to extend a tunnel from the branch into the firewall so that all the user traffic will go through the firewall, would that be correct?


------------------------------
Justin Noonan
------------------------------

Hello Justin!

Sort of. We have a datacenter migration and the new site is being built. Migrate datacenter, move machines in an L2 (migrate one VM of a cluster to new site, they remain in a multi site cluster in L2), then tear down old site. I get that in a large scenario, a dynamic VXLAN is easier to manage and faster to converge, but in a point-to-point scenario L2 static VXLAN just seems easier. (Especially if we have to "deconfigure" these settings after migration).

Also, my question was more about why it is recommended to use Loopback as a source IP for VXLAN. I get that in an OSPF scenario it is not a big deal to just add the L0 interface to the OSPF area, but I just don't see the point of creating a separate interface, and doing additional configuration to route it, when you already have in-band management IPs on the management VLAN, that are already routed on your network (weather its static or dynamic routing it doesn't matter).

Apart from the reason that "Loopback interface is always up while the VLAN interface has to be assigned to a port to be up" (its the inband management VLAN, so it has to be assigned to a port, so that admin can reach it) what are more reasons to use Loopback for VXLAN source IP?

Thanks!

------------------------------
Daniel KATAI
------------------------------

Original Message:
Sent: May 05, 2021 07:59 PM
From: Justin Noonan
Subject: VXLAN source IP not on Loopback IP

It sounds like what you're asking for is static L2 VXLAN, which we can do, but it can be hard to troubleshoot and scale out across a large network.  

Our architecture guides recommends using OSPF and EVPN/MP-BGP with VXLAN for better scalability and troubleshooting like the following:

https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAttachments/E197F883-1871-4792-811D-8B41CF332C24-5-Dynamic%20Segmentation%20-%20Virtual%20Network%20Based%20Tunneling%20(VNBT).pdf

Is this just a single branch-like site with a smaller amount of devices?  I'm gathering that you'd want to extend a tunnel from the branch into the firewall so that all the user traffic will go through the firewall, would that be correct?


------------------------------
Justin Noonan
------------------------------

This is purely for operational best practices at scale:
- loopback is always active as you noticed
- for remote VTEP configuration there is no dependency on underlay IP address mgmt that may change. IP address change would not impact remote VTEP configuration. (which can be huge work for large scale).

If your scenario is just for temporary reason with very small number of VTEPs with static VXLAN, there is no problem to use RoutedPort or SVI IP address.

------------------------------
Vincent Giles
------------------------------

Original Message:
Sent: May 06, 2021 02:41 AM
From: Daniel KATAI
Subject: VXLAN source IP not on Loopback IP

Hello Justin!

Sort of. We have a datacenter migration and the new site is being built. Migrate datacenter, move machines in an L2 (migrate one VM of a cluster to new site, they remain in a multi site cluster in L2), then tear down old site. I get that in a large scenario, a dynamic VXLAN is easier to manage and faster to converge, but in a point-to-point scenario L2 static VXLAN just seems easier. (Especially if we have to "deconfigure" these settings after migration).

Also, my question was more about why it is recommended to use Loopback as a source IP for VXLAN. I get that in an OSPF scenario it is not a big deal to just add the L0 interface to the OSPF area, but I just don't see the point of creating a separate interface, and doing additional configuration to route it, when you already have in-band management IPs on the management VLAN, that are already routed on your network (weather its static or dynamic routing it doesn't matter).

Apart from the reason that "Loopback interface is always up while the VLAN interface has to be assigned to a port to be up" (its the inband management VLAN, so it has to be assigned to a port, so that admin can reach it) what are more reasons to use Loopback for VXLAN source IP?

Thanks!

------------------------------
Daniel KATAI
------------------------------


Original Message:
Sent: May 05, 2021 07:59 PM
From: Justin Noonan
Subject: VXLAN source IP not on Loopback IP

It sounds like what you're asking for is static L2 VXLAN, which we can do, but it can be hard to troubleshoot and scale out across a large network.  

Our architecture guides recommends using OSPF and EVPN/MP-BGP with VXLAN for better scalability and troubleshooting like the following:

https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAttachments/E197F883-1871-4792-811D-8B41CF332C24-5-Dynamic%20Segmentation%20-%20Virtual%20Network%20Based%20Tunneling%20(VNBT).pdf

Is this just a single branch-like site with a smaller amount of devices?  I'm gathering that you'd want to extend a tunnel from the branch into the firewall so that all the user traffic will go through the firewall, would that be correct?


------------------------------
Justin Noonan

Hello Vincent!

Thank you for the clarification. I was in a pickle, because at the moment I only have a GNS3 lab with os-cx OVA switches to simulate this setup. In the 10.05 OVA release notes it sort of says "it doesn't fully support all VXLAN capability". I tested the L0 to L0 VXLAN and it worked in lab (there was traffic traversing the VXLAN tunnel). I tested the VLAN1 to VLAN 1 VXLAN and the tunnel was built but there was no traffic. I think its because simulator doesn't fully support it.

On the same topic: If the two VTEPs are a pair of VSX switches, how would that change this recommendation? Would the pair have to be configured with a joint Loopback IP or is there a special interface that we should use for VTEP termination? (Something like when we use MM VRRP IP to terminate the MD IPsec tunnels)

Br.:
Daniel

------------------------------
Daniel KATAI
------------------------------

Original Message:
Sent: May 06, 2021 05:44 AM
From: Vincent Giles
Subject: VXLAN source IP not on Loopback IP

This is purely for operational best practices at scale:
- loopback is always active as you noticed
- for remote VTEP configuration there is no dependency on underlay IP address mgmt that may change. IP address change would not impact remote VTEP configuration. (which can be huge work for large scale).

If your scenario is just for temporary reason with very small number of VTEPs with static VXLAN, there is no problem to use RoutedPort or SVI IP address.

------------------------------
Vincent Giles
------------------------------


Original Message:
Sent: May 06, 2021 02:41 AM
From: Daniel KATAI
Subject: VXLAN source IP not on Loopback IP

Hello Justin!

Sort of. We have a datacenter migration and the new site is being built. Migrate datacenter, move machines in an L2 (migrate one VM of a cluster to new site, they remain in a multi site cluster in L2), then tear down old site. I get that in a large scenario, a dynamic VXLAN is easier to manage and faster to converge, but in a point-to-point scenario L2 static VXLAN just seems easier. (Especially if we have to "deconfigure" these settings after migration).

Also, my question was more about why it is recommended to use Loopback as a source IP for VXLAN. I get that in an OSPF scenario it is not a big deal to just add the L0 interface to the OSPF area, but I just don't see the point of creating a separate interface, and doing additional configuration to route it, when you already have in-band management IPs on the management VLAN, that are already routed on your network (weather its static or dynamic routing it doesn't matter).

Apart from the reason that "Loopback interface is always up while the VLAN interface has to be assigned to a port to be up" (its the inband management VLAN, so it has to be assigned to a port, so that admin can reach it) what are more reasons to use Loopback for VXLAN source IP?

Thanks!

------------------------------
Daniel KATAI


Original Message:
Sent: May 05, 2021 07:59 PM
From: Justin Noonan
Subject: VXLAN source IP not on Loopback IP

It sounds like what you're asking for is static L2 VXLAN, which we can do, but it can be hard to troubleshoot and scale out across a large network.  

Our architecture guides recommends using OSPF and EVPN/MP-BGP with VXLAN for better scalability and troubleshooting like the following:

https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAttachments/E197F883-1871-4792-811D-8B41CF332C24-5-Dynamic%20Segmentation%20-%20Virtual%20Network%20Based%20Tunneling%20(VNBT).pdf

Is this just a single branch-like site with a smaller amount of devices?  I'm gathering that you'd want to extend a tunnel from the branch into the firewall so that all the user traffic will go through the firewall, would that be correct?


------------------------------
Justin Noonan

VSX VXLAN in the simulator doesn't work

For VSX VXLAN on 8360/8325/8400, you will need to use Lo0 with unique IPs, Lo1 with the same IPs as VXLAN tunnel source/destination.

Take a look here for config examples

------------------------------
DWan
------------------------------

Original Message:
Sent: May 06, 2021 07:01 AM
From: Daniel KATAI
Subject: VXLAN source IP not on Loopback IP

Hello Vincent!

Thank you for the clarification. I was in a pickle, because at the moment I only have a GNS3 lab with os-cx OVA switches to simulate this setup. In the 10.05 OVA release notes it sort of says "it doesn't fully support all VXLAN capability". I tested the L0 to L0 VXLAN and it worked in lab (there was traffic traversing the VXLAN tunnel). I tested the VLAN1 to VLAN 1 VXLAN and the tunnel was built but there was no traffic. I think its because simulator doesn't fully support it.

On the same topic: If the two VTEPs are a pair of VSX switches, how would that change this recommendation? Would the pair have to be configured with a joint Loopback IP or is there a special interface that we should use for VTEP termination? (Something like when we use MM VRRP IP to terminate the MD IPsec tunnels)

Br.:
Daniel

------------------------------
Daniel KATAI
------------------------------


Original Message:
Sent: May 06, 2021 05:44 AM
From: Vincent Giles
Subject: VXLAN source IP not on Loopback IP

This is purely for operational best practices at scale:
- loopback is always active as you noticed
- for remote VTEP configuration there is no dependency on underlay IP address mgmt that may change. IP address change would not impact remote VTEP configuration. (which can be huge work for large scale).

If your scenario is just for temporary reason with very small number of VTEPs with static VXLAN, there is no problem to use RoutedPort or SVI IP address.

------------------------------
Vincent Giles


Original Message:
Sent: May 06, 2021 02:41 AM
From: Daniel KATAI
Subject: VXLAN source IP not on Loopback IP

Hello Justin!

Sort of. We have a datacenter migration and the new site is being built. Migrate datacenter, move machines in an L2 (migrate one VM of a cluster to new site, they remain in a multi site cluster in L2), then tear down old site. I get that in a large scenario, a dynamic VXLAN is easier to manage and faster to converge, but in a point-to-point scenario L2 static VXLAN just seems easier. (Especially if we have to "deconfigure" these settings after migration).

Also, my question was more about why it is recommended to use Loopback as a source IP for VXLAN. I get that in an OSPF scenario it is not a big deal to just add the L0 interface to the OSPF area, but I just don't see the point of creating a separate interface, and doing additional configuration to route it, when you already have in-band management IPs on the management VLAN, that are already routed on your network (weather its static or dynamic routing it doesn't matter).

Apart from the reason that "Loopback interface is always up while the VLAN interface has to be assigned to a port to be up" (its the inband management VLAN, so it has to be assigned to a port, so that admin can reach it) what are more reasons to use Loopback for VXLAN source IP?

Thanks!

------------------------------
Daniel KATAI


Original Message:
Sent: May 05, 2021 07:59 PM
From: Justin Noonan
Subject: VXLAN source IP not on Loopback IP

It sounds like what you're asking for is static L2 VXLAN, which we can do, but it can be hard to troubleshoot and scale out across a large network.  

Our architecture guides recommends using OSPF and EVPN/MP-BGP with VXLAN for better scalability and troubleshooting like the following:

https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAttachments/E197F883-1871-4792-811D-8B41CF332C24-5-Dynamic%20Segmentation%20-%20Virtual%20Network%20Based%20Tunneling%20(VNBT).pdf

Is this just a single branch-like site with a smaller amount of devices?  I'm gathering that you'd want to extend a tunnel from the branch into the firewall so that all the user traffic will go through the firewall, would that be correct?


------------------------------
Justin Noonan