We've been using the LTM and ZebOS for some time now. Time and again we've run into OSPF bugs, and an upgrade usually resolved them. ZebOS's BGP has been relatively stable in that regard.

We're planning on extending our site (that will have its own DC), and need a (carrier-grade) router that'll potentially have a 100G pipe to the internet (and 10/40G connections internally). Would a Viprion 4800 chassis be a terrible choice for a router?

We'd like something that is MPLS L3/L2VPN capable, which F5 doesn't support yet. On the other hand, there could be load balancing requirements in the future, in which case, we'd have to drop an F5 behind an upstream Cisco/Juniper router. By having F5 as THE router for that site, we do away with SNAT (since it'll be inline for all the traffic), and take advantage of its ADC capabilities.

Amongst other things that concern me, since I haven't come across any vendor documentation, is whether F5 can hold the internet routing table (more than half a million routes) in its forwarding table, and if we're taking a performance hit by using a wildcard forwarding virtual server instead of hardware forwarding on a router.

Would appreciate any inputs on whether F5 should/shouldn't be a choice, or if someone in here is using F5s as backbone routers. TIA!

  • Why would your router need to hold the entire Internet routing table? Most companies use a default route for outbound traffic even if you run BGP with the ISP. The important part is that the ISP advertise your prefixes. You only need to entire Internet routing table if you must decide which outbound route is the most preferred.
    – Ron Maupin
    Jan 30, 2017 at 16:47
  • The last statement in your comment is very much a possibility in the long run :)
    – aaaa
    Jan 30, 2017 at 17:21
  • You will need to plan that carefully. You are likely to end up with asymmetric routing. That is usually only used when you advertise prefixes from other ASes, and you let the traffic between other ASes traverse your AS (basically, you become an ISP between ISPs (a transit AS).
    – Ron Maupin
    Jan 30, 2017 at 17:28
  • You would want to import the whole internet routing table so that if one of your upstreams gets into a peering spat and can no longer reach the whole internet your routers find out about it and act accordingly. Jan 30, 2017 at 18:02

2 Answers 2


Pushing full routes into a load balancer is about as far from best practice as you can get. Give it a default route to an actual router and a static route back to your subnets and it should be able to do anything you'd want. This also leaves you free to use that actual router to terminate multiple connections for diversity / best path options without having to now worry about a RIB containing millions of routes in your load balancer. If you really want to scale the typical design would actually have a pair of routers acting as an outbound gateway for the load balancer and then, in turn, a whole series of border routers terminating multiple ISP connections. Manage the heavy BGP work on a platform / OS specifically designed to do so and you won't be stuck in a position to be trying to diagnose whether app slowness is a function of a server, the load balancer, churning routing tables or just weirdness in a routing protocol implementation that is only marginally supported.

If appropriately designed (read: on a modular basis) this also leaves you in a place where scaling load balancers horizontally becomes a possibility to really hit high speeds, improved fail-over, etc. It also opens up a bunch of possibilities in terms of scalable cross-site multi-tenancy (this ties to your point about MPLS features - again, absolutely not a set of features that can be dropped in from open source) as well as opening up the possibilities for various overlay network topologies (read: SDN, et al).

I'm pretty sure if you ask the F5 guys whether they recommend carrying full views that they're going to tend to discourage it. They make an excellent appliance for app-level functions like load balancing, L4-L7 security, etc. That's a very, very different problem than scalable L2/L3. In many ways it's akin to asking whether the super-basic load balancer I can run in hardware on a Cisco switch (ITD) is an apt replacement for an F5 front-ending a complex web site (read: no). Can it handle some functions? Sure. Is it designed to run all the fancy features you actually need to operate at scale? Absolutely not. The same rationale applies to using a LB/ADC as a core router.


Not enough points to comment in agreement with mxrx yet, or vote his answer up, so I'll answer in agreement.

The BIG-IP can do routing well yes, but in support of application delivery. But if you follow the "right tool for the job" principle, as much I as would like our sales guys to sell you a Viprion for this it would be a disservice to you to do so. For security and application delivery, the hardware and software is designed from the ground up. That isn't the case with routing, that's a 3rd party license that is incorporated into the packaging to extend BIG-IP's core functionality.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.