Ingress Virtual Machine Traffic Optimization

date_range 20-Dec-24

arrow_backward

arrow_forward

When virtual machines and hosts are moved within a data center or from one data center to another, network traffic can become inefficient when the traffic is not routed to the optimal gateway. This can happen when the host is relocated. The arp table does not always get flushed and data flow to the host is sent to the configured gateway even when there is a more optimal gateway. The traffic is “tromboned” and routed unnecessarily to the configured gateway.

Starting in Junos OS Release 18.4R1, Junos supports ingress Virtual machine traffic optimization (VMTO). When ingress VMTO feature is enabled, the remote IP host routes are stored in L3 Virtual Routing and Forwarding (VRF) table and the device routes inbound traffic directly back to host that has been relocated.

Figure 1 illustrates tromboned traffic without ingress VMTO and optimized traffic with ingress VMTO enabled. Without ingress VMTO, Spine 1 and 2 from DC1 and DC2 all advertise the remote IP host route 10.0.0.1 when the origin route is from DC2. The ingress traffic can be directed to either Spine 1 and 2 in DC1. It would then be routed to Spine 1 and 2 in DC2 where route 10.0.0.1 has been moved. This causes the tromboning effect. With ingress VMTO, we can achieve optimal forwarding path by configuring a policy for IP host route (10.0.01) to only be advertised by Spine 1 and 2 from DC2, and not from DC1 when the IP host is moved to DC2.

Figure 1: Traffic with and without Ingress VMTO

Figure 2 illustrates an EVPN network with different elements. PE1 shares an Ethernet Segment with PE2. PE3 is on a separate segment. When PE1 learns of new IP host routes from CE1, PE1 adds the route into the VRF table since it is a locally learned route. If PE2 learns the route from remote peer PE1 (and not from CE1), PE2 will also add the route into VRF table as if the route is also locally learned since PE1 and PE2 are in the same Ethernet Segment. Table 1 summarizes the activity taken in the VRF table when a PE device learns of new IP host routes from remote PE devices under EVPN-VXLAN and there are no routing policies configured on the device. Table 2 summarizes the activity taken in the VRF table when a PE device learns of new IP host routes from remote PE devices under EVPN-MPLS and there are no routing policies configured on the device.

Note:

You can also configure policies to selectively add the routes that you want to the VRF table.

Figure 2: EVPN with multihomed devices

Note:

The IP host routes that PE1 and PE2 learned from each other are described as “From remote device that is connected to a shared Ethernet Segment” and the IP host routes that PE3 learned from PE1 or PE2 are described as “From a remote device that is not connected to a shared Ethernet Segment.

Table 1: Activity in the VRF table for EVPN-VXLAN
Ingress VMTO Configuration Status	From a remote device that is connected to a shared Ethernet Segment	From a remote device that is not connected to a shared Ethernet Segment
Prior to Junos OS Release 18.4R1.	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.	The IP host route is not added to the VRF instance table.
Ingress VMTO not configured	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.	The IP host route is not added to the VRF instance table.
Ingress VMTO configured	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.

Table 2: Activity in the VRF table for EVPN-MPLS
Ingress VMTO Configuration Status	From a remote device with a locally shared Ethernet Segment	From a remote device without a locally shared Ethernet Segment
Prior to Junos OS Release 18.4 R1 with chained composite next hop configured.	The IP host route is created with the composite next hop. The route is not advertise to its peer.	The IP host route is created with the composite next hop. The route is not advertise to its peer.
Prior to Junos OS Release 18.4R1 without chained composite next hop.	The IP host route is not added to the VRF instance table.	The IP host route is not added to the VRF instance table.
Ingress VMTO not configured	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.	The IP host route is not added to the VRF instance table.
Ingress VMTO configured	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.
Ingress VMTO configured with composite next hop	The IP host route is created with the IRB interface as the next hop and the route is added to the VRF instance table.	The IP host route is created with the composite next hop and the route is added to the VRF instance table.

To enable ingress VMTO, configure remote-ip-host-routes in the [edit routing-instances routing-instance-name protocols evpn]hierarchy level. When you enable remote-ip-host route, all remote IP host routes will be added to the VRF table. You can specify which remote IP host routes will be added to the VRF table through policies by including an import policy to under remote-ip-host routes to filter out the unwanted routes.

Note:

Juniper recommends that you only enable ingress VMTO on the spine devices in a centrally-routed bridging (CRB) overlay in an EVPN network. This allows devices to advertise learned routes to other routing protocols and to advertise EVPN type 5 routes across different data centers.

To address tomboning in Figure 1, you would define the communities for Data Center 1 and Data Center 2 and configure a policy in the spine devices to only import the routes learned from members in its own community. Before the move, the spine devices in Data Center 1 advertise the IP host route for the local host. After the move, the host becomes part of Data Center 2's community so the spine devices in Data Center 2 will advertise the IP host route. And the next-hop table on the remote host will have the updated route to Data Center 2 after the move.

The following output shows the sample policy and sample configuration with an import policy configured with remote-ip-host.

content_copy zoom_out_map
user@router1# show policy-options
policy-statement vmto-DC1-import { 
    term in-DC1 {
        from community [DC1_devices];
        then accept; 
    }  
    term not-in-DC1 { 
        then reject;
    } 
} 

content_copy zoom_out_map
user@router1# show routing-instances
blue {
	    instance-type virtual-switch;
	    route-distinguisher 10.255.0.3:100;
	    vrf-import vmto-DC1-import;
	    vrf-target target:100:100;
	    protocols {
	        evpn {
	             remote-ip-host-routes {
	                 import vmto-DC1-import;  
	                 mpls-use-cnh;
	          }
	            extended-vlan-list 100;
	            default-gateway do-not-advertise;
	        }
    }
.

Benefits of Ingress Virtual Machine Traffic Optimization

Ingress VMTO provides greater network efficiency and optimizes ingress traffic and can eliminate the trombone effect between VLANs.

arrow_backward PREVIOUS EVPN Type 2 and Type 5 Route Coexistence with EVPN-VXLAN

NEXT arrow_forward Tracing EVPN Traffic and Operations

EVPN User Guide

Ingress Virtual Machine Traffic Optimization

Benefits of Ingress Virtual Machine Traffic Optimization