New vyatta-nsp list
Hello All: There is a new Vyatta NSP list, sponsored by Jared on puck.nether.net. If you are running Vyatta hardware and/or software please join and share your questions, comments and experiences. http://puck.nether.net/mailman/listinfo/vyatta-nsp Regards, Mike
I had a Juniper sales rep laugh at me when I asked for a comparison of their SRX series to Vyatta, as he had "never heard of Vyatta." Anyone have an opinion on Vyatta's software/appliances? Specifically their 3520 ? On 05/24/2011 10:59 AM, Michael K. Smith - Adhost wrote:
Hello All:
There is a new Vyatta NSP list, sponsored by Jared on puck.nether.net. If you are running Vyatta hardware and/or software please join and share your questions, comments and experiences.
http://puck.nether.net/mailman/listinfo/vyatta-nsp
Regards,
Mike
On May 24, 2011, at 12:56 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 24 May 2011 14:42:02 CDT, Rhys Rhaven said:
I had a Juniper sales rep laugh at me when I asked for a comparison of their SRX series to Vyatta, as he had "never heard of Vyatta."
"Danger, Will Robinson! Danger!" :)
it's a pretty short drive to redwood city from sunnyvale.
On Tue, May 24, 2011 at 12:42 PM, Rhys Rhaven <rhys@rhavenindustrys.com> wrote:
I had a Juniper sales rep laugh at me when I asked for a comparison of their SRX series to Vyatta, as he had "never heard of Vyatta."
Anyone have an opinion on Vyatta's software/appliances? Specifically their 3520 ?
On 05/24/2011 10:59 AM, Michael K. Smith - Adhost wrote:
Hello All:
There is a new Vyatta NSP list, sponsored by Jared on puck.nether.net. If you are running Vyatta hardware and/or software please join and share your questions, comments and experiences.
http://puck.nether.net/mailman/listinfo/vyatta-nsp
Regards,
Mike
Well, with the new Juniper entry level MX devices out now, the cost difference between Vyatta and Juniper is probably insignificant now, and with Juniper devices, you have much higher PPS rate. Granted, I have Vyatta devices now doing BGP, and they work fine, but you can't argue that ASICs can forward much faster than a general purpose CPU :) To each their own -- Brent Jones brent@servuhome.net
On May 24, 2011, at 2:26 PM, Brent Jones wrote:
Well, with the new Juniper entry level MX devices out now, the cost difference between Vyatta and Juniper is probably insignificant now, and with Juniper devices, you have much higher PPS rate.
Granted, I have Vyatta devices now doing BGP, and they work fine, but you can't argue that ASICs can forward much faster than a general purpose CPU :)
To each their own
So the applications where I've deployed vyatta have a lot to do with having a topological need for a router/firewall/ipsec tunnel termination point in a VM. Im some cases I'm not particularly proud of the results. but it's not a use case that juniper presently addresses. devices down in srx210/240/ja2320 land are a rather different keetle of fish in comparision to an mx80/mx240.
-- Brent Jones brent@servuhome.net
On Tue, May 24, 2011 at 5:26 PM, Brent Jones <brent@servuhome.net> wrote:
Well, with the new Juniper entry level MX devices out now, the cost difference between Vyatta and Juniper is probably insignificant now, and with Juniper devices, you have much higher PPS rate.
Granted, I have Vyatta devices now doing BGP, and they work fine, but you can't argue that ASICs can forward much faster than a general purpose CPU :)
To each their own
-- Brent Jones brent@servuhome.net
I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta isn't capable of high-end performance. http://download.intel.com/embedded/processor/solutionbrief/322973.pdf
I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta isn't capable of high-end performance.
http://download.intel.com/embedded/processor/solutionbrief/322973.pdf
aeh - mpps - mega packets per second - is really low. and the gbps scale in figure 4 is wrong - factor 10 to high. 1gige linerate: 1,9mpps 10gige linerate: 19mpps and intel is proud to achieve 1,6mpps at 2 10gige cards? I have seen higher values at pc hardware - but still not compareable to asics. Kind regards, Ingo Flaschberger
On 5/24/11 3:25 PM, Ingo Flaschberger wrote:
I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta isn't capable of high-end performance.
http://download.intel.com/embedded/processor/solutionbrief/322973.pdf
aeh - mpps - mega packets per second - is really low. and the gbps scale in figure 4 is wrong - factor 10 to high.
1gige linerate: 1,9mpps 10gige linerate: 19mpps
and intel is proud to achieve 1,6mpps at 2 10gige cards? I have seen higher values at pc hardware - but still not compareable to asics.
Intel is capable of more. See slide 29 from this presentation at IDF 2011 in Beijing. "New System Approach to Network Platform Architecture" Yang Tao & Fu Lizheng https://intel.wingateweb.com/bj11/scheduler/downloadFileCounting.do?sesfid=6DD9DF1ECE719E98767AD5F48E55C119&abb=7638E050E5ED339FE5FB858DB2C16FE9&fn=3649EFF0820DCB079BC4C8A0B1A45ECFDA3BEED134DD5284300AD0E9EA5C516A
<nitpicking>
1gige linerate: 1,9mpps 10gige linerate: 19mpps
and intel is proud to achieve 1,6mpps at 2 10gige cards? I have seen higher values at pc hardware - but still not compareable to asics.
If you're going to specify line rate pps, please get the figures right. Line rate on GigE with minimum packet size (84 bytes including Ethernet headers, FCS, 8 byte preamble and 12 byte IFG) is: 1,000,000,000 / (84 * 8) = 1.488 Mpps </nitpicking> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Tue, May 24, 2011 at 2:54 PM, Jon Bane <jon@nnbfn.net> wrote:
On Tue, May 24, 2011 at 5:26 PM, Brent Jones <brent@servuhome.net> wrote:
Well, with the new Juniper entry level MX devices out now, the cost difference between Vyatta and Juniper is probably insignificant now, and with Juniper devices, you have much higher PPS rate.
Granted, I have Vyatta devices now doing BGP, and they work fine, but you can't argue that ASICs can forward much faster than a general purpose CPU :)
To each their own
-- Brent Jones brent@servuhome.net
I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta isn't capable of high-end performance.
http://download.intel.com/embedded/processor/solutionbrief/322973.pdf
The graphs show near 100% CPU usage at small packet sizes, and low PPS. That would lead to a pretty easy to launch DDoS against a software based router platform. Since there isn't a separation between control plane/forwarding plane, an attacker could trivially take you offline. I'd imagine due to the nature of x86 platform, being interrupt based and forwarding table residing in memory the CPU has to access, theres a finite amount you can scale this without risking big disruptions from a relatively small DDoS. Not saying software platforms can't achieve good throughput, there has to be a realization of the limits of the platform, and when it shouldn't be used. Again, I personally use the Vyatta commercial software, and it works great, so I'm not knocking it. But I wouldn't consider it high-end performance when a few million PPS can lead to service disruptions. -- Brent Jones brent@servuhome.net
The graphs show near 100% CPU usage at small packet sizes, and low PPS. That would lead to a pretty easy to launch DDoS against a software based router platform. Since there isn't a separation between control plane/forwarding plane, an attacker could trivially take you offline. I'd imagine due to the nature of x86 platform, being interrupt based and forwarding table residing in memory the CPU has to access, theres a finite amount you can scale this without risking big disruptions from a relatively small DDoS.
Not saying software platforms can't achieve good throughput, there has to be a realization of the limits of the platform, and when it shouldn't be used. Again, I personally use the Vyatta commercial software, and it works great, so I'm not knocking it. But I wouldn't consider it high-end performance when a few million PPS can lead to service disruptions.
-- Brent Jones brent@servuhome.net
Every tool has its use. Also, they have several different sized appliances. How much CPU use you get depends on how many cores you throw at the problem. They can use multiple cores/processors. The result given in one test might not match someone else's test if they have higher end hardware, maybe better than the appliances Vyatta ships. But the primary point I am trying to make is if you have an office with sub-gigabit connectivity and you need NAT and firewalling and VPNs, it might be a very cost-effective solution. It might not be a good solution in a different environment. It is sort of like pointing out that your neighbor's Accord doesn't have the performance characteristics of a Ferrari but your neighbor only drives in rush hour on roads with a maximum speed of 65 MPH. The Ferrari would cost much more money, cost more to support over time, and not get him to work any faster. If one is never going to pass enough traffic to get anywhere near the maximum performance of the unit anyway, why spend so much more money? Besides, on most integrated firewall/NAT/VPN units I have used in the past, I have run them out of CPU from VPN and NAT long before they ever reached their maximum traffic throughput.
On May 24, 2011, at 7:52 PM, George Bonser wrote:
The graphs show near 100% CPU usage at small packet sizes, and low PPS. That would lead to a pretty easy to launch DDoS against a software based router platform. Since there isn't a separation between control plane/forwarding plane, an attacker could trivially take you offline. I'd imagine due to the nature of x86 platform, being interrupt based and forwarding table residing in memory the CPU has to access, theres a finite amount you can scale this without risking big disruptions from a relatively small DDoS.
Not saying software platforms can't achieve good throughput, there has to be a realization of the limits of the platform, and when it shouldn't be used. Again, I personally use the Vyatta commercial software, and it works great, so I'm not knocking it. But I wouldn't consider it high-end performance when a few million PPS can lead to service disruptions.
-- Brent Jones brent@servuhome.net
Every tool has its use. Also, they have several different sized appliances. How much CPU use you get depends on how many cores you throw at the problem. They can use multiple cores/processors. The result given in one test might not match someone else's test if they have higher end hardware, maybe better than the appliances Vyatta ships.
It's actually rather hard with current pc hardware to get to multiple cores engaged in paralell per input interfaces. while you can plan for various cases the the one to account for is the small packet performance not overwhelming the capabilities of a single cpu core.
But the primary point I am trying to make is if you have an office with sub-gigabit connectivity and you need NAT and firewalling and VPNs, it might be a very cost-effective solution. It might not be a good solution in a different environment. It is sort of like pointing out that your neighbor's Accord doesn't have the performance characteristics of a Ferrari but your neighbor only drives in rush hour on roads with a maximum speed of 65 MPH. The Ferrari would cost much more money, cost more to support over time, and not get him to work any faster.
If one is never going to pass enough traffic to get anywhere near the maximum performance of the unit anyway, why spend so much more money? Besides, on most integrated firewall/NAT/VPN units I have used in the past, I have run them out of CPU from VPN and NAT long before they ever reached their maximum traffic throughput.
Every tool has its use. Also, they have several different sized appliances. How much CPU use you get depends on how many cores you throw at the problem. They can use multiple cores/processors. The result given in one test might not match someone else's test if they have higher end hardware, maybe better than the appliances Vyatta ships.
It's actually rather hard with current pc hardware to get to multiple cores engaged in paralell per input interfaces. while you can plan for various cases the the one to account for is the small packet performance not overwhelming the capabilities of a single cpu core.
Not anymore. Linux will do processor per flow and it will remember which processor handed it traffic outgoing and try to route the reply back to the same CPU so you reduce cache misses. If you have multiple queues on the NICS, multiple CPUs can be operating on the NIC at the same time. The current servers we are using in production have eight queues, the older ones had four. So I can have eight different cores handing traffic to the NIC and the driver remembers which CPU it was and when a packet is received on a flow, sends the interrupt to the CPU that started it. But again, if you have a 10 or a 100 meg link into an office, I don't care how small the packets are, a linux box will handle the traffic just fine. Sure, it isn't going to saturate a 10G interface and do firewalling and VPN and NAT but that isn't what we are talking about here. We are talking average office connectivity. The firewall to the WAN. REF: http://lwn.net/Articles/382428/ but it has come a long way in the past year.
On Fri, May 27, 2011, George Bonser wrote:
It's actually rather hard with current pc hardware to get to multiple cores engaged in paralell per input interfaces. while you can plan for various cases the the one to account for is the small packet performance not overwhelming the capabilities of a single cpu core.
Not anymore. Linux will do processor per flow and it will remember which processor handed it traffic outgoing and try to route the reply back to the same CPU so you reduce cache misses.
FreeBSD is doing much the same, both for TCP flows and for packet routing. The real fun will be when open source freebsd/linux stops trying to do per-flow tracking and optimises their forwarding paths. From what I've heard on the lists, NICs are certainly doing small packet linerate now. Adrian
participants (11)
-
Adrian Chadd -
Brent Jones -
George Bonser -
Ingo Flaschberger -
Joel Jaeggli -
Jon Bane -
Michael K. Smith - Adhost -
Rhys Rhaven -
Robert Bays -
sthaug＠nethelp.no -
Valdis.Kletnieks＠vt.edu