F% Big-IP v.s Cisco CSS

[ed.youkhanna]

The f5 Big-IP series supports OSPF, BGP4 and a fully meshed network deployment. Does the CSS line support that as well? If not is it something in Cisco's future?

[Gilles Dufour]

the CSS does support ospf and rip - no bgp.

The CSM (the other cisco loadbalancing product) works in conjunction with an msfc - so you have ospf,isis,eigrp,bgp,...

I personally do not see the use of BGP on a loadbalancer.

Even a routing protocol is useless if the design is correct - unless you are doing "Route Health Injection" (RHI).

Gilles.

[gmiiller]

I've got to say I disagree with you here Gilles. I see a lot of redundancy deployments with firewalls where clients are prohibited by policy from running redundancy arrangements on the firewalls themselves, or running routing protocols on the firewalls. Often all that the client requires on one side of a multi-interface firewall is a means of dynamically directing all traffic to the standby firewall where the primary one fails, and something like a low end router/switch running multihop BGP through the firewall does the job just fine - provided they have something on the other side of the firewall that will play BGP as well. Lack of support for BGP, combined with some of the quirks as regards basic routing behaviour is probably our greatest bugbear on the CSS, as it limits our design options and frequently sees us using the competition instead. Support for BGP is #1 on our wish list for the CSS - on all of the models, not just the MSFC.

[Gilles Dufour]

this is a question of design.

I personally do not like routing protocols on a loadbalancer.

Also, the CSS runs probes for each static route.

So, you could have 1 default route to each firewall.

When 1 firewall goes down, the CSS will detect it and remove the static route from the routing table.

I still don't see the need for BGP or any routing protocol.

Keep it simple is the number one rule when designing a network.

Gilles.

[gmiiller]

Gilles,

Keeping it simple is our goal too. That's why, when we need to make a layer 3 forwarding decision, we prefer to use a layer 3 device and not push the decision further up the stack. We have designs that let us do this, as well as take advantage of layer 4 switches by deploying layer 4 switches where necessary, rather than where possible. We're also reluctant to rely on a probe to the firewall to test for availability, as we want to test traffic through the firewall, not to the firewall.

My organisation has configuraton responsibility for around a hundred L4 switches, and a lot of FW load-balancing/redundancy arrangements. At the moment Cisco is losing out as our L4 switch of choice because it lacks the features we require.

Whether Cisco are interested in gaining those sales isn't really a question of design at all.....

[Gilles Dufour]

once again, I'm confident we can make a design that will work with our CSS or CSM without using BGP.

You mentioned firewall loadbalancing.

This requires a pair loadbalancer around the firewalls.

With a pair of Cisco loadbalancers, you get a smart mechanism of probes THROUGH the firewall to guarantee that the firewall is alive.

I have assisted in multiple design all around the world and we NEVER had to use BGP.

If you are interested in deploying Cisco loadbalancers I will be glad to assist you in the design. Feel free to send me an email at gdufour@cisco.com with some topology and your design requirements. I'll review the info and let you know what we can do.

You can then decide if you prefer Cisco or F5.

Regards,

Gilles.

[Gilles Dufour]

one more remark regarding the probe.

If not using icmp probes, the CSS will decide to keep or remove a static route based on the presence of not of an ARP entry for the next-hop.

Does not require any ping.

All firewalls answer arp request.

So, this is a solution to avoid BGP.

Gilles.