This article provides a workaround for limitations on Legacy EX switch platforms when attempting to exchange (leaking) directly connected routes across routing instances. This article does not apply to devices with support for Enhanced Layer 2 Software (ELS).

Virtual Routing Overview

Virtual routing instances allow administrators to divide a Juniper Networks EX Series Ethernet Switch into multiple independent virtual routers, each with its own routing table. Splitting a device into many virtual routing instances isolates traffic traveling across the network without requiring multiple devices to segment the network. You can use virtual routing instances to isolate customer traffic on your network and to bind customer-specific instances to customer-owned interfaces.

Both static and dynamic routing is supported in a routing instance and a user can configure multiple routing protocols within each of the routing instances.

There may be a need to route between multiple routing instances. This can be achieved by configuring policy options or importing the Routing-Information-Base of one of the instances to the other, and vice versa. However, specifically on EX Switch platforms, both of these methods cannot be used to exchange directly connected routes across the instances. This is due to a known limitation on EX platforms, which is explained below, along with a workaround.

Exchanging (leaking) directly connected routes across routing instances is not supported.

1. When directly connected routes are exchanged via RIB groups or policy options, the routes get exchanged between routing instances in the kernel.

2. This can be observed by issuing the command show route forwarding-table inet.

3. For the exchanged directly connected routes, the next-hop will show up as rtbl.

4. This next-hop cannot be programmed in the PFE, which is a limitation. 

5. Because of this limitation, when rib-groups and policy options are used to export directly connected routes, the routes will exist in the kernel but not in the PFE.

There is also a special condition wherein users may observe that the method is working. This is an undesired effect of the limitation, which is explained below.

1. When traffic destined to a subnet that resides in the other routing instance enters on a port, the PFE will not have a route for it.

2. If there is no default route configured in the routing instance, then traffic will be rejected (there is an implicit reject of all packets for which there is no route).

3. A rejected packet needs to be sent to the kernel to create the Destination Unreachable message.

4. When this packet reaches the kernel, we now have the route in the kernel so it will be routed by the software.

For the above, this software forwarding results in heavy overhead on the CPU, which causes high CPU utilization and can cause unintended consequences. It also results in packet drops in the network since they are not routed by hardware but software. If there is a default route configured in the ingress routing-instance, then the packet will not be discarded but instead routed to the default next-hop and get black-holed.

Note: To have connectivity from hosts connected to an interface in one routing instance to an IP address the switch owns in a different routing instance, an extra step will be required.

For example, using the topology below and the workaround described, Host 1 and Host 2 will be able to ping each other, but Host 2 will not be able to ping 192.168.0.1. If Host 2 tries to ping 192.168.0.1, the packet will enter the EX4500 on interface ge-0/0/0, the PFE will recognize the address as the switch and proceed to send the packet to the kernel. Once in the kernel, it will be dropped as there is no route to that IP on the routing instance VLAN-BLUE.

If this connectivity is desired, a rib-group configuration to leak directly connected routes between routing instances will be required, which will be in addition to the workaround described below.

There are two workarounds:

1. Filter-based forwarding (FBF) using firewall filters

2. Physically connecting cables between two routing instances

Filter Based Forwarding

Example of leaking directly connected routes between routing instances using FBF.

Setup:


The traffic will be sent from Host 2 IP of 192.168.0.10 to 172.16.0.10 (Host 1) or vice versa.

The routing instance VLAN-RED will have the L3 interface vlan.100 configured, and routing instance VLAN-BLUE will have the L3 interface vlan.200 configured. The interface ge-0/0/0 is part of routing instance VLAN RED, and the interface ge-0/0/1 is part of routing-instance VLAN BLUE.

Problem:

• Host1 should be able to ping Host2.

Solution:

1. The directly connected subnets on routing instances cannot be exchanged by using policy options or RIB groups.
2. To exchange routes, firewall filters should be used to direct traffic to the respective routing instances. This method is called Filter based Forwarding.
3. Two firewalls will be configured, one placed in the ingress of vlan.100 and the other in the ingress of vlan.200.
4. Traffic destined to 172.16.0.10/32 sourced at VLAN RED hosts is forwarded to routing instance VLAN BLUE. 
5. Similarly, traffic destined to 192.168.0.10/32 sourced at VLAN BLUE hosts is forwarded to routing instance VLAN RED.

Configuration:

root@EX4500# show routing-instances 
VLAN-BLUE {
    description 192.168.0.0;
    instance-type virtual-router;
    interface vlan.200;
}
VLAN-RED {
    description 172.16.0.0;
    instance-type virtual-router;
    interface vlan.100;
}

root@EX4500# show interfaces vlan 
unit 100 {
    family inet {
        filter {
            input TO-VLAN-BLUE;
        }
        address 192.168.0.1/24;
    }
}
unit 200 {
    family inet {
        filter {
            input TO-VLAN-RED;
        }
        address 172.16.0.1/24;
    }
}

root@EX4500# show firewall 
family inet {
    filter TO-VLAN-RED {
        term 1 {
            from {
                destination-address {
                    192.168.0.10/32;
                }
            }
            then {
                routing-instance VLAN-RED; <-- If the destination address belongs to VLAN-RED, then forward the packet to the VLAN-RED routing instance. 
            }
        }
        term default {
            then accept;
        }
    }
    filter TO-VLAN-BLUE {
        term 1 {
            from {
                destination-address {
                    172.16.0.10/32;
                }
            }
            then {                      
                routing-instance VLAN-BLUE; <-- If the destination address belongs to VLAN-BLUE, then forward the packet to the VLAN-BLUE routing instance. 
            }
        }
        term default {
            then accept;
        }
    }
}
​

Physically connect cables between the two routing instances

This is an example of looping the cable to allow communication between two routing-instances for directly connected routes.

Topology:



Configuration:

set interfaces ge-0/0/18 unit 0 family inet address 192.168.0.1/30
set interfaces ge-0/0/20 unit 0 family inet address 192.168.0.2/30
set interfaces lo0 unit 0 family inet address 172.16.0.1/32
set interfaces vlan unit 100 family inet address 10.10.10.1/24 <--RVI for vlan 10 in default instance
set routing-instances RI-1 instance-type virtual-router
set routing-instances RI-1 interface ge-0/0/18.0
set routing-instances RI-1 interface lo0.0
set routing-instances RI-1 routing-options static route 10.10.10.0/24 next-hop 192.168.0.1
set routing-options static route 172.16.0.1/32 next-hop 192.168.0.2

root@EX4500> ping 172.16.0.1 rapid count 10   <-- Pinging from default instance to lo0 interface in “RI-1” instance
PING 172.16.0.1 (172.16.0.1): 56 data bytes
!!!!!!!!!!
--- 172.16.0.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.809/2.016/7.051/1.998 ms

• 2018-07-10: Updated second workaround in the solution.
• 2020-11-30: Article reviewed for accuracy; no changes required.​
• 2023-01-26: Added missing configuration lines for instance-type, modified IPs to comply with RFC standards. Validated in the lab as well. Article is still valid and relevant.

• Route leaking not working for local direct routes between virtual-router instances