Re: People trying to sell "ARIN Leads"

[Rob Seastrom]

On Apr 8, 2022, at 19:01, John Curran  wrote:
> 
> Please forward each solicitation (in full with headers) to us via 
> 
> 
> (Unique emails that are only used in the Whois entry are the easiest 
> violations to pursue by far - so reporting such activity can make a huge 
> difference.)

Wouldn’t hurt to associate that email (and perhaps some more honeypot addresses 
at other domains with some orgids and assign them some resources.  Might as 
well cut out the middleman and have the violators rat themselves out…

-r

Sent from my iPad

Re: People trying to sell "ARIN Leads"

[Rob Seastrom]

> On Apr 8, 2022, at 2:40 PM, na...@jima.us wrote:
> 
> Of course, plausible deniability goes out the window when you receive sales 
> emails on an address that ONLY exists in ARIN Whois.
> 
> But no one would put a "canary trap" email in ARIN Whois...right?

I know of nobody who would do any such thing.  ;-)

-r

Re: Non-default X.509 certs on EdgeOS?

[Rob Seastrom]

> On Dec 31, 2020, at 9:08 AM, Brielle  wrote:
> 
> Don’t just replace the lighttpd cert files anymore - has been obsolete way of 
> doing it for a looong time.

Guilty.  Thanks for the clue; I had literally no idea that things had evolved 
(and honestly, hadn't done much to my config other than opening ports and 
changing tunnel endpoints since I got one of the very first er-lites back in 
2013).

I've been told to move to 2.x for a while.  Guess I probably ought to do that.

-r

Non-default X.509 certs on EdgeOS?

[Rob Seastrom]

I realize that Ubiquiti may be in the same “too ashamed to talk publicly about 
it” bucket as Mikrotik, so feel free to email me off list instead of replying 
publicly - is anyone else here running non-default x.509 certs for the web GUI 
on the Ubiquiti EdgeRouter? [*]

I thought I had a fairly bulletproof recipe, sticky across more than a year of 
reboots, but on a recent power outage somehow things reverted to the factory 
self-signed cert.  ER4 still on EdgeOS 1.x.

Any thoughts from people who are also doing this would be appreciated.

-r

[*] - ER4 is on a residential connection, housekeeping raspi keeps DNS updated 
with current external IP address.  If we use ping to monitor in Nagios, in the 
event of a power event when someone else gets our old address we get a false 
service-ok alert, so instead we allow only the monitoring system to touch the 
otherwise-unused web gui on the external interface, and look for the CN to be 
what we’re expecting.  Works great, so long as the cert I put there stays...

Sent from my iPad

Re: Cable Company Hotspots

[Rob Seastrom]

On Nov 22, 2020, at 12:42, Lady Benjamin PD Cannon  wrote:
> 
> Rod, that’s exactly how they are delivering it. Unclear wether it’s over a 
> separately provisioned bandwidth channel, or wether it shares the aggregate 
> capacity of the HFC.

It shares the aggregate bandwidth of the HFC but not your contracted bandwidth. 
 Itmight be possible, but its extremely unlikely, to dedicate downstream or 
particularly upstream DOCSIS channels for this, and if you’re running docsis 
3.1 “channel” takes on a rather different shade of meaning anyway.

This is done with “service flows” which are part of the docsis spec.  They’re 
more like CAR with an ACL than DSCP.  Your cable modem already has at least 
four service flows defined in its profile:  one each for upstream and 
downstream, cablemodem management and contracted-bandwidth commodity internet.  
 If there is a built in phone jack (NANOG would call this an ATA, but the 
cablelabs term for it is an MTA or eMTA) then add a couple of more flows to it 
for the voip.  There could be still more; uses are up to your imagination.

I haven’t seen better than 10-20m service flows for guest wifi...

Shared vs dedicated wifi radio for guest would be dependent on the CPE.  I 
believe they are mostly shared, but my information is dated at this point and 
radios have gotten stupid cheap in the meantime.

Likewise, backhaul technology is implementation dependent; L2TP is what I’ve 
generally seen, not GRE, but again that info is five years out of date at this 
point.

So in short, assuming minimal interference and good wifi config (which may be a 
lot to ask in some environments) someone running speedtest on the guest wifi 
should have almost no effect on your contracted network performance, modulo any 
timing effects of the docsis channel transmission time slot allocator.

HTH,
-r

Sent from my iPad

Re: crypto frobs

[Rob Seastrom]

> On Mar 23, 2020, at 8:48 PM, William Herrin  wrote:

>> If they *do* steal both,
>> they can bruteforce the SSH passphrase, but after 5 tries of guessing
>> the Yubikey PIN it self-destructs.
> 
> What yubikey are you talking about? I have a password protecting my
> ssh key but the yubikeys I've used (including the FIPS version) spit
> out a string of characters when you touch them. No pin.

https://www.yubico.com/products/identifying-your-yubikey/ 


The (presumably) Yubico OTP/OATH/HOTP string from a Yubikey that you may have 
picked up six years ago on a lark  doesn’t even begin to scratch the surface.

The integration with FIDO2 in the low-end models in OpenSSH 8.2 in particular 
is very spiffy (and not to be confused with PIV or OpenPGP mode.

-r

Re: Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit

[Rob Seastrom]


>> On Jan 6, 2020, at 10:30, William Herrin  wrote:
> 
>> - Va Personal Property Tax Recovery (1.8%)

> If it's not written in to your contract, it's a breach of contract. Either 
> way it's a deceitfully imposed surcharge, not a state tax. Virginia does not 
> tax the sale of services like transit and colo. More, the only personal 
> property tax I've heard of in Virginia is on motor vehicles.

Hi Bill,

It’s called “business tangible personal property tax”, and it’s technically 
levied by the counties, not by the state (although authorized by the 
legislature, as all local government activities must be in a Dillon’s Rule 
state).

Loudoun’s page on this (chosen at random because I live here... and can see The 
Cloud’s Cloud from my house) is at 
https://www.loudoun.gov/1556/Business-Tangible-Personal-Property-Tax

-r

Re: DOCSIS 3.1 upstream

[Rob Seastrom]

> On Apr 20, 2016, at 6:12 PM, Jean-Francois Mezei 
> <jfmezei_na...@vaxination.ca> wrote:
> 
> On 2016-04-20 13:09, Rob Seastrom wrote:
> 
>> Going to D3.1 in a meaningful way means migrating to either a mid-split at 
>> 85 MHz or a high split at 200 MHz 
> 
> Thanks. This is what I expected. But in the past, the canadian cablecos
> had argued that removing the 42mhz upstream limitation was a huge
> endeavour (they have to convicne CRTC to keep wholesale rates up, so
> create artificial scarcity by claiming that replacing all those 42mhz
> repeaters would cost a fortune, so they have to do node splits instead.

In my opinion, that fails the sniff test.  I don't have any particular 
budgetary information but I have a really hard time believing that pervasive 
node splits are cheaper than fixing the plant's US/DS splits.

By the way, just as one typically finds downstream DOCSIS channels in the 
600-ish MHz range because that's the space that became freshly available when 
the plant got upgraded from 400 MHz to 800 MHz, one is likely to find that the 
'fat' D3.1 OFDM upstream channels in the freshly-freed-up space that comes from 
doing the split realignment.  Remember that you need to keep the old upstreams 
in order to support all the old crufty D2.0 and D3.0 (and, sadly, probably the 
odd D1.1) modems out there.


> Arguing at CRTC is all about finding out what incumbent statements are
> just spin and which are true.
> 
> Thanks for the links as well.é
> 
>> RFoG is its own kettle of fish.  Getting more than one channel on upstream 
>> for RFoG is hard. 
> 
> But they can allocate a single very big channel, right ?  Or did you
> mean a single traditional NTSC 6mhz channel ?

They can allocate a single very big channel, but unlike QAM modulation, with 
OFDM you can have multiple stations transmitting at the same time on the same 
channel.  So if anything, the optical beat interference from having more than 
one laser on at once is likely to be worse (for some values of worse - I don't 
know of anyone labbing such a thing up and trying to characterize just how bad 
it gets how fast with multiple transmitters - it might become intolerable with 
2 on and it might not).  I ran this past a colleague and he said "ew why 
would anyone do D3.1 over RFoG?".  I think that pretty much sums it up.

My personal opinion is that two-way RFoG is a super bad idea, but one-way RFoG 
on a WDM-separated channel to support legacy QAM (with PON for your high speed 
data) is OK, with the caveat that if you want two-way settop boxes, you're 
gonna have to figure out how to have your STBs speak Ethernet or MoCA or 
something to get out via your commodity high speed data connection.  The latter 
is the way that FiOS does it.

-r

Re: DOCSIS 3.1 upstream

[Rob Seastrom]

> On Apr 14, 2016, at 10:43 PM, Jean-Francois Mezei 
>  wrote:
> 
> Also, have cablecos with such limits for upstream begun to upgrade the
> cable plant to increase the upstream bandwidth ? Canadian cablecos have
> told the regulator it would be prohibitively expensive to do so, but
> incumbents tend to exagerate these things when it is convenient. (they
> can then claim higher costs/congestion/need for node splits which
> increates regulated wholesale rates).

Going to D3.1 in a meaningful way means migrating to either a mid-split at 85 
MHz or a high split at 200 MHz (117 MHz is in the spec but I've never heard 
anyone talk about it).  It is not uncommon to see space (both for the upstream 
and downstream) freed up by sunsetting analog video channels.  Yes, one has to 
do a truck roll and swap out amplifiers etc. but that is relatively 
straightforward.  The "guts" pop out of the enclosure that hangs from the 
messenger wire and are then replaced.  You don't need to actually put a wrench 
on a coax connector in order to do this.  There may need to be plant 
rebalancing (checking and possibly replacing tilt compensators) but that's 
something that should be happening on an annual basis or perhaps more often, 
depending on local practice.

Fiber nodes are similar in terms of work to swap them out, though they may be 
more modular inside.

Amplifier insides:  
https://www.arris.com/globalassets/resources/data-sheets/starline-series-ble100-1-ghz-line-extender-data-sheet.pdf
Fiber node insides:  
https://www.arris.com/globalassets/resources/data-sheets/sg4000-modular-4x4-node-data-sheet.pdf

Passives (splitters, directional taps, terminators, and the like) are 
bidirectional and typically do not need to be replaced.

Possibly useful reading for folks who want an overview of how it all goes 
together:  
http://www.cablelabs.com/wp-content/uploads/2014/12/DOCSIS3-1_Pocket_Guide_2014.pdf

Without having read the Canadian cable providers' representations to the CRTC I 
am ill-equipped to pass judgemenent on them, but in my personal opinion any 
discussion of "D3.1 deployment" that doesn't plan for a refactoring of splits 
is a bit dishonest.


> And would it be correct that in RFoG deployment, the 42mhz limit
> disapears as the customer equipment talks directly tothe CMTS over fibre
> all the way ?

RFoG is its own kettle of fish.  Getting more than one channel on upstream for 
RFoG is hard.  There's a scheduler for transmitting on individual RF channels, 
but not for the upstream laser, so you could have two lasers coming on at the 
same time when two cablemodems (assume legacy D3.0 for a moment) transmit 
simultaneously on 19.40 MHz and 30.60 MHz - in an HFC plant where the mixing 
happens between two different radio frequencies in a copper wire and then feeds 
an single upstream fiber node, one doesn't have this problem.

-r

Re: Netflix stuffing data on pipe

[Rob Seastrom]

I haven't done packet dumps to verify the behavior (too busy catching up on 
holiday email) but I can't help but wonder if IW10 (on by default in FreeBSD 10 
which I believe might be what Netflix has underneath) is causing this problem, 
and that maybe a more gentle CWND ramp-up (or otherwise tweaking the slow start 
behavior) for prefixes that are known to be in networks with weak hardware 
might be a good choice.

Of course this would be a change on Netflix's end...  as for things the ISP 
could do to alleviate the problem the answer is always "sure, but it'll cost 
ya".

-r


> On Jan 4, 2016, at 3:11 AM, Pete Mundy  wrote:
> 
> 
> Very succiently put, Owen!
> 
> I concur.
> 
> Is anything the ISP could avoid to alleviate this occurrence, or is it 
> entirely a 'server-side' issue to resolve?
> 
> Pete
> 
> 
>> On 4/01/2016, at 8:42 pm, Owen DeLong  wrote:
>> 
>> As I understand it, the problem being discussed is an oscillation that is 
>> created when the reaction occurs faster than the feedback resulting in a 
>> series of dynamically increasing overcompensations.
>> 
>> Owen

Re: announcement of freerouter

[Rob Seastrom]

> On Dec 29, 2015, at 4:08 AM, Josh Reynolds  wrote:
> 
> It wasn't about trolling, it was about legitimate prior art and reasonably
> so. Also, there's potentially a confusing association between the two.
> 
> I'm glad the terminology was removed.


Since it's an operating system for routing IP, maybe they could call it "IP 
operating system", styled Ios, to prevent confusion with IOS and iOS.

Lawyers gotta eat too...

-r

Re: Broadband Router Comparisons

[Rob Seastrom]

> On Dec 23, 2015, at 10:38 PM, Lorell Hathcock  wrote:
> 
> That's a good troubleshooting technique when the customer is cooperative and 
> technically competent.

... and has ethernet on anything in the house, which is increasingly a bad 
thing to rely on.  Got an iPad, a smart phone, and a MacBook Air (any 
revision)?  Two of the three have substantially no support for hardwired 
Ethernet.  The third requires an external USB adaptor.  "Go out and buy this 
$24 gizmo so we can confirm that your $29 router/wireless device is indeed 
crap" is a hard thing to get most people to do.

-r

Multi-core clamp on ammeter

[Rob Seastrom]

Hi folks,

I own a Megger MMC850 which will read amps in a multi-core cable, such as the 
10 gauge SEOOW cable one often finds feeding rack PDUs.

Datasheet here:  http://www.mouser.com/ds/2/263/MMC850_DS_en_V02-15853.pdf

Apparently they've been discontinued.  Pity.

Anyone know of a suitable replacement?  I need more.

-r

Re: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6

[Rob Seastrom]

Guarantee there's no BLISS-32 on Johnny's machine.  The source to the
LAT software he's talking to *may* be in BLISS-36.  It's more likely in
MACRO-10.

-r (does this gray hair make me look old?)

George Michaelson g...@algebras.org writes:

 Dec gave you the source on Microfiche. If you want to change LAT just read,
 and find your Bliss32 compiler.

 On Mon, Jun 29, 2015 at 9:04 PM, Scott Whyte swh...@gmail.com wrote:



 On 6/29/15 20:17, Johnny Eriksson wrote:

 Javier Henderson jav...@kjsl.org wrote:

  Or XNS.  On the other hand, people did have a nice career with

 SNA...but they weren't trying to push packets over the

 LAT


 .daytime
 Monday 29-Jun-2015 20:10:46

 .pjob
 Job 3 at ODEN   User BYGG   [10,335]   TTY4

 .where tty4
 LAT PC78(LATD for FreeBSD) TTY4

 Is there anyting wrong with LAT?


 err, its been awhile.  Doesn't LAT have a 1 sec timeout that's not
 configurable?


  -jav


 --Johnny

Re: Whats' a good product for a high-density Wireless network setup?

[Rob Seastrom]

Stephen Satchell l...@satchell.net writes:

 ... They just couldn't believe that 300 people could max out their system
 ...
 Last year, the group AVERAGED four devices each.

A *camping* event that I go to, that is by and large not a
technology-oriented consituency, averaged 2.6 devices per
attendee.

-r

Re: Anycast provider for SMTP?

[Rob Seastrom]

Joe Abley jab...@hopcount.ca writes:

   http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02

 There are privacy concerns, here. But we might posit that you've
 already in the business of trading privacy for convenience if you're
 using a public resolver.

Personally, I've always thought the privacy concerns of
draft-vandergaast (not of using public recursive servers) are
overwrought.

The entity running the recursive nameserver has knowledge of the exact
address (not just the subnet) that you're sending the query from, by
inspection of the packet.

The entity running the authoritative nameserver does not...  but
unless you're using DNS for some kind of off-label purpose (
http://code.kryo.se/iodine/ comes immediately to mind), the next thing
you'll be doing once you have the reply is opening some kind of
connection to the address returned...  at which point the target
entity will be able to tell the exact address that you're coming from.
This assessment makes the assumption that the folks running the
authoritative DNS servers are either the target entity or its agent.
If that's an invalid assumption, one might say you have bigger
problems.

If someone could explain a privacy concern here that doesn't involve
dipping into my meager tinfoil supply (I'm low and not going to the
grocery until tomorrow), that would be swell.

-r

Re: Anycast provider for SMTP?

[Rob Seastrom]

Ray Soucy r...@maine.edu writes:

 You can certainly do anycast with TCP, and for small stateless services it
 can be effective.  You can't do anycast for a stateful application without
 taking the split-brain problem into account.

In my experience, the thing that makes anycast work *well* is having
the concept of a Plan B baked into some-layer-above-4.  That creates
the ability to recovery gracefully in the corner case when a routing
change causes your session to blow up.

Choice of layer 4 protocol doesn't really enter into it, nor does the
length of time that the layer 4 session exists (in the case of UDP,
generally 2 packets; in the case of TCP, somewhat longer).  Shorter
sessions have a lower likelihood of losing, due to shorter exposure
time, but even for a single-packet-each-way UDP transaction the time
(and the risk) is not 0.

People of course use anycast for DNS.  Personal experience shows that
it also seems to work great for HLS video streaming.  I'd imagine it
would work fine for email too, since the whole concept of multi-level
MX is a plan-B-at-higher-level thing.

 The entire CDN model was developed with anycast in mind, 

Not really; practical application of anycast was nascent when US
6,108,703 (the Akamai patent, which centered around DNS) was filed.
A brief history of anycast is at
https://tools.ietf.org/html/draft-mcpherson-anycast-arch-implications-00
section 3.

 Taking a normal application, like mail or a dynamic website, and just using
 anycast for load balancing without designing the service with the anycast
 model in mind is probably not a good idea.  You need to expect that the
 same user could access different systems, and design for that.

For anything at scale, wherein one has multiple back end devices, one
must already design for that.  Designing consistency-synchronized
systems that work over continental or global scale latency is left as
an exercise to the implementer.

 The real point here is the problem OP is describing should be easily
 handled by having proper MX records, and getting into anycast for mail is
 likely not the right choice (unless maybe your goal is to be really
 efficient at SPAM).

Probably originating outbound connections to arbitrary locations from
an anycast locator is a step away from goodness.

-r

Re: stacking pdu

[Rob Seastrom]

William Herrin b...@herrin.us writes:

 Isn't it against the NEC and the fire code to stack power strips? We
 all do it, but isn't it against code?

Sorry to be late to the party (I plead vacation), but no, afaik it is
not.  About as close as the NEC comes art 400.8 - you can't use
flexible cord as a substitute for permanent wiring (think of some of
the shenanigans you've seen with extension cords standing in for NM or
MC on thereifixed.com or similar sites).

Rack wiring is not permanent, but I would not go so far as to claim
it is subject to the qualified personnel rules (OSHA subpart S and
NFPA 70E).  Datacenter workers who could pass a test on LOTO
procedures and routinely utilize proper PPE (even gloves, safety
glasses, and steel toe shoes) are the exception rather than the rule.

As always, when someone asserts that X is against code whether in
the form of a statement or a question, the proper response is
Citation, please!

-r

Re: Alcatel-Lucent 7750 Service Router (SR)

[Rob Seastrom]

Josh Reynolds j...@spitwspots.com writes:

 It really bothers me to see that people in this industry are so
 worried about a change of syntax or terminology. If there's one
 thing about the big vendors that bothers me, it's that these
 batteries of vendor specific tests have allowed many techs to get
 lazy. They simply can't seem to operate well, if at all, in a
 non-Cisco (primarily) environment.

If that bothers you, I recommend you not look at what passes for a
system administrator these days.  It will make you cry.

-r

Re: Alcatel-Lucent 7750 Service Router (SR)

[Rob Seastrom]

More like at least be willing to man up and learn your way around
some platform other than RHEL without whining if there is a business
need for it.

-r

Josh Reynolds j...@spitwspots.com writes:

 *grumble, grumble, grumble*
 Get off my lawn!
 :)


 On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom r...@seastrom.com wrote:

   
  
Josh Reynolds j...@spitwspots.com writes:
  

  


 It really bothers me to see that people in this
   industry are so
worried about a change of syntax or terminology. If
   there's one
thing about the big vendors that bothers me, it's that
   these
batteries of vendor specific tests have allowed many
   techs to get
lazy. They simply can't seem to operate well, if at all,
   in a
non-Cisco (primarily) environment.
   

   If that bothers you, I recommend you not look at what passes
  for a
  system administrator these days. It will make you cry.
  
  -r
  
  
  


 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: IPTV providers in IN/Chicago

[Rob Seastrom]

Brandon Martin lists.na...@monmotha.net writes:

 The network in
 question is IPv4 multicast capable and could somewhat trivially (I
 think) be IPv6 multicast capable (it is definitely IPv6 unicast
 capable).

You'd be surprised how many edge devices (unfortunately) support IPv6
multicast only to the degree necessary to implement neighbor
discovery.  Lean on your vendor.

And for the love of God, do SSM not ASM (requires igmpv3 or mld2).  I
can expound on the problem space off-list if you like.

-r

Re: IPTV providers in IN/Chicago

[Rob Seastrom]

Brandon Martin lists.na...@monmotha.net writes:

 Anyone know of an IPTV provider/wholesaler who I could meet in
 Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)?

IPTV implies, or used to imply, multicast (or unicast, whichever,
swap them with a few DCMs) MPEG2-TS feeds.  If that's what you want,
fine, but if it's not you might want to be a bit more specific.

-r

Re: vendor spam OTD

[Rob Seastrom]

Suresh Ramasubramanian ops.li...@gmail.com writes:

 Given weâ(TM)re going down this âoewhat is spamâY\.. rathole again, spam is
 generally defined as unsolicited BULK email

Correct, and moreover it's generally conceded that having a perl
script insert Dear Robert at the beginning of the email message is
insufficient for it to not be bulk, particularly if it's general and
has nothing to do with any kind of specialized knowledge of your
company beyond the fact that you have an email address.  This sure
looks like bulk mail merge to me.

 As the email appears to be one to one,

Have you gotten a copy too, or are you just idly speculating here?

 though a remarkably persistent one to one, I would suggest procmail,
 unless you know heâ(TM)s harvested nanog and is sending the same
 offer mail merged to a bunch of operators.

Gee, it's almost as if by posing a question to nanog@ like Has anyone
else received spam from X, I might be trying to ascertain an answer
to precisely that question.

-r

vendor spam OTD

[Rob Seastrom]

Anyone else been spammed by Andy Boland at Function5 Technology
Group?

-r

Re: vendor spam OTD

[Rob Seastrom]

Stephen Satchell l...@satchell.net writes:

 On 04/27/2015 07:02 PM, Rob Seastrom wrote:
 Anyone else been spammed by Andy Boland at Function5 Technology
 Group?

 I'm not sure it's fair to class the e-mail as spam, but he is one
 persistent fellow.  My company made list for some of the equipment we
 retired for purchase, and his Cisco buyer never got back to me.  So
 the excess inventory is being offered to another reseller.

Well, it's unsolicited email from a company who I've never had any
commercial relationship with.  If it's not fair to class it as spam,
what is it fair to class it as?

I reported it to the appropriate abuse folks.

-r

Re: reclaiming arin IP allocations?

[Rob Seastrom]

Rob Seastrom r...@seastrom.com writes:

 goe...@anime.net writes:

 Note ARIN has attempted to validate the data for this POC, but has received 
 no response from the POC since 2013-11-06

 So if the owner does not care to respond to ARIN, what now?

 POC validation has an extraordinarily low success rate (under 50% if
 memory serves).  Since this is a direct allocation and the space has
 not been revoked (pulled for cause, e.g. non-payment), I can only
 assume that the billing POC over snail mail is continuing to work as
 anticipated.

 -r

A, irony.  :-)

  goe...@anime.net 
SMTP error from remote mail server after MAIL FROM:r...@seastrom.com: 
host sasami.anime.net [207.109.251.120]: 554 5.7.1 twit filter 
 
-r

Re: reclaiming arin IP allocations?

[Rob Seastrom]

goe...@anime.net writes:

 Note ARIN has attempted to validate the data for this POC, but has received 
 no response from the POC since 2013-11-06

 So if the owner does not care to respond to ARIN, what now?

POC validation has an extraordinarily low success rate (under 50% if
memory serves).  Since this is a direct allocation and the space has
not been revoked (pulled for cause, e.g. non-payment), I can only
assume that the billing POC over snail mail is continuing to work as
anticipated.

-r

Re: Fixing Google geolocation screwups

[Rob Seastrom]

Blair Trosper blair.tros...@gmail.com writes:

 MaxMind (a great product)

I've heard anecdotal accounts of MaxMind intentionally marking all
address blocks assigned to a VPN vendor as open proxy even when
advised repeatedly that the disputed addresses (a) had no VPN services
running on them either inbound or outbound, and (b) in fact were web
servers for the company's payment system, or mail servers for their
corporate email.

Kind of reminiscent of dealing with certain RBLs for whom personal
beef was enough reason to list an address.  So, folks might want to
temper the great product comment with this anti-endorsement.

-r

Re: Fixing Google geolocation screwups

[Rob Seastrom]

shawn wilson ag4ve...@gmail.com writes:

 On Apr 8, 2015 7:19 AM, Rob Seastrom [[r...@seastrom.com]] wrote:


 Blair Trosper [[blair.tros...@gmail.com]] writes:

  MaxMind (a great product)

 I've heard anecdotal accounts of MaxMind intentionally marking all
 address blocks assigned to a VPN vendor as open proxy even when
 advised repeatedly that the disputed addresses (a) had no VPN services
 running on them either inbound or outbound, and (b) in fact were web
 servers for the company's payment system, or mail servers for their
 corporate email.


 I would wonder if these apps didn't have issues that allowed web proxy to the
 world. Maybe MaxMind is doing something wrong or maybe they're seeing the
 result of malicious activities and classifying from that.

That was not the conclusion that one would draw from their replies.

-r

Re: Last-call DoS/DoS Attack BCOP

[Rob Seastrom]

John Kristoff j...@cymru.com writes:

 If the attack is an infrastructure attack, say a routing interface that
 wouldn't normally receive or emit traffic from its assigned address
 except perhaps for network connectivity testing (e.g. traceroute) or
 control link local control traffic (e.g. local SPF adjacencies, BGP
 neighbors), you can hide those addresses, making them somewhat less
 easy to target by using something like unnumbered or unadvertised or
 ambiguous address space (e.g. RFC 1918).

That comes at a cost, both operational/debugging and breaking pmtud.
But if you don't care about collateral damage, setting the interface to
admin-down stops attacks against it *cold*.

Due to the drawbacks, I wouldn't consider this a good candidate for
inclusion in a BCOP document.

I have often thought there ought to be a companion series for
Questionable Current Operational Practices, or maybe desperate
measures.  I volunteer to write the article on YOLO upgrades,
wherein one loads untested software on equipment with no OOB, types
request system reboot, shouts YOLO, and hits return.

-r

Supporting network time software development/maintenance (was: Re: BCOP appeals numbering scheme -- feedback requested)

[Rob Seastrom]

New subject so as to minimize threadjacking, not the least because this is 
important stuff.

Harlan Stenn st...@ntp.org writes:

 Releng is hard and thankless but adds enormous value and
 serves as a forcing function for some level of review, cursory though
 it may be.

 I think so too.

 Hey everybody, please support Network Time.  Spread the word.  OK, I said it.

The check, as we say, is in the mail (literally).  I wish I'd known
about Network Time Foundation before you and I started corresponding a
little over a week ago about GPS cores.

 Harlan Stenn st...@ntp.org
 http://networktimefoundation.org - be a member!

NANOG colleagues, I know it can be hard getting the employer to pony
up for organizations like this, but if correct timestamps in your logs
and being able to correlate your packet captures are something you
find personally valuable and sanity-preserving, you might consider an
individual membership.  I know it's pretty important to me...

http://nwtime.org/individual-membership-application/

-r

Re: BCOP appeals numbering scheme -- feedback requested

[Rob Seastrom]

Charles N Wyble char...@thefnf.org writes:

 Use a git repository.
 Make tagged releases.
 This enables far easier distributed editing, translating, mirroring etc. And

A fine idea in theory, but not quite as much traction in reality as bcp38.

Creating a need for a BCP for retrieving BCPs so that you get the
right version rather than typing git clone and erroneously referring
to whatever is tagged -develop seems like a Bad Plan.

It's also not a really reasonable method for distributing
point-in-time documents once people are done with collaborating on
creating them.  Most end consumers will not care about the change
history.

 you can still do whatever release engineering you want.

Sure.

 A wiki is a horrible solution for something like this.

Agree 100%

-r

Re: Symmetry, DSL, and all that

[Rob Seastrom]

Naslund, Steve snasl...@medline.com writes:

From a Verizon press release last summer, all FIOS speeds are now symmetric. 

 And no one cares.  I don't even see Verizon commercials crowing
 about how great it is to have symmetry.  If customers loved it that
 much don't you think they would market that way?

You must not get out much.  There's a whole Verizon ad campaign about
half fast Internet.

https://www.youtube.com/watch?v=zr5WWFuJeM4

https://www.youtube.com/watch?v=NPqeDokFnok

-r

Re: optical gear cooling requirements

[Rob Seastrom]

Alex Rubenstein a...@corp.nac.net writes:

 My question: have the
 optical folks woken up and made things cool front to back, or are
 they still in to the bottom to top world?

Unless something's changed, ATT NEDS still reads Systems exhausting
more than 50 W/sq ft must exhaust the air vertically..

You can always put baffles above and beneath to channel the air
into/from your hot/cold aisles.  Makes it nice to be able to have the
connectors on whichever side is convenient.

-r

Re: Symmetry, DSL, and all that

[Rob Seastrom]

Naslund, Steve snasl...@medline.com writes:

From a Verizon press release last summer, all FIOS speeds are now symmetric. 

 And no one cares.  I don't even see Verizon commercials crowing about 
 how great it is to have symmetry.  If customers loved it that much 
 don't you think they would market that way?

You must not get out much.  There's a whole Verizon ad campaign about half 
fast Internet.

https://www.youtube.com/watch?v=zr5WWFuJeM4

https://www.youtube.com/watch?v=NPqeDokFnok

 And no one seems to care about it.  By the way, Verizon commercials
 do not run everywhere.  Like Chicago or anywhere else that FIOS is
 not available.

So let me get this straight - you conclude that there are no
commercials and opine that nobody cares because you're not seeing FIOS
commercials that talk about how great their symmetry is...  when you
live in a place that there is no FIOS.  It's almost as if someone
knows how to target their marketing dollars isn't it?  Shocking.

 Steven Naslund
 Chicago IL

Rob Seastrom
Leesburg VA
75 symmetric FIOS, 9.9ms to Equinix.

Re: OT - Small DNS appliances for remote offices.

[Rob Seastrom]

Bryan Seitz se...@bsd-unix.net writes:

 odroid-c1 + eMMC module + RTC battery + case + power adapter.
 Should run you about $75 *AND* wouldn't be bad for running NTP as
 well.

I haven't looked into the details of the clock, so wouldn't be bad
is probably true, notably good, well, that would be a task for
someone with experience doing clock benchmarking and who can describe
MAVAR without looking it up.

 The gig-e port on the C1 has been observed to push 405Mbps TX and
 940Mbps+ RX via iperf.

The 405 Mbps for TX.  I've seen around 30 Mbyte/sec on single stream
TCP RX.  Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so
that's not a limit of the host on the other end of the benchmark.

I call shenanigans on the 940 Mbps iperf number though.  The HSIC bus
is only 480 Mbit/sec.  Two pints of beer in a one pint glass would be
some trick.

-r

Re: OT - Small DNS appliances for remote offices.

[Rob Seastrom]

Denys Fedoryshchenko de...@visp.net.lb writes:

 Beaglebone has gigabit mac, but due some errata it is not used in
 gigabit mode, it is 100M (which is maybe enough for small office). But
 it is hardware mac.

The Beaglebone Black rev C BOM calls out the ethernet phy chip as
LAN8710A-EZC-TR which is 10/100 so there's your constraint.  The MAC
is built into the SoC and according to the datasheet the AM3358B is
10/100/1000.

 Another hardware MAC on inexpensive board it is Odroid-C1.

Difficulty: hardware MAC tells you nothing about how it's connected,
either on the board or internally in the SoC.  Ethernet on Multibus
and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both
hardware MAC yet the bus-constrained bandwidths will differ by
several orders of magnitude.

-r

Re: OT - Small DNS appliances for remote offices.

[Rob Seastrom]

Justin Wilson - MTIN li...@mtin.net writes:

 Have you looked at Mikrotik?
 www.mikrotik.com 

 It may be lacking for DNS options you want, but worth a look.

I'd definitely recommend mikrotik for a cheap and cheerful router.

DNS server (the original subject of this message)?  Not so much.

-r

Re: OT - Small DNS appliances for remote offices.

[Rob Seastrom]

Peter Kristolaitis alte...@alter3d.ca writes:

 Not industrial grade, but Raspberry Pis are pretty great for this
 kind of low-horsepower application.  Throw 2 at each site for
 redundancy and you have a low-powered, physically small, cheap, dead
 silent, easily replaceable system for ~$150 per site.

The Pi is low-powered in more ways than one.  Last fall I ran some
(admittedly fairly simple minded) DNS benchmarks against a Raspberry
Pi Model B and an ODROID U3.

Particularly if you have DNSSEC validation enabled, the Pi is
underwhelming in performance (81 qps in the validation case, 164
without).

The U3 is circa 325 qps with or without DNSSEC validation on, which
suggests that something else other than crypto-computes is the long
pole in the tent.

I haven't gotten motivated to try this against the ODROID-C1 that I
acquired later in December, nor have I sourced a Raspberry Pi 2.  For
anyone who's feeling motivated to do this (please send along
results!), the methodology I used is at http://technotes.seastrom.com/node/53

-r

PS: don't miss the opportunity to run real honest-to-god isc-dhcpd on
same machine rather than whatever your router provides you; you'll be
glad you did.

Re: OT - Small DNS appliances for remote offices.

[Rob Seastrom]

Robert Webb rw...@ropeguru.com writes:

 What I do not like about the Pi is the network port is on the USB
 bus and thus limited to USB speeds. 

Pretty much all of the ARM boards have their ethernet ports on HSIC
channels (480mbit/sec, no-transceiver-phy USB for on-board use -
maximum length is 10cm).

The Pi-B shares the single HSIC channel with the USB hub for the
keyboard and mice.  It seems from looking at block diagrams and lsusb
output that the ODROID U3 has an SoC with multiple HSIC channels and
dedicate one to to the ethernet (though the bus vs port
distinction is suspect).

pi@raspi-b ~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M
|__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
pi@raspi-b ~ $ 

root@odroid:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M
|__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
root@odroid:~# 

But 480 is greater than 100, and none of the Pis have ethernet faster
than 10/100.  The long pole in the tent is definitely not the USB, and
single stream tcp throughput is fine.

pi@raspi-b ~ $ curl -o /dev/null http://172.30.250.101/bigfile
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  989M  100  989M0 0  11.1M  0  0:01:28  0:01:28 --:--:-- 11.1M
pi@raspi-b ~ $ 


-r

Re: Interesting BFD discussion on reddit

[Rob Seastrom]

Dave Waters davewaters1...@gmail.com writes:

 http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/

 Authentication mechanisms defined for IGPs cannot be used to protect BFD
 since the rate at which packets are processed in BFD is very high.

 Dave

One might profitably ask why BFD wasn't designed to take advantage of
high-TTL-shadowing, a la draft-gill-btsh.  

-r

Re: Interesting BFD discussion on reddit

[Rob Seastrom]

Many moons ago, Mike O'Dell had a pithy observation about can
vs. should that is escaping me at this moment, which is a pity since
it almost certainly applies here.

-r

Dave Waters davewaters1...@gmail.com writes:

 Because BFD packets can get routed across multiple hops. Unlike EBGP where 
 you connect to a
 peer in a different AS and you have a direct connection, BFD packets can 
 traverse multiple
 hops to reach the endpoint.



 In case of multihop BFD the BFD packets also get re-routed when the topology 
 changes so you
 can almost never bet on the TTL value to secure the protocol.



 Dave



 On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom [[r...@seastrom.com]] wrote:

  Dave Waters [[davewaters1...@gmail.com]] writes:
  
  
  
 [[http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/]]
  
   Authentication mechanisms defined for IGPs cannot be used to protect 
 BFD
   since the rate at which packets are processed in BFD is very high.
  
   Dave
  
  


  One might profitably ask why BFD wasn't designed to take advantage of
  high-TTL-shadowing, a la draft-gill-btsh.
  
  -r
  
  
  

Re: Recommended wireless AP for 400 users office

[Rob Seastrom]

Paul Nash p...@nashnetworks.ca writes:

 Ruckus is also *way* easier to configure than Cisco.  Some of the
 Cisco folk that I know think that that is a point in favour of
 Cisco, as it adds to job security :-)

That matches my experience with Cisco 802.11 kit.  Way too many knobs
exposed, and guidance on how to set them is thin on the ground.
Sensible defaults and quick to configure on the Ruckus kit.

-r

Re: IPv6 allocation plan, security, and 6-to-4 conversion

[Rob Seastrom]

Eric Louie elo...@techintegrity.com writes:

 I'm putting together my first IPv6 allocation plan.  The general layout:
 /48 for customers universally and uniformly
 /38 for larger regions on an even (/37) boundary
 /39 for smaller regions on an even (/38) boundary

You really really really don't want to subnet on non-nybble
boundaries.  Technically feasible does not equate to good idea.
Optimize for technician brain cells and 2am maintenance windows.  Oh,
and rDNS.

If you can't make your regional aggregation scheme fit within a /32
when rounding up on nybble boundaries...  get more from ARIN.
Seriously.  IPv6 is not scarce.  A /32 is the *minimum* initial
allocation for an ISP.  See ARIN NRPM 6.5.2.1. justification is
viewed in an entirely different light in the IPv6 land-of-plenty that
is IPv6.  If you already have a /32 but haven't rolled it out yet, ask
for a do-over.

Our subnetting scheme [insert description here] requires a /28 is,
at least on paper, an entirely good reason to get a /28 out of ARIN.
If you need it and you are having trouble getting it, it's a sign that
policy needs further evolution; please reach out to folks involved
tightly with the policy process (that would include me) to let us know.

As for giving a /48 to every customer...  that's a fine way to go and
eminently defensible.  If every human being on the face of the earth
(let's round up and say 2^33 or 8 billion to make it easy) had an end
site, and we assume only 10% efficiency in our allocation scheme due
to the subnetting scheme I outlined above and getting unlucky...  that
still uses less than a tenth of a percent of available IPv6 space.

This is one of those things that are easiest to get right the first
time.  If conservation of address space is in your IPv6 numbering
plan, you're doing it wrong.

My $0.02, FWIW.

-r

Re: cable modem firmware upgrade

[Rob Seastrom]

Paul Stewart p...@paulstewart.org writes:

 That has been my experience as well (only from the RF side) and I would
 believe this was a design choice.   The ISP usually wants to keep control
 over the firmware versions of the CM for various technical/support reasons
 versus having consumers mess with the firmware.

15 years ago, in certain circles it was well-understood how to load
one's own (possibly patched) software from the Ethernet side on the
old LanCity (pre-DOCSIS) cablemodems.

You can imagine what kind of hilarity ensued.

-r

Re: PDU for high amp 48Vdc

[Rob Seastrom]

None of the stuff you'll make has UL or NEBS approval unless you pay
for that.  I'd be inclined to suck it up and pay for remote hands to
turn a switch unless you own the colo or they're casual enough that
they don't care (your insurance company might though).

Should you decide to go ahead and build, be sure to check the DC
rating vs. AC rating for break under load - AC arcs are a lot more
self-extinguishing than DC arcs are.  Consider a snubber (resistor and
capacitor in series across the contacts) in your design to minimize
arcing.

More on AC vs DC here:  
http://www.temcoindustrialpower.com/product_selection.html?p=ac_vs_dc_contactor

For context, my Lincoln IM206 arc welder can be dialed down as low as
30 amps, and will have an open circuit voltage of way under 48 volts
when it's set that low (no, I don't feel motivated enough this early
in the morning to go fire it up and stick a voltmeter on it).

-r

Bill Woodcock wo...@pch.net writes:

 The rotary actuators are an off-the-shelf item for transfer switches.  No 
 problem to get them paired with high-amperage switches. But a contactor, 
 which is a solenoid-driven switch, is also an off-the-shelf item. The ones I 
 use in EV applications are rated for 1000A, and cost about $300.  You need to 
 be careful to look at the trade-off between voltage, amperage, and the 
 per-cycle probability of a weld, though.  An over-rated contactor helps a lot 
 if you're going to be cycling it a lot, whereas if it's for emergency use 
 only, you can hew a lot closer to the max rating. 

 
 -Bill


 On Jan 28, 2015, at 18:40, Robert Drake rdr...@direcpath.com wrote:
 
 For larger DC devices with ~50amps per side, does anyone have a software 
 accessible way to turn off power?
 
 I've looked into PDU's but the ones I find have a max of 10amps.
 
 I've considered building something with solenoids or a rotary actuator that 
 would turn the switches on or off, but that's a complete one-off and would 
 need to be done for each device we manage (not to mention it involves janky 
 wiring all over the place I've got to explain to the colo)
 
 My use case is pretty infrequent so it needs to be remote-hands cheap.. it's 
 for emergencies when you need to completely power cycle a redundantly 
 powered DC device.  The last time I needed this it was because a router was 
 stuck in a boot loop due to a bad IOS upgrade and wouldn't break to rommon 
 since it had been 60 seconds.  It came up again tonight because we wanted 
 to disable one power supply to troubleshoot something.
 
 FWIW, I believe I've seen newer Cisco gear with high-end power supplies that 
 have a console or ethernet port which would possibly let you shut them down 
 remotely.  That solves the problem nicely if you're dealing with only one 
 bit of hardware, but I'd like a general solution that worked with any 
 vendor.  Possibly a fuse panel with solenoids that could add/remove fuses 
 when needed.. or would that be considered dangerous in code-ways or in telco 
 fire regulation ways?
 
 
 
 

Re: Recommended wireless AP for 400 users office

[Rob Seastrom]

Manuel Marín m...@transtelco.net writes:

 I was wondering if you can recommend or share your experience with APs that
 you can use in locations that have 300-500 users. I friend recommended me
 Ruckus Wireless, it would be great if you can share your experience with
 Ruckus or with a similar vendor.  My experience with ubiquity for this type
 of requirement was not that good.

I have had a pair of Ruckus R700s at the house for a short while now
(hey, they haven't been out that long).

They work fine without a controller, at least in WPA2-PSK mode with a
few VLANs.  Haven't seen if Enterprise works without the controller or
not, so if you care you might want to check.  For an annual fee,
Ruckus offers a cloud controller too as opposed to their physical
box controllers; this is worthy of consideration depending upon your
situation.

Software upgrades were pretty straightforward.

The R700 has a CLI, but I haven't tried doing anything particular with
it so I can't offer any thoughts there.  Those running with a
controller (the expected mode of operation) will never touch the
individual APs anyway, so I'd expect the CLI might be a little
disappointing.  The web UI is thoughtfully laid out and was easy to
use.

Management VLAN can be separate from the customer traffic VLANs and
they work fine with my slightly demented mix of tagged/untagged
traffic.  The caveat here is that if you were thinking of just tossing
everything in one VLAN without any separation whatsoever, there
doesn't seem to be a good way to filter access to the management
interface.  Then again, it's https/ssh (http and telnet are available
but off by default, hooray!) so you may not care.  The sshd and web
server are dropbear and GoAhead-Webs respectively.

Overall I've found the R700s very stable and been pleased with them.
They're a bit spendy, but you absolutely get what you pay for.  At the
other end of the spectrum is the Ubiquiti and Mikrotik kit, which I
also love, but for a completely different use case and budget.

I would recommend Ruckus without hesitation.

My $0.02.

-r

Re: Fibre Channel Network

[Rob Seastrom]

symack sym...@gmail.com writes:

 Hello Everyone,

 Have a few FC cards and a switch that I would like to use for backplane
 related packets (ie, local network). I am totally new to FC and would like
 to know will I need a router to be able to communicate between the nodes?
 What I plan on doing is connecting the network card to the FC switch.

 Thanks in Advance,

 Nick.

Classic FC is not routed in the sense that you're used to from IP,
although there is a component in the control plane of every FC switch
called a router, which is perhaps where the confusion comes from
(the other three, FWIW, are address manager, fabric controller, and
path selector).

To answer the implied question, yes you can just plug them into the
switch (some configuration will almost certainly be required).  You
can also do a point to point connection between two FC devices (back
to back as it were).  The way we used to do it back in the old days
before switches was an arbitrated loop; in fact I still can't think FC
without thinking FC-AL.

-r

Re: Got a call at 4am - RAID Gurus Please Read

[Rob Seastrom]

Jon Lewis jle...@lewis.org writes:

 OpenSolaris (or even Solaris 11), ZFS, Stable.  Pick one.  Maybe
 two. Three?  Yeah right.  Anyone who's used it hard, under heavy load,
 should understand.

The most recent release of OpenSolaris was over 5 years ago.  You're
working from (extremely) dated information.

The current FOSS Solaris ecosystem forked when Oracle brought stuff
back in-house.  Significant development has happened over the
intervening half-decade.  

Anyone who's using Nexentastor (or hosted in Joyent Cloud) is getting
all three (supra).

-r

Re: Got a call at 4am - RAID Gurus Please Read

[Rob Seastrom]

Gary Buhrmaster gary.buhrmas...@gmail.com writes:

 There is always Illumos/OnmiOS/SmartOS
 to consider (depending on your particular
 requirements) which can do ZFS and KVM.

2.5-year SmartOS user here.  Generally speaking pretty good though I
have my list of gripes like everything else I touch.

-r

Re: Got a call at 4am - RAID Gurus Please Read

[Rob Seastrom]

+1 on both.  Mostly SmartOS, some FreeNAS (which is FreeBSD underneath).

-r

Ryan Brooks r...@hack.net writes:

 Zfs on BSD or a Solaris like OS


 On Dec 11, 2014, at 10:06 AM, Bacon Zombie baconzom...@gmail.com wrote:
 
 Are you running ZFS and RAIDZ on Linux or BSD?
 On 10 Dec 2014 23:21, Javier J jav...@advancedmachines.us wrote:
 
 I'm just going to chime in here since I recently had to deal with bit-rot
 affecting a 6TB linux raid5 setup using mdadm (6x 1TB disks)
 
 We couldn't rebuild because of 5 URE sectors on one of the other disks in
 the array after a power / ups issue rebooted our storage box.
 
 We are now using ZFS RAIDZ and the question I ask myself is, why wasn't I
 using ZFS years ago?
 
 +1 for ZFS and RAIDZ
 
 
 
 On Wed, Dec 10, 2014 at 8:40 AM, Rob Seastrom r...@seastrom.com wrote:
 
 
 The subject is drifting a bit but I'm going with the flow here:
 
 Seth Mos seth@dds.nl writes:
 
 Raid10 is the only valid raid format these days. With the disks as big
 as they get these days it's possible for silent corruption.
 
 How do you detect it?  A man with two watches is never sure what time it
 is.
 
 Unless you have a filesystem that detects and corrects silent
 corruption, you're still hosed, you just don't know it yet.  RAID10
 between the disks in and of itself doesn't help.
 
 And with 4TB+ disks that is a real thing.  Raid 6 is ok, if you accept
 rebuilds that take a week, literally. Although the rebuild rate on our
 11 disk raid 6 SSD array (2TB) is less then a day.
 
 I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds).
 It took nowhere near a day let alone a week.  Theoretically takes 8-11
 hours if the vdev is completely full, proportionately less if it's
 not, and I was at about 2/3 in use.
 
 -r
 

Re: Got a call at 4am - RAID Gurus Please Read

[Rob Seastrom]

Barry Shein b...@world.std.com writes:

 From: Randy Bush ra...@psg.com
 We are now using ZFS RAIDZ and the question I ask myself is, why
 wasn't I using ZFS years ago?

because it is not production on linux, which i have to use because
freebsd does not have kvm/ganeti.  want zfs very very badly.  snif.

 I keep reading zfs vs btrfs articles and...inconclusive.

 My problem with both is I need quotas, both file and inode, and both
 are weaker than ext4 on that, zfs is very weak on this, you can only
 sort of simulate them.

By file, you mean disk space used?  By whom and where?  Quotas and
reservations on a per-dataset basis are pretty darned well supported
in ZFS.  As for inodes, well, since there isn't really such a thing as
an inode in ZFS...  what exactly are you trying to do here?

-r

Re: Got a call at 4am - RAID Gurus Please Read

[Rob Seastrom]

The subject is drifting a bit but I'm going with the flow here:

Seth Mos seth@dds.nl writes:

 Raid10 is the only valid raid format these days. With the disks as big
 as they get these days it's possible for silent corruption.

How do you detect it?  A man with two watches is never sure what time it is.

Unless you have a filesystem that detects and corrects silent
corruption, you're still hosed, you just don't know it yet.  RAID10
between the disks in and of itself doesn't help.

 And with 4TB+ disks that is a real thing.  Raid 6 is ok, if you accept
 rebuilds that take a week, literally. Although the rebuild rate on our
 11 disk raid 6 SSD array (2TB) is less then a day.

I did a rebuild on a RAIDZ2 vdev recently (made out of 4tb WD reds).
It took nowhere near a day let alone a week.  Theoretically takes 8-11
hours if the vdev is completely full, proportionately less if it's
not, and I was at about 2/3 in use.

-r

CAs with dual stacked CRL/OCSP servers

[Rob Seastrom]

At $DAYJOB, we have some applications that we would like to be all
hipster and *actually check* for certificate revocation.  I know this
is way out there in terms of trendiness and may offend some folks.

Difficulty: the clients are running on single stacked IPv6.  We have
recently been advised by our existing CA that they do not currently
have IPv6 support plan (sic).

OCSP Stapling sounds like it could be a winner here.  Unfortunately,
the software support is not quite ready yet on the platform on either
end of the connection (client or server).

So...  we're looking around for a vendor that's taken the time to dual
stack its servers.

Any leads?

-r

Re: ARIN's RPKI Relying agreement

[Rob Seastrom]

Bill Woodcock wo...@pch.net writes:

 On Dec 4, 2014, at 7:35 AM, Andrew Gallo akg1...@gmail.com wrote:

 In my informal conversations, what I got was that lawyers read the
 agreement, said 'no, we wont sign it' and then dropped it.  If
 specific legal feedback isn't making it back to ARIN, then we need
 to start providing it,

 All the specific legal feedback I’ve heard is that this is a
 liability nightmare, and that everyone wants ARIN to take on all the
 liability, but nobody wants to pay for it.  Are you hearing
 something more useful than that?

The way the RPA is worded, ARIN seems to be attempting to offload all
the risk to its member organizations.

Anything that ARIN does has some degree of risk associated with it.
Twice a year we host parties where alcohol is served.  That's a risky
endeavor on all sorts of ways - at least we're typically taking buses
to and from the event so we aren't driving.  I have heard it asserted
the board is unwilling for the organization to shoulder even that
level of risk as part of providing RPKI.  As a board member, can you
speak to this?

Whether this extreme level of risk aversity is a matter of mistaken
priorities (putting the organization itself ahead of accomplishing the
organization's mission) or a way of making sure that we stop wasting
money on RPKI due to demonstrable non-uptake is left as an exercise to
the reader.

You can infer from the last statement that I would applaud cutting our
losses on RPKI.  The quote on slide 23 of Wes' deck about replacing
complex stuff like email templates with simple, easy to understand
public key crypto was mine.  If you can't get people to play ball
nicely with client filtering, IRR components, etc. where the bar to
entry is low, who can _possibly_ say with a straight face that we can
get people to embrace RPKI?

To the usual suspects: sorry to call your kid ugly.  Don't hate the messenger.

-r

Re: Buying IP Bandwidth Across a Peering Exchange

[Rob Seastrom]

Colton Conor colton.co...@gmail.com writes:

 Some might ask why not get a cross connect to the provider. It is cheaper
 to buy an port on the exchange (which includes the cross connect to the
 exchange) than buy multiple cross connects. Plus we are planning on getting
 a wave to the exchange, and not having any physical routers or switches at
 the datacenter where the exchange/wave terminates at. Is this possible?

Technically possible and advisable are two different things.  If
you enjoy finger-pointing on the occasions where you are trying to
smoke out performance issues, I encourage as many third, fourth, and
fifth-party-managed network layers in the mix as possible.  A wave
with no way to test to the handoff point would of course be the icing
on the cake.

Are you sure you can't afford to sublet a few ru of space from someone
and pay for a couple extra cross connects?

-r

Re: I am about to inherit 26 miles of dark fiber. What do I do with it?

[Rob Seastrom]

While short and to the point, what Fletcher said is likely to be the
best advice in this thread.

Getting someone on staff who understands *both* outside plant
architecture and balance sheets...  and can co-develop a business
model that involves the lateral build-out from the six POPs around
town without going broke is the hard part.

Six POPs, six strands, MPLS backbone vs. selling waves could be the
concept for the opening lines to a sad country song where the
protagonist doesn't realize that the long pole in the tent is the
making the edge work (someone please run with this and get a musical
lightning talk at San Antonio!)

-r

Faisal Imtiaz fai...@snappytelecom.net writes:

 WoW !.. that was a rather cruel and un-called for !

 How does that saying go.Don't say anything, if you cannot say anything 
 nice !



 Faisal Imtiaz
 Snappy Internet  Telecom

 - Original Message -
 From: Fletcher Kittredge fkitt...@gwi.net
 To: Lorell Hathcock lor...@hathcock.org
 Cc: nanog@nanog.org
 Sent: Sunday, November 9, 2014 9:56:08 PM
 Subject: Re: I am about to inherit 26 miles of dark fiber. What do I do with 
 it?
 
 The below is a really sad story. Condolences on the coming trainwreck. I
 hope you get someone on staff or on consult that understands outside plant
 architecture, because it is much more important and complex topic than you
 seem to realize.
 
 
 On Sun, Nov 9, 2014 at 9:18 PM, Lorell Hathcock lor...@hathcock.org wrote:
 
  All:
 
  A job opportunity just came my way to work with 26 miles of dark fiber in
  and around a city in Texas.
 
  The intent is for me to deliver internet and private network services to
  business customers in this area.
 
  I relish the thought of starting from scratch to build a network right
  from the start instead of inheriting and fixing someone else's mess.
 
  That being said, what suggestions does the group have for building a new
  network using existing dark fiber?
 
  MPLS backbone?  Like all businesses these days, I will likely have to
  build the lit backbone as I add customers. So how would you recommend
  scaling the network?
 
  I have six strands of SMF that connect within municipal facilities. Each
  new customer will be a new build out from the nearest point. Because of
  having only six strands, I don't anticipate selling dark fiber. I believe I
  need to conserve fibers so that it would be lit services that I offer to
  customers.
 
  I would like to offer speeds up to 10 GB.
 
  Thoughts are appreciated!
 
  Sincerely,
 
  Lorell Hathcock
 
 
 
 
 --
 Fletcher Kittredge
 GWI
 8 Pomerleau Street
 Biddeford, ME 04005-9457
 207-602-1134
 

Re: Is it unusual to remove defunct rr objects?

[Rob Seastrom]

Baldur Norddahl baldur.nordd...@gmail.com writes:

 On 1 November 2014 23:18, Rob Seastrom r...@seastrom.com wrote:

 Where on the public Internet?

 Do networks run by organizations such as SITA, ARINC, BT Radianz, UK
 MOD, and US DOD that use globally unique space and may interconnect
 with each other in some way (and could hypothetically be using
 IRR-type structures to describe that routing policy though I don't
 think the military does that) get their objects unceremoniously booted?


 Why would I want routes from US DOD in my filters, if this stuff is not
 supposed to be on the public internet? That is a waste of everyones
 ressources.

If you (and they) use the full capabilities of RPSL...  you won't.

-r

Re: Is it unusual to remove defunct rr objects?

[Rob Seastrom]

Jimmy Hess mysi...@gmail.com writes:

 Do the internet route registries  exist  to track routes that are not
 to appear on the public internet?  I think not.

What's the public Internet?  Does it mean the DFZ as seen at Jimmy
Hess' router, with his set of upstreams?  If so, I can assure you
that there are plenty of routes that need to pass filters that are (or
optimally would be) built off of IRR data that would not pass this
test.

 There should probably be an attribute provided for such objects,
 however,  that would indicate  This route does not appear on the
 public internet.

see above.  :)

 If not tagged like that in some manner, and a matching route does has
 not appeared on the public internet  at any time during the past  6 to
 12  months,  then  I would consider the registry object to be defunct.

Where on the public Internet?

Do networks run by organizations such as SITA, ARINC, BT Radianz, UK
MOD, and US DOD that use globally unique space and may interconnect
with each other in some way (and could hypothetically be using
IRR-type structures to describe that routing policy though I don't
think the military does that) get their objects unceremoniously booted?

-r

Re: Why is .gov only for US government agencies?

[Rob Seastrom]

Nick Hilliard n...@foobar.org writes:

 On 19/10/2014 13:05, Matthew Petach wrote:
 Would love to get any info about the history
 of the decision to make it US-only.

 incidentally, why does the .gov SOA list usadotgov.net in its SOA?  The web
 site for the domain looks like it's copied from drjanicepostal.com.  Has
 USGOV decided to open a new executive branch for podiatry?

Government's got to keep on its feet.

-r

Re: fema.net dnssec issues

[Rob Seastrom]

Antonio Querubin t...@lavanauts.org writes:

 Anybody have a good DNS tech contact at FEMA?  I tried to report a
 dnssec problem to them but apparently the contact listed in whois is
 out of the office.  In the meantime we have a near hurricane-strength
 storm approaching.

fema.net looks like it belongs to who you'd expect, and indeed the
dnssec is broken, but their web site seems to be broken when you try
to visit it from a non-validating location too.

fema.gov appears to be working properly.

it would not have occurred to me to use fema.net to contact the
fema.gov people and it comes to me as a complete surprise that they
even own fema.net.  are they pushing fema.net in their advertising or
somesuch?

best of luck in the storm; stay dry.

-r

Re: IPV6 Multicast Listener storm control?

[Rob Seastrom]

Richard Holbo hol...@sonss.net writes:

 I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst
 3750 and 3560 switches.  These are switched back to a routed interface and
 IP addresses are assigned by DHCP.  We are not using IPV6 at all, and I
 don't have control of the clients.

This configuration is reminiscent of my back lawn.  It probably grew
organically, has been neglected for a period of time, and it's going
to require a bit of effort to tame it and bring it under control.

You probably don't have the option of blocking horizontal layer 2
traffic like the WISP guys do, and even if you were able to get away
with that it brings its own set of downsides to it.

The solution here is to chop things into separate broadcast domains,
each one no bigger than a single switch.  You might bring each to a
routed interface on another device (or likely more than one other
device depending on your network layout), but on no account should you
have the broadcast domain span more than one port on that device.

Hopefully you don't have any poorly behaved software that depends on
being in the same broadcast domain.  It can be difficult to inventory
that and make sure it all works before taking the leap.  It could be
easier to just peel off one workgroup of people to configure them that
way as a pilot and see if anyone squawks.  Tell them that you're doing
it and that you want feedback, since your current configuration is
conditioning them to just suck it up when the network periodically
flakes.

Hope this helps,

-r

Re: IPV6 Multicast Listener storm control?

[Rob Seastrom]

Richard Holbo hol...@sonss.net writes:

 I am seeing issues with IPV6 multicast storms in my network that are fairly
 low volume (1-2mbit), but that are causing service disruptions due to CPU
 load on the switches and that the network is a Point to MultiPoint wireless
 network.

OK, well one comment in my previous email will sound stupid (not
enough coffee yet) but the upshot remains: more subnetting.

-r

Re: IP Geolocation Issue

[Rob Seastrom]

Good luck with that.  My past experience with them (while not as bad
as dealing with certain fast-n-loose RBLs) has been less than
encouraging.

-r

Alex Wacker a...@alexwacker.com writes:

 You can submit corrections to maxmind here:
 https://www.maxmind.com/en/correction

 On Wed, Sep 17, 2014 at 6:17 PM, Jose Damian Cantu Davila jca...@nic.mx 
 wrote:
 Hi, Im new here, so any advice would be very appreciated.

 Is someone from Maxmind IP Geolocation available, that I can talk to offline?

 Its regarding to a block we assigned to a client. The client and its 
 customers are located in Mexico but the IP Geolocation services says they 
 are located in Brazil.

 Thanks for your help.

 [damian cantu]

Re: Prefix hijacking, how to prevent and fix currently

[Rob Seastrom]

Matthew Kaufman matt...@matthew.at writes:

 I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
 registrations.

I'd assume that it would be included in your annual LRSA maintenance
fees.

-r

Re: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions

[Rob Seastrom]

Denis Fondras xx...@ledeuns.net writes:

 May we discuss IPv6 support ? Last time I checked, UBNT was lagging
 behind...

I've been running an IPv6 tunnel (cough FIOS) with one end being
Mikrotik and the other being UBNT (ER-Lite) since January 2013.  The
UBNT is in a fairly simple-minded configuration so I can't speak to
things like VRRP, OSPFv3, etc.  The Mikrotik is in the datacenter...
speaks OSPF[v3] and BGP to Cisco stuff.  No difficulties, though I'm
pretty sure I didn't create/configure the tunnel via the GUI.

-r

Re: [HFC] pooling modems in layer2

[Rob Seastrom]

Toney Mareo halfli...@gmx.com writes:

 Hello

 I think it's kind of an isp secret but I would be curious how do
 people distribute modems to pools before they would even reach the
 actual IP network so on layer2:

 http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg

Nobody does CMTRI anymore.  That illustration is over a decade and a
half old, which is part of what's confusing you.  The scheme there is
that they use a dialup modem for the upstream and a cablemodem for the
downstream.

 For this I would like to get some clarification because I do not work in the 
 telco industry.

If you're interested in how CMTRI works for historical reasons, the spec is 
here:

http://www.cablelabs.com/wp-content/uploads/specdocs/SP-CMTRI-I01-970804.pdf

 As I can figure out of the docsis, cablelabs documents. The CMTS
 device is connected to the coax segments through fiber. Therefore
 one could say that the modem facing side is a fiber optic
 interface but it's not 1000 Base-FX, not a regular Ethernet over
 fiber. It sends signals through a broad range of frequencies.

It sends signals over RF (i.e. truly broadband).  The RF happens to
be on a laser-lit fiber instead of a piece of coax (until it hits the
fiber node and gets turned into coax cable).  There are Ethernet MAC
addresses in there if you look at the right layer, but the DOCSIS data
rides as a program atop a J.83 single program transport stream on a
QAM64 or QAM256 modulated RF signal.  It's just like a digital TV
program and occupies the same frequency space - but 0x1FFE is the
well-known PID that means DOCSIS data.

The upstream channels are comparatively low (under 80 MHz) and the
downstream channels are comparatively high (over 80 MHz to 800-1000
MHz depending on the system).  Splitting them out is accomplished with
bidirectional high and low pass filters called diplexers.

 So what I would like to accomplish to provide a different pool of
 dhcp servers, which provides different config file, tod server,
 router, dns etc. infos to the modems but to do all this in Layer2.

 I don't have hands on experience with CMTS-es but I would think that
 they are able to pool clients by MACs and able to send eg 500
 clients to DHCP server1 and the other 1500 to DHCP server2 before
 they would even get an IP, so I talking of pure layer2 here!

There are multiple ways to approach this.  You need a consultant who
is well-versed in the care and feeding of DOCSIS edge networks to walk
through your options with you so that you don't find yourself in a
painful technical place.

 Let's say if the CMTS device does not support this, what are the
 other options for routing layer2 traffic coming out of the CMTS?

I don't recommend PPPoE.  :)

 If I would know more about the device I would say that put a
 linuxbox after it (on the ISP facing nic) and mark the packets going
 out with arptables/ebtables then send them out of different nics to
 different dhcp servers.

 Any suggestions are welcome.

You might start by sharing a high level overview of what it is that
you're trying to accomplish.  If it's simply sandboxing people who
haven't paid their bills, there are well-known ways to do that.  If
it's business services over DOCSIS, there are likewise ways to do
that.

-r

Re: Huawei Atom Router

[Rob Seastrom]

To be fair, they've fixed one of the big concerns that were raised
with them a couple of years ago: google for huawei + psirt now
actually returns usable results.  No idea how well the interface with
them works when you're actually trying to report a vulnerability
(maybe someone can speak up).

-r

Alain Hebert aheb...@pubnix.net writes:

 Was more a statement of fact.

 As if it was warranted.  I do not know.

 -
 Alain Hebertaheb...@pubnix.net   
 PubNIX Inc.
 50 boul. St-Charles
 P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
 Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

 On 08/05/14 11:34, Randy Bush wrote:
 And a bunch of ban's around Oct 2013 from a wide variety of
 countries...
 you mean fear of implants as there are in cisco products?

Re: Remooted: a deployment design for Muni Fiber (was Re: Muni Fiber and Politics)

[Rob Seastrom]

Matthew Kaufman matt...@matthew.at writes:

 In the meantime, I'd like to see the city where an ISP can buy as many
 of the microducts as they want. I'd like to buy them all,
 please... though I have no intention of running anything though them,
 as I'm an investor in the local cable TV company.

The fire ants have beaten you to it and they don't take kindly to
people running fiber through their living room.

(SFW but kind of disgusting):
http://www.rainbowtech.net/products/docs/c51ce4107047eb1b2dc/Ants%20in%20OSP%20Equipment.pdf.pdf

-r

Re: Net Neutrality...

[Rob Seastrom]

Michael Thomas m...@mtcc.com writes:

 On 7/17/14, 2:15 PM, valdis.kletni...@vt.edu wrote:
 /me makes popcorn and waits for 4K displays to drop under US$1K and
 watch the network providers completely lose their shit

 http://www.amazon.com/Seiki-SE39UY04-39-Inch-Ultra-120Hz/dp/B00DOPGO2G

 $339!

 I use it for doing dev. It's *fabulous*.

Refresh rate is limited to 30Hz with 4K

Bracing for my first seizure ever in 3...  2... 1...

-r

Re: Listing or google map of peering exchange

[Rob Seastrom]

Dennis Burgess dmburg...@linktechs.net writes:

 Looking for a good listing of US/Canada peering exchange, similar to
 Torx in Toronto..Google map listing would be nice J 

Similar to Torx in Toronto, assuming you're OK with 4 points instead
of 6, would be Robertson/Scrulox.  Get 'em at Canadian Tire.

-r

Re: US patent 5473599

[Rob Seastrom]

Eygene Ryabinkin rea+na...@grid.kiae.ru writes:

 If you hadn't seen the cases when same VRIDs in the same network were
 used for both VRRP and CARP doesn't mean that they aren't occurring in
 the real world.  We use CARP and VRRP quite extensively and when we
 first were hit by this issue, it was not that funny.

+1

 ...
 but choosing OUI from the VRRP space (hijacking that space) was
 clearly the poor design choice.  Fullstop.

+\infty

Either it was an intentional conflict that was meant to cause
operational problems or it was not.

If it was, then a previous characterization of CARP as a trojan is spot on.

If it was not (and I'm willing to be charitable here), then the
take-away from this is that the folks who made this decision are
utterly clueless about standards, the reason for standards, and
operations.  That would hardly be earth shattering news.

Those wishing to decide for themselves which it is may wish to
consider the fact that this tripping point remains undocumented in
OpenBSD's man page ten years on.

-r

Re: US patent 5473599

[Rob Seastrom]

Matt Palmer mpal...@hezmatt.org writes:

 On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote:
 However, assume that the OpenBSD developers did document their protocol
 and requested an IESG action and was refused.  Do you believe that would
 justify squatting on an already assigned number?

 I'm going to go with yes, just to be contrary.  At the point that the IESG
 refused to deal with 'em, they've effectively been ostracised from the
 Internet community, and thus they are under no obligation to act within the
 rules and customs of that community.

The bar for an informational RFC is pretty darned low.  I don't see
anything in the datagram nature of i'm alive, don't pull the trigger
yet that would preclude a UDP packet rather than naked IP.  Hell,
since it's not supposed to leave the LAN, one could even get a
different ethertype and run entirely outside of IP.  Of course, the
organization that has trouble coming up with the bucks for an OUI
might have trouble coming up with the (2014 dollars) $2915 for a
publicly registered ethertype too.

Must be a pretty horrible existence (I pity the fool?) to live on
donated resources but lack the creativity to figure out a way to run a
special fund raiser for an amount worthy of a Scout troop bake sale.
Makes you wonder what the OpenBSD project could accomplish if they had
smart people who could get along with others to the point of shaking
them down for tax-deductible donations, doesn't it?

-r

Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.

[Rob Seastrom]

I just recently got four sets off eBay.  Purportedly genuine Cisco.  A
shade over $100.  Raid the departmental beer fund.  :)

-r

Vlade Ristevski vrist...@ramapo.edu writes:

 It would probably be a good time to upgrade the memory on my 7206
 NPE-G1 as well (512MB). I was going to replace the router but am going
 to keep it around for the Fall Semester. Anyone know of any good 3rd
 party memory modules that are equivalent to the MEM-NPE-G1-1GB? I got
 a quote for the official Cisco ones last summer and it was around
 $5,000 lol

 On 5/6/2014 11:39 AM, Drew Weaver wrote:
 Hi all,

 I am wondering if maybe we should make some kind of concerted effort to 
 remind folks about the IPv4 routing table inching closer and closer to the 
 512K route mark.

 We are at about 94/95% right now of 512K.

 For most of us, the 512K route mark is arbitrary but for a lot of folks who 
 may still be running 6500/7600 or other routers which are by default 
 configured to crash and burn after 512K routes; it may be a valuable public 
 service.

 Even if you don't have this scenario in your network today; chances are you 
 connect to someone who connects to someone who connects to someone (etc...) 
 that does.

 In case anyone wants to check on a 6500, you can run:  show platform 
 hardware capacity pfc and then look under L3 Forwarding Resources.

 Just something to think about before it becomes a story the community talks 
 about for the next decade.

 -Drew

 Vlad

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Rob Seastrom]

Randy Bush ra...@psg.com writes:

 Ah, so you're in the camp that a /10 given to one organization for
 their private use would have been better than reserving that /10 for
 _everyone_ to use. We'll have to agree to disagree there.

 you forced an rfc allocation.  that makes public space, and is and will
 be used as such.  you wanted an 'owned' allocation that you and your
 friends control, you shoulda gone to the rirs.

Usually I manage to keep the Strangelove hand in check and not feed
the troll, but the matter was raised (at least in the ARIN region).

https://www.arin.net/policy/proposals/2011_5.html

I believe that the arguments that shared transition space were IETF's
purview were compelling.  I'm no fan of non-globally-unique space in
general, but forcing the RFC route was the least-worst route for
things to move forward.

Randy, I trust that you're also vigorously advocating people's use of
UK-MOD-19850128 (aka net 25) as just more 1918 space inside their
organizations too?  After all, it's what I encourage *my* competitors to do.

-r

Re: Fwd: Serious bug in ubiquitous OpenSSL library: Heartbleed

[Rob Seastrom]

Randy Bush ra...@psg.com writes:

 you might like (thanks smb, or was it sra)

 openssl s_client -connect google\.com:443  -tlsextdebug 21| grep 'server 
 extension heartbeat (id=15)' || echo safe

protip: you have to run this from a device that actually is running
1.0.x, i.e. supports the heartbeat extension.  your desktop mac
(running 0.9.8y if you're running mavericks and haven't stomped on it
via ports; homebrew is a keg only install) WILL NOT SUFFICE and will
just sit there quietly until the http server times out (60 seconds in
my case) and then echo safe even when you're not.

-r

Re: Serious bug in ubiquitous OpenSSL library: Heartbleed

[Rob Seastrom]

Me jsch...@flowtools.net writes:

 Thanks for the expanded list, I had some of these already. I'm not
 comfortable in letting some online code that I can't see test my site
 though.

If that's true, you might want to consider immediately disconnecting
your systems from the Internet and never re-connecting them.  After
all, theres a lot of online unseen code testing your site already
whether you like it or not.

-r

Re: Recommendation on NTP appliances/devices

[Rob Seastrom]

On a tangential note, it's all very nice to say We have brand X and
like them, but I'd be curious to hear from folks who have deployed at
least four divergent brands with non-overlapping GPS chip sets and
software [*] to keep a conspiracy of errors from causing the time to
suddenly be massively incorrect.  Not that this has ever happened in
the past in a single vendor configuration [cough].

Along the same lines I'm troubled by the lack of divergent sources
these days - everything seems slaved to GPS either directly or
indirectly (might be nice to have stuff out there that got its time
exclusively via Galileo or Glonass).  The sole exception that I can
think of offhand is that I have an office within ground wave of WWVB,
which would be a tasty ingredient.  GOES is gone.  LORAN is defunded.
And so it goes; all our eggs are in one basket.

I've thought about posting this request to the NTP developers list,
but maybe someone who's an operator and actually cares about keeping
the byzantine generals sequestered from each other has solved this
problem recently.

Clues?

-r


[*] to the extent possible; I'm sure that there's a lot of reference
implementation DNA floating around out there)


Berry Mobley be...@gadsdenst.org writes:

 We have symmetricom (now microsemi) and are very happy with them, but we use 
 the roof mounted gps antennas. They will peer with public ntp severs if that 
 would work for you. 

 David Hubbard dhubb...@dino.hostasaurus.com wrote:

Anyone have recommendations on NTP appliances; i.e. make, model, gps vs
cell, etc.?  Roof/outdoor/window access not available.  Would ideally
need to be able to handle bursts of up to a few thousand simultaneous
queries.  Needs IPv6 support.

Thanks!

Re: Recommendation on NTP appliances/devices

[Rob Seastrom]

Chris Adams c...@cmadams.net writes:

 Once upon a time, Rob Seastrom r...@seastrom.com said:
 Along the same lines I'm troubled by the lack of divergent sources
 these days - everything seems slaved to GPS either directly or
 indirectly (might be nice to have stuff out there that got its time
 exclusively via Galileo or Glonass).

 Since you mentioned GLONASS: it had a 10+ hour outage yesterday,
 apparently due to a bad ephemeris upload.  Did anybody have a
 GLONASS-using NTP server experience problems?

It would be the height of arrogance to think that this couldn't happen to GPS.

I want redundancy.

-r

Re: L6-20P - L6-30R

[Rob Seastrom]

Lamar Owen lo...@pari.edu writes:

 Actually, there is no NEC 384.16 any more, at least in the 2011 code.

Guilty.  I reflexively reached for my 2008 copy since that's the code
of record here where I live.  Glad we're not on 2011, wish we were
still on 2005; a lot of stupidity has crept in since then.  Tamper-resistant
receptacles required in the unfinished basement shop?  *really*?

-r

Re: L6-20P - L6-30R

[Rob Seastrom]

Alex Rubenstein a...@corp.nac.net writes:

 Go look at any standard household lamp. It has a 5-15P on the end of
 it, which could be plugged into an outlet rated for 20 amps (5-20R),
 with 16 gauge lamp cord rated for 10 amps or less.

Mine all seem to be NEMA 1-15P, some (most?) with 18 AWG wire.

Have I been shortchanged?  :)

-r

Re: L6-20P - L6-30R

[Rob Seastrom]

Alex Rubenstein a...@corp.nac.net writes:

 But my point remains. Appliance/load wire size is often, and many
 times smaller than the ampacity of the circuit.

 Heck, how many times have you plugged in a 14 gauge extension cord
 to a 5-20R?

I do this all the time.  In (all our) defense, lamp cord is the
closest thing to conductors in free air that most people will ever run
into, and although the insulation isn't high temperature stuff, the
heat buildup isn't the same as a few dozen THHN conductors in EMT.

If you want something that will make your head explode a little (until
you think it through and realize that ampacity is just another way
of expressing i^2r losses plus dissipation rate), read NEC table
630.11(A), and then 630.12(A) and noodle on just how skinny a wire you
can use for hooking up a (home, low duty cycle) welder that's
breakered at 50 amps.  12 AWG anyone?

-r

Re: L6-20P - L6-30R

[Rob Seastrom]

Jay Ashworth j...@baylink.com writes:

 It is exactly that: no one says you *can't* wire a 20A branch circuit with 
 #10.

 It is even *possible*, though unlikely, that if you did so, you wouldn't
 have to derate it to 80%.  I would have to reread the Code to be sure.

It's not the conductor that you're derating; it's the breaker.  Per
NEC Table 310.16, ampacity of #12 copper THHN/THWN2 (which is almost
certainly what you're pulling) with 3 conductors in a conduit is 30
amps.  Refer to Table 310.15(B)(2)(a) for derating of more than 3
current-carrying conductors in a conduit.  4-6 is 80%, 7-9 is 70%.
Plenty good for 20 amps for any conceivable number of conductors in a
datacenter whip.

Thermal breakers are typically deployed in an 80% application for
continuous loads, per NEC 384-16(c).  See the references to 125% of
continuous load, which of course is the reciprocal of 80%.

http://cliffordpower.com/wp/wp-content/uploads/2010/08/CPS_info_sheet_37_CB_80_versus_100.pdf

-r

Re: NetBSD as a TimeCapsule?

[Rob Seastrom]

Atticus grobe...@gmail.com writes:

 Use avahi.

Isn't that built into netatalk3?

-r

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Rob Seastrom]

Larry Sheldon larryshel...@cox.net writes:

 On 3/7/2014 5:03 AM, Rob Seastrom wrote:

 for decades.  i have a vague recollection of an rfc that said
 secondary nameservers ought not be connected to the same psn (remember
 those?) but my google fu fails me this early in the morning.

 Packet Switch Node?

 Not sure what would be in this context.

 Not on the same router?  How about two routers away with both THEM on
 the same router (a third one)?

A PSN or IMP was an ARPANET/MILNET core router.  Some sites had more
than one.  A reasonable carry-forward of the concept would be that
nameservers ought to be geographically and topologically diverse so as
to avoid fate-sharing.  Different upstreams, different coasts (maybe
different continents?), different covering prefixes, and certainly not
on the same IPv4 /32...  would be the intelligent thing to do
particularly if one wants to query nanog@ about operational hinkiness
and not be on the receiving end of derisive chuckles.

 Not on a host that does anything else?

 Both of those actually make some sense to me, the first from a single
 point of failure consideration, the second regarding unrelated
 failures (I have to re-boot my windows PC at least once a day, most
 days because Firefox, the way I use it, gets itself tangled about that
 often and a reboot is the quickest way to clear it).

Can't hurt to have authoritative nameservers on dedicated VMs
(enterprise guys running AD have my sympathies), but that's not what
we're talking about here.

-r

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Rob Seastrom]

Thanks Bill.  Clearly my Google-fu was failing because of plugging in
anachronistic terms when searching for a document that is only barely
old enough to drive.

-r

bmann...@vacation.karoshi.com writes:

 RFC 2182



 On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote:
 
 Larry Sheldon larryshel...@cox.net writes:
 
  On 3/7/2014 5:03 AM, Rob Seastrom wrote:
 
  for decades.  i have a vague recollection of an rfc that said
  secondary nameservers ought not be connected to the same psn (remember
  those?) but my google fu fails me this early in the morning.
 
  Packet Switch Node?
 
  Not sure what would be in this context.
 
  Not on the same router?  How about two routers away with both THEM on
  the same router (a third one)?
 
 A PSN or IMP was an ARPANET/MILNET core router.  Some sites had more
 than one.  A reasonable carry-forward of the concept would be that
 nameservers ought to be geographically and topologically diverse so as
 to avoid fate-sharing.  Different upstreams, different coasts (maybe
 different continents?), different covering prefixes, and certainly not
 on the same IPv4 /32...  would be the intelligent thing to do
 particularly if one wants to query nanog@ about operational hinkiness
 and not be on the receiving end of derisive chuckles.
 
  Not on a host that does anything else?
 
  Both of those actually make some sense to me, the first from a single
  point of failure consideration, the second regarding unrelated
  failures (I have to re-boot my windows PC at least once a day, most
  days because Firefox, the way I use it, gets itself tangled about that
  often and a reboot is the quickest way to clear it).
 
 Can't hurt to have authoritative nameservers on dedicated VMs
 (enterprise guys running AD have my sympathies), but that's not what
 we're talking about here.
 
 -r
 

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Rob Seastrom]

bmann...@vacation.karoshi.com writes:

   sorry for the poor attempt at humour...
   it was ancient practice to hang many names (not cnames)
   off a single IP address. all perfectly legal from a DNS POV.

 rs.example.org. in a 10.10.10.53
 nick.example.com. in a 10.10.10.53
 bbss.isc.org. in a 10.10.10.53

it's also a poor practice operationally and one that's been deprecated
for decades.  i have a vague recollection of an rfc that said
secondary nameservers ought not be connected to the same psn (remember
those?) but my google fu fails me this early in the morning.
nevertheless, i direct our august audience to rfc 1537 section 6
(october 1993).  it's entirely reasonable to bring up this
configuration misstep in the context of things acting hinky.

   the punchline here was anycasting the address across multiple names.
   nary a routing trick in sight or in play.

When *I* use a word, Humpty Dumpty said, in rather a scornful tone,
it means just what I choose it mean to neither more nor less.'

   Lame I know.

   as a tool to defeat the autobots who insist on two nameservers
   for a delegation - its kind of a clever poke in the eye w/ a
   sharp stick.

I hear the owners' manual for Fords tells you how to turn off the seat
belt alarm too.  Clever in rather the same way.

-r

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Rob Seastrom]

Nick Hilliard n...@foobar.org writes:

  haven't you heard about anycast??

 rs probably has.  The owner of 199.73.57.122, probably not.

indeed.  there are many pieces of evidence that this is not an anycast
prefix.  proof is left as an exercise to those who can perform
traceroutes from multiple continents, run nmap -sP, log into
route-views, or do some combination of the above.

-r

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Rob Seastrom]

Paul S. cont...@winterei.se writes:

 For all it's worth, it might be Cox ignoring TTLs and enforcing their
 own update times instead.

 Wait 24-48 hours, and it should probably fix it all up.

Possibly.

 I'm not seeing anything majorly broken with your system except the SOA
 EXPIRE being ridiculously large.

Nowhere even close to ridiculously large.  360 (1 hours, 41
days) is the historical example value in RFC 1035.  It's a bit larger
than current recommended practices (2-4 weeks) but I wouldn't fault
anyone for using that value nor would I expect any nameserver software
to malfunction when confronted it.  Besides, that value only matters
to secondary nameservers.  Speaking of that...

;; ADDITIONAL SECTION:
ns1.nineplanetshosting.com. 172800 IN   A   199.73.57.122
ns2.nineplanetshosting.com. 172800 IN   A   199.73.57.122

I think OP ought to approach his hoster with a cluebat.  Not just on
the same subnet but the same address?  Really.

-r

Re: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences?

[Rob Seastrom]

Justin Wilson li...@mtin.net writes:

   The biggest problem with Mikrotik is you just can¹t call them up for
 support on buggy code. In a critical network this can be a major problem.

I've contacted them (via email) and the experience seems to be exactly
the same as dealing with first level TAC at the big guys: the guy you
contact doesn't care much about your problem once he realizes that
it's a legitimate issue with their stuff and not simply a case of
pilot error for which he can refer you to the documentation, and
eventually you give up and develop a workaround, such as it is.

-r

Re: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences?

[Rob Seastrom]

Dennis Burgess dmburg...@linktechs.net writes:

 Mikrotik really relies on its list of consultants and trainers,
 these are all outside companies, yes such as mine, that provide the
 higher class of support than MikroTik own e-mail. .  While their
 e-mail does have a lack of responsiveness, I was told the volume
 that they do get form other parts of the world, not saying that's an
 excuse, but it is what it is.

This wasn't a support issue; it was bug reports.  Things such as:

* your CLI has an incomplete implementation of the Emacs key bindings
  (detailed list elided here on nanog@for brevity's sake but if you've ever
  used Mikrotik kit and are a seasoned CLI user on C and J platforms
  you know what I'm talking about); please consider fixing or adopting
  libcli, gnu readline, or somesuch in future releases.

* your GRE implementation always has a protocol type of 0x0800 in the
  GRE header even when it is forwarding an IPv6 packet (packet dumps
  attached).

* ssh sessions crash when ServerAliveInterval SSH application layer
  keepalives kick off.  See http://www.openssh.org/faq.html section
  2.12 or http://www.kehlet.cx/articles/129.html To replicate: ssh -o
  ServerAliveInterval=120 admin@myrouter (to their credit this was
  eventually fixed in 5.x - this behavior was observed in 5.0rc4)

* /ping and /tool/traceroute fail for a DNS name for which there is
  no A record, only an  record (although both commands will
  accept an IPv6 address as digits).  This is still a problem today.

* When trying to remove files, it seems that they are not removed by
  number, but rather by name, despite what the online help says.

There was more stuff along those lines.  Thanks for the bug reports;
I made sure to open tickets for them but we can't commit to when or if
they'll get addressed due to competing priorities but they've
absolutely been documented would have been a fine reply; I completely
understand the Real World considerations involved and that my
priorities were not necessarily their priorities.  Unfortunately the
return email left me with the impression that nobody cared and that
they were not equipped to handle issues brought to their attention by
people with field experience, hence the unfavorable parallels to the
big guys.

Note that this has not kept my from speccing their kit when the task
calls for something that's surprisingly good considering how
inexpensive it is!  So maybe from a business perspective they were
entirely correct to blow me off - at least where it comes to revenue
attributable to Rob Seastrom, the negative impact has been nil.

-r

Re: turning on comcast v6

[Rob Seastrom]

Eric Oosting eric.oost...@gmail.com writes:

 It brings a tear to my eye that it takes:

 0) A long standing and well informed internet technologist;
 1) specific, and potentially high end, CPE for the res;
 2) specific and custom firmware, unsupported by CPE manufacturer ... or
 anyone;
 3) hand installing several additional packages;
 4) hand editing config files;
 5) sysctl kernel flags;
 6) several shout outs to friends and coworkers for assistance (resources
 many don't have access to);
 7) oh, and probably hours and hours twiddling with it.

 just to get IPv6 to work correctly.

 Yea, that's TOTALLY reasonable.

Pretty much works out of the box on Mikrotik RouterOS if you are
secure enough in your geek cred to admit to running such stuff here in
this august forum.

-r

Re: Naive IPv6 (was ATT UVERSE Native IPv6, a HOWTO)

[Rob Seastrom]

Brian Dickson brian.peter.dick...@gmail.com writes:

 Rob Seastrom wrote:

 Ricky Beam jfbeam at 
 gmail.comhttp://mailman.nanog.org/mailman/listinfo/nanog
 writes:
 
 * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom rs at seastrom.com
 http://mailman.nanog.org/mailman/listinfo/nanog wrote: *
 * So there really is no excuse on ATT's part for the /60s on uverse
 6rd... *
 * ... *
 * Handing out /56's like Pez is just wasting address space -- someone *
 * *is* paying for that space. Yes, it's waste; giving everyone 256 *
 * networks when they're only ever likely to use one or two (or maybe *
 * four), is intentionally wasting space you could've assigned to *
 * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *
 * the power of huge, but it's still finite. People like you are *
 * repeating the same mistakes from the early days of IPv4... * There's
 finite, and then there's finite. Please complete the
 following math assignment so as to calibrate your perceptions before
 leveling further allegations of profligate waste.
 Suppose that every mobile phone on the face of the planet was an end
 site in the classic sense and got a /48 (because miraculously,
 the mobile providers aren't being stingy).
 Now give such a phone to every human on the face of the earth.
 Unfortunately for our conservation efforts, every person with a
 cell phone is actually the cousin of either Avi Freedman or Vijay
 Gill, and consequently actually has FIVE cell phones on active
 plans at any given time.
 Assume 2:1 overprovisioning of address space because per Cameron
 Byrne's comments on ARIN 2013-2, the cellular equipment providers
 can't seem to figure out how to have N+1 or N+2 redundancy rather
 than 2N redundancy on Home Agent hardware.
 What percentage of the total available IPv6 space have we burned
 through in this scenario? Show your work.
 -r


 Here's the problem with the math, presuming everyone gets roughly the same
 answer:
 The efficiency (number of prefixes vs total space) is only achieved if
 there is a flat network,
 which carries every IPv6 prefix (i.e. that there is no aggregation being
 done).

 This means 1:1 router slots (for routes) vs prefixes, globally, or even
 internally on ISP networks.

 If any ISP has  1M customers, oops. So, we need to aggregate.

 Basically, the problem space (waste) boils down to the question, How many
 levels of aggregation are needed?

 If you have variable POP sizes, region sizes, and assign/aggregate towards
 customers topologically, the result is:
 - the need to maintain power-of-2 address block sizes (for aggregation),
 plus
 - the need to aggregate at each level (to keep #prefixes sane) plus
 - asymmetric sizes which don't often end up being just short of the next
 power-of-2
 - equals (necessarily) low utilization rates
 - i.e. much larger prefixes than would be suggested by flat allocation
 from a single pool.

 Here's a worked example, for a hypothetical big consumer ISP:
 - 22 POPs with core devices
 - each POP has anywhere from 2 to 20 border devices (feeding access
 devices)
 - each border has 5 to 100 access devices
 - each access device has up to 5000 customers

 Rounding up each, using max(count-per-level) as the basis, we get:
 5000-8192 (2^13)
 100-128 (2^7)
 20-32 (2^5)
 22-32 (2^5)
 5+5+7+13=30 bits of aggregation
 2^30 of /48 = /18
 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
 A thousand ISPs seems like a lot, but consider this: the ISP we did this
 for, might only have 3M customers.
 Scale this up (horizontally or vertically or both), and it is dangerously
 close to capacity already.

 The answer above (worked math) will be unique per ISP. It will also drive
 consumption at the apex, i.e. the size of allocations to ISPs.

 And root of the problem was brought into existence by the insistence that
 every network (LAN) must be a /64.

 That's my 2 cents/observation.

 Brian

At a glance, I think there's an implicit assumption in your
calculation that each ISP has to be able to hold the whole world
(unlikely) and/or there is no such thing as mobile IP or any other
kind of tunneling technology going on within the mobile network (also
wrong from everything I understand).

Also, I'm not sure where from the current /8 comes from, as there's
a /3 in play (1/8 of the total space, maybe that was it?) and each 
RIR is getting space in chunks of /12...

Re-working your conclusion statement without redoing the math, This
leaves room for 2^15 such ISPs (a mere 16384), from the current /3.

Oddly enough, I'm OK with that.  :)

-r

Re: ATT UVERSE Native IPv6, a HOWTO

[Rob Seastrom]

Cutler James R james.cut...@consultant.com writes:

 Does this mean we can all get back to solving real IPv6 deployment and 
 operations problems?

I sure hope so.  :)

 I certainly hope you all can finally see which is the better business choice 
 between: 

  1. Using up to around 10% of IPv6 space to make our network operations 
 simpler for the next twenty years or more.

You're high by more than an order of magnitude.  Inasmuch as I don't
hail from Chicago, I'm not suggesting actually issuing addresses to
people who are dead (Eric's final datapoint).

  2. Continuing to spend time and money on micromanagement of addressing 
 rather than real customer needs.

 One who cannot properly understand the business decision here perhaps should 
 not be debating network policies.

 Strongly worded letter to follow.

Indeed.

-r

Re: ATT UVERSE Native IPv6, a HOWTO

[Rob Seastrom]

jean-francois.tremblay...@videotron.com writes:

 IPv4-thinking.  In the fullness of time this line of reasoning [...]

 Hopefully, the fullness of time won't apply to 6RD (this is what
 was being discussed here, not dual-stack).

I agree but there's a subtlety here - we don't want to get people used
to parsimony in IPv6-land via chintzing out on deployments with a
transition technology.  There are dinosaurs in every organization who
cling to the monetizing addresses/subnets model and will want to
charge more for a /48 or a /56 and point to the market being used to a
/60 or a /64, and it becomes the unfortunate task for folks like us to
argue against that line of thinking.  We've got a little over two
decades worth of IPv4 penny-pinching to undo here, and the interim
deployments ought to help that to the degree possible.

 Most MSOs are planning /56s for native. ARIN 2011-3 is great, but
 it came a bit late (January 2012) for those who already had planned
 their network.

Yep, we're planning /56es for native at $DAYJOB too.  Worse than /48s,
not as bad as /64s or /60s.  Not that ARIN policies constrain this at
all; it was certainly possible before 2011-3 to get more than a /32 of
space, it just wasn't as easy (certainly there was more than one org
that managed to do it).  As for the 6rd part, there was no 2010-12 6rd
policy before December 2010...  then again, before August 2010 there
was no 6rd.  :)  I'm unfortunately quite familiar with the internal
costs of a do-over in a large organization.

-r

Re: ATT UVERSE Native IPv6, a HOWTO

[Rob Seastrom]

Ricky Beam jfb...@gmail.com writes:

 On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom r...@seastrom.com wrote:
 So there really is no excuse on ATT's part for the /60s on uverse 6rd...
 ...
 Handing out /56's like Pez is just wasting address space -- someone
 *is*  paying for that space. Yes, it's waste; giving everyone 256
 networks when  they're only ever likely to use one or two (or maybe
 four), is  intentionally wasting space you could've assigned to
 someone else. (or  **sold** to someone else :-)) IPv6 may be huge to
 the power of huge, but  it's still finite. People like you are
 repeating the same mistakes from  the early days of IPv4...

There's finite, and then there's finite.  Please complete the
following math assignment so as to calibrate your perceptions before
leveling further allegations of profligate waste.

   Suppose that every mobile phone on the face of the planet was an end
   site in the classic sense and got a /48 (because miraculously,
   the mobile providers aren't being stingy).

   Now give such a phone to every human on the face of the earth.

   Unfortunately for our conservation efforts, every person with a
   cell phone is actually the cousin of either Avi Freedman or Vijay
   Gill, and consequently actually has FIVE cell phones on active
   plans at any given time.

   Assume 2:1 overprovisioning of address space because per Cameron
   Byrne's comments on ARIN 2013-2, the cellular equipment providers
   can't seem to figure out how to have N+1 or N+2 redundancy rather
   than 2N redundancy on Home Agent hardware.

What percentage of the total available IPv6 space have we burned
through in this scenario?  Show your work.

-r

Re: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond

[Rob Seastrom]

Matthew Petach mpet...@netflight.com writes:

 Using a 1/10th of a second interval is rather anti-social.
 I know we rate-limit ICMP traffic down, and such a
 short interval would be detected as attack traffic,
 and treated as such.

This should be obvious to everyone here but just in case, there's also
a huge difference between hammering the control plane of every router
along the path due to TTL expiration (mtr) and trying to smoke out
intermittent performance problems between end points with a few
hundred packets/second of various sizes of icmp or udp *between those
end points*.  Folks should expect the former to be rate limited - a
reasonable control plane policing policy is not optional these days.

-r

Re: ATT UVERSE Native IPv6, a HOWTO

[Rob Seastrom]

I'd like to call everyone's attention to ARIN's policy on IPv6
transition space https://www.arin.net/policy/nrpm.html#six531 which
was created specifically in response to the standardization of 6rd.

The discussion at the time that this policy was under consideration
was that encoding the [m,n] in a non-overlapping fashion when one has
a bajillion allocations due to slow start was a pain in the butt and
that, in practice, everyone would just encode 32 bits of IPv4 into 6rd.

Note that it's possible to get a /24 of IPv6 space (huge!).  Yes, it's
from space that is tainted as being marked as transition space.
Yes, you have to recertify that you're using it for the intended
purpose every three years.

Of course, 24 + 32 = 56.  This is not an accident.  It was our sense
at the time that /56 was bad enough and that there was no reason to
codify giving people an even more parsimonious slice of IPv6 space.

So there really is no excuse on ATT's part for the /60s on uverse 6rd...

-r

Re: ATT UVERSE Native IPv6, a HOWTO

[Rob Seastrom]

jean-francois.tremblay...@videotron.com writes:

 Offering /48s out of a single /16 block, to take a simple example, 
 would use a whole /32.

Sounds as if your organization can justify more than the /32
minimum/default allocation of IPv6 then (I'd imagine you have more
than a minimum-assignment /22 of IPv4 space based on my interactions
with Videotron back circa 2004 too).  Have you tried asking for more
IPv6 space, backed up with your network architecture documents?

 This space wouldn't be used much anyway, 
 given that most 6RD routers use only one /64, sometimes two. 
 I argue that a /60 is actually the best compromise here, from 
 a space and usage point of view. 

IPv4-thinking.  In the fullness of time this line of reasoning will be
greeted with the same wry grin and eyeroll that the NANOG community
today reserves for academics who teach their students classful
networking.

-r

Re: Meraki

[Rob Seastrom]

Ray Soucy r...@maine.edu writes:

 Can confirm the current ER Lite is a plastic enclosure.

I got mine almost a year ago, and mine is plastic too.

 But for $ 100 I can definitely look past that.

Likewise.

 I believe the chips they use are from Cavium [1], but I could be mistaken.

The bootloader output agrees with you :)

-r