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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
