On 9/26/2013 6:53 AM, Justin M. Streiner wrote:
> What flavor of multimode fiber are you dealing with? The answer and
> the distance you can run becomes substantially more important at 10G.
>
> Hopefully you're at least dealing with OM3. OM1/OM2 imposes distance
> limitations and you'll likely ne
On Fri, Sep 27, 2013 at 02:10:47AM -0400, Ryan McIntosh wrote:
> I don't respond to many of these threads but I have to say I've
> contested this one too only to have to beaten into my head that a /64
> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
> other protocols depend o
On Thu, 26 Sep 2013, Blake Pfankuch - Mailing List wrote:
To follow up, all of this fiber is mm and all light is sx to sfp.
Currently all 1gbit, but it will be repulled as 10gbit capable soon... I
guess I'm going to have to be a little less cheap and shoot for
something under $1000. I had an
On Sep 26, 2013, at 13:18 , Darren Pilgrim wrote:
> On 9/26/2013 1:07 PM, joel jaeggli wrote:
>>
>> On Sep 26, 2013, at 12:29 PM, Darren Pilgrim
>> wrote:
>>
>>> On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote:
sounds just like folks in 1985, talking about IPv4...
>>>
>>> The
BGP Update Report
Interval: 19-Sep-13 -to- 26-Sep-13 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS36998 63716 2.4% 34.2 -- SDN-MOBITEL
2 - AS15003 57887 2.1% 42.2 -- N
This report has been generated at Fri Sep 27 21:13:30 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
On Fri, Sep 27, 2013 at 2:11 PM, William Herrin wrote:
> On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter wrote:
>> Therefore, I don't see any reason to artificially inflate
>> the routing table by conserving, and then making
>> orgs come back for additional allocations.
>
> I'm not convinced of
> In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that
> 18619 ~40% announce only one prefix. given the distribution of prefix counts
> across ASNs it's quite reasonable to conclude that the consumption of
> routing table slots is not primarly a property of the number of p
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to bgp-st...@lists.ap
On Fri, Sep 27, 2013 at 1:04 PM, Randy Carpenter wrote:
>
>> There is no bit length which allocations of /20's and larger won't
>> quickly exhaust. It's not about the number of bits, it's about how we
>> choose to use them.
>
> True, but how many orgs do we expect to fall into that category? If th
On Sep 27, 2013, at 10:04 AM, Randy Carpenter wrote:
>
>> There is no bit length which allocations of /20's and larger won't
>> quickly exhaust. It's not about the number of bits, it's about how we
>> choose to use them.
>>
>> Regards,
>> Bill Herrin
>
> True, but how many orgs do we expect t
> There is no bit length which allocations of /20's and larger won't
> quickly exhaust. It's not about the number of bits, it's about how we
> choose to use them.
>
> Regards,
> Bill Herrin
True, but how many orgs do we expect to fall into that category? If the
majority are getting /32, and onl
On Fri, Sep 27, 2013 at 10:40 AM, Brandon Ross wrote:
> Okay, I'm just curious, what size do you (and other's of similar opinion)
> think the IPv6 space _should_ have been in order to allow us to not have to
> jump through conservation hoops ever again? 128 bits isn't enough, clearly,
> 256? 1k?
On 2013-09-27, at 10:40, Brandon Ross wrote:
> On Fri, 27 Sep 2013, Ryan McIntosh wrote:
>
>> It's a waste, even if we're "planning for the future", no one house
>> needs a /64 sitting on their lan.. or at least none I can sensibly
>> think of o_O.
>
> Okay, I'm just curious, what size do you
On Fri, 27 Sep 2013, Ryan McIntosh wrote:
It's a waste, even if we're "planning for the future", no one house
needs a /64 sitting on their lan.. or at least none I can sensibly
think of o_O.
Okay, I'm just curious, what size do you (and other's of similar opinion)
think the IPv6 space _should
On Thu, Sep 26, 2013 at 5:05 PM, Scott Brim wrote:
> Oh this sure will be fun. For a good time, see how GSMA handles connectivity
> with IPXs.
Hi Scott,
For those of us who aren't deeply engrossed in GSM mobile telecom,
would you offer a synopsis?
Thanks,
Bill Herrin
--
William D. Herrin ..
On Sep 26, 2013, at 1:43 PM, Randy Bush wrote:
> y'know, it's funny. there is a market in ipv4 space. there is no
> market in routing table slots. perhaps this is not conspiracy but
> rather the market is speaking.
That easily could be the case. So how well is has the current model
been work
A10 is in pretty early stages right now on DDoS , this may be a good thing if
you have time to wait and can help mold them a bit. They are still mostly
enterprise focused , not really carrier grade . Radware is a little further
along, but Arbor is king when it comes suitability for a carrier d
Hi,
Maybe you can see what A10 Networks is doing. They build a new product
dedicated to DDOS.
Regards
Fabien
Le 26 sept. 2013 à 18:47, Tempest a écrit :
> Doing a bunch of research, and I can't find a meaningful comparison of
> these two products. Work for a carrier, and I am looking at imp
I don't respond to many of these threads but I have to say I've
contested this one too only to have to beaten into my head that a /64
is "appropriate".. it still hasn't stuck, but unfortunately rfc's for
other protocols depend on the blocks to now be a /64..
It's a waste, even if we're "planning f
It's back with this: "Ben quite succinctly sums it up on a nanog mailing list,
“Your (the service provider) user is paying you to push packets. If that’s
causing you a problem, you either need to review your commercial structure
(i.e. charge people more) or your technical network design. Face th
21 matches
Mail list logo
