Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[EX] Exchanging (leaking) directly connected routes across routing instances is not supported - workaround provided

0

0

Article ID: KB23027 KB Last Updated: 11 Jul 2018Version: 3.0
Summary:

This article provides a workaround to a limitation on EX Switch platforms when attempting to exchange (leaking) directly connected routes across routing instances.

 

Symptoms:

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.

 

Cause:

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

  1. When the 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 '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 in which the user may observe the method is working. This is an undesired affect of the limitation which is explained below.

  1. When the traffic destined to a subnet which 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, Host1 and Host2 will be able to ping each other, but Host2 will not be able to ping 155.3.51.251 and Host1 will not be able to ping 10.30.97.253. If Host1 one tries to ping 10.30.97.253 the packet will ingress the EX4500 on interface ge-0/0/0 and in the PFE it will be recognized as an ip address the switch owns and will be sent to the kernel. Once it is in the kernel it will be dropped as there is no route to 10.30.97.253 in routing-instance nb-test.

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

 

Solution:

There are two workarounds:

  1. Filter based forwarding using firewall filters.

  2. Physically connect cables between the two routing instances.


Filter Based Forwarding

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

Setup:

Host1 (155.3.51.226) <---> VLAN_A (155.3.51.251) ge-0/0/0(VR:NB-test) --- (EX4500) --- (VR:NB-test2) ge-0/0/1 (10.30.97.253) VLAN_B <---> (10.30.97.53) Host2
  1. Two routing instances, 'nb-test' and 'nb-test2' are configured with two l3 interfaces (vlan.100 and vlan.200)

  2. Vlan.100 refers to the l3 interface for VLAN_A and vlan.200 to VLAN_B

  3. Ge-0/0/0 is part of VLAN_A and ge-0/0/1 belongs to VLAN_B

Problem:

Host1 should be able to ping Host2.

Solution:

  1. The directly connected subnets on routing instances cannot be exchanged using policy options and rib groups

  2. In order to exchange routes, firewall filters should be used to direct the traffic to 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 10.30.97.53/32 originating from VLAN_A hosts are forwarded to routing instance NB-test2

  5. Similarly, traffic destined to 155.3.51.226/32 originating from VLAN_B hosts are forwarded to routing instance NB-test

Configuration:

{master:0}[edit]
juniper@Ram-NB# show routing-instances
nb-test {
    instance-type virtual-router;
    interface vlan.100;
}
nb-test2 {
    instance-type virtual-router;
    interface vlan.200;
}

{master:0}[edit]
juniper@Ram-NB# show interfaces vlan.100
family inet {
    filter {
        input nb-fbf2;
    }
    address 155.3.51.251/24;
}

{master:0}[edit]
juniper@Ram-NB# show interfaces vlan.200
family inet {
    filter {
        input nb-fbf;
    }
    address 10.30.97.253/24;
}

{master:0}[edit]
juniper@Ram-NB# show firewall
family inet {
    filter nb-fbf {
        term one {
            from {
                destination-address {
                    155.3.51.226/32;
                }
            }
            then {
                routing-instance nb-test; <-- If the destination address belongs to nb-test routing instance, then forward the packet to the nb-test routing instance.
        }
        term default {
            then accept;
            }
        }
    }
    filter nb-fbf2 {
        term one {
            from {
                destination-address {
                    10.30.97.53/32;
                }
            }
            then {
                routing-instance nb-test2;  <-- If the destination address belongs to nb-test2, then forward the packet to the nb-test2 routing instance. 
       }
        term default {
            then accept;             
        }
    }
}

{master:0}[edit]
juniper@Ram-NB# show interfaces ge-0/0/0
unit 0 {
    family ethernet-switching {
        vlan {
            members VLAN_A;
        }
    }
}

{master:0}[edit]
juniper@Ram-NB# show interfaces ge-0/0/1
unit 0 {
    family ethernet-switching {
        vlan {
            members VLAN_B;
        }
    }
}

​

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:

   +--------------+-------------+           Loopback Interface
   |              |  Routing    |           9.9.9.9 - lo0
   | Default      |  Instane - test            |
   | routing      |             |              |
   | instance     |             +--------------+
   +--------------+---------+---+
ge-0/0/16                   |
1.1.1.1/30               ge-0/0/18
        |                1.1.1.2/30
        |     Cable loop    |
        |                   |
        |                   |
        |                   |
        +-------------------++

Configuration:

set interfaces ge-0/0/16 unit 0 family inet address 1.1.1.1/30
set interfaces vlan.10 unit 0 family inet address 10.10.10.1/24 <--RVI for vlan 10 in default instance
set interfaces ge-0/0/18 unit 0 family inet address 1.1.1.2/30
set interfaces lo0 unit 0 family inet address 9.9.9.9/32
set routing-instances test interface ge-0/0/18.0
set routing-instances test interface lo0.0
set routing-instances test routing-options static route 10.10.10.1/24 next-hop 1.1.1.1
​set routing-options static route 9.9.9.9 next-hop 1.1.1.2
 
root@switch> ping 9.9.9.9 count 10 rapid <-- Pinging from default instance to lo0 interface in “test” instance
PING 9.9.9.9 (9.9.9.9): 56 data bytes
!!!!!!!!!!
--- 9.9.9.9 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.152/1.443/1.814/0.239 ms

 

Modification History:

2018-07-10: Updated second workaround in the solution.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search