Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Ingress Virtual Machine Traffic Optimization

 

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
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
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. You can specify the remote IP host routes to 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.

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 to the host. After the move, the spine devices in Data Center 2 will advertise the IP host route to the host . As a result, 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.

user@router1# show policy-options
user@router1# show routing-instances

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.