Re: GeoIP database issues and the real world consequences

[Joel Maslak]

On Mon, Apr 11, 2016 at 3:09 PM, Owen DeLong  wrote:


> So really, what is needed is two additional fields for the lat/lon of
> laterr/lonerr so that, for example, instead of just 38.0/-97.0, you would
> get 38.0±2/-97.0±10 or something like that.
>

It does seem needed to the geo location companies too, at least several of
them provide this - and it's been this way for a long time.

I didn't remember if Maxmind does or not, so I just checked.  From some of
their documentation, the field "accuracy_radius" is returned which is "The
radius in kilometers around the specified location where the IP address is
likely to be." See
http://dev.maxmind.com/geoip/geoip2/web-services/#location .  I don't think
it's in their free stuff (you get what you pay for, it seems).

It doesn't show up on their web interface to "try" the service nor does it
give a warning that these things can be wrong, but IMHO probably wouldn't
be a bad idea to say "Don't go show up at this address - it might not be
right!"

Re: Internet Exchanges supporting jumbo frames?

[Joel Maslak]

On Wed, Mar 9, 2016 at 9:27 AM, joel jaeggli  wrote:

> PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> > my opinion (although it's strange how many hosts that seem to get away
> > with 1492 (or is it 1496) MTU because they're using PPPoE).
>
> if your adv_mss is set accordingly you can get away with
>  a lot.
>

At least for TCP.  EDNS with sizes > 14xx bytes just plain doesn't
universally work across the internet, yet it's the default everywhere.

Static IPs

[Joel Maslak]

A helpful hint from a local broadband provider (I'm trying to wade through
broadband options at home):

"If your business is online, then you should have an IP address."

I do find that helps.

(in fairness, they are talking about static IPs, but it kind of fits with
the rest of their marketing which says their highest speed plans include
the advantage of "most reliable Wifi" when compared to their lower speed
plans)

Re: Extraneous "legal" babble--and my reaction to it.

[Joel Maslak]

Postel's Law seems relevant to this issue.

Sorry for contributing to the noise.

Re: RES: Exploits start against flaw that could hamstring huge swaths of

[Joel Maslak]

On Tue, Aug 4, 2015 at 4:53 PM, Randy Bush ra...@psg.com wrote:

 i love the devops movement; operators discover that those computers can
 be programmed.  wowzers!


Maybe we can give them a new title.  I'm thinking, System Programmer.

Re: Android (lack of) support for DHCPv6

[Joel Maslak]

Agreed - apparently the solution is to implement SLAAC + DNS advertisements
*AND* DHCPv6.  Because you need SLAAC + DNS advertisements for Android, and
you need DHCPv6 for Windows.

Am I the only one that thinks this situation is stupid?

On Tue, Jun 9, 2015 at 1:17 PM, Randy Bush ra...@psg.com wrote:

 i love this discussion.  another enterprise wants to use ipv4 with
 minimal change from ipv4, has problems, and the usual suspects tell
 them to drink koolaid.

 and we wonder at the pitiful ipv6 deployment.

 randy

Re: Android (lack of) support for DHCPv6

[Joel Maslak]

Most APs don't support bridging, not enough addresses in the protocol
(without enabling WDS or whatever modern versions of that are).

On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams c...@cmadams.net wrote:

 Once upon a time, valdis.kletni...@vt.edu valdis.kletni...@vt.edu said:
  On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said:
   Hope the question doesn't make me look like an idiot, but why does
 using
   stateful DHCPv6 mean having to go back to NAT?
 
  How does the device ask for a *second* DHCPv6'ed address for tethering or
  whatever?

 It's called bridging.  Let whatever is being tethered ask directly for
 its own address.
 --
 Chris Adams c...@cmadams.net

Re: Android (lack of) support for DHCPv6

[Joel Maslak]

Of course I've been up too long, ignore the idiot (me).  :)

On Tue, Jun 9, 2015 at 9:37 PM, Joel Maslak jmas...@antelope.net wrote:

 Most APs don't support bridging, not enough addresses in the protocol
 (without enabling WDS or whatever modern versions of that are).

 On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams c...@cmadams.net wrote:

 Once upon a time, valdis.kletni...@vt.edu valdis.kletni...@vt.edu said:
  On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said:
   Hope the question doesn't make me look like an idiot, but why does
 using
   stateful DHCPv6 mean having to go back to NAT?
 
  How does the device ask for a *second* DHCPv6'ed address for tethering
 or
  whatever?

 It's called bridging.  Let whatever is being tethered ask directly for
 its own address.
 --
 Chris Adams c...@cmadams.net

Re: gmail security is a joke

[Joel Maslak]

I also suspect not every telco validates number porting requests against
social engineering properly.

A telephone number isn't something you have, it is something your provider
has.

On Wednesday, May 27, 2015, Saku Ytti s...@ytti.fi wrote:

 On (2015-05-27 14:19 +0200), Owen DeLong wrote:

 Hey,

  If someone has the ability to hijack your BGP, then you???ve got bigger
 problems than
  having them take over your Gmail account.

 This is second reply to this notion. I don't understand what is attempted
 to
 communicate. I'm sure no one on nanog thinks BGP hijacks are rare,
 difficult
 or yield to consequences when called out.

  That???s interesting??? Why do you choose to give access to your
 personal SMS messages
  to so many of your coworkers?

 I don't, but they can provision my number to any SIM they want to.

 --
   ++ytti

Re: Rasberry pi - high density

[Joel Maslak]

Rather then guessing on power consumption, I measured it.

I took a Pi (Model B - but I suspect B+ and the new version is relatively
similar in power draw with the same peripherials), hooked it up to a lab
power supply, and took a current measurement.  My pi has a Sandisk SD card
and a Sandisk USB stick plugged into it, so, if anything, it will be a bit
high in power draw.  I then fired off a tight code loop and a ping -f from
another host towards it, to busy up the processor and the network/USB on
the Pi.  I don't have a way of making the video do anything, so if you were
using that, your draw would be up.  I also measured idle usage (sitting at
a command prompt).

Power draw was 2.3W under load, 2.0W at idle.

If it was my project, I'd build a backplane board with USB-to-ethernet and
ethernet switch chips, along with sockets for Pi compute modules (or
something similar).  I'd want one power cable and one network cable per
backplane board if my requirements allowed it.  Stick it all in a nice card
cage and you're done.

As for performance per watt, I'd be surprised if this beat a modern video
processor for the right workload.


On Mon, May 11, 2015 at 5:16 PM, Rafael Possamai raf...@gav.ufsc.br wrote:

 Maybe I messed up the math in my head, my line of thought was one pi is
 estimated to use 1.2 watts, whereas the nuc is at around 65 watts. 10 pi's
 = 12 watts. My comparison was 65watts/12watts = 5.4 times more power than
 10 pi's put together. This is really a rough estimate because I got the
 NUC's power consumption from the AC/DC converter that comes with it, which
 has a maximum output of 65 watts. I could be wrong (up to 5 times) and
 still the pi would use less power.

 Now that I think about it, the best way to simplify this is to calculate
 benchmark points per watt, so rasp pi is at around 406/1.2 which equals
 338. The NUC, roughly estimated to be at 3857/65 which equals 60. Let's be
 very skeptical and say that at maximum consumption the pi is using 5 watts,
 then 406/5 is around 81. At this point the rasp pi still scores better.

 Only problem we are comparing ARM to x86 which isn't necessarily fair (i am
 not an expert in computer architectures)





 On Mon, May 11, 2015 at 5:24 PM, Hugo Slabbert h...@slabnet.com wrote:

  Did I miss anything? Just a quick comparison.
 
 
  If those numbers are accurate, then it leans towards the NUC rather than
  the Pi, no?
 
  Perf:   1x i5 NUC = 10x Pi
  $$: 1x i5 NUC = 10x Pi
  Power:  1x i5 NUC = 5x Pi
 
  So...if a single NUC gives you the performance of 10x Pis at the capital
  cost of 10x Pis but uses half the power of 10x Pis and only a single
  Ethernet port, how does the Pi win?
 
  --
  Hugo
 
 
  On Mon 2015-May-11 17:08:43 -0500, Rafael Possamai raf...@gav.ufsc.br
  wrote:
 
   Interesting! Knowing a pi costs approximately $35, then you need
  approximately $350 to get near an i5.. The smallest and cheapest desktop
  you can get that would have similar power is the Intel NUC with an i5
 that
  goes for approximately $350. Power consumption of a NUC is about 5x that
  of
  the raspberry pi, but the number of ethernet ports required is 10x less.
  Usually in a datacenter you care much more about power than switch
 ports,
  so in this case if the overhead of controlling 10x the number of nodes
 is
  worth it, I'd still consider the raspberry pi. Did I miss anything?
 Just a
  quick comparison.
 
 
 
  On Mon, May 11, 2015 at 4:40 PM, Michael Thomas m...@mtcc.com wrote:
 
   As it turns out, I've been playing around benchmarking things lately
  using
  the tried and true
  UnixBench suite and here are a few numbers that might put this in some
  perspective:
 
  1) My new Rapsberry pi (4 cores, arm): 406
  2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857
  3) AWS c4.xlarge (4 cores, ~8gb's): 3666
 
  So you'd need to, uh, wedge about 10 pi's to get one half way modern
 x86.
 
  Mike
 
 
  On 5/11/15 1:37 PM, Clay Fiske wrote:
 
   On May 8, 2015, at 10:24 PM, char...@thefnf.org wrote:
 
 
  Pi dimensions:
 
  3.37 l (5 front to back)
  2.21 w (6 wide)
  0.83 h
  25 per U (rounding down for Ethernet cable space etc) = 825 pi
 
  Cable management and heat would probably kill this before it ever
  reached completion, but lol…
 
 
  This feels like it should be a Friday thread. :)
 
  If you’re really going for density:
 
  - At 0.83 inches high you could go 2x per U (depends on your mounting
  system and how much space it burns)
  - I’d expect you could get at least 7 wide if not 8 with the right
  micro-USB power connector
  - In most datacenter racks I’ve seen you could get at least 8 deep
 even
  with cable breathing room
 
  So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get
  truly creative about how you stack them you could probably beat that
  without too much effort.
 
  This doesn’t solve for cooling, but I think even at these numbers you
  could probably make it work with nice, tight cabling.
 
 
 

Re: Network Segmentation Approaches

[Joel Maslak]

I'd certainly forget anything with service provider in the name.
Different problem, different architecture.

Last time I built this, I built a core network (WAN links, routers, etc)
that enforced anti-spoofing rules, so I knew if I saw an internal IP
address (either public assigned to me or RFC1918) on a given device inside
this core, it came from the network segment it claimed to have come from.

Then I built building-specific firewalls using proper firewalls.  These
might have anywhere from two interfaces (branch office) to thousands of
interfaces (datacenters) with lots of VLANs.  Checkpoint is a good product
for this.  The firewalls' job was to protect the building/segments behind
it, not to protect things upstream (towards the core) of it.  There was
obviously an edge firewall.

Users were segmented by job role.  Workstations were typically considered
to be *MORE* secure from a network perspective.  AD servers need to be
contacted by everything in your Windows domain. Most workstations don't.
And your Windows domain, nowadays, probably includes cloud services over
the internet.  So it's hard to say AD servers are secure from a purely
how many open network ports are there? standpoint.  Servers were likewise
segmented.  I'd consider putting department file servers on the same LAN as
the users, but only if performance required it - otherwise I'd put them on
their own segments too.

The benefit of this in a large organization is that a subdivision could put
a firewall behind one of my anti-spoofing interfaces (so I validate packets
come from them) and run it themselves without ruining everyone else's
security.

I second the thoughts about embedded management stacks.

As for management, I put workstations used by IT management on their own
segment (and give them a Stand up the infected workstation you're working
on LAN separate from that segment).  I put servers used for management on
yet another segment.  I've never had a problem with giving those
workstations and servers access to management segments in the wild, but I
trusted my skilled admins I worked with.

Think mesh of connections, not tiers or levels or DMZs.  Because you'll
find that super-secure accounting server needs access from some random
vendor across the internet, and stuff like that, such that everything
eventually ends up in the DMZ anyhow (except MAYBE workstations).

You can use separate firewalls for particularly sensitive segments - for
instance, your management stuff might not be behind your main firewall -
that way when Joe User gets a virus and fills the connection table on his
firewall(s), you can still manage things.

One more thing: Guest network access.  When it was needed, I built a
virtual network on top of the real Corporate LAN that tunneled this
around.  I terminated it on a DSL modem (which was sufficient for my
needs).  Just about every building with a conference room these days will
need a guest network. It also helps if your employees can use their cell
phones for checking work email and such - do you really want them on your
main LAN?


On Tue, May 5, 2015 at 7:01 AM, Keith Medcalf kmedc...@dessus.com wrote:


 It is called the Purdue Enterprise Reference Architecture ...

  -Original Message-
  From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of
  nan...@roadrunner.com
  Sent: Monday, 4 May, 2015 20:56
  To: nanog@nanog.org
  Subject: Network Segmentation Approaches
 
  Possibly a bit off-topic, but curious how all of you out there segment
  your networks.  Corporate/business users, dependent services, etc. from
  critical data and/or processes with remote locations thrown in the mix
  which could be mini-versions of your primary network.
 
  There's quite a bit of literature out there on this, so have been
  considering an approach with zones based on the types of data or
  processes within them.  General thoughts:
 
  - Business Zone - This would be where workstations live,
web browsing occurs, VoIP and authentication services live too.
Probably consider this a somewhat dirty zone, but I should
generally be OK letting anything in this zone talk fairly unfettered
to anything else in this zone (for example a business network at my
HQ location should be able to talk unfettered to an equivalent
network at a remote site).
 
I'd probably have VoIP media servers in this zone, AD, DNS, etc.
 
  - Some sort of management zone(z) - Maybe accessible only via jump host
-- this zone gives control access into key resources (most likely
IT resouces like network devices, storage devices, etc.).  Should
have sound logging/auditing here to establish access patterns outsid
the norm and perhaps multi-factor authentication (and of course
FW's).
 
  - Secure Zone(s) - Important data sets or services can be isolated from
untrusted zones here.  May need separate services (DNS, AD, etc.)
 
  - I should think carefully about where I stick stateful FW's --
especially on 

Re: BCOP appeals numbering scheme -- feedback requested

[Joel Maslak]

You'll get more comments about the numbering scheme than any actual BCOP...

On Thu, Mar 12, 2015 at 1:01 PM, Yardiel D. Fuentes yard...@gmail.com
wrote:



 Hello NANOGers,

 The  NANOG BCOP committee is currently considering strategies on how to
 best create a numbering scheme for the BCOP appeals. As we all know, most
 public technical references (IETF, etc) have numbers to clarify references.
 The goal is for NANOG BCOPs to follow some sort of same style.

 The BCOP committee is looking for feedback and comments on this topic.

 Currently, the below numbering scheme is being considered:

 A proposed numbering scheme can be based on how the appeals appeals in the
 BCOP topics are presented as shown below:

 http://bcop.nanog.org/index.php/Appeals

 In the above page, the idea is to introduce a 100-th range for each
 category and as the BCOPs. This way a 100th number range generally
 identifies each of the categories we currently have. An example is:

 BCP Range   Area of Practice
 100 - 199   EBGPs
 200 - 299   IGPs
 300 - 399   Ethernet
 400 - 499   Class of Service
 500 - 599   Network Information Processing
 600 - 699   Security
 700 - 799   MPLS
 800 - 899   Generalized

 An arguable objection could be that the range is limited...but a
 counter-argument is that considering more than 100 BCOPs would be either a
 great success or just a sign of failure for the NANOG community ...

 Comments or Thoughts ?


 Yardiel Fuentes

Re: Checkpoint IPS

[Joel Maslak]

On Thu, Feb 5, 2015 at 10:47 AM, Roland Dobbins rdobb...@arbor.net wrote:


 On 6 Feb 2015, at 0:38, Raymond Burkholder wrote:

  There must some sort of value in that?

 No - patch the servers.


Patching servers protects against 0 Day attacks only.

This does not protect against 0 day attacks, unless you know of an OS
vendor that writes good code without security holes.

What type of device needed depends on risk, what you are protecting, what
attacks are important, etc.  It's not a simple matter of firewall bad or
firewall good.

I won't even get into the stateless-vs-stateful debate, because it's more
complex than stateful bad (*cough* SIP *cough*). Nor will I mention that
it depends on what your protecting to figure out how much of each of
availability or confidentiality or integrity you need - you might need lots
of integrity but little availability, for instance.

Re: DDOS solution recommendation

[Joel Maslak]

On Sun, Jan 11, 2015 at 6:46 AM, Mike Hammett na...@ics-il.net wrote:


 You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to
 my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web,
 etc. You have more than say 5 bad login attempts to my mail server in 5
 minutes, blackholed for 30 days. You're trying to access various web pages
 known for home router or Wordpress exploitation, blackholed for 30 days.


I urge caution in building automatic systems to respond to network abuse,
lest you have unanticipated consequences.

How are you tracing the source for DNS UDP, NTP UDP, etc, requests?  Or TCP
SYNs?  If you say source address in the packet, you might not be doing what
you think you're doing.  Or for that matter HTTP accesses.  Without giving
too much discussion, let me point out:

1) You can forge a victim's IP and send packets to a honeypot (or indeed
the entire IPv4 internet if you want). You may not want to assume I see a
packet with this claimed source being sent to X, so it must be a bad guy
and I should block it.

2) Web crawlers will follow links from Bad Guy's Site to your website, even
if these links might match an IDS signature on your end.  You may not want
to block some search engine crawlers.

3) Legitimate recursive DNS servers can be made to connect to any IP
address a bad guy wants them to connect to. You may not want to block some
ISP's recursive DNS servers.

There are good things to do automatically, but make sure you think them
through.

I used to do click fraud detection 15 years ago - when that was still a new
field and we all were inventing our own ways of doing it.  I was amazed at
the number of ways a bad guy could do an HTTP request from millions of
source IPs (hint: they weren't spoofed).  I suspect it hasn't gotten better.

The internet isn't able to be broken because the people building and
running it are idiots.  It's able to be broken because breaking things has
always been far easier than building them.  It takes much more
intelligence, skill, and expertise to build a glass window than to throw a
brick through one.

Re: Cisco CCNA Training

[Joel Maslak]

You might look at your local community college's offerings.  Probably
better bang for the buck than many other offerings.

On Sun, Nov 2, 2014 at 10:02 AM, Colton Conor colton.co...@gmail.com
wrote:

 We have a couple of techs that want to learn cisco and networking in
 general. What do you recommend for learning and getting certified on Cisco?
 There seems to be a million different training courses, books, etc out
 there.

Re: L6-20P - L6-30R

[Joel Maslak]

You probably should ask your facility operator or electrician what the
requirements are (who, unlike most network engineers, is qualified to
decide what to do), but it sounds like replacing the PDU is simple and
easy, and unquestionably not a bad thing to do.

Alternatively, you can replace the 30A circuit with a 20A one.  I'm not an
electrician, but I'll bet it's not much more complex or expensive than
replacing a breaker and a receptacle, and I'd be shocked if it took more
than an hour of a qualified person's time, and I suspect it would cost
about the same for parts as building some sort of adaptor cord (and less if
you the electrician has spare parts - he gets a 30A breaker and 30A socket
in exchange for a 20A breaker and 20A socket).  The added benefit of 20A,
assuming your equipment power usage is low enough to use 20A, is that it's
usually cheaper (sometimes significantly) if you're paying someone else for
the power circuit each month.

Re: valley free routing?

[Joel Maslak]

I have worked for the middle network when I was responsible for a
government network - typically we were the middle network.  Logic was it
was good for citizens for us to essentially act like a peering exchange for
certain types of entity (who also typically were government affiliated).
One I can think of was to allow a full mesh of video education between
various institutions - it was the right thing to do for all entities
involved and I facilitated it through the network I was affiliated with.

You might also think about the circumstance of two government
subcontractors working on a common project or interfacing with each other's
systems on behalf of a common customer.  The middle network is paying each
end to connect to the middle but is providing reverse transit between them
(I.E. the end entities are paid to transit the middle!), although the
contracts aren't exactly phrased to say that!  A lot of time, this may be
done with static routes, but it could easily be done with BGP and the end
effect is the same.

I have never heard the term valley free.  Where does it come from?
On Mar 5, 2014 1:25 PM, William Herrin b...@herrin.us wrote:

 Hi folks,

 Can anyone tell me about a situation in which a route which was not
 valley free was not a result of a misconfiguration or a bad actor? For
 those who don't recall the terminology, a network path is valley free
 if it crosses exactly zero or one free peering links when traveling
 between the two endpoints.

 Thanks,
 Bill Herrin


 --
 William D. Herrin  her...@dirtside.com  b...@herrin.us
 3005 Crane Dr. .. Web: http://bill.herrin.us/
 Falls Church, VA 22042-3004

Re: home network monitoring and shaping

[Joel Maslak]

I've had great luck with Cisco's fair-queue option (and similar
techniques).  Using RED, small queues (think on the order of 10-20
packets), and creating a choke point in and out of the network, I've
implemented similar behavior on plenty of DSL lines on the CPE-side.  My
most successful was sharing one 7mbps line with 120 technical employees -
before the implementation of improved queuing, web pages took 60 seconds or
more to load during peak usage.  After implementation, people didn't know
they were on a shared DSL unless they tried streaming video (fortunately
not a business requirement) or a bulk download (it worked fine, it just
would be slow if there were several others going on at the same time).  I
suspect I could have even made a VoIP call across the line with a MOS in
the high 3's easily.

A second issue is poor wireless retransmission and buffering
implementations in consumer wireless.  For my home, to make VoIP work with
low-end gear, I had to break most HTTP sessions and switch to a delay-based
congestion control algorithm inside my network - due to the 5+ second
buffers on the wifi gear.  That would probably have been enough, but
turning on WMM really took the rest of the pain out of wifi-VoIP.

I don't know how to fix the home wifi problems (WMM helps with some
applications, certainly, but it's not a full solution if you still have 5
second buffers in the default traffic class).  But for the other problems,
it would be nice if my provider didn't give me huge buffers and no RED on
the output queue (I have no idea if they are doing the best they can with
the gear they have or not, so there may not be any option here).  But, even
without that, home routers can do better than they do now.  My router knows
what speed it's connected at.  It can create an internal bottleneck
slightly slower, prioritize small packets, implement RED, and use
reasonably-sized buffers (fast downloads should not increase ping times by
hundreds of ms).  I shouldn't need to hang a Linux box between it and my
home network.

Large buffers have broken the average home internet.  I can't tell you how
many people are astonished when I say one of your family members
downloading a huge Microsoft ISO image (via TCP or other congestion-aware
algorithm) shouldn't even be noticed by another family member doing web
browsing.  If it is noticed, the network is broke.  Even if it's at the end
of a slow DSL line.

Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)

[Joel Maslak]

On Tue, Oct 23, 2012 at 9:18 AM, Mike Jones m...@mikejones.in wrote:
 IPv4 addresses ending in .0 and .255 can't be used either because the
 top and bottom addresses of a subnet are unusable.

 Why would hetzner be making such assumptions about what is and is not
 a valid address on a remote network? if you have a route to it then it
 is a valid address that you should be able to exchange packets with,
 any assumptions beyond that are almost certainly going to be wrong
 somewhere.

As to why: I suspect they don't know either.  I wouldn't be surprised
if it was someone's misguided attempt years ago to stop smurf
amplification attacks, long since forgotten.  I'm not saying it's a
good idea (it's not), just why I suspect someone would do this.

Centurylink Contact

[Joel Maslak]

Does anyone have a good contact to report outside plant issues in the
Denver, CO area?

Some construction equipment in my neighborhood snagged and snapped a
messenger cable between poles, and probably stretched some copper.
I'd like to make sure that CL actually gets notified and gets it
fixed.  My line is fine, so their automated residential customer
service line wasn't helping me at all.

Re: Color vision for network techs

[Joel Maslak]

On Aug 31, 2012, at 12:27 PM, JC Dill jcdill.li...@gmail.com wrote:

 So if you DO decide to test for color vision, make sure you know your rights 
 and responsibilities for handling any employee or applicant who fails the 
 test.
 
 IANAL - if you have any questions be sure to get advice from an attorney - 
 preferably one who specializes in employment law.

Agreed.  It's also a good idea to check with JAN if you're in the US, to see 
what accommodations they might suggest.  I'd also add that it's the decent 
thing to do - if someone is qualified for the job, except for not being able to 
do one small part of the job the way you would imagine it being done, the right 
response is to find solutions, not immediately dismiss the qualified applicant.

I had some involvement in the past with employees with vision disabilities.  
Many are trivial to accommodate.

Tools I've personally seen used are the Seekey and colored pieces of plastic 
(overlays).  The overlays are very cheap, not sure how much a Seekey costs.  
I'd also suggest asking the employee, since they have a vested interest in 
finding a solution.   These would also work for terminating twisted pair cables.

I've also seen an electronic pen-like device that was used by blind people, to 
determine if an LED was lit. We used this for a phone receptionist who needed 
to scan busy lights on a telephone while handling calls (I'd probably look at 
a softphone type solution today, but the phone system we used was definitely 
not softphone capable!).  I don't know if it can tell the difference between 
red or green, nor do I remember what the thing was called.

(also note that, depending on environment, reasonable accommodation might 
also mean asking a coworker what color the light is)

Re: DDoS using port 0 and 53 (DNS)

[Joel Maslak]

On Wed, Jul 25, 2012 at 8:43 AM, John Kristoff j...@cymru.com wrote:

 Some UDP applications will use zero as a source port when they do not
 expect a response, which is how many one-way UDP-based apps operate,
 though not all.  This behavior is spelled out in the IETF RFC 768:

That would only be applicable if the box was expecting to receive UDP
and not send a response.  I'm not sure I can think of anything but
specialized, vertical applications that would have that behavior with
port zero (syslog and SNMP traps send without expecting a response,
but they don't use port zero in any implementation I've seen, and
neither is generally allowed to be received from the internet at
large).

In addition to the fragments, these packets might also be non-TCP/UDP
(ICMP, GRE, 6to4 and other IP-IP, etc).  If the host doesn't expect to
receive large UDP packets, you can block UDP fragments.  Note that
recursive DNS servers would need UDP fragments (well, if you want to
do large DNS packets - if you set the right options, you can turn that
off).  But if you aren't generally providing UDP services, blocking
UDP packets, especially to stop an attack, wouldn't hurt (you can also
block anything with the MF bit set).  If you block these fragments at
your provider's router, and it is a DNS amplification attack, you're
problems are probably solved until the hacker figures it out.  Just
make sure you think of things like recursive DNS and other
applications that may be using UDP fragments.

Re: technical contact at ATT Wireless

[Joel Maslak]

On Thu, Jun 28, 2012 at 1:35 PM, PC paul4...@gmail.com wrote:

 While you're at it, I've been also trying to complain about them using
 RFC1918 (172.16.) address space for the DNS servers they assign to their
 datacard subscribers.  Causes all sorts of problems with people trying to
 VPN in as the same IP range is used by me.

Which is why enterprises generally shouldn't use RFC1918 IPs for
servers when clients are located on networks not controlled by the
same entity.  Servers that serve multiple administration domains (such
as VPN users on ATT - or on some random home Linksys box) probably
shouldn't be addressed using addresses that conceivably could be used
at the other end.  But I'm probably fighting a losing battle saying
that...

It's why at my last enterprise net admin jobs, I refused to establish
a site-to-site VPN session with organizations using RFC1918 space as
part of the tunnel definition (it's amazing how few organizations
wanted to use global IPs for inter-domain routing, but most came
around, although I had to loan IP addresses to several so they could
static NAT their servers behind them).  It's simple: If I wouldn't
accept IPs in that range over a public BGP peering, I didn't want it
over a private static route either.  I couldn't control what you did
for RFC1918, nor could you control what I did - so I exposed public
IPs, and expected you to do the same.  :)

RFC1918 and VPN becomes non-scalable fast when you connect to lots of
different organizations - it doesn't take long before two
organizations you connect to both want to use 172.16.0.x/24 or
10.0.0.x/24 or 192.168.0.0/24, or similar).  The same logic goes for
VPN clients - if one end is potentially using RFC1918, the other end
better not use it.  Since you can usually only control one end of the
VPN for road-warrior VPN, it's best to make that end not use RFC1918.
Otherwise you may find you need to route 192.168.x.y, but that just so
happens to be the user's default gateway, name server, printer, or
other key device.  Of course having another set of NAT addresses for
CGN will solve everything (yes, that's sarcastic, but I can predict
how they'll be used to solve this type of problem).

Just because it usually works doesn't mean using RFC1918 addresses
for left and/or right subnets in a VPN is a good idea.

Re: CVV numbers

[Joel Maslak]

On Jun 9, 2012, at 1:06 AM, Hal Murray hmur...@megapathdsl.net wrote:

 Should I really take them seriously?

Your call.

That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a 
skimmer from being able to do mail-order/internet-order with your card number.  
The CVV is not on the magnetic strip, so a skimmer installed at the ATM or gas 
pump won't be able to capture it.

There's a similar value on the magnetic strip that keeps the internet site you 
gave your card number and CVV to from being able to print cards and use them at 
the gas pump.

Certainly they don't stop all fraud.  They stop one type of fraud.

Re: IPv6 day and tunnels

[Joel Maslak]

On Jun 4, 2012, at 1:01 AM, Owen DeLong o...@delong.com wrote:

 Any firewall/security device manufacturer that says it is will not get any
 business from me (or anyone else who considers their requirements
 properly before purchasing).

Unfortunately many technology people seem to have the idea, If I don't 
understand it, it's a hacker when it comes to network traffic.  And often they 
don't understand ICMP (or at least PMTU).  So anything not understood gets 
blocked.  Then there is the Law of HTTP...

The Law of HTTP is pretty simple: Anything that isn't required for *ALL* HTTP 
connections on day one of protocol implementation will never be able to be used 
universally.

This includes, sadly, PMTU.  If reaching all possible endpoints is important to 
your application, you better do it via HTTP and better not require PMTU.  It's 
also why protocols typically can't be extended today at any layer other than 
the HTTP layer.

As for the IETF trying to not have people reset DF...good luck with that 
one...besides, I think there is more broken ICMP handling than there are paths 
that would allow a segment to bounce around for 120 seconds...

Re: IPv6 day and tunnels

[Joel Maslak]

On Jun 3, 2012, at 7:38 PM, Joe Maimon jmai...@ttec.com wrote:

 www.arin.net works and worked for years. www.facebook.com stopped June 1.
 
 So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?

It doesn't fix the fragmentation issues.  It assumes working PMTU.

For what it's worth, I also use a tunnel without issue to reach 
www.facebook.com via IPv6, with an MTU of 1476 (since it's running over a 1492 
byte IPv4 PPoE tunnel...).

Re: Comcast Paid Peer Pricing

[Joel Maslak]

On Jun 2, 2012, at 3:08 PM, Nabil Sharma nabilsha...@hotmail.com wrote:

 Dear NANOG:
 I seek pricing on Comcast AS7922 paid peer at following commit level:
 1G
 10G
 100G
 Please reply in private and I will sum up on list.
 Sincerely,
 Nabil

I'd suggest contact Comcast sales.

Re: Outdoor Wireless Access Point

[Joel Maslak]

On Apr 1, 2012, at 3:44 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp 
wrote:

 With 802.11, you can connect to an AP and, if the AP
 fails, you may be connected to another AP, but the
 transition takes considerable amount of time not
 tolerable for voice communication, which is why it
 is not called mobility.

True under basic 802.11, at least with WPA2 + EAP, for some clients.  Not all 
clients wait until they lose connectivity to start looking for another AP - it 
depends on how the client was built.  However, even without needing to lose 
connectivity to learn what other APs are nearby, there still is a substantial 
associatiation delay with EAP.

That's why 802.11r + 802.11k exist.  I'm sure the big name vendors support this 
and also support their proprietary alternatives that may or may not be better.


 If you want mobility, have different SSIDs for APs in
 the same frequency band (or, let terminals have multiple
 sets of radio interfaces) and let terminals connect
 to multiple APs simultaneously.

That's one way of doing it, provided you have a way to manage all the end 
devices when you add new APs.  It has the disadvantage of not being a COTS 
solution AFAIK.

Another way to do it is Meru's one frequency, one MAC approach.

As for locating other access points, even without 802.11k, most solutions I 
have seen go into power save mode for long enough to do a quick scan every once 
in a while, taking into account the size of the phone's jitter buffer.  That 
causes the AP to hold packets until the scan finishes.  So one channel is not 
required for fast roaming.

I've seen solutions cope without 802.11r + 802.11k by using a WEP-only SSID on 
each AP (typically the same SSID for all APs) and throwing that into a 
VOIP-only VLAN.  But with smartphones capable of running VoIP clients, I'd be 
less inclined to do it that way even if I thought WEP was secure-enough for 
voice calls.

The other solution that I've seen some things support is to use WDS on the VoIP 
device.  I'm also not a fan of that personally, but others may be.  WDS would 
require one frequency throughout the network however.


 Though you only have to modify software on terminals,
 AFAIK, there is no such commercial products.

There are plenty of commercial products that support VoIP handoff without 
issues.  Some are proprietary, some are open standards.  Many support 
multi-channel networks.  It starts to get expensive to do this though, as most 
(all?) of the cheap vendors don't do what is required on the AP side.  That 
said, I'd love to hear I'm wrong on this - I'm looking for new APs for home.

So, if I was buying an enterprise 802.11 solution and needed to support 
seamless VoIP roaming, I'd look at either a one-vendor solution (I'm sure Cisco 
phones + Cisco APs + Cisco Controller + Cisco PBX would do this just fine, for 
instance; you can substitute a few other big vendors for Cisco, no doubt, 
although not likely cheap ones; you'll be spending 10x or more per AP in many 
cases than if you could have used the cheap ones) or someone that complies with 
802.11r + 802.11k (both for handses and APs).  Obviously your network better 
support DSCP and/or VLAN priority marking and WMM as well.

Supporting VoIP handoff is much more complex (and, at least from what I've 
seen, expensive) than supporting web browsing handoff.  It's also what 
seperates different pricing tiers of wireless equipment.

Re: Outdoor Wireless Access Point

[Joel Maslak]

On Mar 31, 2012, at 3:38 AM, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote:

 As I look for maps we need at least 3 or 4 outdoor radio, I think in these
 networks the best solution is to have only one SSID in whole network to
 give mobility for the network, is this called ad-hoc? or it has an other
 name?

No, it's still infrastructure mode, not ad-hoc.

Ad-hoc means no access point.

All you need to do is set the APs up to use the same SSID and authentication 
methods, keys, etc.  It's pretty simple and can even be done with consumer gear 
(with less stable performance of course).  If you don't put the APs all on the 
same layer 3 LAN (same subnet), you'll need some sort of controller-based 
solutions so that a user's IP address still makes sense to their computer when 
they move from one AP to another.  If you can keep all the APs on one subnet, 
you won't need that.

It gets a bit more complex if you are using radio to link buildings together 
and/or backhaul to the access point.  There's plenty of good references on the 
internet.

Note that the wireless handoffs aren't perfect on basic 802.11 gear.  Your 
laptop might not pick the best AP if it can hear multiple APs.  And you might 
lose a few packets when you hand-off between APs, but it's typically no big 
deal.   Your ssh session would stay connected across those hand-offs just fine.

If you plan on doing VoIP on the wireless, it gets more complex yet - you have 
to worry about the time it takes handoffs and that can be more complex.  You 
have to implement WMM and DSCP.  You need to worry about low-speed users 
(1mbps, 2mbps, etc) on the same link.  It's a lot harder to build a VoIP 
wireless solution than a web browsing wireless solution, but still plentty 
possible to do without expensive equipment.

In summary: you probably should find a guide on how to build wireless networks, 
preferably a vendor agnostic one.  You will either be the hero of your 
organization or the enemy, depending on how well your network works.

Regex validation, was Re: Programmers with network engineering skills

[Joel Maslak]

On Mon, Mar 12, 2012 at 9:18 PM, Mark Andrews ma...@isc.org wrote:

 Only if you don't properly quote/escape the arguments you are passing.

You're using your OS wrong if you are quoting/escaping the arguments.
You do not need a shell involved to use fork() + exec() + wait(), as
the shell is not involved (assuming Unix; I also suspect libc has a
nice packaged function for this that is not insecure like system(),
but it's not all that hard to roll your own).  In Perl, use the
multi-argument form of system(), not the single argument version().
In both cases you should clear the environment as well prior to the
exec()/system() unless you know nobody can play with LD_PRELOAD, IFS,
etc.

This is one of my pet peeves about programming - programmers calling
out to insecure functions when secure alternatives are available.

The same goes for SQL statements - if you need to quote things to
prevent SQL injection, you're using your SQL database wrong.  Look up
prepared statements.  Generally, it's very bad practice to dynamically
build SQL strings.  It's also very common practice, hence why so many
applications have SQL injection vulnerabilities.  It's the Perl/PHP
equivalent of the buffer overflow that simply wouldn't exist if
developers, instead of trying to figure out how to quote everything,
simply used prepared statements and placeholders.

As for checking for bogus email addresses, read the RFC and code it
right.  That's not with a too-simple regex, nor is it with a complex
regex.  You need a parser, which is the right tool for the job.  Regex
is not.  But there is value in not passing utter garbage to another
program (it has a tendency to clog mail queues, if for no other
reason) - just make sure you do it right.

I might add that the same goes for names.  People don't just have a
first name and a last name - some people just have one name, some
people have three or four names, some people have surnames with
spaces, hypens, or apostrophes (remember what I said about SQL?!),
etc.  Yet most systems I see assume people have two names with no
spaces, apostrophies, hyphens, etc.  Big mistake.  And don't get me
started on addresses, which might have one address line, two address
lines, even 5 address lines, to say nothing that international
addresses may or may not put the street part first.  It's certainly
not easily regex-able.

Okay, I'll step off the soap box and let the next person holler about
how I was wrong about all this!

Re: VLAN Troubles

[Joel Maslak]

I've never had problems setting up multiple VLANs on a link between
Cisco, HP, Dell switches, IBM mainframes, VMWare servers, 3COM/Nortel,
Polycom Phones, Linux servers, etc.  If both ends supported 802.1q, it
just worked, if the admin read the manual for both pieces of gear and
knew how to troubleshoot problems.

Sure, one vendor can be nice a lot of the time - even cheaper once
support costs are factored in.  But making VLANs work between
different vendor's equipment is a pretty basic networking skill.  So
I'm kind of astonished at the sell what you have and buy new from one
vendor responses.

I've not used the specific Dell switches mentioned, but I've used
others and have plenty of opinions on the management interface of
them.  But for a wiring closet or top of rack switch, I can't say that
I would suggest to replace them with something new just because I
wanted a different management interface (that said, I very well might
write some scripts to manage the uglier interfaces).

Re: Please help our simple bgp

[Joel Maslak]

On Mon, Jan 30, 2012 at 7:27 PM, Ann Kwok annkwo...@gmail.com wrote:

 We discover the routes is going to ISP A only even the bandwidth 100M is
 full

There are several ways to handle this is, if you have at least two
/24s of space.

Let's say you just have two /24s, both part of the same /23.

Option 1:

Announce m.m.m.m/24 with no path prefixing on ISP A.
Announce m.m.m.m/24 prefixed with your own ASN one or two times on ISP B.
Announce n.n.n.n/24 with no path prefixing on ISP B
Announce n.n.n.n/24 prefixed with your own ASN one or two times on ISP A.

Most of the internet would probably prefer A for m.m.m.m/24, and
prefer B for n.n.n.n/24.  But if either A or B went down, there would
still be a reachable route.

Option 2:

Announce m.m.m.m/23 on both ISP A and B
Announce m.m.m.m/24 on ISP A
Announce n.n.n.n/24 on ISP B

The n.n.n.n/24 which is part of m.m.m.m/23 would use ISP B for inbound
traffic, while ISP A would be used for m.m.m.m/24.  If either A or B,
the less specific /23 would provide a backup path.


 Can we set the weight to change to ISP B to use ISP B as preference routes?

Not really.  You may be able to set a community that controls how ISP
B advertises the routes or preferences your traffic.  Weights
generally aren't used for path selection.

Re: bgp question

[Joel Maslak]

On Thu, Jan 19, 2012 at 6:27 AM, Deric Kwok deric.kwok2...@gmail.com wrote:

 We are planning to have 3 x 1G bgp connections (full tables) eg: Path A, B, C

 Can I say that we have 3G output totally?

Sure.

 From my understanding, the bgp chooses the best path to route automatically

It doesn't.  It typically chooses the path with the least number of
autonomous systems for a given destination.  That can actually result
in longer physical paths in many cases.

Let's say provider C buys bandwidth from A and B (and nobody else).
If that's the case, you will only use C for things directly connected
to C's network (typically only things that pay C), but every other
internet destination would use A or B.  (unless you adjust things to
not do this).

 If the path A is best route and that path 1G bandwidth is used up,
 will bgp try to use path B and path C automatically?

No, with one caveat.  If you fill up the pipe enough that routing
messages don't get through, those routes will eventually time out and
the path won't be used at all.

 How can I use up those 3G?

You will need to manually adjust routes, preferences, etc.  You'll
still have one path that is hotter than the others (although hopefully
not too much hotter).

Are you worried about incoming or outgoing bandwidth, or both?  For
incoming, you will need to do things like:

1) Announce all of your prefixes aggregated out all 3 links
2) Announce parts of your prefixes out ONLY ONE link.  So announce /24
#1 out A, /24 #2 out B, /24 #3 out C.  This means you're forcing
incoming traffic to generally come in one link per /24.  The problem
with this is that a really active /24 will get more traffic still.  It
also requires you to have at least 3 /24s (you can't route longer
prefixes, which means you can't route PART of a /24).

For outbound, the easy and obvious way would be for your providers to
just announce 0/0 to you and for you to do some sort of flow-based
load balancing.  But if one provider had reachability problems, you'd
go down.  So without that, you'll have to adjust the preferences of
incoming routes.

Alternatively use BGP multipath and buy from one provider (and connect
to the same router on the provider side).  Bandwidth from one provider
isn't necessarily a horrible thing, if you pick a good one provider.
Even with multiple BGP feeds, unless you are really, really careful
(and, most likely, spend tons of money for things like fiber
redundancy so the different fibers don't all end up on one pole or
going into the same telco building) you'll still have single points of
failure.

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

[Joel Maslak]

On Dec 29, 2011, at 7:00 PM, Jeff Kell jeff-k...@utc.edu wrote:

 The real-world case for host routing (IMHO) is a server with a public
 interface, an administrative interface, and possibly a third path for
 data backups (maybe four if it's VMware/VMotion too).  Unless the
 non-public interfaces are flat subnets, you need some statics (today). 
 It can be a challenge to get SysAdmins in a co-operative mindset to
 route that correctly (and repetitively if you have a server farm).

What I've done in that case as a sysadmin was a default out the internet 
interface and some sort of ospf daemon to handle the rest.  If I want a host to 
learn routing, I put a routing daemon on it.  Otherwise I just use a default 
route.  I don't see why this changes with IPv6.

Re: Speed Test Results

[Joel Maslak]

On Fri, Dec 23, 2011 at 10:13 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
 If you want to understand the issue in detail, check out the report from
 MIT this year, written by Steve Bauer and available at
 http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurem
 ents.pdf.

They should have put a date on their paper, including when the
measurements were done.  It appears to me to have been done sometime
after or around June of 2010.

Re: subnet prefix length 64 breaks IPv6?

[Joel Maslak]

On Dec 27, 2011, at 4:28 PM, Glen Kent glen.k...@gmail.com wrote:

 I had assumed that nodes derive their link local address from the
 Route Advertisements. They derive their least significant 64 bytes
 from their MACs and the most significant 64 from the prefix announced
 in the RAs.

No, link local addresses are not derived from RAs.  Even a system not connected 
to a router will have a link local address on each ethernet (I couldn't tell 
you how link local works on PPP, ATM, etc, without looking it up - but it 
doesn't require /64 networks).

Re: Speed Test Results

[Joel Maslak]

On Fri, Dec 23, 2011 at 2:18 AM, jacob miller mmzi...@yahoo.com wrote:

 Am having a debate on the results of speed tests sites.

 Am interested in knowing the thoughts of different individuals in regards to 
 this.

It's one data point of many.

Depending on the speed test site, the protocols it uses, where the
test is located, any local networking gear (I've seen transparent
proxies get great speedtest ratings!), etc, they can be useful,
particularly in verifying that a provider's off-net interconnects and
partners are doing well.

However, they are susceptible to things like wireless network issues,
TCP limitations (one stream vs. many streams), and misconfiguration of
devices at the customer location.  And the speed test box isn't
necessarily configured/speced correctly either.

I second the thoughts on NDT and I like the ICSI Netalyzer.  But I
wouldn't necessarily put either tool in most end users' hands (I think
they are too complex for most end users to interpret the results
properly).

Re: Recent DNS attacks from China?

[Joel Maslak]

Other than being non-compliant, is an ANY query used by any major
software?  Could someone rate limit ANY responses to mitigate this
particular issue?

On Fri, Dec 2, 2011 at 8:17 AM, Leland Vandervort 
lel...@taranta.discpro.org wrote:

 Yup.. they're all ANY requests.  The varying TTLs indicates that they're
 most likely spoofed.  We are also now seeing similar traffic from RFC1918
 source addresses trying to ingress our network (but being stopped by our
 border filters).

 Looks like the kiddies are playing


 On 2 Dec 2011, at 16:02, Ryan Rawdon wrote:

 
  On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote:
 
 
  -Original Message-
  From: rob.vercoute...@kpn.com [mailto:rob.vercoute...@kpn.com]
  Sent: Wednesday, November 30, 2011 3:05 PM
  To: matlo...@exempla.org; richard.bar...@gmail.com;
 andrew.wall...@rocketmail.com
  Cc: nanog@nanog.org; lel...@taranta.discpro.org
  Subject: RE: Recent DNS attacks from China?
 
  Yes it is, but the problem is that our servers are attacking the so
 called source address. All the answers are going back to the source. It
 is huge amplification attacks. (some sort of smurf if you want) The ip
 addresses are spoofed (We did a capture and saw all different ttl's so
 coming from behind different hops) And yes we saw the ANY queries for all
 the domains.
 
  I still wonder how it is still possible that ip addresses can be
 spoofed nowadays
 
  We're a smaller shop and started receiving these queries last night,
 roughly 1000 queries per minute or less.  We're seeing that the source
 (victim) addresses are changing every few minutes, the TTLs vary within a
 given source address, and while most of the source/victim addresses have
 been Chinese we are seeing a few which are not, such as 74.125.90.83
 (Google).  The queries are coming in to ns1.traffiq.com (perhaps ns2
 also, I haven't checked) and are for traffiq.com/ANY which unfortunately
 gives a 492 byte response.
 
 
 
  =
 
  Rob,
 
  Transit providers can bill for the denial of service traffic and they
 claim it's too expensive to run URPF because of the extra lookup.
 
  -Drew
 

Re: Network device command line interfaces

[Joel Maslak]

On Fri, Nov 25, 2011 at 12:01 AM, Robert Bonomi bon...@mail.r-bonomi.comwrote:


 The trick to deailing with this as a propellorhead[sic] is to include a
 *monetized* estimate of the increased manpower OPEX of using the 'dog to
 work with' box.  And a TCOS figure over the projected lifetime of the
 units.   No need to 'fight' with management about it, just understand
 'how'  they make the decisions, and give them the informatin they need
 to make the decision come out 'your way'.


I'd say that the ethical thing to do is to give them the information they
need to make a decision, not to get it your way.  I see, for instance,
people buying local closet switches from brand A when brand B is much, much
cheaper (but lacks the prestige of brand A), had a perfectly workable
management interface, and will perform identically, with similar support
offered by both vendors.  But they are an ACNA or whatever, or they've just
heard of (insert brand here), so they buy it.  Because it's easy and
familiar.

It's also possible that a web managed switch (which I despise) might
actually be the right choice for a business - because factors other than a
technologist's distaste might be important.

Part of being ethical (and NOT like the business people we might all
despise!) is to be honest.  So we don't compare brand A to brand B
unfairly.  We don't inflate the cost of brand B by adding brand B's
management infrastructure to the cost when we darn well know we just will
need a minor tweak to our scripts that can already manage brand A.  That
sort of thing.

I generally agree with what Robert said: It's about what makes sense to the
business.  If operating expenses will increase (Well have to grow
headcount by 3 to support this), then bring that up.  A caution though:
Takes less effort to run doesn't equate to dollars (the question a former
manager would ask me when I tried that line was, So who do you think we
should lay off then to get the dollar savings?  Fortunately he was a good
manager who wasn't serious, but was rather trying to get me to think about
what I'm saying).  I like paychecks, which is why I work for a living -
it's about the dollars.  So it's not unreasonable for my management to also
care about the money (since it's a key motivation for myself, after all!).
Yes, I'm fortunate to do a job I love and get paid for it at the same time.

I can say, for a CUI interface, operations over low-speed links (wireless
VPN when I'm away from the office and in a bad cell zone, for instance) is
likely important.  So is ability to script common tasks to allow people
like the help desk to do their jobs at low risk.  Flexibility is also
important - when I'm stuck with this piece of gear (which is shiny today)
in 5-7 years, when it's not so shiny, is it going to have flexibility to
last a bit longer if the business needs to conserve cash - or will a minor
change in how we do business make this thing functionally obsolete?

Relating to the discussion on the tier 1 mentor thread, someone who wants
to go far in networking won't be married to a particular vendor or way of
doing things.  They'll excel and find ways to overcome challenges,
including less than perfect equipment, that they might have to deal with.
They'll do so in a way that makes the customer and their own management
happy.  A highly paid network engineer who complains about work being
difficult probably won't do that.  One that finds a $500 replacement for a
$5000 router probably will stick around, provided they can actually deliver
what they promised (the guy that puts the $500 replacement in only to have
to replace it in a year with a $5000 router again won't go far, so be
careful! And you better have figured in the real costs of running a network
with $500 routers, not just the cost of the router).

Re: Dynamic (changing) IPv6 prefix delegation

[Joel Maslak]

On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote:

 As long as a static allocation can be billed as a premium service,
 most providers will unfortunately do it.

Exactly.  ISPs are in business to make as much money as they can - go figure.

For myself, having a static IP is the least of my concerns - even on my inside 
network.  Everything I have (printers, media boxes, etc) does some sort of 
lookup protocol so I have no problem connecting (and thus they get assigned 
dynamic addresses by my router).

I'm personally much more concerned about other things:

1) Not having IPv6 at all.  I expect to get it on my DSL in about 10 years or 
so when the equipment my line on is old enough to be replaced under a 15 or 20 
year replacement cycle.

2) Bandwidth caps probably affect people a lot more than changing IPs.  I don't 
have one on my landline, but I expect to get it when the DSL aggregation 
devices are replaced (I suspect I don't have it now because the equipment 
doesn't do it well).

3) If you write an application using anything other than UDP or TCP, it won't 
work on most networks (with some minor exceptions for PPTP and IPSEC, which 
work sometimes).

4) What would happen if someone wrote a popular app that used IP options?  I 
don't want to know that answer even though I already know it.  Break the 
internet is about how I'd phrase it.

5) I have a server in a datacenter that provides IPv6.  They even assign me a 
/48.  They assigned the /48 to my subnet.  I guess they thought I'd run out of 
addresses in a /64 and heard that you are supposed to assign /48's.  The only 
problem is that a subnet /48 means I can't route /64s elsewhere, nor does 
autoconfiguration work (maybe that is a feature?).

6) The same server can't receive IP fragments, except for the first one.  For 
security.  Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will 
cause longer answers).  Yes, I know I can turn off large UDP responses on my 
resolver.  I bet more than a few people don't know that though.

7) Even UDP and TCP aren't going to work everywhere.  Hense why everything 
seems to tunnel over HTTP or HTTPS even when that's an inappropriate method 
(such as when reliable ordered packet delivery is a hinderence).

8) Don't use the wrong ToS on your packets.  It'll be eaten by some random 
provider.  So if you use any ToS internally, you need a middlebox to unset your 
ToS bits.

I'd gladly give up a static IP address just to have an internet that delivered 
my packets from my home or server to the remote destination.

Re: Strange static route

[Joel Maslak]

On Sep 25, 2011, at 3:37 AM, Tom Storey t...@snnap.net wrote:

 I found I had to do this many years ago on some Cisco routers to get them to
 load balance (per packet) across two links. Adding 0.0.0.0/0 routes across
 both links just resulted in traffic routing across one link. Broke it into
 two /1's per link and it worked perfectly.


Two other reasons for this too:

1) Something won't redistribute 0.0.0.0/0 on the network.  Either because the 
person doesn't know the command to tell the router to do it, or because the 
router simply won't redistribute a default route.

2) Could also be failover.  One router might be advertising 0.0.0.0/0 on one 
end of the network. A different router on a different part of the network might 
be advertising the two /1's.  The /1's would be used unless they became 
unreachable.

Re: Strange static route

[Joel Maslak]

Protection against learning a bad default route through whatever routing 
protocol they are learning, since these two routes would be more specific than 
any typical default route.  They probably got burned learning a default route.

On Sep 23, 2011, at 7:12 PM, Glen Kent glen.k...@gmail.com wrote:

 Hi,
 
 I have seen a few operators adding static routes like:
 0.0.0.0/1 some next-hop and
 128.0.0.0/1 some next-hop.
 
 Why would anyone want to add such static routes? What does 0.0.0.0/1
 mean. Note that the netmask is 1 and not 0.
 
 Thanks,
 Glen
 

Re: OT: Given what you know now, if you were 21 again...

[Joel Maslak]

On Wed, Jul 13, 2011 at 3:08 PM, Larry Stites nc...@sbcglobal.net wrote:

 Given what you know now, if you were 21 and just starting into networking /
 communications industry which areas of study or specialty would you
 prioritize?


Make sure you are always learning.  You can't stop learning in this
industry.

Study the academic side of computers, not just how to use specific systems.
Know that systems other than the all-or-nothing superuser-based security
model exist, what a functional programming language is, basic computational
complexity, etc.  Unix or Cisco aren't always the best choices, but if you
don't know about the others you won't know that (FWIW, Cisco and Unix are
often excellent choices).

Learn to program reasonably well in at least a script language.

Learn TCP/IP.  It's going to be around for a while.  Focus on IPv4, but
expose yourself to IPv6.  This is probably the only specific
protocol/technology I'll mention.

Don't limit yourself to layer 3.  Learn about things like how to terminate
fiber optic cables and how application acceleration works.

Make sure you can write and speak well.

Learn when to shut up.  (I probably still haven't learned that one)

Learn how to get along with people, even ones that aren't as brilliant as
yourself.

Learn how to appropriately show accomplishment.  You don't want to be
arrogant, but you also don't want to be laid off because nobody knew that
you did great things.

Learn that people almost always have a reason for doing things the wrong
way, and it's best to find out what it is before you fix it!

This is probably controversial...Don't specialize religiously.  What I mean
about this is don't become a Cisco guy.  Sure, you might become a Cisco
expert, and that's fine.  But don't lock yourself to a vendor or system
type.  Don't turn down a dream job that uses a different kind of router,
server, workstation, etc, just because you like Cisco (or whoever) better.
You won't want to use today's technology in a few years anyhow, so why make
long-term decisions based on hardware/software used today?  In the computer
field, even giants have fallen.

Learn that there is always someone smarter than you out there.  Learn from
them.

You have to start somewhere.  If you don't have good experience, you aren't
going to start at a (insert nice salary here) senior position, no matter how
much you know or what degree you have.  You might have to start on the night
shift of a NOC, making barely enough to eat, doing basic tasks.  Even in a
position like that, you can show you can learn - don't waste time while
working in these jobs, spend your free time learning, not playing computer
games or watching TV.  You'll get noticed.

Don't do illegal stuff.  It'll limit your options.  Pay your bills, don't do
drugs, don't get picked up for drunk driving, don't beat your significant
other.  These are the things that disqualify people with even basic
background checks - and many, many senior network jobs require a background
check.

Take opportunities.  Consider jobs where you'll have to learn a bit to be
effective - you might be the best person that applied.  But don't expect to
get jobs you aren't qualified for, and be honest about your abilities (but
confident).  Right now is a difficult time to get a job, even if you have
terrific qualifications.

Re: best practices for management nets in IPv6

[Joel Maslak]

Public IPs.

At some point you will have to manage something outside your current world or 
your organization will need to merge/partner/outsource/contract/etc with 
someone else's network and they might not be keen to route to your ULA space 
(and might not be more trustworthy than the internet at large anyhow).  Think 
about things like VPN endpoints, video devices, telephones, etc, that may end 
up on a public network, maybe behind a device you manage.  You may just manage 
routers today, but who knows about tomorrow.  Put behind a firewall and use 
good ingress filtering throughout your network, separating trust zones with 
distinct subnets.

If you are worried about forgetting to enable a firewall, put in a network 
management system to verify connectivity stays blocked combined with a 
monitored IDS.

Re: ICANN to allow commercial gTLDs

[Joel Maslak]

I wonder what sort of money .wpad would be worth...

Re: Question about migrating to IPv6 with multiple upstreams.

[Joel Maslak]

On Mon, Jun 13, 2011 at 6:59 PM, Randy Carpenter rcar...@network1.netwrote:

This is precisely what we are doing on the main network. We just want to
 keep the general browsing traffic separated.



If you're worried about browsing traffic and not worried about occasional
other things slipping through, set up Squid and WPAD on your network.
Direct all general internet stuff (via WPAD) out the cheap connection, the
business-critical traffic through the other traffic.

Now things that don't listen to the WPAD configuration (basically anything
but PC and Mac browsers) will go out your expensive connection.   But it
sounds like a little bit of leakage wouldn't be a huge problem.  You could
get a bit fancier and run DNS on the proxy server, so that the proxy uses
itself for DNS resolution rather than the corporate DNS.  That would let you
do basic browsing while the corporate WAN is down.

The proxy would be the only box on the cable modem segment.  It would also
need an interface on some internal LAN segment.  Default route on it would
be via the cable modem, with routes to everything internal on the internal
interface.  Make sure you set the cable modem IP as Squid's outbound IP, and
make sure your WPAD file doesn't use this proxy for anything internal.

Everything else inside the network would have a default route pointing at
the corporate WAN and wouldn't know anything about the cable segment.

The nice thing about this setup is that you don't have any address
translation going on and only one IP per host.  You can replace Squid with
the proxy of your choice, doing as much or as little caching as you want to
do (and other things if desired, like virus scanning, deep packet
inspection, or content filtering - if your policy requires it).  Make sure
you talk to your legal and/or HR about what logs should be kept or removed
from the proxy.  You may also want to repress X-Forwarded-For headers to
keep your internal network addressing hidden while browsing.  Also remember
to make sure the proxy is secure enough to trust as a firewall for your
corporation - or put it behind a firewall that is secure enough.

Re: user-relative names - was:[Re: Yahoo and IPv6]

[Joel Maslak]

On Tue, May 17, 2011 at 9:37 PM, valdis.kletni...@vt.edu wrote:


 Unless you end up behind a fascist firewall that actually checks that the
 EUI-64 half of the SLAAC address actually matches your MAC address - but we
 all
 know that firewalls are weak at IPv6 support, so probably nobody's actually
 doing that checking. :)



Nevermind you can change your MAC address easily on most networks, since
most don't provide any reasonable way of verifying that L2 packets are from
where they claim to be.

FWIW, Windows Vista and 7 default to using privacy addresses with SLAAC.
Even without that, today, in the IPv4 NAT world, it's pretty much possible
to uniquely identify a user nearly almost all of the time anyhow - at least
for web access.  This is thanks to browser fingerprinting - see
https://panopticlick.eff.org/browser-uniqueness.pdf

There's a lot of FUD about IPv6.  Yes, the addresses are longer.  But which
is easier - remembering all the intermediate layers of network translation
(likely two boxes for nearly every residential and small business user) or
an IPv6 address that is the same, regardless of whether you are another
customer on the same ISP, a public internet user, or an internal corporate
user?  Nevermind what it is like to debug IPSEC/PPTP/L2TP, SIP, or P2P
protocols with just one NAT involved.  Imagine doing that with two NAT
devices (CGN + home NAT).  If you haven't had that unfortunate pleasure,
than I envy you!  There's also no reason we should have to remember our IPv6
addresses.  Seriously.  There are about 50 protocols to name things on
networks, many of which are scope aware.  Among other things, it's why we
don't typically have to remember MAC addresses - ARP works and it works
well.  Just because bad design forced us to remember IPv4 addresses doesn't
mean our IPv6 networks should carry over that brokenness.

IPv6 is also already in widespread use (I would guess all 500 of the Fortune
500 have it somewhere on their network, albeit quite likely not
intentionally).  I use it almost daily for my Apple MobileMe account (albeit
typically tunneled over IPv4, all behind-the-scenes).  I also use it when I
stream music around my house (Bonjour will utilize IPv6, AirTunes typically
uses it).  Windows admins might be using it too (DirectAccess; MS Remote
Assistance if firewalls block connectivity then Windows will set up a direct
IPv6 link, tunneling through your firewalls and NAT...).  And Grandma very
well may be using it today (Windows Home Groups use IPv6).  I would guess
half of the family members of NANOG list subscribers are using IPv6 on a
daily basis - TODAY.  The danger is in ignoring what is already on your
networks.  Sure, you can't get to most websites via IPv6.  But it's being
used for plenty of useful work today, although mostly as a way around
firewalls and as isolated islands (not connected to the global IPv6
network).

Re: Clearing DF bits...

[Joel Maslak]

On May 13, 2011, at 6:02 PM, Warren Kumari war...@kumari.net wrote:

 Years This was done both to deal with multiple encapsulations and for the 
 folk that block all ICMP for security reasons.

I did it as recently as last month, for the same reasons.

Re: IPv6 foot-dragging

[Joel Maslak]

Who sees the most AS's?

Re: Yahoo and IPv6

[Joel Maslak]

On Mon, May 9, 2011 at 3:57 PM, Jeff Wheeler j...@inconcepts.biz wrote:

I do take issue with your suggestion that /64 LANs are in any way
 smart in the datacenter.  They are not.  I have some slides on this
 topic: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf



There are ways of mitigating this (the easiest is to use ACLs or firewalls
to limit traffic into a subnet from untrusted sources so that only
legitimate traffic is allowed).

As for IPv6 in general, for other posters, I have a lot more concern about
things like missing routes in routing tables, lack of residential IPv6 (one
place where it would be *very* useful - think VoIP, P2P, etc), and lack of
any good tunnel broker options.

I've also had plenty of trouble getting IPv6 in data centers (4 different
providers of caged data center space, none of which provided it, including
one Tier 1 who advertised that all their business customers got free IPv6
with IPv4 transit from them; I guess they didn't think someone renting caged
space and redundant ethernet in one of their data centers was a business
customer, but I digress...)

I'd settle for a good tunnel at this point.

What do I mean by good tunnel option?  The following:

1) Provider treats it like production, not as a tool for business leverage
or a service only used for testing

2) Provider that has full routing table.  A provider couldn't stay in
business in the IPv4 world if they lacked connectivity to one or more
default free networks.  Yet in IPv6, it's the norm.

3) Provider that provides support for it - first through top level

4) Provider has redundancy at all levels

5) Provider makes it quick and simple to sign up, with rates posted on their
website based on bandwidth desired (for residential and small business
customers).  I don't want to talk to a sales guy if I'm just setting up a
tunnel for a DSL site!

6) Provider has an access location somewhere within, say, 1000 miles of my
location.  Ideally at a major exchange point in the metro.

7) Provider's network doesn't route me through Tokyo or Frankfurt to get
from Denver to Chicago - regardless of who's network in Chicago I'm trying
to connect to.

This doesn't exist - it's wishful thinking.  So this leaves native
connectivity.  Of course native connectivity is problematic, as it doesn't
always come with full routing tables, isn't necessarily available on the
circuit you have, and doesn't really give you all that much.  That's
assuming you can find it at all.  After all, it's only been around for most
of the time of the web.

Re: riverbed steelhead

[Joel Maslak]

On Thu, Apr 21, 2011 at 12:49 PM, harbor235 harbor...@gmail.com wrote:

 Anyone out there have experience with Riverbed Steelhead products?
 Do they improve TCP performance over WAN links? is it worth the price?


I'll let others answer the specific question about Riverbed.  I've heard
plenty of good things about them though.

(forgive me if this is extremely basic)  If the problem is that someone
downloading a big file slows the whole office down, there may be cheaper
ways of solving this.  Assuming your WAN links are private connections (not
VPN over internet), I'd also suggest before spending money that you ensure
you are doing some sort of fair queuing with RED/WRED enabled.  This will
ensure with on a network dominated by typical business TCP that one user
can't monopolize a circuit.  I'd also ensure that you are not sending bits
faster than your provider will allow (beyond your burstable bit rate) by
ensuring your bandwidth selections on your interfaces are set correctly.
You might be able to fix your users' concerns/complaints just by a few lines
of router config (and if you're using anything beyond home routers, your
routers probably already support these things).  In my experience, the
problem isn't that the line is too small for the workload, but rather that
bulk transfers keep everyone from doing work over it - that's where fair
queuing and WRED come in.  If you've already done this, than please ignore
this suggestion.  :)

-- 
Joel Maslak