[j-nsp] Share static routes between routing-instances on EX series

Andy Litzinger Andy.Litzinger at theplatform.com
Tue Jun 18 19:29:29 EDT 2013


I have a network that contains two distinct groups of servers.
Group1 with subnets A,B
Group2 with subnets C,D

Both groups use RVIs on a core VC (mix of EX4550s and 4200s) as their default route.  There are two different paths out of the network.  I'd like Group1 to take path1 and Group2 to take path2.  Subnets A,B,C and D should be able to communicate directly, preferably within the VC (not out to another device and back).

I can create a routing-instance for each group (or 1 and use the global table for the other).  Adding the RVIs and maintaining a separate default route out for each routing-instance is no problem.  The trouble is trying to allow the subnets to communicate to each other.

I've tried adding a static route under the routing-instance for Group 1 to a subnet outside the routing-instance, e.g. a route to subnet C inside routing-instance for Group1, but the route never shows up in the routing table, presumably because there isn't a live interface in routing-instance C with a connection to subnet C.  and it doesn't look like there's an option to make the next-hop an interface instead of an IP.

group1-vr {
    instance-type virtual-router;
    interface vlan.A;
    routing-options {
        static {
            route C.0/23 next-hop C.1;
        }
    }
}

root at ex# run show route
<snip>
group1-vr.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A.0/23      *[Direct/0] 1d 00:52:00
                    > via vlan.A
A.1/32      *[Local/0] 1d 00:52:00
                      Local via vlan.A

I will try rib groups next, but I think I read somewhere that EX switches don't support importing static routes via rib groups.

I suppose this could also be solved by Filter Based Forwarding, but I'd like to avoid that if possible; it just doesn't seem as clean.

thanks in advance!
-andy



More information about the juniper-nsp mailing list