[f-nsp] foundry-nsp Digest, Vol 111, Issue 4

Sun Apr 8 12:43:04 EDT 2012

these two solutions don't even make sense.
you can use mlxe-4's and have pleanty of port density and if you use the M cards you will have plenty of future-proof features and able to carry full tables in your core.
turboiron is a transit switch or ospf core node, not a border router or isp core.
gateD kinda setups are for kids wih time to fix it and no customers expecting a reliable service.
if you can't swing the mlx's get some m7's off ebay.
if you need 10g then you really don't have a choice.
chad

Sent from my iPad

On Apr 7, 2012, at 12:02 PM, "foundry-nsp-request at puck.nether.net" <foundry-nsp-request at puck.nether.net> wrote:

> Send foundry-nsp mailing list submissions to
>    foundry-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://puck.nether.net/mailman/listinfo/foundry-nsp
> or, via email, send a message with subject or body 'help' to
>    foundry-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
>    foundry-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of foundry-nsp digest..."
>
>
> Today's Topics:
>
>   1. MLX vs. TurboIron and Vyatta (Greg Dok)
>   2. Re: MLX vs. TurboIron and Vyatta (Nick Hilliard)
>   3. Re: MLX vs. TurboIron and Vyatta (George B.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Apr 2012 15:32:43 +0200
> From: Greg Dok <gregdok at gmail.com>
> To: foundry-nsp at puck.nether.net
> Subject: [f-nsp] MLX vs. TurboIron and Vyatta
> Message-ID:
>    <CA+FupdSj+59UtDegsnjim8Yakb6yCMj94ig=xXcYvw5GA777=w at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20120407/9b91600e/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 7 Apr 2012 16:16:24 +0100
> From: Nick Hilliard <nick at foobar.org>
> To: Greg Dok <gregdok at gmail.com>
> Cc: "foundry-nsp at puck.nether.net" <foundry-nsp at puck.nether.net>
> Subject: Re: [f-nsp] MLX vs. TurboIron and Vyatta
> Message-ID: <5C31DD36-351A-4E66-B8E0-D6BB418A1C12 at foobar.org>
> Content-Type: text/plain;    charset=utf-8
>
> On 7 Apr 2012, at 14:32, Greg Dok <gregdok at gmail.com> 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
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 7 Apr 2012 08:31:10 -0700
> From: "George B." <georgeb at gmail.com>
> To: Nick Hilliard <nick at foobar.org>
> Cc: "foundry-nsp at puck.nether.net" <foundry-nsp at puck.nether.net>
> Subject: Re: [f-nsp] MLX vs. TurboIron and Vyatta
> Message-ID:
>    <CAJ2iOjS_mXE=yh1Y1CLAQCW2_W0w2VLdLUX37PcCMkUmG0BOXg at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> 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.org> wrote:
>> On 7 Apr 2012, at 14:32, Greg Dok <gregdok at gmail.com> 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.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> ------------------------------
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
> End of foundry-nsp Digest, Vol 111, Issue 4
> *******************************************

The information contained in this e-mail (including any attachments) is intended solely for the use of the intended recipient(s), may be used solely for the purpose for which it was sent, may contain confidential, proprietary, or personally identifiable information, and/or may be subject to the attorney-client or attorney work product privilege or other applicable confidentiality protections. If you are not an intended recipient please notify the author by replying to this e-mail and delete this e-mail immediately. Any unauthorized copying, disclosure, retention, distribution or other use of this email, its contents or its attachments is strictly prohibited.