On 17/Apr/15 15:05, Max Tulyev wrote:
> One more interesting thing.
>
> If you buy IP transit, mostly you are paying by exact bandwidth, per
> megabit. If you buy IX peering port, you are paying for port. This means
> Tranist ports are overloaded or close to it, while IX ports usually
> always ha
Doug Barton schreef op 18-04-15 om 01:52:
> Harley is correct that 192.0.1/24 is mentioned in 1166, but AFAICS after
> cursory examination it has fallen through the cracks since then.
It has been seen in the wild a few times though (for whatever reason...)
https://stat.ripe.net/192.0.1.0%2F24#ta
Harley is correct that 192.0.1/24 is mentioned in 1166, but AFAICS after
cursory examination it has fallen through the cracks since then. (Note,
this is not the same as 192.0.2/24, which has been updated in several
RFCs recently, including 6303 by Mark Andrews (cc'ed for his information).
I've
On Fri, Apr 17, 2015 at 11:13:11PM +0200, Marco Davids wrote:
> Marco Davids schreef op 17-04-15 om 23:08:
>
> > https://tools.ietf.org/html/rfc6333 ?
>
> Oh wait, that's 192.0.0.0/29, not 192.0.1.0/24...
192.0.1.0/24 sounds vaguely like something really old HP JetDirects
used as a "default IP"
Weird issues with console and various service...can someone contact me off
list?
BGP Update Report
Interval: 09-Apr-15 -to- 16-Apr-15 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS23752 291648 6.3%2430.4 -- NPTELECOM-NP-AS Nepal
Telecommunications Corporation, Intern
This report has been generated at Fri Apr 17 21:14:32 2015 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/2.0 for a current version of this report.
Recent Table History
Date
Marco Davids schreef op 17-04-15 om 23:08:
> https://tools.ietf.org/html/rfc6333 ?
Oh wait, that's 192.0.0.0/29, not 192.0.1.0/24...
--
Marco
smime.p7s
Description: S/MIME-cryptografische ondertekening
Wasn't (part) of this space assigned to RFC6333? Carrier Grade NAT and
stuff...
https://tools.ietf.org/html/rfc6333 ?
--
Marco
manning schreef op 17-04-15 om 22:45:
> nothing that is authoritative (anymore)… 1996-2000
>
> last century, 192.0.0.0/24 and 192.0.1.0/24 were identified as usable
nothing that is authoritative (anymore)… 1996-2000
last century, 192.0.0.0/24 and 192.0.1.0/24 were identified as usable address
blocks, post-CIDR testing/evaluation.
they were both earmarked for use in the (then) four new root servers (which
became J, K, L, and M)… they were
then supposed to
It is mentioned in RFC 1166 as "BBN-TEST-C". I suppose it's still not
publicly allocated.
On Fri, Apr 17, 2015 at 4:18 PM, Josh Luthman
wrote:
> No one?
>
> http://whois.arin.net/rest/net/NET-192-0-0-0-0/pft
>
>
> http://www.dslreports.com/forum/r28692406-Outgoing-traffic-to-192.0.1.0-port-1000-
No one?
http://whois.arin.net/rest/net/NET-192-0-0-0-0/pft
http://www.dslreports.com/forum/r28692406-Outgoing-traffic-to-192.0.1.0-port-1000-
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Fri, Apr 17, 2015 at 4:14 PM, Harley H wrote:
> Does
Jump the slightest bit ahead in the library:
https://tools.ietf.org/html/rfc5737
On Fri, Apr 17, 2015 at 1:14 PM, Harley H wrote:
> Does anyone know the status of this netblock? I've come across a malware
> sample configured to callback to an IP in that range but it does not appear
> to be rout
Does anyone know the status of this netblock? I've come across a malware
sample configured to callback to an IP in that range but it does not appear
to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any
whois information.
Thanks,
Harley
On Fri, Apr 17, 2015 at 3:17 PM, Joe McLeod wrote:
> Or you build the cable to fit the span. I must be getting old.
There's a "best of both worlds" version of this: buy lots of the
short-length cables (1 to 6 feet) and "cut down" longer cables where
the distance exceeds the short cables I can bu
> From: "Bob Evans"
> You must build them if you want the professional look. No way around that
> - unless you want to take up rack space with some sort of cable management
> wrapping system and that becomes a pain to make future changes or replace
> cables.
Re lacing is as much a pain (if you wa
On Fri, Apr 17, 2015 at 3:22 PM, Bob Evans wrote:
> You must build them if you want the professional look. No way around that
> - unless you want to take up rack space with some sort of cable management
> wrapping system and that becomes a pain to make future changes or replace
> cables.
>
>> Or
On Fri, Apr 17, 2015 at 3:23 PM, Justin Wilson - MTIN wrote:
> Copper and fiber patch panels are key. This way you can control the length
> from the patch to the device (router, switch,server).
>
Yeah, I am talking about just the runs in the rack - I don't see
a(nother) patch panel helping here
Copper and fiber patch panels are key. This way you can control the length
from the patch to the device (router, switch,server).
Justin
Justin Wilson j...@mtin.net
http://www.mtin.net Managed Services – xISP Solutions – Data Centers
http://www.thebrotherswisp.com Podcast about xISP topics
ht
You must build them if you want the professional look. No way around that
- unless you want to take up rack space with some sort of cable management
wrapping system and that becomes a pain to make future changes or replace
cables.
Thank You
Bob Evans
CTO
> Or you build the cable to fit the spa
Or you build the cable to fit the span. I must be getting old.
Joe
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Rafael Possamai
Sent: Friday, April 17, 2015 3:00 PM
To: North American Network Operators Group
Subject: Re: rack cable length
Hi Shawn,
If yo
Hi Shawn,
If you don't leave slack, you can't really pull the server out of the RU
for maintenance (hot swaps, etc). Your best choice is to purchase cable
management trays if that makes sense (Dell servers usually come with
those). Otherwise you just need to deal with the loops and whatnot the
be
Cables should be within 2 feet of the total distance, if you order a stack
several sizes too long then add something like above/below the switch:
http://www.chatsworth.com/products/cable-management/horizontal-cable-management/
Slack should never be stored in the vertical, only in the horizontal.
This is probably a stupid question, but
We've got a few racks in a colo. The racks don't have any decent cable
management (square metal holes to attach velcro to). We either order
cable too long and end up with lots of loops which get in the way (no
place to loop lots of excess really) or too
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,
CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to bgp-st...@lists.apnic.net
For hi
Peering and peering on an exchange are two different things. Peering at an
exchange has several benefits other than the simple cost of transit. If you
are in a large data center which charges fees for cross connects a single cross
connect to an exchange can save you money.
Peering can also be
One more interesting thing.
If you buy IP transit, mostly you are paying by exact bandwidth, per
megabit. If you buy IX peering port, you are paying for port. This means
Tranist ports are overloaded or close to it, while IX ports usually
always have some extra free capacity.
In practice, this mea
E, countering that if transit is cheaper than peering, you should talk to
your IX. The effects of posting when I haven't been awake for hardy more than
ten minutes
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
- Original Message -
From: "Mike
Transit should cost more than peering and should never cost little more than
the cost of a cross connect or a switch, given the load of additional
responsibilities. I counter that if peering is cheaper than transit, you need
to talk to your IX about it's cost models.
-
Mike Hammett
In
Hello,
I'm thinking of buying a Juniper EX8208 to serve as the core L3 switch
on an collapsed campus network (faculty, academia).
Rough figures: around 6,000 eyeballs, up to around 10,000 MACs, spread
over some 30 buildings of varying size. OM2/OM3 fiber from the buildings
to the core, using 1Gb
On 16/Apr/15 17:10, Edward Dore wrote:
>
> I don't have any quantifiable data on what has happened to IP transit
> costs over the same period, but for a point comparison I'd say that
> off the top of my head you can get a 1G CDR on a 10G port from a
> tier-1 provider in London for approximately t
For sure, that's the main reason of peering, not a cost saving ;)
On 04/15/15 23:12, Grzegorz Janoszka wrote:
> Please keep in mind that some companies peer despite it offers no
> savings for them and at the end of the day it might be even more
> expensive. They do it because of performance and re
If you have so much difference in price of IX connectivity (in general,
including cabling, DWDM to one of major IX, colo, etc) - this only mean
you should have a long talk with your current IP transit sales. Or just
change it to another one.
On 04/15/15 21:45, Mike Hammett wrote:
> (Reply to threa
33 matches
Mail list logo
