Interceptor

[MeToo2]

Thanks very much both of you for the replies.

Indeed mentioning that the Interceptors work using NAT is the magic hint for me.

Once it is NATted I presume then that the flow for optimisation just follows the general routing and switching protocols to the redirect pool (and back). So we just have to make sure the routing and addressing tables in the devices are all correct so they follow the correct paths

We use this trick on a site for internet offloading of non critical traffic from a site via a GRE tunnel over Internet together with policy based routing. The traffic gets directed into the tunnel using PBR at the site end and then NATted on tunnel exit so that the return traffic follows the same (correct) path.

Regards using the interceptor to reference the partner interceptor: I'll leave that design decision until later when we hire in a real Riverbed expert. It doesn't affect the project planning and purchasing phase we're currently in. Not sure what it'll bring given the relatively long BGP timers that our providers insist on using. The sessions will probably anyway die during a failover.... the failover is seen more of an extreme availability event rather than the users having any expectation of continuous uninterrupted service. Although the use of NAT would certainly make the sessions die. On the other hand I'm not expecting latency issues on the inter-data centre site links. These are relatively short compared to the length of the cables/connections to the remote sites that have the optimised traffic (~5mS relative to 30-250mS round trip latency). Sites not too far away will anyway get 1Gbps metro Ethernet, and will not have any optimised traffic at all, so they won't be affected by any Riverbed failover.

Message Edited by MeToo2 on 07-07-2009 01:51 PM

[alfred]

As Zsolt said, this should be fine.  I just wanted to add that when it comes to the Interceptor, there aren't  L2 vs L3 connectivity tradeoff's (like performance, fragmentation, etc) that exist for routers/switches handling WCCP redirection and return. I'm not sure if this was a reason why you asked, but it is a common reason for questions around Interceptors and L2 vs L3 connectivity.

For routers/switches, an issue that comes up during WCCP design is whether they can process GRE encapsulated packets in hardware or software. The interceptor only uses GRE encapsulation when it's performing session setup for an optimized connection, so it's just handling the small syn & syn/ack packets used during autodiscovery.  Thereafter, it uses NAT to redirect the data bearing packets to a particular Steelhead in its redirect pool.  That way, there's no need for fragmentation; contrast that to the case when you need to GRE encapsulate a fully sized data packet.

Hope that helps give some context - Al

Message Edited by alfred on 07-02-2009 03:47 PM

[zszabo]

With respect to the diagram, this looks like it should work just fine to me.

  The steelheads in this picture would need 'in-path neighbor allow-failure' set.  The interceptor configurations could be done in one of two ways, depending on your preference

 1) The interceptors reference each other as redirect peers with allow-failure. This would ensure optimization for existing connections continues during a switchover

 2) The interceptors do not reference each other and existing optimized connections would break during  a switchover.  While less desirable, this does eliminate the two interceptors from having to communicate with each other during client/server connections, gaining you improved connection latency.  This is probably less of a concern when you consider the benifit from optimization will be multiple orders of magnitude greater than any latency . (Non optimized traffic would not have this latency issue)

[MeToo2]

I can't find Riverbed CLI documentation anywhere online. You seem to already have to have a maintenance contract before you are allowed to read the details about what a box can do. Shame. Not even the Borg behave that way.

Anyway I have a question. I'm working on a project to define a WAN optimisation service for a reasonably large company. They have a few data centres that need to have high availability connections and optimisation, but they want to start slowly with the amount of WAN optimisation they purchase in the initial implementation. Eventually it'll probably be around 300Mbps of WAN optimisation traffic per data centre, with platinum availability (>99.9% optimisation service availability).

They run a twin DC where the 2 halves are separated by a fair distance (80Km = 50 miles) There's plenty of bandwidth available between the 2 DC's, but they'd strongly prefer if the interconnection was one or more Layer3 routed connections (not layer 2 failover). Failover of the WAN interface is already arranged using BGP. One site is always main and the other standby at the WAN level with gigabit uplinks to the WAN MPLS core. Only one WAN link will be active at any one time (guaranteed balanced routing due to use of BGP MED)

One idea I have is to use dual interceptors with dual stealhead clusters. There'd be one Stealhead cluster on each site and one interceptor on each site. In order to reduce the number of Steelheads required, I'd like to cross connect across the data centre sites (at layer 3) to also utilise the Steelhead cluster on the back up site.

In other words, during normal operation the main interceptor on site 1 can use Cluster A on site 1 AND Cluster B on site 2. If the MPLS WAN link fails over to site 2, the interceptor on site 2 can still also use Cluster A on site 1 and Cluster B on site 2 (via internal layer 3 links over DWDM between the twin DC sites). If a single Steelhead fails, the interceptor will detect this and load balance across the remaining 3 Steelheads. This would mean 8 subnets as per the diagram below, and the Intereceptor would not be directly connected at layer 2 with the cluster on the opposing site (only at layer 3).

Is this possible?

diagram:

Message Edited by MeToo2 on 06-30-2009 10:18 AM