Asymmetric Routing with Juniper Routed VLAN Interfaces

I ran into a scenario the other day which I thought would be worth sharing. The customer had a layer 2 trunk link between the SRX firewall and the EX switch was configured so that two VLANs could reach the Internet. Here is the configuration:

SRX:

set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 100
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 200
set interfaces vlan unit 100 family inet address 10.10.10.1/24
set interfaces vlan unit 200 family inet address 10.10.20.1/24
set vlans 100 vlan-id 100
set vlans 100 l3-interface vlan.100
set vlans 200 vlan-id 200
set vlans 200 l3-interface vlan.200

EX:

set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 100
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 200
set interfaces vlan unit 100 family inet address 10.10.10.2/24
set interfaces vlan unit 200 family inet address 10.10.20.2/24
set vlans 100 vlan-id 100
set vlans 100 l3-interface vlan.100
set vlans 200 vlan-id 200
set vlans 200 l3-interface vlan.200
set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1

Obviously in an ideal scenario, we would not set the environment up this way. Creating a layer 2 trunk between devices while also having layer 3 interfaces on each device will create routing problems. Why? Let's think about the path that traffic destined for the Internet will take for each VLAN...

A host on VLAN 100 (10.10.10.0/24 network) will hit the switch, look at the default route and see a next-hop of 10.10.10.1. Once to 10.10.10.1 (the SRX), traffic will follow that default route out to the Internet. Return traffic will follow the same path back to the host, but with one difference - when the traffic looks at its route table to get back to the host on VLAN 100 (10.10.10.x), it will use the route with the lowest preference. In this case it is a directly connected route to vlan.100, which works fine because it's on the same network.

However, this does not work for VLAN 200, or any other VLAN for that matter.  A host on VLAN 200 (10.10.20.0/24 network) will hit the switch, look at the default route and see a next-hop of 10.10.10.1 (which is on a different network). Once to 10.10.10.1 (the SRX), traffic will follow that default route out to the Internet. Return traffic will NOT follow that same path back to the host due to the fact that there is a more preferred route present. In this case as well, there is a directly connected route to the 10.10.20.0/24 network via vlan.200. To illustrate, here is what the route table looks like on the SRX:

10.10.20.0/24   *[Direct/0] 00:00:17
                    > via vlan.200

Traffic used the default route on the way out and a direct route on the way back. This means that Internet-bound traffic by hosts on VLAN 200 will fail due to asymmetric routing...

There are multiple ways to resolve this issue architecturally, but I thought I would use this scenario as an opportunity to demonstrate the flexibility of routing instances in Junos. We need a way to remove that direct route so that return traffic to the host on VLAN 200 uses the same path that was used on the way out. Here is how it could be accomplished using a routing instance on the SRX:

set routing-instances TEST instance-type virtual-router
set routing-instances TEST interface vlan.200
set routing-options static route 10.10.20.0/24 next-hop 10.10.10.2

By applying this configuration change, we can now see that the direct route is no longer present in the inet.0 route table:

inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.20.0/24   *[Static/5] 2d 13:07:42
                    > to 10.10.10.2 via vlan.234

test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.20.0/24   *[Direct/0] 1d 06:10:43
                    > via vlan.200

Traffic from a host on the 10.10.20.0/24 subnet now follows the same path in both directions. I want to be clear that the best way to resolve this issue would be to make architectural changes to the network. However, this is a way to "make things work" temporarily, if necessary.