The thing that surprises me is that there aren't any small
vendors offering fairly generic routing boxes, i.e. Intel-based
imagestream does this, afaik. not too familiar with their offerings
though.
I stand corrected. The following page comparing Cisco and Imagestream
is quite interesting.
http://www.imagestream.com/Cisco_Comparison.html
How many of you would buy an Imagestream box to evaluate for
your next network buildout?
--Michael Dillon
I intend to give them a serious look: they sound like
they could make good CPE for about 75% of my
customers...
(and of course, ssh v2 is a big plus 
-David Barak
-Fully RFC 1925 Compliant-
>imagestream does this, afaik. not too familiar with their offerings
though.I stand corrected. The following page comparing Cisco and Imagestream
is quite interesting.http://www.imagestream.com/Cisco_Comparison.html
How many of you would buy an Imagestream box to evaluate for
your next network buildout?
Imagestream uses Cisco list prices to sell their wares. No sane person that
buys from Cisco pays list price.
If one wants to complete with Cisco in a router business, they cannot claim
that it costs $3411 to get 2x T1 router by Cisco or that 7507 chassis is
$21,700.
Alex
That might be true, but have a look at the following article: they
outperform a 26xx. (Ok, I admit, a 26xx is not a power-monster, but it's
in the same price range as the small rebels)...
http://www.nwfusion.com/reviews/2003/0714rev.html
Kind Regards,
Frank Louwers
I've been managing a couple of these for a customer for a couple of years.
They work. The main problem I'd have with trying to use them on our
network is a lack of certain features I'm either used to or totally
dependent on in our ciscos.
i.e.
MPLSVPN (lack of it) would be a show stopper for us.
The gated-public they come with lacks features...AFAIK there is no support
for communities, prepending, etc.
Their current software image does include zebra now, but last I looked it
was not officially supported.
For a relatively simple end-user BGP customer, it works fine. And the
nice thing is it's PC-type hardware so if you need more RAM, just throw in
another dimm. No worries about the global routing table growing and
having to buy a bigger router because your year or two old one no longer
supports enough memory to hold full routes. I suspect the CPUs are
upgradable as well...but I've never actually touched the hardware...I've
always worked on it remotely.
OS-wise, it's a minimal Linux distribution with a menu interface (or you
can drop to a shell) and there is a little space on the flash to add
additional software if there something you want that they don't supply.
Have been discussing PCs for a bit but as yet not deployed one, as I understand
it a *nix based PC running Zebra will work pretty fine but has the constraints
that:
o) It has no features - not a problem for a lot of purposes
This isnt necessarily a problem for what I have in mind
o) On a standard PCI but your limit is about 350Mb, you can increase that to a
couple of Gb using 64-bit fancy thingies
For connecting to small IXPs, connecting customers, I dont need large amounts of
throughput.
o) This may be fixed but I found it slow to update the kernel routing table
which isnt designed to take 120000 routes being added at once
Icky, could perhaps cause issues if theres a major reconvergence due to an
adjacent backbone router failing etc, might be okay tho
o) As its entirely process based it will hurt badly in a DoS attack
This is a show stopper. I need the box to stay up in an attack and be responsive
to me whilst I attempt to find the source.
I'm not an expert in PC hardware, so I do struggle to work out the architecture
that I need and I'm sure its possible to build boxes that are optimised for this
purpose however I'm still not convinced that the box can keep up with the
demands of day to day packet switching - I'd like to hear otherwise tho.. has
anyone deployed a PC with Zebra that could switch a few Gbs, didnt suffer from
latency or jitter or fail under a DoS?
Steve
: o) This may be fixed but I found it slow to update the kernel routing table
: which isnt designed to take 120000 routes being added at once
:
: Icky, could perhaps cause issues if theres a major reconvergence due to an
: adjacent backbone router failing etc, might be okay tho
This is the general feeling on the Quagga list; that many limitations
are not the routing daemon(s) themselves but the underlying OS and
kernel.
james
Have been discussing PCs for a bit but as yet not deployed one, as I
understand it a *nix based PC running Zebra will work pretty fine but
has the constraints that:o) It has no features - not a problem for a lot of purposes
Which "no features"? I haven't played with zebra yet, but my
understanding is that it supports a large subset of the IOS BGP config
language including application of route-maps to incoming/outgoing routes,
and therefore things like prepending, setting metrics or preference, etc.
Am I mistaken?
o) On a standard PCI but your limit is about 350Mb, you can increase that to a
couple of Gb using 64-bit fancy thingies
The application where I'm caring for one of these is around a dozen T1's
to several different transit providers on a Gateway router. According to
Imagestream, this router can handle up to 1 OC3 at "wire speed". We're
obviously not pushing anywhere near that through it. The same customer
has a handful of Rebel routers used for T1s/ethernets within their
network.
o) This may be fixed but I found it slow to update the kernel routing table
which isnt designed to take 120000 routes being added at onceIcky, could perhaps cause issues if theres a major reconvergence due to an
adjacent backbone router failing etc, might be okay tho
I've never timed it, but I haven't noticed it taking routes any slower
than the ciscos I'm used to.
o) As its entirely process based it will hurt badly in a DoS attack
This is a show stopper. I need the box to stay up in an attack and be responsive
to me whilst I attempt to find the source.
But it's got so much more CPU power than comparably priced ciscos...and
most of the cisco gear I've worked on doesn't to terribly well under
DoS...so I don't see a distinction here. Either way, getting DoS'd sucks,
but I've never seen a DoS hit any of the Imagestreams, so I don't know how
it copes.
I'm not an expert in PC hardware, so I do struggle to work out the
architecture that I need and I'm sure its possible to build boxes that
are optimised for this purpose however I'm still not convinced that the
box can keep up with the demands of day to day packet switching - I'd
Their bigger routers, I'm pretty sure, have multiple PCI buses, so if you
wanted to push lots of traffic, careful planning of which bus you put each
card in may make a difference. Their tech support is pretty responsive,
so they'd be the place to go with technical/architectural questions.
Another nice feature is with iptables, they can now do stateful
firewalling / connection tracking.
It is my impression that Zebra is pretty feature-rich.
There are some things that are difficult for Zebra to do since they relate to (absent) capabilities in the host kernel, though; RFC 2385 requires the host to support the TCP MD5 Signature option, for example, and most do not.
Joe
: Which "no features"? I haven't played with zebra yet, but my
: understanding is that it supports a large subset of the IOS BGP config
: language including application of route-maps to incoming/outgoing routes,
: and therefore things like prepending, setting metrics or preference, etc.
: Am I mistaken?
Yes, all of that is supported & more:
zebra(config-router)# neighbor 1.1.1.1
advertisement-interval Minimum interval between sending BGP routing updates
interface Interface
peer-group Member of the peer-group
port Neighbor's BGP port
strict-capability-match Strict capability negotiation match
timers BGP per neighbor timers
transparent-as Do not append my AS number even peer is EBGP peer
transparent-nexthop Do not change nexthop even peer is EBGP peer
version Neighbor's BGP version
activate Enable the Address Family for this Neighbor
allowas-in Accept as-path with my AS present in it
attribute-unchanged BGP attribute is propagated unchanged to this neighbor
capability Advertise capability to the peer
default-originate Originate default route to this neighbor
description Neighbor specific description
distribute-list Filter updates to/from this neighbor
dont-capability-negotiate Do not perform capability negotiation
ebgp-multihop Allow EBGP neighbors not on directly connected networks
enforce-multihop Enforce EBGP neighbors perform multihop
filter-list Establish BGP filters
local-as Specify a local-as number
maximum-prefix Maximum number of prefix accept from this peer
next-hop-self Disable the next hop calculation for this neighbor
override-capability Override capability negotiation result
passive Don't send open messages to this neighbor
prefix-list Filter updates to/from this neighbor
remote-as Specify a BGP neighbor
remove-private-AS Remove private AS number from outbound updates
route-map Apply route map to neighbor
route-reflector-client Configure a neighbor as Route Reflector client
route-server-client Configure a neighbor as Route Server client
send-community Send Community attribute to this neighbor
shutdown Administratively shut down this neighbor
soft-reconfiguration Per neighbor soft reconfiguration
unsuppress-map Route-map to selectively unsuppress suppressed routes
update-source Source of routing updates
weight Set default weight for routes from this neighbor
James Edwards
Routing and Security
jamesh@cybermesa.com
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965
: Be real carfull with Zebra, I got stung big time !!!
What I run is actually Quagga, despite saying Zebra.
Would you share your experiences ?
James Edwards
Routing and Security
jamesh@cybermesa.com
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965
almost all times I hear people saying there is problem with Zebra or Quagga,
more than half of all times it is problem with their OS, not the daemon.
almost all times I hear people saying there is problem with Zebra or
Quagga,
more than half of all times it is problem with their OS, not the daemon.
... and we care because? the router is a black box. if the output is not
what is expected, it matters not why. though understandable, it is still not
acceptable. </imho>
paul
... and we care because? the router is a black box. if the output is not
what is expected, it matters not why. though understandable, it is still not
acceptable. </imho>
and you blame zebra ?
if an equipment / vendor you have on your network is not acceptable, do what is
acceptable such as (get another vendor|debug the problem|call the support) etc
> ... and we care because? the router is a black box. if the output is not
> what is expected, it matters not why. though understandable, it is still
not
> acceptable. </imho>
and you blame zebra ?
no, i blame the solution. if fans in my switch keep dying, i blame the
manufacturer of the switch for picking an unreliable fan manufactuer, not
the manufacturer of the fan alone.
if an equipment / vendor you have on your network is not acceptable, do
what is
acceptable such as (get another vendor|debug the problem|call the support)
etc
yes. i handle this by not using zebra/(.*)OS boxes for tasks that are better
handled by something else.
paul
no, i blame the solution. if fans in my switch keep dying, i blame the
manufacturer of the switch for picking an unreliable fan manufactuer, not
the manufacturer of the fan alone.
wrong. more than half of all problems i hear, the _fan_ is the OS or the
implementation by user, not zebra/quagga.
>
> no, i blame the solution. if fans in my switch keep dying, i blame the
> manufacturer of the switch for picking an unreliable fan manufactuer,
not
> the manufacturer of the fan alone.
wrong. more than half of all problems i hear, the _fan_ is the OS or the
implementation by user, not zebra/quagga.
that is exactly the way i meant it.
paul
Have been discussing PCs for a bit but as yet not deployed one, as I
understand it a *nix based PC running Zebra will work pretty fine but
has the constraints that:o) It has no features - not a problem for a lot of purposes
This isnt necessarily a problem for what I have in mind
It depends. Zebra/Quagga has lots of features, it just may be that these
aren't the features you want. At many cases, you can get a developer to
implement the features you need for half the cost of a proprietary router.
I would add, more importantly for nanog audience:
o) lack of unified tools to configure and manage:
Your average PC router is configured at least by:
* your distribution-based startup scripts
* your routing protocol daemon (gated/zebra/etc)
* linecard-specific tools (ethtool for linux)
* protocol-specific tools (br2684 for rfc1483 encaps, for example)
* eb/iptables to configure ACLs (or ipfw/ipf/pf)
* tc to configure QoS (or ALTQ)
Each of those tools has varied degrees of documentation, different
configuration interface, vastly different 'status' interface, different
support mailing lists, etc.
It is much easier for a given organization to find a cisco/juniper/etc
expert than to find someone who's experienced with Linux/FreeBSD network
toolchain, and I don't foresee that changing anytime soon.
o) On a standard PCI but your limit is about 350Mb, you can increase
that to a couple of Gb using 64-bit fancy thingiesFor connecting to small IXPs, connecting customers, I dont need large
amounts of throughput.
64/66 PCI hasn't been fancy for last 3 years.
On a single-processor P4/3ghz, I already can (and do:) route 400mbps of
DoS-like traffic (one packet per flow, small packets, 400kpps).
Of course, this is ridiculously low compared to current generation of
high-end routers, however, it has its niche (and see below for possible
scaling).
o) This may be fixed but I found it slow to update the kernel routing table
which isnt designed to take 120000 routes being added at onceIcky, could perhaps cause issues if theres a major reconvergence due to an
adjacent backbone router failing etc, might be okay tho
Actually, considering the CPU on common desktop and CPU on a RE on common
router (aka "you are reading this email on a machine with faster CPU than
fastest RE in your network"), PCs can do BGP much faster than
"hardware-based" routers (aka "forwarding ASICs don't run BGP"). As
result, BGP Zebra/Linux can take 100k routes in <10 seconds (haven't
measured exactly).
o) As its entirely process based it will hurt badly in a DoS attack
This is a show stopper. I need the box to stay up in an attack and be
responsive to me whilst I attempt to find the source.
Well, its not "process based", but it *is* "flow based". Yes, performance
suffers as packets/flow rate decreases, however, it doesn't suffer as bad
as other flow-based devices.
I'm not an expert in PC hardware, so I do struggle to work out the
architecture that I need and I'm sure its possible to build boxes that
are optimised for this purpose however I'm still not convinced that the
box can keep up with the demands of day to day packet switching - I'd
like to hear otherwise tho.. has anyone deployed a PC with Zebra that
could switch a few Gbs, didnt suffer from latency or jitter or fail
under a DoS?
It is not gbps that kill you, it is the pps (and/or new-flows-per-second).
Getting to 1mpps on a single router today will probably be hard. However,
I've been considering implementing a "clustered router" architecture,
should scale pps more or less linearly based on number of "PCs" or
"routing nodes" involved. I'm not sure if discussion of that is on-topic
here, so maybe better to take it offline.
This is exactly what Pluris PC-based proof-of-concept prototype did in 97.
PCs were single-board 133MHz P-IIs, running custom forwarding code on bare
metal, yielding about 120kpps per board, or 1.9Mpps per cage.
In the production box CPU-based forwarding was replaced with ASICs, 1Gbps
hybrid optical/electrical butterfly/hypercube interconnect was replaced
with 12Gbps optical hypercube interconnect, otherwise architecture was
unchanged. That was a total overkill which was one of the reasons the
company went down.
--vadim
There are so many many many legitimate things to blame Zebra for, and so
many more legitimate things to blame Linux for, that when you put the two
of them together there is no need to make up problems that aren't their
fault.
The reasons that PC routers bite have nothing to do with the fact that
they use PC hardware, the limitations of the PCI bus, or any other
nonsense like that. PC routers bite because of the software, pure and
simple. Raw forwarding performance is only a small component of a quality
router, the rest is SOFTWARE, SOFTWARE, and MORE SOFTWARE. Unfortunately,
software quality isn't easy to measure in numbers other than units sold.
On the topic of PC routers, I've fully given in to the zen of Randy Bush.
I FULLY encourage my competitor to use them.