Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: foundry
Re: foundry-nsp Digest, Vol 111, Issue 4
 

Index | Next | Previous | View Flat


cparris at eexchange

Apr 8, 2012, 9:43 AM


Views: 307
Permalink
Re: foundry-nsp Digest, Vol 111, Issue 4

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" <foundry-nsp-request [at] puck> wrote:

> Send foundry-nsp mailing list submissions to
> foundry-nsp [at] puck
>
> 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
>
> You can reach the person managing the list at
> foundry-nsp-owner [at] puck
>
> 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>
> To: foundry-nsp [at] puck
> Subject: [f-nsp] MLX vs. TurboIron and Vyatta
> Message-ID:
> <CA+FupdSj+59UtDegsnjim8Yakb6yCMj94ig=xXcYvw5GA777=w [at] mail>
> 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>
> To: Greg Dok <gregdok [at] gmail>
> Cc: "foundry-nsp [at] puck" <foundry-nsp [at] puck>
> Subject: Re: [f-nsp] MLX vs. TurboIron and Vyatta
> Message-ID: <5C31DD36-351A-4E66-B8E0-D6BB418A1C12 [at] foobar>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 7 Apr 2012 08:31:10 -0700
> From: "George B." <georgeb [at] gmail>
> To: Nick Hilliard <nick [at] foobar>
> Cc: "foundry-nsp [at] puck" <foundry-nsp [at] puck>
> Subject: Re: [f-nsp] MLX vs. TurboIron and Vyatta
> Message-ID:
> <CAJ2iOjS_mXE=yh1Y1CLAQCW2_W0w2VLdLUX37PcCMkUmG0BOXg [at] mail>
> 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> 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
>
> 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.

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

Subject User Time
Re: foundry-nsp Digest, Vol 111, Issue 4 cparris at eexchange Apr 8, 2012, 9:43 AM

  Index | Next | Previous | View Flat
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.