[j-nsp] FBF with st interfaces on SRX3400

[Ben Dale]

Oh boy..  I just spent the better part of this week doing exactly this with a Citrix Branch Repeater and an SRX210, having to deploy hacks on top of hacks to make up for the fact the Junos doesn't support something simple like WCCP, or FBF on the st0 interface.

My solution ended up being:

st0 and lt-0/0/0.0 interface in inet.0
WAN Accelerator (one-armed), lt-0/0/0.1 and Customer-facing vlan.units in virtual-router.
Both routing-instances stitched together with lt-0/0/0.x interfaces
Outbound FBF applied to customer vlan.x inteface(s)
inbound FBF applied to the lt-0/0/0.1 interface.


Because of the way the Citrix appliance works, I also had to do some funky rib policy to make sure that the return traffic passed through the Citrix box, even when there was a directly attached VLAN as the final destination.

A new(ish) feature (11.2) is the ability to use ip-monitoring to override existing routes when an RPM probe fails.  I'm using this to route around a failure in the Citrix box and it works pretty well (1 second probe) which is faster than WCCP can do it.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB25052

With the Citrix platform I ended up having to use selective packet-mode to send traffic to it, because of a weird FBF return flow issue that I'm currently working through with JTAC.  Ingress traffic from the CBR seems to be attempting next-hop lookup via the FBF forwarding-table like it's part of the same egress flow destined for it.

Regarding OSPF - you could just set up your OSPF in inet.0 and redistribute an aggregate for all the prefixes (assuming what sits behind the SRX isn't too complex) in the other VR/lt intefaces.

Per's GRE suggestion sounds MUCH cleaner though : )

Good luck!

Ben

On 19/12/2012, at 9:18 PM, Dennis Hagens <root at ipaddr.nl> wrote:

> Hi,
> 
> I'm running into a design problem for FBF with a Riverbed Steelhead. Our requirement is, to send __part__ of our VPN traffic through a Riverbed appliance for acceleration.
> The complicating factors here, are a multi tunnel VPN connection between 2 sites, running OSPF over the tunnel interfaces. Also, since we will process a lot more VPN traffic than the Riverbed can handle (1G+ whilst the Riverbed only has 1G interfaces), we cannot put the Riverbed physically in-line.
> 
> I have been able to separate the traffic with firewall filters and as such i can apply an action like send to different routing instance. I cannot however apply this to a tunnel (st) interface in this firewall, running Junos 12.1R2.9.
> 
> Currently i'm considering to set up 3 (Riverbed+VPN+inet.0) routing instances and running OSPF between 2 of them over a logical tunnel and using 1 of them purely for connectivity to the Riverbed (see http://postimage.org/image/tsxjq5gjv/ ).
> That way i i can apply the FBF filters on the lt and physical interfaces and redirect traffic to the riverbed instance, with a default to the riverbed. The riverbed would have a default back to the physical interface, where i could apply FBF again and push all traffic back to inet.0 again.
> The Riverbed would run in virtual in-path mode.
> 
> Besides the fact that in my initial setup OSPF wasn't working over the lt interfaces, i don't like the complexity of this. If i would be able to attach filters to the tunnel interfaces, i think i could set this up somewhat more simple.
> 
> Does anyone have a suggestion or experience with a similar setup?
> 
> Kind regards,
> 
> Dennis Hagens
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>