Re: Verizon IDE

[Justin M. Streiner]

On Sat, 5 Jan 2019, Mitchell Lewis wrote:

How common is it for Verizon to deliver "Internet Dedicated Ethernet" 
over sonet? Ran into a situation where the canoga-perkins nte was 
uplinked to a Flashwave 4100es in the basement (uplinked by an OC-48). 
There is in a Verizon ILEC area.


If the location has an existing Verizon SONET node, and there is capacity 
on it to provide the Ethernet service you need, Verizon could opt to 
deliver the Ethernet service that way.


Thank you
jms

Re: Cleveland/Cincinnati Co-location

[Justin M. Streiner]

On Tue, 1 Jan 2019, Mitchell Lewis wrote:

I am working on project that may involve building points of presence in 
Cleveland & Cincinnati. Any suggestions as to which colocation facility 
in each city to build in? The prime factor of consideration for this 
project is access to waves to places like Chicago, New York & Ashburn. 
It would be nice to have multiple wave provider options to choose from.


I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in 
Cleveland.


Expedient has two facilities in Cleveland that might be worth looking at.

Thank you
jms

Re: Stupid Question maybe?

[Justin M. Streiner]

On Mon, 17 Dec 2018, Joe wrote:


Apologizes in advance for a simple question. I am finding conflicting
definitions of Class networks. I was always under the impression that a
class "A" network was a /8 a class "B" network was a /16 and a class "C"
network was a /24. Recently, I was made aware that a class "A" was indeed a
/8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a class
"C" is actually a /16.


As others have mentioned, IP address classes are no longer relevant, 
beyond understanding how things were done in the past.  Address classes 
haven't been used for assignment or routing purposes for over 20 years, 
but the term lives on because it keeps getting undeserved new life in 
networking classes and training materials.


Classfull address assignment/routing was horribly inefficient for two main 
reasons, both of which were corrected by a combination of CIDR and VLSM:


1. Assigning IP networks on byte boundaries (/8, /16, /24) was not 
granular enough to allow networks to be assigned as close as possible to 
actual need in many cases.  If you only needed 25 addresses for a 
particular network, you had to request or assign a /24 (legacy class C), 
resulting in roughly 90% of those addresses being wasted.


2. Classfull routing was starting to bloat routing tables, both inside of 
and between networks.  If a network had a little over 8,000 IPv4 addresses 
under its control, in the pre-CIDR days, that meant that they or their 
upstream provider would need to announce routes for 32 individual and/or 
contiguous /24s.  In the post-CIDR world, under the the best 
circumstances (all of their address space is contiguous and falls on an 
appropriately maskable boundary like x.y.0.0 through x.y.31.0), that 
network could announce a single /19.  When scaled up to a full Internet 
routing table, the possible efficiencies become much more obvious.  The 
network operator community has has to continue to grapple with routing 
table bloat since then, but for different reasons.


Had CIDR, VLSM, and NAT/PAT not been implemented, we (collectively) would 
have run out of IPv4 addresses many years before we actually did.


Thank you
jms


Is this different depending on the IP segment, i.e. if it is part of a
RC1918 group it is classed differently (maybe a course I missed?) Or aren't
all IP's classed the same.
I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or
wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with
172.16/12 as one that just a VLSM between the two.

Again, apologizes for the simple question, just can't seem to find a solid
answer.

Happy holidays all the same!
-Joe

Re: Unsolicited LinkedIn requests

[Justin M. Streiner]

On Tue, 11 Dec 2018, David Cornejo wrote:


not sure he was complaining about the request, just that it provided
no context or reason why they should link. a personal pet peeve of
mine.


Agreed, and I do get unsolicited Linkedin requests quite often. 
Sometimes, this is clearly the result of someone scraping a list like 
NANOG in an effort to drum up new business/contacts.  Those end up in the 
bitbucket.


It is annoying, but an unfortunate reality these days...

Thank you
jms

Re: Multicast traffic % in enterprise network ?

[Justin M. Streiner]

On Wed, 8 Aug 2018, Mankamana Mishra (mankamis) via NANOG wrote:

 *   If there is any data which can provide what % of traffic is 
multicast traffic. And if multicast is removed, how much unicast traffic 
it would add up?
 *   Since this forum has people from deployment area, I would love to 
know if there is real deployment problems or its pain to deploy 
multicast.


These questions is to work / discussion in IETF to see what is pain 
points for multicast, and how can we simplify it.


The amount of multicast traffic on an enterprise network will depend 
greatly on how multicast is being used, and to some extent, the type of 
business the enterprise is in.


An enterprise that uses multicast primarily for IPTV distribution might 
have different business and technology drivers than, say, a hospital 
or healthcare organization that has patient monitors that use multicast 
to communicate back to a central monitoring station.  The percentage of 
multicast traffic in those two scenarios might be vastly different, but 
no less important to their respective organizations.


Thank you
jms

Re: Confirming source-routed multicast is dead on the public Internet

[Justin M. Streiner]

On Tue, 31 Jul 2018, John Kristoff wrote:


Second best might be the Internet2 community where a number of
institutions that have always had it might still have it turned on.
Though there has been only one post in all of 2018 on their list if
that tells you anything.


At my previous job (large .edu), we spoke MSDP with Internet2 through our 
regional I2 connector, however we turned that MSDP session off probably 
two years ago, and I don't think that session moved any useful traffic for 
probably two years before that.  Multicast was used extensively within our 
network, but nothing outside for quite a while.


I agree with general sentiment that multicast across the larger Internet 
is dead.


Thank you
jms

Re: Rising sea levels are going to mess with the internet

[Justin M. Streiner]

All:

Let's kindly kill off the portions of this thread that have absolutely 
nothing to do with running a network.  Political rants, plate tectonics, 
Math 101, and debating whether or not climate change is a thing really 
have no place on this list / in this context.


Thank you
jms

Re: How can I obtain the abuse e-mail address for IPs from Japan?

[Justin M. Streiner]

On Wed, 23 Aug 2017, Kurt Kraut wrote:


Network Information:
a. [Network Number] 59.106.12.0-59.106.27.255
b. [Network Name]   SAKURA-NET
g. [Organization]   SAKURA Internet Inc.
m. [Administrative Contact] KT749JP
n. [Technical Contact]  KW419JP

No e-mail addresses of the abuse team or NOC or SOC.


Since they don't have an abuse contact and there's not much additional 
useful contact information in their peeringdb entry, your next best bet 
would be to reach out to the admin and technical contacts listed in their 
whois record, or try the abuse contacts for one or more of their

upstreams.

jms

Re: Creating a Circuit ID Format

[Justin M. Streiner]

On Tue, 22 Aug 2017, James Bensley wrote:


In my opinion the circuit ID should be an abitrary (but unique) value
and nothing more. As Nick suggested start at 1 and go up. If your
company is called ABC Ltd then maybe have your first circuit ID as
ABC0001 and count up from there, it's as simple as that.

For me, all the circuit ID should be is a record number/ID of a
database entry and nothing more (or a search string). Some people like
to have circuit IDs which include circuit types, or circuit speeds, or
interface type, but as you asked, do you then change the circuit ID if
the circuit speed changes, or the interface types changes, or the
medium etc?


Agreed.  I designed something similar at a previous employer, and it just 
used a date-coded ID with sequence number (ex: UOP 20170822.0001), and 
then all of the cross-connect details were recorded in a place that was 
better suited to capturing that sort of information.  That would also 
allow us to re-use fiber paths when we upgraded 1G links to 10G, etc.


This also included IDs that could reference other circuit IDs - including 
circuit IDs from other providers - so we could tie non-dark elements 
together, such as waves through DWDM gear end up riding on separate dark 
fiber paths on either side of the mux.


The biggest obstacle was getting people to label fiber jumpers in the 
field, but that obstacle went away as people get a better understanding of 
it and having all of the cross-connects documented saved lots of time and 
frustration when having to search through a large patch field at 3 AM...


jms

Re: Point 2 point IPs between ASes

[Justin M. Streiner]

On Thu, 29 Jun 2017, William Herrin wrote:


Heck, I’m gonna do whatever it takes to NOT subnet on bits with my v6

deployment.  Hopefully with v6, gone are the days of binary subnetting math.


I hedged my bets when I laid out our v6 space at my previous $dayjob.  We 
used /126s for point-to-point links, but carved out a /64 for each 
point-to-point link in our IPAM system.  That way, if we ever encountered 
a device that wouldn't play nicely with a /126 on a point-to-point link, 
we could just change the mask to /64 (or something else, if the device 
requires a byte or nibble boundary) on the interface and any relevant 
ACLs and not have to re-provision addresses for the link.


I seem to recall that our upstreams generally standardized on /126s for 
point-to-point interconnects to us.  We had one interconnect that was a 
/64, but that also wasn't a point-to-point link.


jms

Re: Another Big day for IPv6 - 10% native penetration

[Justin M. Streiner]

On Mon, 4 Jan 2016, Ca By wrote:


Just a reminder, that 10% is a global number.

The number in the USA is 25% today in general, is 37% for mobile devices.

Furthermore, forecasting is a dark art that frequently simply extends the
past onto the future.  It does not account for purposeful engineering
design like the "world IPv6 launch" or iOS updates.

For example, once Apple cleanses the app store of IPv4 apps in 2016 as they
have committed and pushes one of their ubiquitous iOS updates, you may see
substantial jumps over night in IPv6 eyeballs, possibly meaningful moving
that 37% number to over 50% in a few shorts weeks.

This will squarely make it clear that IPv4 is minority legacy protocol for
all of mobile, and thusly the immediate future of the internet.


True, but as noted in other recent threads, it would appear that IPv6 
deployment in many areas outside the United States is nowhere near as far 
along. While IPv6 is the future (in some areas, the present), it's 
probably way too early to try to nail down a date to write the obituary 
on IPv4.


jms

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Justin M. Streiner]

On Fri, 2 Oct 2015, Rob McEwen wrote:

it then seems like dividing lines can get really blurred here and this 
statement might betray your premise. A site needing more than 1 address... 
subtly implies different usage case scenarios... for different parts or 
different addresses on that block... which could slip back into... "you 
blocked my whole /48... but the spam was only coming from this tiny corner of 
the block over here (whether that be a one IP, a /64, or a /56)... and now 
other parts of the block that were sending out legit mail, are suffering".


Likewise, sub-allocations can come into play, where a hoster is delegated a 
/48, but then subdivides it for various customers.


That touches on the tough part of doing things like ingress/egress filtering
and spam blacklisting for IPv6.  Net every network assigns IPv6 space to
end-users the same way, and even fewer still provide good data on how they
assign to end-users (SWIP, rwhois, etc).  Networks that are blocking 
traffic are left to make a decision that straddles the line between 
providing the necessary level of protection for their services and 
minimizing the potential of collateral damage by blocking legitimate 
traffic from other users.


Blocking a single IPv6 address is generally not effective because it's 
trivial for a host to switch to a different address in the same /64, and 
hosts that have privacy extensions enabled will do so with no further 
action needed by the owner.  This turns into an endless game of 
whack-a-mole.  The same thing can happen with blocking /64s.


It's often not clear if provider XYZ is assigning /56, /48, or something 
else to end-users, especially if the provider doesn't provide any publicly 
accessible information to that end.


jms

Re: Wrong use of 100.64.0.0/10

[Justin M. Streiner]

On Fri, 2 Oct 2015, Marco Paesani wrote:


I know that we must filter this type of route, but AS9498 (upstream) MUST
accept only correct networks.
Or not ?


They should filter out routes that are not supposed to be globally 
routable, but many providers don't do this, unfortunately.


jms


2015-10-02 16:52 GMT+02:00 Justin M. Streiner <strei...@cluebyfour.org>:


On Fri, 2 Oct 2015, Marco Paesani wrote:

Hi,

probably this route is wrong, see RFC 6598, as you can see:

show route 100.64.0.0/10

inet.0: 563509 destinations, 1528595 routes (561239 active, 0 holddown,
3898 hidden)
+ = Active Route, - = Last Active, * = Both

100.100.1.0/24 *[BGP/170] 2d 14:46:05, MED 100, localpref 100
 AS path: 5580 9498 9730 I, validation-state:
unverified
  > to 78.152.54.166 via ge-2/0/0.0



My guess is someone leaking an internal route.  It's not uncommon to see
people using random IPv4 space for internal purposes.  Ranges such as
100.100.x.0/24 or 20.20.x.0/24 are often mis-used in this way.

It also looks like at least one of their upsteams is not filtering out any
advertisements from 100.64/10.

jms





--

Marco Paesani
MPAE Srl

Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: ma...@paesani.it

Re: Wrong use of 100.64.0.0/10

[Justin M. Streiner]

On Fri, 2 Oct 2015, Marco Paesani wrote:


Hi,
probably this route is wrong, see RFC 6598, as you can see:

show route 100.64.0.0/10

inet.0: 563509 destinations, 1528595 routes (561239 active, 0 holddown,
3898 hidden)
+ = Active Route, - = Last Active, * = Both

100.100.1.0/24 *[BGP/170] 2d 14:46:05, MED 100, localpref 100
 AS path: 5580 9498 9730 I, validation-state:
unverified
   > to 78.152.54.166 via ge-2/0/0.0


My guess is someone leaking an internal route.  It's not uncommon to see 
people using random IPv4 space for internal purposes.  Ranges such as

100.100.x.0/24 or 20.20.x.0/24 are often mis-used in this way.

It also looks like at least one of their upsteams is not filtering out any 
advertisements from 100.64/10.


jms

Re: /27 the new /24

[Justin M. Streiner]

On Fri, 2 Oct 2015, Niels Bakker wrote:


* t...@ninjabadger.net (Tom Hill) [Fri 02 Oct 2015, 18:34 CEST]:
Any RIR - or LIR - that considers allocating space in sizes smaller than a 
/24 (for the purpose of announcing to the DFZ) would do well to read this 
report from RIPE Labs:


 
https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed

tl;dr: it's still a bad idea to allocate smaller than a /24.


RIPE has long allocated up to /29.  Not everybody needs addresses for the 
Internet; some just need a guarantee of global uniqueness.


Right, but the OP's question seems to be pointed much more toward global 
reachability, not just global uniqueness.


jms

Re: Academic Paper - ISPs Sharing Long Haul Infrastructure in the USN

[Justin M. Streiner]

On Mon, 21 Sep 2015, Sean Donelan wrote:

It could be summarized as "Circuit route diversity sucks."  The only thing 
worse than circuit route diversity were the processes to assure diverse 
circuit orders stayed diverse.


No small feat when carriers re-groom circuits and don't bother to tell 
anyone, beyond *maybe* a cryptic notification regarding "maintenance on 
your service".


jms

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

[Justin M. Streiner]

On Wed, 9 Sep 2015, Dovid Bender wrote:

I am trying to understand why the legal babble bothers anyone. Does it 
give you a nervous twitch? Remind you why you hate legal? It's just text 
at the bottom of your email.


I can see both sides of this:
1. People who post to this list from a work email address often have no 
control over what their employer appends to the end of their outgoing 
emails.  The footers in question are usually added after the fact because 
someone in a position of authority at $employer says it needs to be there.


2. A half-page of legalese boilerplate following a one-line message on a 
mailing list that goes out to many thousands of people can be a bit 
irritating.


The compromise would seem to be to use a third-party email account for 
subscribing to mailing lists, but there could be environments where that 
doesn't fly with those same people in positions of authority...


jms


-Original Message-
From: Larry Sheldon 
Sender: "NANOG" Date: Tue, 8 Sep 2015 03:56:30
To: 
Subject: Re: Extraneous "legal" babble--and my reaction to it.

On 9/8/2015 03:31, Rich Kulawiec wrote:

On Sun, Sep 06, 2015 at 09:14:02PM +, Connor Wilkins wrote:

Honestly.. the best method is to not let it bug you anymore. It's
only a seething issue to you because you let it be.


Curiously enough, the same thing was said about spam 30-ish years ago.
The "ignore it and maybe it will go away" approach did not yield
satisfactory results.

These "disclaimers" are stupid and abusive.  They have no place in
*any* email traffic, and most certainly not in a professional forum.
And it is unreasonable to expect the recipients of the demands and
threats they embody to silently tolerate them ad infinitum.


Exactly so.
JHD


--
sed quis custodiet ipsos custodes? (Juvenal)

Re: Cogent revisited

[Justin M. Streiner]

On Wed, 12 Aug 2015, James Bensley wrote:


Perhaps that depends on were are you in the world and your traffic types.

I have worked with two UK ISPs that have Cogent as one of their
transit providers, neither have had any problems in the 5+ years
they've both had the Cogent transit, it has always just worked.


And for the most part, that will be the case.  If you're multi-homed, it's 
really not a major issue.  It's more when someone is:
1. single-homed to Cogent and they get into a peering/transit/pay-us spat 
with one of the DFZ carriers, and Cogent gets de-peered. Single-homed 
customers of $de-peering_carrier disappear from your view of the Internet.
2. single-homed to one of said DFZ carriers and a peering/transit/pay-us 
spat arises with Cogent, and Cogent gets de-peered.  Single-homed customers

of Cogent's disappear from your view of the Internet.

jms

Re: Is it possible to roughly estimate network traffic distribution for given ASN?

[Justin M. Streiner]

On Fri, 14 Aug 2015, Martin T wrote:


there are various tools out there which show the prefix distribution
among the peers/uplinks for given ASN. For example
https://radar.qrator.net/as/graph#96311 or
http://bgp.he.net/AS#_asinfo. As far as I know, those tools build
the graphs mainly based on data from route servers. Am I correct that
at best this data could give very rough estimation on ingress traffic
for ASN as those graphs indicate announced prefixes? I mean for
example if ASN 1 announces 1.1.0.0/16, 2.2.0.0/16 and 3.3.0.0/16 to
ASN 2, but only 1.1.0.0/16 to ASN 3, then one could assume that more
ingress data to ASN 1 goes over ASN 2. What about egress traffic? In
general, are there ways to roughly estimate network traffic
distribution for given ASN among its peers/uplinks? I would say it is
not possible.


You can certainly make inferences about the traffic between ASN 1 and ASN 
2, 3, etc... however without being the operator of one of those ASNs, 
those inferences are just that - inferences.  Even if you operate a 
network that peers with both ASN 1 and ASN 3, the traffic you see 
transiting your network to get to/from them might only be a fraction of 
the total traffic between those ASNs, given the possibility of there being 
other paths between then that don't cross your network.


What are you trying to figure out?  If you want to see how much traffic 
you move between your AS and another AS, Netflow, IPFIX, and other tools 
can help you figure that out.  If you're looking for the same kind of 
data for a source, destination (or both) that you don't control, all you 
can realistically do is guess.


jms

RE: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Justin M. Streiner]

On Thu, 23 Jul 2015, Nicholas Warren wrote:

How will the customer know the ISP is blocking the traffic? Does the 
FCC make ISPs disclose this information?


If a customer is legitimately trying to reach someone in one of the 
affected IP ranges and failing, at some point, they will either a) give up 
and try later, or b) contact their provider to try to find out what's 
going on.


If it's something widespread enough that the ISP's support line is blowing 
up with calls, I'd hope they would either put some sort of announcement on 
their website/support site/support line.


As with anything else in the ISP world, it's about striking an appropriate 
balance.  If ISP X is getting hit with DDoS traffic hard enough to 
severely impact their business, that can warrant an emergency response, 
albeit likely a short-term/tactical response.  If not, perhaps a more 
limited response is better.  Again, each provider is free to run their 
network as they see fit.


The balance point can also change if downstream ISPs are involved, since 
ISP X might be making the decision to block or not block traffic for 
the downstreams, with or without their consent.


jms


On 07/22/2015 09:01 PM, Justin M. Streiner wrote:

You're certainly free to block whatever traffic you wish, but your
customers might not appreciate a heavy-handed approach to stopping bad
traffic at the gates.

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[Justin M. Streiner]

On Mon, 20 Jul 2015, Colin Johnston wrote:

blocking to mitigate risk is a better trade off gaining better 
percentage legit traffic against a indventant minor valid good network 
range.


There are bound to be an awful lot of babies in that bathwater you're 
planning to throw out.


You're certainly free to block whatever traffic you wish, but your 
customers might not appreciate a heavy-handed approach to stopping bad 
traffic at the gates.


jms

RE: another tilt at the Verizon FIOS IPv6 windmill

[Justin M. Streiner]

On Mon, 13 Jul 2015, Paul B. Henson wrote:


Seems to be a lot less noise on this iteration of the shake fist at
Verizon's lack of IPv6 thread, I guess everybody is pretty much burned out
and given up 8-/. Verizon should just update their IPv6 status page with a
link to hurricane electric's tunnel broker page sigh.


For a long time, Verizon's general What is IPv6? page stated the 
standard assignment for customers was a /56... or 56 LANs.  *headdesk*.


jms

Re: another tilt at the Verizon FIOS IPv6 windmill

[Justin M. Streiner]

On Sun, 12 Jul 2015, Paul B. Henson wrote:


I think it's been about a year and a half since I last looked (and
cried) at the status of FIOS IPv6. As far as I can tell, there's been no
new official news since 2013. We're deploying IPv6 at the university I
work at, so IPv6 at home is moving from wish I had it to play with
towards need to have it to work from home. So it seems I either cancel
my fios and go with business class cable (I live in Time Warner
territory and it looks like they're good to go with IPv6) or set up a
tunnel with HE. Or pray Google fiber comes to my neck of the woods.


I've shaken this tree many times in the 3 years I've had FIOS (Pittsburgh, 
PA), and the results from Verizon have not been promising.  I call their

customer service center to ask about IPv6 availability every few months,
and get the electronic equivalent of a blank stare.  Promises to make a 
notation in my account don't mean much if no one who is in a position to 
act on that notation will ever read it.


I've also asked our Verizon rep through $dayjob about the v6 deployment 
status, and Verizon is so segmented and siloed internally, that it's been 
nearly impossible for them to find the right people.


As others have suggested, set up a tunnel with Hurricane Electric, and 
move on with life.  I've had one for probably two years, and it's been 
rock-solid.  While it would be great to have native v6 from Verizon, it 
doesn't look like it'll happen any time soon.


From what I understand, many of the ONTs and possibly set-top boxes if 
you have FIOS TV service don't play nicely with v6.  I don't know how true 
that is, or if those are still issues.  I do recall hearing that upgrading
to their Quantum service might get you a different ONT, but if that's 
true, I don't know if the those ONTs are any more v6-friendly.  I don't
know if there are any v6 compatibility issues further up the chain from 
the ONT.


jms

Re: Route leak in Bangladesh

[Justin M. Streiner]

On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote:


Randy Bush ra...@psg.com wrote

A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.


7007 all over again.  do not redistribute bgp into igp.  do not
redistribute igp into bgp.


I also suggested them to implement BGP community based route filtering
in their outbound policy.  Any other suggestions or thoughts to
prevent such incidents in general?


At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) and 
your downstream customer ASNs.  Whether this is done manually, built 
using AS-SETs from your route registry of choice, or through some other

automated means is another story.

jms

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

[Justin M. Streiner]

On Tue, 30 Jun 2015, Ricky Beam wrote:

The death of Novell NetWare (and their transitioned to IP) killed it the 
enterprise. Games adopting IP for network play killed it in the home.


Ultimately, it sucks as a WAN protocol, so the internet was built using this 
new fangled IP thing.


There are still isolated pockets of devices out there speaking IPX, 
DECnet, Appletalk, etc, but either they're not connected to the 
'Internet', or their traffic passes through other devices that encapsulate 
and de-encapsulate it in IP to allow it to be transported.


jms

Re: Route leak in Bangladesh

[Justin M. Streiner]

On Tue, 30 Jun 2015, Sandra Murphy wrote:


On Jun 30, 2015, at 10:39 AM, Justin M. Streiner strei...@cluebyfour.org 
wrote:
At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) 
and your downstream customer ASNs.  Whether this is done manually, 
built using AS-SETs from your route registry of choice, or through some 
other automated means is another story.




That sort of AS_PATH filtering would not have helped in this case.  The 
AS originated the routes, it did not propagate an upstream route.


I didn't realise they offending AS was originating those routes, rather 
than propagating the existing ones.



So an AS_PATH filter to just its own AS would have passed these routes.


That's why I suggested it as a minimum precaution.  When I worked in the 
service provider world, we did prefix + AS-PATH filtering + max-prefix, 
which was pretty effective in keeping BGP-borne madness down to a dull 
roar.  Would that stop everything?  No, but it did help a lot.  I still 
work in a BGP-speaking organization - just not one that has downstream 
BGP-speaking customers at this point.


You would need origin validation on your outbound routes.  Job 
suggested prefix filters on outbound routes.  (If you are doing prefix 
filters on your inbound customer links, it might be excessive caution to 
also prefix filter customers prefixes on outbound links?  Or is it: you 
can never be too careful, belt-and-suspenders, measure twice, etc?)


It depends on how much automation can be done to update the 
necessary filters and AS-PATH ACLs, and how much you trust both the 
automation method and the data source for those filters.


jms

Re: Any Verizon datacenter techs about?

[Justin M. Streiner]

On Sun, 28 Jun 2015, chris wrote:


I cant say much about other incumbents but i have been in alot of vz co's
in nj/nyc and Its very rare to see any humans in a CO anymore even in ones
in really dense metro areas


The majority of ILEC COs I've seen are unstaffed these days, save for the 
rare occasion where something needs to be physically touched.  CLECs are 
sometimes a different story because they might only have one physical CO 
in a given LATA.


jms


On Jun 26, 2015 10:40 PM, Christopher Morrow morrowc.li...@gmail.com
wrote:


On Fri, Jun 26, 2015 at 8:32 PM, John Musbach johnmusba...@gmail.com
wrote:

On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:

On Wed, Jun 24, 2015 at 2:46 PM, John Musbach johnmusba...@gmail.com

wrote:

Hello,

I'm a techie that recently moved to South Jersey for a tech job. To my
astonishment, I discovered that there appears to be a Verizon
datacenter near my house that has colocation:


how / why did you think this has colocation?


Look at the second picture, the sign on the door more specifically. :)


oriiginal view of the door sign was not readable... had to do some
work to see 'co locators entrance'. Bet this means 'clec entrance'
(they probably forgot to include the hours of operation: 9-4, lunch
11-3)

Re: Open letter to Level3 concerning the global routing issues on June 12th

[Justin M. Streiner]

On Sat, 13 Jun 2015, Mark Tinka wrote:


For peering and customers, we set a default prefix limit value for IPv4
and IPv6. We only change this if the peer/customer informs us that they
will announce a lot more than what we've configured. We add some % to
cover for sudden growth, but not too much to impact the network.

For customers, we add prefix lists and AS_PATH filters as mandatory.

I'm sure others do the same. It would be good if we all did.

I know the largest transit providers tend to be more relaxed for various
reasons. Some rely on filters generated by IRR entries, others don't.

A lot more work is needed, indeed. It's not 2008 anymore...


At my previous job (regional ISP with a decent amount of BGP-speaking 
downstream customers), we did prefix and AS-PATH filtering on all customer 
sessions.  The only thing lacking at that time (1997-2004) was a decent 
way to automate changes - everything was pretty manual.  That said, it 
kept issues caused by customers leaking routes back to us down to pretty 
much nil.


jms

Re: eBay is looking for network heavies...

[Justin M. Streiner]

On Mon, 8 Jun 2015, Yardiel D. Fuentes wrote:

This discussion is always reminisced of questions such as: Why would I 
want to learn Algebra or Calculus in college ? or why would I want to go 
to college at all ? .. the student argues that calculus or college is 
hardly ever used, if at all, in a job …  the most sensible perspective 
has always been:  It is not only about the knowledge itself, but how 
learning those subjects train your mind to tackle technical 
problems…same in networking… Some of the best interview questions 
are those that pose a problem and ask you to tackle it by explaining 
your train of thought…It requires both: knowledge and how to apply 
it...


Your point is well taken, but being asked to recite section 4.2.1 of RFC 
 is:

1. little more than rote memorization
2. says nothing about a candidate's skills or critical thinking abilities.

For the record, there are times in my professional career where I've made 
some use of algebra and calculus :)


jms

Re: eBay is looking for network heavies...

[Justin M. Streiner]

On Mon, 8 Jun 2015, Jeroen van Aart wrote:


On 06/05/2015 06:38 PM, Mike Hale wrote:

 We need a pool on what percentage of readers just googled traceroute.


Don't learn by heart that which you can look up. In this day and age where 
knowledge about every subject imaginable is a 5 second (to a minute for those 
less versed in researching) internet search away there is no need to hold all 
that knowledge iny our memory.


Reminds me of a job interview I had many years ago, where the interviewer 
was looking for me to quote chapter and verse of several RFCs for 
different routing protocols.  Uh... yeah.


jms

RE: eBay is looking for network heavies...

[Justin M. Streiner]

On Sun, 7 Jun 2015, Joshua Riesenweber wrote:

As someone studying their first CCIE (RS), I sometimes find these kind 
of discussions disheartening. They come up every now and again, and the 
opinions seem vary anywhere between 'a good interview tool' and 'less 
than worthless'.

[snip]
Does a certification mean that you are an expert? No. Does it mean you 
are devoid of skill? No. All it means is that the person has studied the 
curriculum, and passed the tests.No more, no less.

[snip]
When I see someone who has a certification, and they can follow it up 
with actual skills, it indicates they have a certain level of dedication 
to improving themselves and their education. (In my experience it takes 
more time to study a certification track than to learn just what you 
need to get a job done.)


Agreed.  I don't think certs are completely worthless, nor do I make a 
professional judgment on someone based solely on the alphabet soup they 
append to their name (or don't).


I've been working in the technology world for over 20 years and have had 
the opportunity to work with people who had the papers and were top-notch, 
and people who had those same papers and were complete tools in an *I* 
have a CCIE... my excrement can't *possibly* stink! kind of way. 
Likewise, some of the sharpest people I've ever worked with had no certs 
at all, but there were lots of tools there, too.  Certs are nice, but 
someone who has them on their resume had better be prepared to walk the 
walk in a technical interview.


As the OP mentioned, the alphabet soup just puts someone at the head of 
the line for a phone interview.  Nothing more.


jms

Re: gmail security is a joke

[Justin M. Streiner]

On Thu, 28 May 2015, Rich Kulawiec wrote:


I think this (Bill's) is a very good practice.  It's not that difficult
to enumerate the name of every pro sports team in the US, the 100 most
popular dog names, the 200 most common street names, etc.  This attack
can be mitigated by limiting attempts...but of course if that's done,
then it's possible for an attacker to lock out the real owner by just
hammering away constantly using assorted botnet hosts.


There are providers (banks, etc) who will disable an online account that
has had X failed login attempts.  While that's good for preventing 
$bad_guy from continuing to try to brute-force-guess the password, it 
creates a nominal DoS condition for the legitimate owner who then has to 
contact the provider and go through their password reset procedure.


In most of the cases I've seen, the provider is not well equipped to block 
login attempts for $legit_user from whatever address range is doing the 
brute-forcing (possibly spoofed / botted anyway).


jms

Re: Galaxy S6 is IPv6 on all US National Mobile carriers

[Justin M. Streiner]

On Mon, 13 Apr 2015, Stephen Frost wrote:


I'm still wondering when they're going to teach the Verizon FIOS people
about the IPv6 goodness...


I've been barking up that three for nearly the past three years.  No 
definite answers thus far, other than the ONTs deployed in many customer 
locations might make IPv6 deployment a bit of a PITA, regardless of which 
model router you have on site.


Trying to get good answers on this from VZ sales/marketing contacts 
through $dayjob has not gotten much in the way of good answers either.


I have a v6 tunnel through Hurricane Electric that works very well, but it 
would be nice to go native.


jms

Re: Getting hit hard by CHINANET

[Justin M. Streiner]

On Mon, 23 Mar 2015, Ca By wrote:


Having your upstream apply a permanent udp bw policer, say 5 or 10x busy
hour baseline, works well for this.


Many upstreams will not do that, particularly on a permanent basis.  They 
might do something temporarily to deal with an incident, but many of the 
bigger carriers probably wouldn't want to leave that in place permanently.


jms

Re: Usage Graphing per Subnet

[Justin M. Streiner]

On Wed, 18 Feb 2015, Methsri Wickramarathna wrote:


My company has 3 upstream providers and we are serving more than 400
customers ..In that case we have to manage our upstream capacity... When
considering capacity managing normally we just transfer a  /24 from
congested Up stream provider to non congested provider.
Issue we have is we don't know exactly the usage of a /24 subnet before
transfer.


Netflow/sflow/IPFIX is most likely going to be the easiest/cleanest way to 
get the data you want.


I would also recommend announcing a consistent set of prefixes to all 3 
providers, and using mechanisms like AS-PATH prepending and/or whatever 
BGP communities each provider offers to do things like tweak preferences 
or do selective prepending, rather than shuffling prefixes between 
providers to achieve some level of traffic engineering, and also keeping 
your announcements aggregated as much as possible.  Less routing table 
bloat and churn is a good thing.


jms

Re: Intrusion Detection recommendations

[Justin M. Streiner]

On Fri, 13 Feb 2015, Rich Kulawiec wrote:


On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote:

I am a huge fan of FreeBSD, but for a medium/large business I'd definitely
use a fairly well tested security appliance like Cisco's ASA.


Closed-source software is faith-based security.


The ASA, like so many network/security appliances anymore, runs Linux (or 
*BSD) under the hood, however I don't know how old or horribly mangled it 
is.


jms

Re: MultiMode Fiber Connectivity... (850nm) Power Question

[Justin M. Streiner]

On Wed, 11 Feb 2015, Faisal Imtiaz wrote:


I was looking for feedback on the following question:-

When connecting two MM SFP/SFP+/XFP 's together...(short range).

What should be the best practice receive power range ?


SX (1G) / SR (10G) / SR10 (100G) gear generally has a receive threshold 
that's higher than the maximum launch power.  They are designed for 
short-reach applications (in-building, data center, etc), so no 
attenuation is needed.


Is it true that if the rx power is higher than (x?) then it shortens 
the life of the optics ?
(assumption being made here is that MAX Rx Power is not being exceed as 
per the spec sheets of the optics)


On short-reach optics, this should never be a problem.  On long-reach 
optics, receiver saturation will generally result in link errors/flaps, 
and possibly high rx power warnings (depending on the gear on the 
receiving end), however, these can be addressed using in-line attenuators.


On very long-reach optics, such as ZX (1G) and ER/ZR (10G), it is possible 
to damage the receivers with too hot of a signal because they are designed 
for long spans and a certain amount of distance-based attenuation is 
factored into the optical power budget.


jms

Re: Cisco Nexus

[Justin M. Streiner]

On Mon, 2 Feb 2015, Brandon Ewing wrote:


On Mon, Feb 02, 2015 at 12:51:04PM -0600, David Bass wrote:

The n2k ToR is not a great design for user or storage interfaces if most of 
your traffic is east/west.  It is great as a low cost ilo/drac/choose your oob 
port, or if most of your traffic is north/south.  Biggest thing to remember is 
that it is not a switch, and has limitations such as not connecting other 
switches to it. Like anything else you have to understand the product so that 
you don't engineer something that it wasn't designed to do.



And remember -- The Nexus 2K performs absolutely ZERO local switching -- all
frames received from client ports are just copied to the upstream device, so
it can handle the frame/packet forwarding logic.


Also remember that the Nexus (5K, at least) does cut-through switching. 
If you receive an errored frame on one port, the switch can and often will 
happily forward those errored frames once it figures out the destination 
MAC address(es).


jms

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

[Justin M. Streiner]

On Fri, 30 Jan 2015, Tore Anderson wrote:


For many folks, that's easier said than done.

Think about it: If everyone could just dual-stack their networks, they
might as well single-stack them on IPv4 instead; there would be no
point whatsoever in transitioning to IPv6 for anyone.


I re-read this 3 or 4 times, and it still doesn't make any sense.

I dual-stacked our backbone here at $dayjob 3+ years ago, and it really 
wasn't painful at all.  Sure, there were were some transition pains, but 
they've been more at the edge (firewalls, wireless, managing users, etc), 
but getting the backbone to handle both v4 and v6 was the easy part.


Granted, this process can be more or less painful in different 
environments, but definitely no reason to stick your head in the sand and 
pretend that IPv6 doesn't exist, especially in 2015.


jms

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

[Justin M. Streiner]

On Fri, 30 Jan 2015, Eric Louie wrote:


If you assign a customer IPv6 space only, a translation mechanism is
needed to allow that customer to reach Internet destinations that only
speak IPv4 today.  There's no way around that.


What IPv6 to IPv4 translation mechanisms are available for networks with
multiple ingress/egress points?


A bunch were listed in an earlier post.  Translation is generally best 
done either as close to the customer edge as possible.


jms

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

[Justin M. Streiner]

On Fri, 30 Jan 2015, Eric Louie wrote:


It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't
want me to advertise anything longer than my /32 into BGPv6.  Is that true?
(I'm getting that from the spamming comments made by others)  Am I
supposed to be asking ARIN for a /32 for each region that I want to
address?  (They turned down my request for an increase to a /28 last year)


Not true.  A peek at the global IPv6 routing table shows lots of prefixes 
that are smaller than /32.  One of the hopes with larger allocations and 
assignments was that there would be less bloat in the global IPv6 routing 
table because networks would need to announce fewer prefixes.  How well 
that will hold up in practice remains to be seen :)



As far as the v6 to v4 translation is concerned, I'm looking at that for
the future - for the time being, we will be dual-stacked.  However, if we
move into a new area, based on our current IPv4 inventory, I don't really
have enough to assign to each new customer, so I was looking for ways to
allow those customers access to properties that are still IPv4 only.  Is
there yet another way to do that?


If you assign a customer IPv6 space only, a translation mechanism is 
needed to allow that customer to reach Internet destinations that only 
speak IPv4 today.  There's no way around that.


jms

Re: How do I handle a supplier that delivered a faulty product?

[Justin M. Streiner]

On Tue, 16 Dec 2014, Baldur Norddahl wrote:


Zhone reversed their stance on this and put everything on finding a fix.
Now we have a working firmware that moves data at line speed with no need
to put limits on downloads. Everyone are happy now. The 2301 with new
firmware is performing as expected and seems like a good product for our
needs.


Good to see they came around.  I take it they did not elaborate on their 
sudden change of heart?


jms

Re: Charging fee for BGP prefix per /24?!

[Justin M. Streiner]

On Wed, 10 Dec 2014, Yucong Sun wrote:


It is not the same thing though. In my case, they just say we want you to
buy our IP, if you don't and want use you own Arin allocated IP blocks
through bgp, then we got to charge you anyway!


Are they charging per /24 (assuming IPv4 here...), or per prefix?

If they are charging per /24, that seems like a great way to encourage 
customers to find another provider.


If they are charging per prefix, that seems like an interesting way to 
encourage customers to make sure they aggregate their BGP advertisements 
as much as possible.


jms

Re: How do I handle a supplier that delivered a faulty product?

[Justin M. Streiner]

On Tue, 25 Nov 2014, Miles Fidelman wrote:

If it doesn't deliver to spec, that certainly seems like a warranty claim, 
followed by a lawsuit (yes - talk to a lawyer).


Also, define large shipment and total dollars involved.  You might be able 
to take them to small claims court (much simpler process, but generally for 
$10,000 or under).


Disclaimer: I am not a lawyer, and I don't play one on TV.

Don't be afraid to march this up the chain at Zhone, if you're dealing 
with a salescritter.  You might be able to get better responses from VPs 
or CxOs.  Keep the lawsuit option in your back pocket if you need it.


Many companies don't want the PR black eye that comes with a customer 
filing suit against them, so the threat of beating them with a stick can 
be just as effective actually carrying out that threat.  If you have a 
lawyer on retainer already, maybe have them on the phone with you when you 
speak to the CxO at Zhone.


If their product is advertised as providing a service that it can't/won't 
actually provide, whether it's positioned as a low-cost product or not is 
irrelevant.  If their data sheets make no mention of the limitations that 
have been found, that's more ammunition for the cannon.


Before anyone comes back with something like So if I buy an entry level 
car, but I expect it to perform like a high-end sports car, does that mean 
I can sue the entry-level car maker for false advertising when it doesn't 
perform like a high-end sports car?  No, it doesn't.  There are reasonable 
expectations.  Expecting an entry-level car to perform like a high-end 
sports car isn't reasonable.  Expecting a GPON modem to be able to forward 
wire-speed gigabit Ethernet in this day and age is perfectly reasonable.


jms

Re: A case against vendor-locking optical modules

[Justin M. Streiner]

On Mon, 17 Nov 2014, Jérôme Nicolle wrote:


What are other arguments against vendor lock-in ? Is there any argument
FOR such locks (please spare me the support issues, if you can't read
specs and SNMP, you shouldn't even try networking) ?

Did you ever experience a shift in a vendor's position regarding the use
of compatible modules ?


In the case of some vendors (yes, you again, Cisco), the shift has been in 
the wrong direction.


Some vendors treat optics as just a tool to do a job, and price 
accordingly.  Those vendors tend to have fairly relaxed policies re: 
working with non-$vendor optics, as well.


Other vendors treat optics as a cash cow^H^H^H^H^H^H^H^Hprofit center, and 
also price accordingly.  Those vendors tend to scream bloody murder if a 
non-$vendor optic is encountered.


Beyond that, I'd say you've covered all of the logical reasons why vendor 
lock-in is a bad idea, but as others have mentioned in this thread, those 
attitudes tend to change at a ridiculously slow pace, and only when forced 
by market conditions.


jms

Re: A case against vendor-locking optical modules

[Justin M. Streiner]

On Mon, 17 Nov 2014, Jérôme Nicolle wrote:


Is it unrealistic to hope for enough salesmen pressure on the corporate
ladder to make such moronic attitude be reversed in the short term ?


No salesperson is likely to do that for you.  They know only to well that 
eliminating vendor lock-in means they will lose sales on artificially 
costly optics from $vendor to a lower-cost rival.  Less sales = less 
commission for the affected sales person.


jms

Re: A case against vendor-locking optical modules

[Justin M. Streiner]

On Mon, 17 Nov 2014, valdis.kletni...@vt.edu wrote:


On Mon, 17 Nov 2014 15:34:50 -0500, Justin M. Streiner said:


No salesperson is likely to do that for you.  They know only to well that
eliminating vendor lock-in means they will lose sales on artificially
costly optics from $vendor to a lower-cost rival.  Less sales = less
commission for the affected sales person.


I suspect that losing the commission on a few $6digit chassis sales is worse
than losing the commission on a $3digit optic?


That turns into a forest  trees problem.  Many salescritters don't think 
about the larger picture, or the responsible business units don't care 
about what affects other business units.  Also, in the 10G-and-up world, 
most of those optics are a lot more than $3digits.


jms

Re: Kind of sad

[Justin M. Streiner]

On Wed, 12 Nov 2014, Sholes, Joshua wrote:


I concur.   I was recently an admin/ITSO for a defense contractor, and
from a network logging standpoint it is VERY difficult to tell the
difference between what you posted and a really subtle
social-engineering-enabled attack--and EVERY attacker these days has to be
assumed to be subtle.


Agree completely.  While the OP's intentions might be honorable, even if 
he notified the organization directly, they might not react the way he 
would want:


Thank you for bringing this to our attention!  We will get it fixed 
immediately.


I am not a lawyer, but I would strongly advise against randomly logging 
into hosts on a network where I don't have a formal business relationship 
that includes explicit authorization to do pen-testing and other 
[insert-color-here]-hat activities.


Being a good Samaritan and the current state of computer crime laws do not 
always line up very nicely with each other.


Bottom line: Tread carefully.

jms

Re: Equinix Virginia - Ethernet OOB suggestions

[Justin M. Streiner]

On Tue, 11 Nov 2014, valdis.kletni...@vt.edu wrote:


On Mon, 10 Nov 2014 21:36:17 -0500, Christopher Morrow said:


also, it's hard to use ipv6 when your last miile provider doesn't offer it...


I hear the chaps at Hurricane Electric can help you with a nice tunnel 
for that...


Indeed.  I've had one in place for probably two years.  Works like a 
charm.


Kudos to Owen  co :)

jms

Re: Tech Laptop with DB9

[Justin M. Streiner]

On Mon, 10 Nov 2014, Max Clark wrote:

DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on 
a cheap laptop for use in field support (with an onboard DB9)?


You might be able to pick up something like an old Dell Latitute D800 
series pretty cheaply.  Built-in RS232 serial ports are very tough to find 
on current laptops, however USB serial drivers have come a long way in the 
last several years, depending on your OS.


jms

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

[Justin M. Streiner]

On Sun, 9 Nov 2014, Lorell Hathcock wrote:

A job opportunity just came my way to work with 26 miles of dark fiber 
in and around a city in Texas.


How is the outside plant being built and supported?  Who fixes fiber cuts? 
Who manages the fiber-cut-fixers?  Who monitors the network and handles 
initial triage to determine if there is a fiber cut, as opposed to a 
hardware/optic failure?


Those questions lead to many others, such as who has documentation and 
as-built drawings for the fiber plant?  Are all of the access agreements, 
insurance certificates, letters of agency, etc. up to date and accurate?


jms

Re: Cogent admits to QoSing down streaming

[Justin M. Streiner]

On Thu, 6 Nov 2014, Blake Hudson wrote:

Owen, should providers be able to over subscribe their networks? If so, at 
what tier level (tier 1, 2, 3, residential ISP)? Is it acceptable for a 
provider to permit frequent congestion if they choose to? Or should they be 
forced to take action that may (potentially) lead to increased customer rates 
or reduced customer bandwidth?


Tier levels are marketing terms - irrelevant to technical/operational 
discussions.


Every provider oversubscribes to some level, whether they're in the last 
mile serving residential users, or a carrier of carriers.  It's just a 
question of what amount of oversubscription is acceptable, and what the 
risks are when customers blow that oversubscription model out of the 
water, either in the short term (streaming major sporting events, etc), or 
in the longer term (increased prevalence of streaming video, rich content, 
etc).  Congestion due to short-term spikes is often seen as an acceptable 
risk.  Congestion due to long-term shifts in customer network usage habits 
requires the oversubscription model to be re-worked, or the provider (and 
by extension... their customers) accepts a reputation of not dealing 
proactively with congestion.


jms

Re: Comcast throttling?

[Justin M. Streiner]

On Fri, 31 Oct 2014, Mark Price wrote:


Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.

Downloading a file from one of our web servers is very slow (~15KByte/sec).
mtr looks clean in both directions.  I added an IP address on the same
server from a different class C on our network, and downloads form this new
IP are fast (2MByte/sec).

Tracerouting from server to client is the same using both source IPs.  But,
one IP consistently has the very slow speeds that the other does not.
Changing our outbound path between different upstreams does not make a
difference.

It certainly feels like Comcast is throttling one of our IP ranges.  Could
someone at Comcast please contact me off-list for details?


That's possible, but while a traceroute can help shed some light on 
certain performance problems, this doesn't seem like one where a 
traceroute will help very much.  The slow traceroute hops are more likely 
due to other factors (ICMP rate limiting / control plane policing / etc), 
rather than a direct indicator of Comcast shaping / throttling your 
traffic.


As others have indicated, doing a packet capture of a transfer session 
that shows the behavior you noted is likely to be a lot more telling than 
a traceroute.


jms

Re: Industry standard bandwidth guarantee?

[Justin M. Streiner]

On Wed, 29 Oct 2014, valdis.kletni...@vt.edu wrote:


On Wed, 29 Oct 2014 15:24:46 -0700, keith tokash said:


Is there an industry standard regarding how much bandwidth an inter-carrier 
circuit should guarantee?


And where your PoPs are (and how many) matters as well - if you have a peering
agreement with another carrier, and you exchange 35Gbits/sec of traffic, the
bandwidth at each peer point will depend on whether you peer at one location,
or 5, or 7, or 15.


...and many different carriers have different definitions of congestion. 
Some carriers might have several definitions of the word, depending on the 
service you have and which group you happen to be speaking to that day.


It's pretty much impossible to guarantee bandwidth on an inter-carrier 
packet-switched link.


jms

Re: NTT high packet loss from US and BR to AU?

[Justin M. Streiner]

Do you see any other indications of performance problems?

jms

On Thu, 23 Oct 2014, Javier J wrote:


Anyone else notice this?

Or is this an AWS issue in APAC that hasn't been reported yet?

AU-NY(aws)
18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%

BR(aws)-AU(aws)
11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%


NJ/NYC to AU(aws)
9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0

Re: Requesting a Global Crossing contact

[Justin M. Streiner]

On Thu, 2 Oct 2014, Eric Sieg wrote:


Could someone from Global Crossing reach out to me please?  Just need to
confirm you see a route and haven't had any luck accessing your looking
glass in the last 24 hours.


Have you tried reaching out to anyone at Level3?  Level3 acquired GX 3 years
ago.

jms

Re: Verizon FiOS IPv6

[Justin M. Streiner]

On Wed, 1 Oct 2014, Anthony Junk wrote:


I already have IPv6 on my router at home. They rolled out an update a few
months back that added the capability for the latest 802.1N model. I'm not
at home to look at it but I'll update with the model this evening.


Like many others, I would be interested to hear more about this.

Verizon pushed a firmware update to my Fios router some time ago that 
supports IPv6, but I was not receiving native v6 connectivity from Verizon 
at home.


I think they did some small-scale deployments as a test, and maybe you're 
in one of the areas they rolled out, but I don't think there are any 
larger deployments on the immediate radar.


My calls to the front-line call center (I make a point of doing this every
few months) generally get no information.  Offering to put a note in my
account stating that I asked about IPv6 is only useful if someone from
Verizon actually goes back and reads those notes.  Shaking other trees at
Verizon through $dayjob has not produced any better results so far.

Until Verizon offers native IPv6, I will continue using my tunnel through 
HE, which has been rock-solid.


jms


On Wed, Oct 1, 2014 at 1:44 AM, Bryan Seitz se...@bsd-unix.net wrote:


On Wed, Oct 01, 2014 at 01:35:15AM -0400, Christopher Morrow wrote:

On Wed, Oct 1, 2014 at 1:28 AM, Romeo Czumbil rczum...@xand.com wrote:

Does anybody have any idea on when Verizon FiOS is turning up IPv6?

(dual-stack)


looking at the archives is helpful in this question/answer process..
but to save you the digging: When there's ice in the devil's house
(essentially)


Yeah... although they seem to be releasing a new residential gateway that
does IPV6 as
well as 802.11AC.  Maybe this is a good sign ? :)


http://www.dslreports.com/shownews/Verizon-Preps-Launch-of-New-FiOS-Gateway-130273

--

Bryan G. Seitz

RE: Saying goodnight to my GSR

[Justin M. Streiner]

On Mon, 22 Sep 2014, David Hubbard wrote:


Got you beat by nine weeks with a Foundry 9604. :-)


I might have a Cat5505 or two on our out-of-band management network with 
uptimes that approach this.


jms


#sh ver
 SW: Version 03.3.01aTc1 Copyright (c) 1996-2004 Foundry Networks, Inc.
 Compiled on Feb 01 2005 at 11:21:12 labeled as FES03301a
 (2057881 bytes) from Primary foundry-FES/FES03301a.bin
 Boot Monitor: Version 03.2.00Tc4
 HW: Stackable FES9604

==
 Serial #:
 330 MHz Power PC processor 8245 (version 129/1014) 66 MHz bus
 512 KB boot flash memory
16384 KB code flash memory
 128 MB DRAM
The system uptime is 3411 days 7 hours 52 minutes 20 seconds
The system started at 01:38:44 Eastern Sat May 21 2005

The system : started=warm start   reloaded=by reload



Poor thing just handles traffic for managed power strips and we haven't
had the heart to replace it lol.

David


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew
Crocker
Sent: Saturday, September 20, 2014 10:19 AM
To: NANOG
Subject: Saying goodnight to my GSR


Has been running for a while, time to shut 'er down.   She (is a router
a she?) used to handle all of my BGP GigE links but over the years has
been demoted to OSPF and T1 aggregation.

If anyone needs a boat anchor let me know.

gsr8-1#show version
Cisco Internetwork Operating System Software IOS (tm) GS Software
(GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support:
http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco
Systems, Inc.
Compiled Thu 30-Jun-05 18:29 by pwade
Image text-base: 0x50010E80, data-base: 0x536E8000

ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2]
RELEASE SOFTWARE

gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime
for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6
2005 System image file is slot0:gsr-p-mz.120-30.S3.bin

cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of
memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last
reset from power-on

2 Route Processor Cards
2 Clock Scheduler Cards
3 Switch Fabric Cards
2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2
GigabitEthernet).
1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3
GigabitEthernet).
1 Ethernet/IEEE 802.3 interface(s)
5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile
configuration memory.

20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matt...@crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com

RE: Saying goodnight to my GSR

[Justin M. Streiner]

On Mon, 22 Sep 2014, Jim Devane wrote:


They make great fish tanks in their second lives, although uptime stats are more 
general recollection for me now.

http://postimg.org/image/xdyp4o6p7/


Reminds me of a kegerator I saw many moons ago, made out of a hollowed-out 
Wellfleet BCN ;)


jms


-Original Message-
From: NANOG [mailto:nanog-bounces+jdevane=switchnap@nanog.org] On Behalf Of 
Drew Weaver
Sent: Monday, September 22, 2014 10:58 AM
To: 'Matthew Crocker'
Cc: 'nanog@nanog.org'
Subject: RE: Saying goodnight to my GSR

The best thing about having GSRs around is trading them in for ASR 9900s.

The freight is a ding, though.

-Drew


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew Crocker
Sent: Saturday, September 20, 2014 10:19 AM
To: NANOG
Subject: Saying goodnight to my GSR


Has been running for a while, time to shut 'er down.   She (is a router a she?) 
used to handle all of my BGP GigE links but over the years has been demoted to 
OSPF and T1 aggregation.

If anyone needs a boat anchor let me know.

gsr8-1#show version
Cisco Internetwork Operating System Software IOS (tm) GS Software (GSR-P-M), 
Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support: 
http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Thu 30-Jun-05 18:29 by pwade
Image text-base: 0x50010E80, data-base: 0x536E8000

ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2] RELEASE 
SOFTWARE

gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime for this control 
processor is 9 years, 2 weeks, 2 days, 18 minutes System returned to ROM by Stateful 
Switchover at 13:46:36 UTC Tue Sep 6 2005 System image file is 
slot0:gsr-p-mz.120-30.S3.bin

cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last reset from 
power-on

2 Route Processor Cards
2 Clock Scheduler Cards
3 Switch Fabric Cards
2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2 GigabitEthernet).
1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet).
1 Ethernet/IEEE 802.3 interface(s)
5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile 
configuration memory.

20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matt...@crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com




CONFIDENTIAL INFORMATION

This email message, its chain, and any attachments: (a) may include proprietary 
information, trade secrets, confidential information and/or other protected information 
(Confidential Information) which are hereby labeled as Confidential for 
protection purposes, (b) is sent to you in confidence with a reasonable expectation of 
privacy, (c) may be protected by confidentiality agreements requiring this notice and/or 
identification, and (d) is not intended for transmission to, or receipt by unauthorized 
persons. If you are not the intended recipient, please notify the sender immediately by 
telephone or by replying to this message. Please then delete this message, any 
attachments, chains, copies or portions from your system(s). Thank you.

Re: Facebook down?

[Justin M. Streiner]

Works here (large .edu in Western PA).  I would expect there to be rioting 
in the streets if FB was down.


jms

On Wed, 3 Sep 2014, Charles Mills wrote:


W. PA. too.  Looks pretty widespread.


On Wed, Sep 3, 2014 at 3:46 PM, aUser au...@mind.net wrote:


Appears to be in Oregon, Southern Oregon.  Mobile too.

Sent from my iPhone 5S.


On Sep 3, 2014, at 12:45 PM, Marshall Eubanks 

marshall.euba...@gmail.com wrote:


This message has no content.

Re: Multicast Internet Route table.

[Justin M. Streiner]

On Tue, 2 Sep 2014, Corey Touchet wrote:


14 years at Verizon Wireless and I despised the crop of multicast products
that seemed to pop up from time to time.  Even in a fully controlled
network multicast remains at best black magic.  There are ways to make it
more reliable and prevent people from ruining the setups especially for
PIM type setups, but I would agree with others, unicast has better
advantages though you have to keep up with the bandwidth curve.


I can tell you that the IPv4 multicast routing table size has been 
pretty much flat (stable to declining slightly) for the past several 
years.  Right now, I see a total of just under 3,800 IPv4 multicast routes 
through Internet2 and other research/education networks, and that number 
hasn't changed much in probably 2-3 years.  I don't get any multicast 
routes from my commodity Internet providers.  Several years ago (2008-ish),
I was receiving around twice that many multicast routes, so it has died 
off significantly in the long view.


External IPv4 multicast traffic has been pretty much zilch for quite some 
time, from my viewpoint.


jms

Re: Best US Tunnelbroker for Youtube

[Justin M. Streiner]

On Wed, 20 Aug 2014, Ryan Shea wrote:


Just one man's experience, but my YouTube performance over my Hurricane
Electric tunnel has been strikingly poor lately - so much so that I was
thinking of squashing v6 in my house entirely. Looking for your
experiences/thoughts on whether cutting over to SixXS or Routinghouse could
be a path to 1080p cat video bliss instead.


I haven't noticed any significant performance degradation to Youtube 
lately over my HE tunnel.  My home ISP is Verizon Fios.


Are you experiencing problems _just_ to Youtube, or wider-scale problems 
in general?  If it's the latter, perhaps there's congestion or some other 
problem between your ISP and HE.


jms

Re: Urgent

[Justin M. Streiner]

On Mon, 18 Aug 2014, Daniel Roesen wrote:


Just send your request to the all-gods well-known multicast group.


224.6.6.6?

jms


On Mon, Aug 18, 2014 at 05:20:48PM +, Kain, Rebecca (.) wrote:

Which one?

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of ra...@psg.com
Sent: Monday, August 18, 2014 1:00 PM
To: nanog@nanog.org
Subject: Urgent

Contact for God, please reach out to me offlist.

Regards,
 -AS666 NOC


--
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: Akamai charges for IPv6 support?

[Justin M. Streiner]

On Tue, 19 Aug 2014, Mark Andrews wrote:


No, I expect it to be part and parcel of the basic fees, as IPv4
is, which I'm happy to hear it is in this case.


Based on a response I saw in this thread earlier today, it sounds like 
IPv6 support is no longer a separate charge from Akamai.  Perhaps that 
hasn't filtered out to the salescritters yet.


jms

Re: Akamai charges for IPv6 support?

[Justin M. Streiner]

On Tue, 19 Aug 2014, Rubens Kuhl wrote:


Or they did get the memo, but realised that no sale == no commission.


If they got the memo and chose to ignore it, then that gives me all the 
ammunition I need to hit them with the biggest cluebat I have, and squeeze 
them for a discount for the inconvenience.


Trying to charge for something that is known to be a no-charge item is bad 
business, and will end badly for $salescritter when they get called out 
for it.


jms

Re: IPv6 route annoucement

[Justin M. Streiner]

On Thu, 7 Aug 2014, John York wrote:


Hoping to not start a war...

We (a multi-homed end-user site) are finally getting IPv6-enabled Internet
connectivity from one of our ISPs. In conversations regarding our BGP
config, the ISP has balked at allowing us to advertise our ARIN-assigned
/44, saying things like, do you know how many addresses that is!!??


Sounds like the ISP in question is in need of some serious IPv6 clue.  The 
number of hosts means nothing, in terms of BGP advertisements.  In fact, 
fewer announcements is better.  De-aggregation bloats the global routing 
table.


Most carriers I've seen will accept IPv6 announcements as small as a /48.

If your /44 was assigned by your RIR, and it's documented in their 
whois/rwhois/route registry, your ISP really doesn't have a leg to stand 
on, regarding not accepting your announcement.



Am I way off base in thinking this network size is not out of the norm? I
know it's a lot of addresses (19 octillion-something?), but that
assignment was based on the same criteria that got us a /22 in v4 space.
Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting
a /22 in v4?


The largest IPv6 prefix I saw in the global Internet routing table the 
last time I looked (a few months ago) that wasn't for a special purpose 
was a /19 ~33 million times larger than a /44.


Your ISP should have more constructive things to do than hassling a 
customer about announcing a /44.


jms

Re: Comcast IPv6 Milestone

[Justin M. Streiner]

On Thu, 24 Jul 2014, Ian Bowers wrote:


Thank you for sharing!  Would LOVE to see something like this from Verizon
about FioS.


Agreed.  I'd love to see some movement from Verizon, but I'm not hopeful.

I'm not above using this announcement to needle them a bit (more than 
normal) the next time I ask them about their deployment plans.


jms

Re: Next steps in extortion case - ideas?

[Justin M. Streiner]

On Sat, 5 Jul 2014, C. A. Fillekes wrote:


Furthermore, since the internet is everywhere, I pointed out (or did you
stop reading after I mentioned that we don't actually know the gender of
the scammer?) Markus has the option of pursuing this in a jurisdiction
where the penalties for criminal defamation are the harshest.  It would not
have to be in the US.


Unless one or more of the plaintiffs is located a country with the harshest 
penalities, or a plaintiff can otherwise demonstrate how people in country 
XYZ are being harmed by the scammer's actions, I don't see that going very 
far.  A plaintiff in Germany trying to bring a case to court in Singapore 
against a defendant in the United States isn't going to work so well.  I 
am not a lawyer, but my guess is that the case would be thrown out because 
the plaintiff would lack standing to bring a case to court in that 
country.


Yes, the global Internet is a global communications tool, but that doesn't 
mean you can cherry-pick which country to use in trying a case just because

the extortion is taking place over the Internet.


Finally, you fail to address the one very simple way I described to
determine who this scammer is: follow the money.  Make a small partial
payment on this supposed debt and see who cashes the check.  Much easier
than trying to follow him around on the internet, though that would be
made easier in the course of negotiating a partial payment.


This is much easier to do once law enforcement agencies are engaged.  They 
can trace the money trail more throughly and effectively than you or I 
can, as civilians.


jms

Re: Next steps in extortion case - ideas?

[Justin M. Streiner]

On Sat, 28 Jun 2014, Markus wrote:

nothing operational here, but there are many smart minds on this list and 
people working for telcos, ISPs and law enforcement agencies, so maybe you 
are willing to give me some advice in the following case:


That individual is hiding his real identity really well, obviously, and he 
knows what he's doing. Domain hosted in Russia, taking good care his IP 
address won't show up in the mail headers, using false names and identities, 
phone numbers registered through some DID provider who doesn't collect 
personal information about the DID owner etc.


Fair warning: I am not a lawyer, and not an expert in the intricacies of 
international law.  You would be well-advised to seek counsel from a 
lawyer who specializes in this area.


Have you contacted your local police, or the German equivalent (the 
BKA?) of the United States' FBI?  Law enforcement agencies are going to

have (or can get through court order) the legal authority to get the
information you're after, and if the information is deemed credible and 
the offense serious enough, charges can be brought against the individual. 
Most likely the US FBI would get involved after being contacted by their 
counterparts in Germany, since international crime generally falls under 
federal jurisdiction in the US.


My personal opinion is that having a PI go to the individual's house would 
not accomplish more than 'tipping your hand' to that person - letting them 
know that you've committed resources to tracking them down.


jms

Re: short, two part question ICANN Vs. The World

[Justin M. Streiner]

On Mon, 23 Jun 2014, stovetop 202 wrote:


What do you mean by if anyone can see it?
The lines are now closed off from the public's view.. but the textbooks 
still teach you that you should be able to have access freely.  Is it 
the data on the hard line that you're worried people can see?


It would help if you'd provide an explanation of what you're trying to 
accomplish.  It almost sounds like some combination of firewalls and proxy 
servers to provide some separation between your network(s) and the rest of 
the global Internet might be a more functional solution than doing odd 
things with DNS.


Bear in mind that a lot of the answers you get will probably be along the 
lines of it depends or this might work, and come with an implied 
disclaimer (no guarantees).  People might also recommend that you consider 
engaging a consultant to design/build what you need.


jms

Re: Ars Technica on IPv4 exhaustion

[Justin M. Streiner]

On Thu, 19 Jun 2014, Brian Hartsfield wrote:


I am going to be real interested to see how the media handles the situation
when ARIN runs out of IPv4 addresses.   I could really see some big doom
and gloom stories hit some of the mainstream media when that occurs.  While
it isn't the end of the world when ARIN runs out, it is still significant
and I personally think that moment is going to be what starts to spur more
CIOs to start asking questions about IPv6 and if their organization is
ready (and the answer likely being no)


IPv4 doom and gloom is just more irresponsible/un-informed journalism.

ARIN getting close to running out of IPv4 addresses is not news.  That 
this would eventually happen has been known for a very long time. 
Entities choosing to keep their heads in the sand and ignore that fact is 
another matter altogether.


Were there (m)any OMG WE'RE OUT OF IP ADDRESSES!!!1!111 articles when 
APNIC throttled final assignments down to one /22 per organization after 
they dipped into their last /8?  Were there (m)any when RIPE got down to 
their last /8


jms

Re: Ars Technica on IPv4 exhaustion

[Justin M. Streiner]

On Thu, 19 Jun 2014, Christopher Morrow wrote:


2. The network Admins at the above mentioned companies need to learn IPV6,
most will want there company to pay the bill for this.


for a large majority of the use cases it's just configure that other
family on the interface and done.


In the simplest cases, yes.  Throw things that often exist in 
mid to large sized enterprises, like firewalls, DHCP servers, load 
balancers, log analyzers, etc, having to upgrade $XYZ to get IPv6 support 
or fix bugs, and there's a bit more to it.  These are not insurmountable 
problems, but administrative/political/financial inertia is a real thing 
in many shops.



3. The vendors that make said equipment should lower the cost of said
equipment to prompt said companies into purchasing said equipment.


the equipment in question does both v4 and v6 ... so why lower pricing?
(also, see 'if made in the last 7 yrs, it's already done and you
probably don't have to upgrade')


There could be problems with things like DHCPv6, depending on how the 
user's ISP provisions service.  SLAAC 'just works' for the most part, but 
if the FooTronics 1000 an all-in-one router/firewall/wireless AP/printer/
belt sander/toaster from $BIGBOXSTORE doesn't come with firewall settings 
that let IPv6 work just out of the box, or at least have a big, shiny 
Make IPv6 work button, support calls will be generated.  ISPs and 
FooTronics both hate support calls.


Again, playing devil's advocate here.  I just don't look forward to 
dealing with support calls from customers who bought kit from vendors who 
slammed in IPv6 support as quickly and cheaply as possible.


jms

Re: Ars Technica on IPv4 exhaustion

[Justin M. Streiner]

On Thu, 19 Jun 2014, Ricky Beam wrote:

Can we stop with the lame every person, and their dog! numbering plans. The 
same MISTAKE has been repeated so many times in recent history you'd think 
people would know better. It's the exact same wrong-think that was applied to 
the 32bit IPv4 addressing in an era where there were a few dozen computers 
worldwide. (also that IPv4 was an experiment that was never imagined to be 
this big.)


How much IPv6 space would you propose an ISP provisions for each of its 
residential users?


jms

Re: BGP route flapping

[Justin M. Streiner]

On Wed, 14 May 2014, Gus Crichton wrote:

Hope you networking experts can shed some light on a concern I have 
please. I am multihoming using 2 ISPs to the internet, due to reasons 
outside my control, my primary preferred link keeps dropping a number of 
times a day forcing traffic to my backup and vice-versa when the primary 
comes back up.


Is it feasible to make your backup ISP your primary ISP until your 'real' 
primary ISP gets the link flapping issues sorted out, or you and your real 
primary ISP work together to get the issue sorted out?


The route calculations by the upstream tier 1s and 2s handle the route 
calculations but if I do this too many times consuming their resources, 
is there a penalty/blackmark on my AS? Is this monitored even by the 
tier1s and 2s?


Networks can choose to implement some amount of BGP flap damping, however 
this is generally done at the closest point to the source of the flapping.


This is typically a temporary measure - the damped routes will be restored 
after a period of stability.


The bigger issue is finding the source of the flapping and getting it 
fixed.


jms

Re: level3 dia egress filtering?

[Justin M. Streiner]

On Mon, 12 May 2014, Bob Evans wrote:


Ahh,  Yep, same thing port and/or protocol for an address range.  I haven't
seen that accomplished via BGP. I know ATT will do it - they want about 2K
more per month for that ability. All your traffic is redirected (extra
hops ) through a firewall. So, it's a basic expensive firewall service.

We have done both port based and protocol. But it gets installed by hand
only on the connected port the customer.


From what I've seen, most of the major carriers don't filter traffic 
outside of truly exceptional circumstances, or it's treated as a revenue 
source.  If it's offered at all, it's often priced unattractively, because 
carriers often don't want to be in the firewall/port-filtering business.


jms

Re: What Net Neutrality should and should not cover

[Justin M. Streiner]

On Mon, 28 Apr 2014, Rick Astley wrote:


Double-billing Rick. It's just that simple. Paid peering means you're 
deliberately

billing two customers for the same byte

Where your statement is short sighted I already explained partly in saying
its too difficult to decide who gets a free ride and who gets the bill so I
challenge you to propose an actual policy that prohibits charging for
peering that doesn't have major unintended consequences. All in all I am
sort of disappointed to find so few rational opinions around here. One of
the few decent articles I have read on it is here:
http://blog.streamingmedia.com/2014/02/media-botching-coverage-netflix-comcast-deal-getting-basics-wrong.html

I think if you make a law that says all content providers big and small get
free pipes and the residential subscribers of broadband must pay the tab
the cost of broadband in the US compared to the rest of the world
skyrocket.


No one is suggesting that all content providers get a 'free ride', let 
alone a legally-mandated free ride.  Giving last-mile providers an 
implicit (if not explicit) OK to bill providers whose content happens to 
be popular with the last-mile providers' customers sets a horrible 
precedent.


Content providers have infrastructure costs, just like last-mile ISPs. 
Your arguments seem to ignore that minor point.  Those cost cover 
different things than what a last-mile ISP would need to cover, but they 
have costs nonetheless.  They either pay other providers to haul their 
bits to other networks or they build infrastructure to locations that 
allow them to peer with providers.  That could be to a mutually-agreed 
meet point for private peering, or it could be to an exchange point to 
peer with other providers who have a presence at the same exchange point.


Look at the Peering DB.  In general, you will see that content networks 
have more open peering policies than eyeball networks.  It's in their best 
interests to get as topologically close to their consumers as possible. 
Some transit networks do the same, but that's a much more variable 
picture.


jms

Re: The FCC is planning new net neutrality rules. And they couldenshrine pay-for-play. - The Washington Post

[Justin M. Streiner]

On Mon, 28 Apr 2014, Hugo Slabbert wrote:

Comcast is the destination network for the traffic; they're not providing 
transit services to Netflix.  Comcast needs to accept the Netflix traffic 
that Comcast's customers are requesting *somehow*;  I don't see why they get 
to charge Netflix for a private peering relationship that's beneficial to 
both sides.


If done on a cost-recovery basis (alternating or otherwise), the net cost 
to both providers should be small, well within the of the boundaries of a 
standard cost of doing business.  That argument also seems to be 
overlooked by people in the Yes, $ISP should be able to charge both 
customers and content providers for the same traffic camp.


jms

Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post

[Justin M. Streiner]

On Sun, 27 Apr 2014, Rick Astley wrote:


That amount of data is massive scale. I don't see it as double dipping
because each party is buying the pipe they are using. I am buying a 15Mbps
pipe to my home but just because we are communicating over the Internet
doesn't mean the money I am paying covers the cost of your connection too.
You must still buy your own pipe in the same way Netflix would. I covered
this scenario in more detail in my post What Net Neutrality should and
should not cover but if you expand on the assumption that paying for an
internet connection also pays for the direct connection of every party who
you exchange traffic with then you have a scenario where only half the
people connected to the Internet should have to pay at all for their
connection because any scenario where people simply buy their own pipe
would be considered double billing.


The size of the pipes involved doesn't change the fundamental premise that 
double-dipping is involved.  Comcast, et al want to be paid twice for the 
same traffic.  The money I pay Verizon every month for my Fios 
connection, by itself, doesn't pay for the rest of their network, but 
take the millions of Fios customers as a whole, and the revenue stream 
is significant.  We'll leave the government-mandated revenue stream 
out of the equation for now.  Just about every ISP, and certainly all of 
the big ones, practice statistical multiplexing - there is always some 
amount of oversubscription at play.  Add up the subscription speeds of 
every Fios customer, and the total ingress/egress capacity of Verizon's 
network, and the two numbers will not be equal - not by a long shot.


While 100G linecards and optics are still very expensive, those costs will 
come down over time.  Even at that, the cost of adding a 100G link between 
Big Network A and Big Network B is at most pennies per customer.


jms

Re: Phase 4.

[Justin M. Streiner]

On Thu, 24 Apr 2014, Bryan Socha wrote:


Whats the big deal   If your just arin, dont panic. Akamai and
digitalocean has been the only people aquire fair priced v4 putside
arin.So arin is ending.   It doesnt stop anything. be smart 3 usd
per ip is fair if dirty.  F the auct8ons they are fake and we get the ips
lower than op3ning.

Icann is the mast 8 class as real?Distribute them


At the risk of feeding the troll, ARIN is not 'ending'.  APNIC and RIPE 
didn't 'end' when they exhausted their supply of IPv4 addresses.


Will some people acquire IPv4 addresses on the secondary market?  Sure, 
though there are limits to how small chunks of IPv4 can be sliced up and 
maintain any realistic hope of global routability.  That's something that 
is *not* dictated by the RIRs.


jms

Re: IPv4 Address transfer after company acquisition

[Justin M. Streiner]

On Wed, 23 Apr 2014, John Jackson wrote:


I have a customer who previously didn't have any IPv4 address space.  They
recently acquired a competitor that has a /24.

Are there any special ARIN rules for this type of transfer?

Any pointers, or 'gotchas'?


I'm pretty sure ARIN has the transfer process documented on their website. 
From what I remember, ARIN will need to see some documentation of the 
acquisition, including a letter of agency/authorization from the company 
that was acquired, on the original company's letterhead.


jms

Re: BGPMON Alert Questions

[Justin M. Streiner]

On Wed, 2 Apr 2014, Laszlo Hanyecz wrote:


They're just leaking every route right?
Is it possible to poison the AS paths you announce with their own AS to get 
them to let go of your prefixes until it's fixed?
Would that work, or some other trick that can be done without their cooperation?


Keep in mind that the more AS hops there are between you and Indosat, the 
less effective that any hackery you do in your own BGP table will be.


Two things need to happen:
1. Indosat needs to clean their mess up.
2. Indosat's upstreams need to apply some BGP clue to Indosat's 
announcements.


It's pretty clear that both parties have dropped the ball in a big way, 
in terms of sane BGP filtering practices.


jms

Re: BGPMON Alert Questions

[Justin M. Streiner]

On Thu, 3 Apr 2014, Adrian Minta wrote:


Already too late :(

*Delivery has failed to these recipients or groups:*

indriana.triyunianingt...@indosat.com 
mailto:indriana.triyunianingt...@indosat.com
The recipient's mailbox is full and can't accept messages now. Please try 
resending this message later, or contact the recipient directly.


As long as that's not the only person behind the ip@indosat.com 
mail alias, all hope is not lost.  Still, I imagine their NOC is getting 
crushed with reports right now.


jms


On 02.04.2014 23:40, Aris Lambrianidis wrote:

 Contacted ip@indosat.com about this, I urge others to do the same.

 --Aris


 On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley
 andre...@aware.co.thwrote:

  Hi All,
 
  I am a network admin for Aware Corporation AS18356 (Thailand), as

  mentioned in the alert.
  We operate a BGPMon PeerMon node on our network, which peers with the
  BGPMon service as a collector.
 
  It is likely that AS4761 (INDOSAT) has somehow managed to hijack these

  prefixes and CAT (Communications Authority of Thailand AS4651) is not
  filtering them,
  hence they are announced to us and are triggering these BGPMon alerts.
 
  I have had several mails to our NOC about this already and have 
  responded

  directly to those.
  I suggest contacting Indosat directly to get this resolved.
  AS18356 is a stub AS, so we are not actually advertising these learned
  hijacked prefixes to anyone but BGPMon for data collection purposes.
 
 



--
Best regards,
Adrian Minta

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Justin M. Streiner]

These also get posted to other mailing lists, such as cisco-nsp.

jms

On Wed, 26 Mar 2014, rw...@ropeguru.com wrote:



Thanks everyone for the replies. I guess since they are done so infrequently, 
I was not a list member the last go around.


Robert

On Wed, 26 Mar 2014 12:58:44 -0400
 Andrew Latham lath...@gmail.com wrote:

 Robert

 Perfectly normal, almost an announce list for issues like this.

 On Wed, Mar 26, 2014 at 12:45 PM, rw...@ropeguru.com 
rw...@ropeguru.com wrote:
 
 Is this normal for the list to diretly get Cisco security advisories or

  something new. First time I have seen these.
 
  Robert
 
 
  On Wed, 26 Mar 2014 12:10:00 -0400

   Cisco Systems Product Security Incident Response Team ps...@cisco.com
  wrote:
  
   -BEGIN PGP SIGNED MESSAGE-

   Hash: SHA1
  
   Cisco IOS Software SSL VPN Denial of Service Vulnerability
  
   Advisory ID: cisco-sa-20140326-ios-sslvpn
  
   Revision 1.0
  
   For Public Release 2014 March 26 16:00  UTC (GMT)
  
   Summary

   ===
  
  A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of 
  Cisco

  IOS Software could allow an unauthenticated, remote attacker to cause a
   denial of service (DoS) condition.
  
  The vulnerability is due to a failure to process certain types of HTTP
  requests. To exploit the vulnerability, an attacker could submit 
  crafted
  requests designed to consume memory to an affected device. An exploit 
  could
  allow the attacker to consume and fragment memory on the affected 
  device.
  This may cause reduced performance, a failure of certain processes, or 
  a

   restart of the affected device.
  
  Cisco has released free software updates that address this 
  vulnerability.

   There are no workarounds to mitigate this vulnerability.
  
   This advisory is available at the following link:
  
   http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn
  
  Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled
  publication includes six Cisco Security Advisories. All advisories 
  address

  vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security
   Advisory lists the Cisco IOS Software releases that correct the
   vulnerability or vulnerabilities detailed in the advisory as well as 
  the

   Cisco IOS Software releases that correct all Cisco IOS Software
   vulnerabilities in the March 2014 bundled publication.
  
  Individual publication links are in Cisco Event Response: Semiannual 
  Cisco
  IOS Software Security Advisory Bundled Publication at the following 
  link:
  
   http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html

   -BEGIN PGP SIGNATURE-
   Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
   Comment: GPGTools - http://gpgtools.org
  
   iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+

   mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i
   uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc
   X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd
   atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn
   dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo
   RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8
   2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ
   0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd
   EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB
   ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7
   RF3x0wYuErbbC7N9m1UH
   =1Ixo
   -END PGP SIGNATURE-
  
 





 -- 
~  Andrew lathama Latham lath...@gmail.com http://lathama.net ~

Re: A little silly for IPv6

[Justin M. Streiner]

On Wed, 26 Mar 2014, valdis.kletni...@vt.edu wrote:


On Wed, 26 Mar 2014 09:19:14 -0400, rw...@ropeguru.com said:


Again comparing something like factual numbers of IPv6 addresses the
the very fuzzy math of guessing how many atoms there are is very silly
indeed.


A bit of thought will show that you can probably compute this based on our
estimage of the mass of the earth, which is known to be 5.97219 ? 10^24 kg,
and an estimate of what elements the mantle and core are made up of.


This thread has gone pretty far off the rails, in terms of being on topic 
for NANOG.


jms

Re: misunderstanding scale (was: Ipv4 end, its fake.)

[Justin M. Streiner]

On Sat, 22 Mar 2014, Bryan Socha wrote:


Oh btw, how many ipv4s are you hording with zero justification to keep
them?   I was unpopular during apricot for not liking the idea of no
liability leasing of v4. I don't like this artificial v4 situation
every eyeball network created.Why is v4 a commodity and asset?   Where
is the audits.I can justify my 6 /14s, can you still?


That ship sailed a long time time ago.  Can some IPv4 space be recovered 
by 'auditing' consumers of IPv4?  Possibly.  Does the amount of space that 
would be recovered justify the effort (economic, administrative, legal, 
technical)?  No.  IPv6 is the way to go.


All of these 'Hail Mary' options for 'saving' IPv4 really are pointless.

Don't forget that IPv4, in the form we know it, was never intended to go 
into production.  It's a lab experiment that grew legs and got out of its 
cage.


jms


On Mar 22, 2014 4:36 AM, TJ trej...@gmail.com wrote:


Millions of IPs don't matter in the face of X billions of people, and
XX-XXX billions of devices - and this is just the near term estimate.
(And don't forget utilization efficiency  - Millions of IPs is not
millions of customers served.)

Do IPv6.
/TJ

On Mar 22, 2014 3:09 AM, Bryan Socha br...@digitalocean.com wrote:


As someone growing in the end of ipv4, its all fake.Sure, the rirs

will

run out, but that's boring.Don't believe the fake auction sites.
Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for

no

spam and $4 for legacy.Stop the inflation. Millions of IPS exist,
there is no shortage and don't lie for rirs with IPS left.

Re: Ipv4 end, its fake.

[Justin M. Streiner]

On Sat, 22 Mar 2014, Cb B wrote:


You can pay $3 per ipv4, that is your business. But, it may be worth noting
that ATT, Verizon, Comcast, T-Mobile, TWT, Google Fiber all have have
double digit ipv6 penetration today.


To be fair:
Verizon Wireless, if you're referring to 4G LTE?  Agreed.
I don't know what the plan is for the remaining 3G services.
Verizon Enterprise (what used to be UUNET)?  Agreed.
Verizon Online (Fios, DSL)?  I have to disagree.  Lots of foot-dragging 
here.


Most carriers appear to be making IPv6 capability a requirement for their 
LTE buildouts.  The only major US carrier that I hears was resisting IPv6 
was Sprint, and I don't know if their position has changed in the past 12 
months.


jms

Re: misunderstanding scale (was: Ipv4 end, its fake.)

[Justin M. Streiner]

On Sat, 22 Mar 2014, William Herrin wrote:


On Sat, Mar 22, 2014 at 10:33 AM, Justin M. Streiner
strei...@cluebyfour.org wrote:

All of these 'Hail Mary' options for 'saving' IPv4 really are pointless.


IPv4 is like the U.S. Penny. It'll be useless long before it goes
away. And right now it's far from useless.


Bill:

Interesting analogy, but it misses the larger point.  The larger point is 
that the ongoing effort to squeeze more mileage out of IPv4 will soon [1] 
outweigh the mileage we (collectively) get out of it.  IMHO, that effort 
is better invested in preparing for and deplying IPv6.  Things like 
LSN/CGN are stop-gaps that result in performance problems for people 
behind them, and aren't terribly useful for people who need to run inbound 
services.  Shaking down entities (to the extent that they can be shaken 
down) that have chunks of IPv4 they're not currently using doesn't change 
the end-game for IPv4.


I'm not saying that there aren't challenges to deploying IPv6.  There are. 
Like many of the people on this list, I run a network, and I'm familiar 
with many of those challenges.  If a network makes a conscious decision 
*not* to deploy IPv6, that is certainly their choice, and they will have 
to live with the consequences and will have to justify that decision to 
their customers.


[1] - For varying values of soon.

jms

Re: misunderstanding scale (was: Ipv4 end, its fake.)

[Justin M. Streiner]

On Sat, 22 Mar 2014, William Herrin wrote:


That's what I hear. Interesting thing though: it hasn't happened yet.
IANA ran out of /8's and it didn't happen. The RIRs dropped to
high-conservation mode on their final allocations and it didn't
happen. How could that be?


I never said that things would get bad the instant that IANA ran out of 
space or your friendly neighborhood RIR reached the trigger point for 
their IPv4 exhaustion plans.  Different RIRs have different consumption 
rates.


There are also different pain points for different networks.  A large .edu 
that has a big enough chunk of legacy IPv4 space to meet their needs 
for the next several years is in a different place than a large eyeball 
network that is deploying LSN/CGN to stretch what they have left because 
they can't go back to the well to get more.  A large content/hosting 
provider who has customers that have different Internet reachability 
requirements where LSN/CGN doesn't help much has yet another different set 
of business drivers and pain points.



In completely unrelated news, placard-bearing lunatics on the streets
of New York City report that The End Is Nigh... for most of the last
century.


I put my sandwich board away a long time ago.  I'm too busy working on 
deploying IPv6 ;)


jms

Re: misunderstanding scale

[Justin M. Streiner]

On Sat, 22 Mar 2014, Nick Hilliard wrote:


FB, T-mobile and you are all using ipv6-ipv4 protocol translators because
ipv6-only services are not a viable alternative at the moment.


Using IPv6 internally is different from being able to use IPv6 end-to-end. 
6-4 translators will be needed to reach the IPv4-only chunks of the 
Internet.  I don't think anyone is disputing that.  Traffic that can go 
IPv6 end-to-end can do so.



The advantage that using ipv6 gives in these deployment scenarios is that
it scales beyond the amount of address space available from rfc1918.  As a
side effect, it also makes native end-to-end ipv6 connectivity pleasant.

Sadly, ipv4 address availability continues to be necessary at the same run
rate as before, except in situations where CGN is a possibility.


I think the expectation is that the utilization of those translators will 
plateau at some point, and then tail off as end-users go dual-stack or v6 
only.  Large/highly visible chunks of the Internet pushing IPv6 adoption 
helps get people toward the long-term goal of turning down those 
translators.  Eventually those remaining pockets of IPv4ness will have to 
sit behind 4-6 translators to be able to speak with the rest of the 
Internet.


CGN also comes with lots of downside that customers are likely to find 
unpleasant.  For some operators, customer (dis)satisfaction might be the 
driver that ultimately forces them to deploy IPv6.


jms

Re: misunderstanding scale

[Justin M. Streiner]

On Sat, 22 Mar 2014, Nick Hilliard wrote:


On 22/03/2014 19:35, Justin M. Streiner wrote:

CGN also comes with lots of downside that customers are likely to find
unpleasant.  For some operators, customer (dis)satisfaction might be the
driver that ultimately forces them to deploy IPv6.


don't believe for a moment that v6 to v4 protocol translation is any less
ugly than CGN.


True, but the ugliness of NAT64 and friends will decrease over time as 
more people go v6.  The ugliness of IPv4 in general, and CGN/LSN will 
likely increase over time as people have to jump through more NAT hoops to 
reach an increasingly ugly/fragmented IPv4 Internet.


jms

Re: L6-20P - L6-30R

[Justin M. Streiner]

On Tue, 18 Mar 2014, Randy wrote:

I have a situation where a 208v/20A PDU (L6-20P) is supposedly hooked to a 
208v/30A circuit (L6-30R).   Before I order the correct PDU's and whip 
cords...sanity check...are connectors 'similar' enough that this is possible 
(with force) or am I going to find we've actually got L6-20R's on the 
provider side?


Generally, all common electrical plugs and receptacles (straight-blade, 
twist-lock, IEC, and CEE) are physically sized and keyed differently, so 
that they can't be connected together, to keep people from connecting 
loads that require a specific voltage/current to supplies that aren't 
intended to provide it.


While it's not uncommon for someone to replace a plug with the right 
kind, this can (in order of badness):


1. start a fire
2. short out and (hopefully) trip a breaker - that's what breakers are for!
3. violate building/electrical codes
4. void your device's warranty

As others have mentioned, just making it work, rather than making it 
work correctly, can be bad news.


People often fancy themselves unlicensed/uncertified electricians.  I've 
seen some of the handiwork from such people, and while their creativity is 
impressive, having to rip their stuff out and re-do it is not fun.


jms

Re: ISP inbound failover without BGP

[Justin M. Streiner]

On Mon, 3 Mar 2014, Eric A Louie wrote:

Are there any other solutions, short of using BGP multihoming and 
having them try to get their own ASN and IPv4 /24 block?


For what it sounds like the customer wants to do, this really is the right 
solution.  Most everything else has some level of 'ugly hack' attached to 
it, that can cause reliability/reachability problems at inopportune times 
(as opposed to problems that happen at opportune times).


If the customer is just looking for failover capabilities, they can take 
default via BGP from both providers, prefer one over the other, and use 
some other bits to prefer one provider over for inbound connectivity. 
They would not need very beefy routers for this.


That will get you basic service redundancy.  Add a second router, and they 
can have some protection in the event of a router failure.


It all really boils down to what the customer wants and is willing to pay 
for.  If they have services that need to be reliably reachable, then using 
a time-tested design is a prudent decision.


jms

Re: ISP inbound failover without BGP

[Justin M. Streiner]

On Mon, 3 Mar 2014, Eric A Louie wrote:

Honestly?  Because the end-customers are not technically competent 
enough to run dual-homed BGP, and we don't want to be their managed 
service providers on the IT side.  And announcing the ATT space is fine 
until something goes wrong, and I have to troubleshoot the problem 
(Customer - How come ATT is down, and we're not getting inbound 
traffic to our servers?, and I discover L3 or CenturyLink isn't 
accepting my advertisement for some weird reason, but they won't fess up 
to it for a few frustrating hours)


If they're not technically competent enough to handle BGP, they won't be 
technically competent enough to deal with solutions that play the short 
DNS TTL game.


As someone else mentioned in this thread - would colocating the servers be 
a workable solution for them?  Put the servers some place where the 
redundancy exists already.


jms

Re: Verizon FIOS IPv6?

[Justin M. Streiner]

On Thu, 27 Feb 2014, Bryan Seitz wrote:


On Thu, Feb 27, 2014 at 09:18:08PM -0500, Stephen Frost wrote:

I echo the 'good luck' and ditto on the experience.

There's a lot of people anxious to get IPv6 on FIOS, but there seems to
be precious little movement over there.


I've been fighting this battle for as long as I've had FIOS (about a year 
and a half), with no end in sight.  Front-line reps don't know the 
situation, and I don't fault them for that.  Getting a hold of anyone who 
comment with anything approaching authority has been impossible.


In the meantime, I will continue using my tunnel through HE, which works 
great (kudos to HE).


jms

Re: Verizon FIOS IPv6?

[Justin M. Streiner]

On Thu, 27 Feb 2014, Tristan Lear wrote:

We have a business-class FIOS connection where I work and a static 
IP as well. At least three people who work here have FIOS at home. 
I've read rumors about business class customers who really work their 
phone sex getting native ipv6, and I also heard somethin about static 
ip's. So I'll try that, and also mention that we're transitioning our 
employees who remote in from home to FIOS but we'd like ipv6 for 
... VPN purposes, NAT traversal, etc ... I mean, that should get them 
a little wet right?


Not likely.  Verizon is a very expensive date, so you *really* have to 
open the wallet to make that kind of impression, and by that point, you're 
working with VZ Enterprise, which is what used to be UUNET, where v6 is 
easy to get, so the point ends up being moot.


I have a bit of a hairbrained theory that the reason ISP's have 
stagnated on ipv6 has to do with relationship between capitalism and 
scarcity. Having a limited quantity of anything makes it more valuable. 
Why wouldn't that apply to IP's?


I doubt it's anything quite so nefarious, though VZ trying to figure out 
how to monetize their IPv6 rollout is certainly a possibility.


I've heard all sorts of BS answers as to why there is no v6 for FIOS, such 
as:
1. We're having problems getting it to work on our set-top boxes.  So 
go dual-stack and let the set-top boxes stay v4 until the problem gets 
worked out.  VZ has already stated that dual-stack is the way thry're 
going to do it.
2. We have plenty of IPv4 space.  Perhaps today, yes, but that misses 
the point entirely.


jms

Re: FW: Updated ARIN allocation information

[Justin M. Streiner]

On Thu, 30 Jan 2014, Mark Andrews wrote:


Or you could just accept that there needs to be more routing slots
as the number of businesses on the net increases.  I can see some
interesting anti-cartel law suits happening if ISP's refuse to
accept /28's from this block.


In the worst case, this would add another 262,144 routes (/10 fully 
assigned, and all assignments are /28s) to the global IPv4 route view. 
Realistically, the number will be a good bit smaller than that, but only 
time will tell for sure exactly how much smaller.  Wash/rinse/repeat for 
any other RIR that adopts a similar policy.


jms

Re: FW: Updated ARIN allocation information

[Justin M. Streiner]

On Thu, 30 Jan 2014, Tore Anderson wrote:


I wouldn't worry if I were you. I'll wager you $100 that pretty much all
of the people requesting a block from ARIN under this policy (or any
other) is going to go for a /24 (or larger). There is some precedent;
RIPE policy has not mandated a minimum assignment size for IPv4 PI, at
least not in the last decade, yet the NCC has made almost no assignments
smaller than /24.


Depends on the burn rate on that /10...

jms

Re: Updated ARIN allocation information

[Justin M. Streiner]

On Fri, 31 Jan 2014, Mark Andrews wrote:


In Australia I would sue Telstra, Optus, ... if their customers
couldn't reach me due to routes being filtered.  I would take this
to the ACCC (Australian Competition and Consumer Commission) as a
restraint of trade issue.


And if the provider doing the filtering isn't in $your_country?  I'm sure 
a few tech-savvy lawyers are salivating over this one.


jms

Re: Fw: ipv6 newbie question

[Justin M. Streiner]

On Wed, 29 Jan 2014, Nick Hilliard wrote:


On 29/01/2014 17:35, Philip Lavine wrote:

Is it best practice to have the internet facing BGP router's peering ip
(or for that matter any key gateway or security appliance) use a
statically configured address or use EUI-64 auto config?


how are you going to set up the bgp session from the remote side to an
eui-64 auto configured address on your side?

best use static here.  And make sure to disable RA (with fire, i.e. disable
send + receive + answering solicited requests) and EUI64.  If it's a point
to point link, use a /126 or /127 netmask.


+1.  I've seem some providers do /64 on their point-to-point links.  I 
don't have an issue with that, and the whole /64 vs /126 or /127 debate 
has been thoroughly beaten into the ground.  No need to re-hash it.


I have never seen a provider use a pseudo-dynamic address on an 
interface/BGP peer.  Having to reconfigure a BGP session because a 
provider did a hardware upgrade or moved my link to a new interface would 
not make me happy.


jms

Re: BGP multihoming

[Justin M. Streiner]

On Wed, 29 Jan 2014, Baldur Norddahl wrote:


I had a customer ask if we could provide him with BGP such that he could be
multihomed. He already has 128 IP addresses from another ISP. Obviously a
/25 is a non go for multihoming as everyone are going to ignore his route.


Not necessarily everyone, but a lot of providers will filter that.  More 
headaches than it's worth.



I would then need to help him with acquiring a /24 PI. Which appears to be
impossible as RIPE does no longer assign PI space and PI can not be
reassigned and thus be bought.

Is assigning a /24 from my own PA space for the purpose of BGP multihoming
considered sufficient need?


I haven't looked at RIPE policies in a while, but I would imagine that 
assigning a customer a /24 of your space because they need to multihome is 
considered a justifiable use.



Could he get some PI from another region, such as ARIN? How does others
handle this situation?


Most likely no, for two reasons.  1. Most RIRs don't assign IPv4 /24s to 
end-users except in very special cases, 2. The smallest PI block they 
would assign is usually something like a /21 or /22, so your customer 
would need to be justifiably using that much space before they could apply 
for a PI block, and 3, if the customer is in an area outside of $RIR's 
service area, they would direct them to contact the appropriate RIR.


I also hope your customer is making plans for IPv6 deployment.

jms