Discussion between developers on bugfixes can often be seen in ##vyatta
on Freenode. 
I find it interesting to idle/chime-in occasionally at least.
Tom
Hi,
In the past, I helped a few small ISP (sub 1Gbps) with software routers setup like Vyatta (Well FreeBSD/64 + Quagga really).
Until recently the hardware required to run over 500Mbps + could be as pricey as a pair recycle Cisco 7206VXR since most MBs where coming with only 1 PCI busses which could kills the BW+PPS depending on the amount of interfaces you use.
Now-a-days MBs with more than 1 PCI bus have become cheaper and shouldn't be a problem.
Its all in the setup anyway:
2 servers ($3k each with 4 interface).
Split your uplink on each router.
1 link for "client-reflector" | OSPF | <whatever you like> between the router.
VRRP back-end.
PS: Sub 10Gbps, any DDoS will kill the link before killing those routers, but there is solutions to this which is hella-easy to deal with in this situation.
I would expect a properly configured Vyatta running as a route server
to be pretty darn near zortch-proof, no? (Barring BGP packet-o-death
issues of course - but is there a router vendor who *hasn't* had at
least 2 or 3 of those? 
One important thing it overlooks is what percent of DDoS attackqs are simple
"flood the pipe" attacks directed at a target behind the router. If you got a
100M or 1G pipe to the outside world and you're getting hammered by multiple G
worth of packets, things are going to suck no matter what the router is. And
let's face it, kicking that pipe to 10G is gonna cost a bit....
In a message written on Mon, Sep 12, 2011 at 06:56:26PM +0000, Dobbins, Roland wrote:
The days of public-facing software-based routers were over years ago - you need an ASIC-based edge router, else you'll end up getting zorched.
Some enterprises get MPLS L3 VPN service from their providers, and
need boxes that can route packets to it and speak BGP to inject
their routes. They are not, per se, connected to the Internet, and
thus won't be "zorched", at least in the sense you are using it.
Also, many enterprises get DS-3, Cable Modem, or 100M Ethernet
handoffs, and won't ever get a faster "zorch" due to link speed.
In a message written on Mon, Sep 12, 2011 at 06:56:26PM +0000, Dobbins, Roland wrote:
The days of public-facing software-based routers were over years ago - you need an ASIC-based edge router, else you'll end up getting zorched.
Some enterprises get MPLS L3 VPN service from their providers, and need boxes that can route packets to it and speak BGP to inject their routes. They are not, per se, connected to the Internet, and thus won't be "zorched", at least in the sense you are using it.
Also, many enterprises get DS-3, Cable Modem, or 100M Ethernet handoffs, and won't ever get a faster "zorch" due to link speed.
Hence 'public-facing'.
;>
Is Vyatta really not suited for the task?
I keep checking up on it and holding off looking into it as they don't
support multicast yet.
Modern commodity sever hardware these days often out-powers big iron
enough to make up for not using ASICs, though, at least on the lower
end of the spectrum.
Does anyone have any more details on Vyatta not scaling? Were you
trying to run it as a VM? What were you using for NICs? etc.
The hardware matters. Saying Vyatta doesn't cut it could mean anything...
Hi,
As usual this end-up in what people prefer.
Vyatta is as good as the hardware it runs on, the backend they use and the people configuring/maintaining it.
The nature of ASIC make it more reliable than a multi-purpose device (aka server) running an OS written for it.
It end up being a choice between risk and cost and being that you can get your hand on second hand iron for cheap these days...
Why risk it.
Ray
Download the Podcast "The Packet Pushers - Show 31" they talk a little
about this topic... If nothing else it's a great listen
Cheers!
Thanks for the tip, first time I hear this podcast.
We're using Vyatta for a handful of fast ethernet links to the internet, with I think about three dozen BGP peers. (Mix of IPv4 and IPv6; about four full feeds on each protocol, the rest is peering). It's not as mature or polished as I understand some of the Cisco or Juniper platforms are; but on our small scale it's fine.
We have a decent amount of of Linux expertise in the office (and virtually zero for Juniper/Cisco/...), so having more familiar tools on the routers is nice.
As a small shop it's also convenient that the boxes are cheap (so we can have two hot ones with VRRP etc and cheaply a third cold spare) and that the spare parts etc are the same or similar to the rest of the boxes in the rack.
- ask
I'll chime in,
In an enterprise environment, I've worked with software routers as well as
hardware beasts (ala Junipers, Cisco 6500s, ASAs, and more).
Ultimately, the network is as reliable as you build it. With software, it's
much cheaper to divide and scale horizontally. Hardware devices are
expensive and usually horizontal scalability never happens. So in reality,
an enterprise blows 100k on two routers, they both flop because of some
"firmware bug", and you're down.
The most reliable/cost effective solution is the cheap and redundant
approach to architecture.
Reliable hardware is incredibly inexpensive, and every year we get better
CPUs and (recently) GPUs that are providing APIs and interfaces to their
incredible parallel processing capability.
btw, you guys might find
PacketShader<http://shader.kaist.edu/packetshader/>a pretty
interesting concept
-Andreas
The most reliable/cost effective solution is the cheap and redundant
approach to architecture.Reliable hardware is incredibly inexpensive, and every year we get better
CPUs and (recently) GPUs that are providing APIs and interfaces to their
incredible parallel processing capability.-Andreas
+1 Scaling Horizontally. Applies to your networking gear, your applications,
etc. If you assume anything is going to break, just get more and
scale/architect properly.
Excellent! I was wondering how far along this was. Good to see. Very exciting.
I've got a couple parallel systems sitting around looking for packets to route...
If anyone is doing research in this area, please let me know. Most of my research has been into accelerating IDS/IPS and fuzzing workloads with parallel systems. (Yes that's on top of starting an ISP).
I've been looking into http://www.read.cs.ucla.edu/click/Click
With this in mind, I am keen to understand how many implementations of packages such as Quagga and Zebra that the group use. With the likes of Vyatta being discussed, I am keen to see if products such as Quagga as still regularly used as it used to be.
Thoughts welcome!
Kind regards,
/P.
Ultimately, the network is as reliable as you build it. With software, it's much cheaper to divide and scale horizontally. Hardware devices are expensive and usually horizontal
scalability never happens. So in reality, an enterprise blows 100k on two routers, they both flop because of some "firmware bug", and you're down.With this in mind, I am keen to understand how many implementations of packages such as Quagga and Zebra that the group use. With the likes of Vyatta being discussed, I am keen to see if products such as Quagga as still regularly used as it used to be.
I think that the original/upstream versions are out of date as compared to the one maintained by Vyatta. Or Google (for their MPLS processing needs). See http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50
We are actively supporting Quagga. We currently have a git repo at code.google.com with some BGP multipath updates, and are working with ISC to provide SQA on that branch. Hopefully more features will be forthcoming. Search quagga-dev if you're interested in more details.
Vyatta has done a lot of great work on Quagga, as have many others. It would be nice to see all the various useful branches merged into a cherry-picked mainline that would simplify the Quagga development community's lives considerably.
-Scott
We service most of the state's public schools and libraries (about
1000). Historically the CPE of choice was a small Cisco ISR (1600,
1700, 1800, and 1900 most recently). As bandwidth levels went up, and
Ethernet-based transport services became available, we started looking
and leveraging FOSS on commodity hardware to lower costs and move
services to the edge. Right now we have about 100 of the bigger
school districts being services by a Linux-based appliance running
XORP for its routing engine (we would have tried Quagga, but they
don't support multicast routing yet, nor does Vyatta).
It's been a learning experience. Most of the problems we ran into
have been resolved by tuning the kernel parameters to act more like a
router than a desktop or server. XORP itself has had a rocky ride
since we started, so the stability of the project has also been a
concern. Thankfully it is seeing somewhat active development again.
I will note that XORP is very touchy about how it's configured; if you
have well tested configuration templates it's fine, but it's very easy
to get it into a crashing state based on something as little the order
of configuration directives. For the most part once it's running it's
stable.
Modest hardware (3.2GHz dual-core Xeon, 2GB RAM, with 1GB tied up as a
RAM disk) seems to do the job well for 100 Mbps without much issue,
and that's with stateful firewall, and web content filtering in place.
Instead of doing it in-house we found a vendor in MA that was doing
something similar to what we wanted and had them develop a modified
version of their existing offering for us. The vendor is MECnet for
those interested.