Mailing List Archive: nsp: foundry

MLX vs. TurboIron and Vyatta

Index | Next | Previous | View Threaded

gregdok at gmail

Apr 7, 2012, 6:32 AM

Post #1 of 3 (369 views)
Permalink

MLX vs. TurboIron and Vyatta

Hi People,

I am part of a group who currently brainstorm for a new Internet
Connectivity solution.

We are currently evaluating two options: “mass switching and standalone
BGP” vs. “mass routing capacity”, which in everybody language would
translate to do we buy a bunch of MLX chassis or do we focus on pure
switching capacity aka TurboIron and use Vyatta on the side to do the BGP
traffic engineering.

We currently operate our AS on 10 different locations, from which four are
major locations. On each site we have 2 upstream with full BGP routing
table and 2 upstream with partial BGP table, plus local private peering of
interest and customer downstream. Our network is fully consistent and fully
meshed. Each router iBGP peer with each other and we use is-is within the
network for capacity management. The is-is bit is easy, as it should not
suffer of scale issues and we can do all the QoS within IronWare, though
eBGP is the limitation to go ahead considering a global 10*2*350k +
10*2*120k + 10*50k total BGP routes, although by design BGP will only
advertise best routes to iBGP peers.

Now, the big question is the financial investment of an MLX platform full
10 GbE vs. a switching capacity and a bunch of x86 boxes for the BGP job.
This is basically what retains us from just buying and going the easy way.
Though we understand, Vyatta is pretty stable nowadays and would just work
well with next-hop attribute as long as the network don’t change too often.

We are now actively looking for experience and tips with both Vyatta +
TurboIron or any experience that would retain or encourage us to going
ahead.

Cheers,

Greg

nick at foobar

Apr 7, 2012, 8:16 AM

Post #2 of 3 (350 views)
Permalink

Re: MLX vs. TurboIron and Vyatta [In reply to]

On 7 Apr 2012, at 14:32, Greg Dok <gregdok [at] gmail> wrote:
> Though we understand, Vyatta is pretty stable nowadays and would just work well with next-hop attribute as long as the network donā€™t change too often.

Vyatta uses quagga as its rib management engine. Not sure about the vyatta branch, but mainline quagga is-is support is flaky.

Turboirons are ok switches but they have very small port buffers. This may or may not be a concern for you.

Which solution is best for you depends on lots of details, eg your budget, expected traffic rates, support requirements, power and space issues, etc.

Nick

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

georgeb at gmail

Apr 7, 2012, 8:31 AM

Post #3 of 3 (355 views)
Permalink

Re: MLX vs. TurboIron and Vyatta [In reply to]

On the other hand, the TurboIron's are cut through switches, not store
and forward so they shouldn't NEED as large a buffer. And if you have
enough congestion to cause packet drop, you want TCP to back off a
little. They have enough buffer to handle most microburst.
conditions. Give them plenty of uplink and it shouldn't be a problem.
I generally use 20 to 40G of uplink capacity depending on the
downlink capability.

On Sat, Apr 7, 2012 at 8:16 AM, Nick Hilliard <nick [at] foobar> wrote:
> On 7 Apr 2012, at 14:32, Greg Dok <gregdok [at] gmail> wrote:
>> Though we understand, Vyatta is pretty stable nowadays and would just work well with next-hop attribute as long as the network don’t change too often.
>
> Vyatta uses quagga as its rib management engine. Not sure about the vyatta branch, but mainline quagga is-is support is flaky.
>
> Turboirons are ok switches but they have very small port buffers. This may or may not be a concern for you.
>
> Which solution is best for you depends on lots of details, eg your budget, expected traffic rates, support requirements, power and space issues, etc.
>
> Nick
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads