SRX

Hi All

I have a small issue I would like to run by you SRX experts.  I have an SRX firewall with 3 Virtual routers.  I want to give each Virtual router its own internet IP for web surfing.

I have a switch outside the SRX which as a VLAN (vlan-id 100) on the internet.  If a device plugs into that VLAN with a public IP they have access to the internet, pretty simple.

How would I go about terminating the same VLAN into 3 different VR's?  This box is a cluster which means I can't use switching features

My thoughts was to do something like

reth0

  vlan-tagging

  unit 100

     vlan-id 100

     family inet address 72.23.23.5

but then I realized OK I can tie reth0.100 into one VR but how do I

  a) setup the other two IP address'

  b) reth0.100 is tied to a VR, I can't tie it to another one.

I know that I could have 3 physical cables and dedicate 3 physical ports on my SRX but what a waste....and if I grow to 10 VR's this does not scale very nicely.

Thanks for any comments!

I don't think that would work, even if you could get the SRX to allow you to configure it that way.

When a packet/frame comes into the device on a physical interface, it's going to look at the VLAN tag first to determine what virtual interface the packet/frame is to be assigned to, and that becomes the ingress port.  The ingress port then is tied to a VR, so L3 decisions are made based on that VR.

If you have mutliple virtual interfaces with the same VLAN tag, how would the device know which virtual interface it should assign the packet/frame to? The SRX is going to look at the layer 2 header information before it looks at any layer 3 information.

Perhaps one solution might be to make a rib-group so that your interface route for your egress interface is available to all your VRs, then use some combination of filter-based-forwarding and/or NAT rules to assign egress traffic public IPs based on which VR the traffic is to/from?

Just throwing spaghetti at the wall there... without a little more info to describe exactly what you're looking for I don't know that I fully understand the problem.

Thanks for the reply Keithr.

Your comment was just what I needed to hear.  My alternate plan was to have the default route from the main injected through instance-import ( I Hate rib groups) into each of the VR's.  I would then have a NAT policy based on the source zone/ip to determine which public IP each VR would get.

Thanks!

fun fact:  You dont need the interface route anymore.  Not sure which version of JUNOS did this but you can have a route imported in a VR and work without having to have the next-hop subnet in the VR (the route still needs to be in the originating VR of course).  This saves alot of time.

---

@Magraw wrote:

fun fact:  You dont need the interface route anymore.  Not sure which version of JUNOS did this but you can have a route imported in a VR and work without having to have the next-hop subnet in the VR (the route still needs to be in the originating VR of course).  This saves alot of time.

---

Could you show an example?  I have not yet investigated this...

 Here is one example:

First I have an SRX-100 with two tables; the Main Table (inet.0) and a second table called VR-A

I start by adding my default route to the main routing table

[edit routing-options static]
route 0.0.0.0/0 next-hop 23.23.23.1;

 My internet facing interface is 23.23.23.2 so I have the r

oute for the next-hop in my main table

router# run show route terse

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

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 0.0.0.0/0          S   5                       >24.24.24.1
* 24.24.24.0/28  D   0                           >ge-0/0/0.0
* 24.24.24.2/32  L   0                            Local

 I then create a policy statement and use that to import  the default route into the VR-A

[edit policy-options policy-statement Internet-Route]
term First {
    from {
        instance master;
        route-filter 0.0.0.0/0 exact;
    }
    then accept;
}
term LAST {
    then reject;
}

[edit routing-instances VR-A]
    instance-import Internet-Route;

Which gives me the following in the VR-A Table

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

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 0.0.0.0/0          S   5                       >24.24.24.1

Notice I have a default route in my VR-A table with a next-hop address that i do NOT have a route for in VR-A.  This setup works great!

Interesting... I sent you some kudos for that one.

I wonder when this behavior changed, I'm still stuck in rib-group hell on most of my VR setups.

I also wonder what the caveats are now for when rib-groups are needed, and when they are not.  Maybe things like DHCP relay or routing protocols, multicast, etc., may not work properaly across VRs without rib-groups...

Any Juniper employees care to fill us in on the benefits and caveats/drawbacks/limitations of these two different methods?

Hi Keithr and Magraw,

Interesting discussion. From my understanding, the behavior never changed.
You can export routes with instance-import and they can be used in a new
instance wihthout any further configuration. You can copy the routes with RIB-group.
You can use a next-table option or lt-interfaces.

But if you want FBF, you will need anyway 2 things 1) Create a new (e.g. default) route
in FBF instance; 2) make sure it can resolve its next hop => need for a RIB group
or instance-import.