Re: Acquiring unused IP range. Some questions

[Faisal Imtiaz]

> My question is, what do they and we need to do to accomplish that in
> the proper way, so that the internet at large would accept the advertisement
> from a different ASN,

The internet in terms of IP Prefix advertisements is a 'Trust' based system. 


> and not view as some sort of hijacking, etc.

The difference between Hijacking vs a valid advertisement is the simple LOA 
document a.k.a having permission to do so..


>  I am guessing they may need to update some RADB or something like that, but 
> i’ll be
> honest my knowledge of how those things work and their complete function is
> pretty slim.


Only if you are using it for yourself or if your upstream is using it to create 
their prefix Filter lists.
RADB is not the only RRDB provider, ARIN also provides this service 

> This would be a short term thing as we expect the purchase process to complete
> pretty quickly, but it would be advantageous to us to be able to advertise the
> space immediately.  We just want to make sure we start off on the right foot.
> 

All you need is permission from the IP block owner (LOA) and the appropriate 
upstream filters to be setup or opened.
Which could be a manual process (provide them a copy of the LOA) or could be a 
'Trust' based using RRDB Record which someone has to create and update.

Best of luck.

Faisal Imtiaz
Snappy Internet & Telecom


- Original Message -
> From: "William McLendon" 
> To: "nanog list" 
> Sent: Friday, December 2, 2016 5:43:57 PM
> Subject: Acquiring unused IP range.  Some questions

> Hi everyone,
> 
> we are about to acquire a block of IP’s from another organization that has
> unused space, and being fairly new to these procedures, I was hoping for some
> guidance.
> 
> We have already been pre-approved by ARIN for the block size we are acquiring,
> and finalizing the deal with the current owner of the address space.  First
> question is, once they initiate the transfer request to transfer the IP range
> to us, how long does that typically take for ARIN to complete?
> 
> Secondly, our relationship with the IP block owner is a very good one, such 
> that
> I think they would be ok with us advertising this block before we technically
> own it.  My question is, what do they and we need to do to accomplish that in
> the proper way, so that the internet at large would accept the advertisement
> from a different ASN, and not view as some sort of hijacking, etc.  I am
> guessing they may need to update some RADB or something like that, but i’ll be
> honest my knowledge of how those things work and their complete function is
> pretty slim.
> 
> This would be a short term thing as we expect the purchase process to complete
> pretty quickly, but it would be advantageous to us to be able to advertise the
> space immediately.  We just want to make sure we start off on the right foot.
> 
> 
> Thanks,
> 
> Will

Re: Acquiring unused IP range. Some questions

[TJ Trout]

Arin about a week. Just need a LOA for the block I think.

On Fri, Dec 2, 2016 at 2:43 PM, William McLendon  wrote:

> Hi everyone,
>
> we are about to acquire a block of IP’s from another organization that has
> unused space, and being fairly new to these procedures, I was hoping for
> some guidance.
>
> We have already been pre-approved by ARIN for the block size we are
> acquiring, and finalizing the deal with the current owner of the address
> space.  First question is, once they initiate the transfer request to
> transfer the IP range to us, how long does that typically take for ARIN to
> complete?
>
> Secondly, our relationship with the IP block owner is a very good one,
> such that I think they would be ok with us advertising this block before we
> technically own it.  My question is, what do they and we need to do to
> accomplish that in the proper way, so that the internet at large would
> accept the advertisement from a different ASN, and not view as some sort of
> hijacking, etc.  I am guessing they may need to update some RADB or
> something like that, but i’ll be honest my knowledge of how those things
> work and their complete function is pretty slim.
>
> This would be a short term thing as we expect the purchase process to
> complete pretty quickly, but it would be advantageous to us to be able to
> advertise the space immediately.  We just want to make sure we start off on
> the right foot.
>
>
> Thanks,
>
> Will

Acquiring unused IP range. Some questions

[William McLendon]

Hi everyone,

we are about to acquire a block of IP’s from another organization that has 
unused space, and being fairly new to these procedures, I was hoping for some 
guidance.

We have already been pre-approved by ARIN for the block size we are acquiring, 
and finalizing the deal with the current owner of the address space.  First 
question is, once they initiate the transfer request to transfer the IP range 
to us, how long does that typically take for ARIN to complete?

Secondly, our relationship with the IP block owner is a very good one, such 
that I think they would be ok with us advertising this block before we 
technically own it.  My question is, what do they and we need to do to 
accomplish that in the proper way, so that the internet at large would accept 
the advertisement from a different ASN, and not view as some sort of hijacking, 
etc.  I am guessing they may need to update some RADB or something like that, 
but i’ll be honest my knowledge of how those things work and their complete 
function is pretty slim.

This would be a short term thing as we expect the purchase process to complete 
pretty quickly, but it would be advantageous to us to be able to advertise the 
space immediately.  We just want to make sure we start off on the right foot.


Thanks,

Will

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Randy Bush]

> I just want to come back on behalf of Cisco on this. We just
> investigated this issue and the issue is not an ASIC bug, but a flag
> set wrong by SW.

damn!  you just took all the fun out of lynching ieee.  sheesh!


randy

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Saku Ytti]

On 2 December 2016 at 18:16, Alia Atlas  wrote:
> This sounds related to the well-known (at least 10+ years) issues around
> guessing the
> type of IP packet by looking at the first nibble of the encapsulated packet.
> Take a quick look at RFC 7325, section 2.4.5.1 bullet 6.
> This is what using the pseudo-wire code-word is meant to protect against.
>
> I don't know if that's an option for networks using this.

Some devices by default look inside pseudowires to find IP inside
them, in this case even control-word won't help, you'll need to also
disable looking inside pseudowire.


-- 
  ++ytti

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Simon Lockhart]

On Fri Dec 02, 2016 at 09:23:24PM +, Sukumar Subburayan (sukumars) wrote:
> I just want to come back on behalf of Cisco on this. We just investigated
> this issue and the issue is not an ASIC bug, but a flag set wrong by SW.  We
> will reach out to the original customer through TAC who posted this in NSP to
> resolve this issue.

Sukumar,

Can I just publicly say thank you for taking the time to investigate my issue,
and identify that a fix is possible.

Looking forward to having a working Nexus... 

Simon

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Sukumar Subburayan (sukumars)]

All,

I just want to come back on behalf of Cisco on this. We just investigated this 
issue and the issue is not an ASIC bug, but a flag set wrong by SW.
 We will reach out to the original customer through TAC who posted this in NSP 
to resolve this issue.

sukumar

On 12/2/16, 11:50 AM, "NANOG on behalf of Job Snijders" 
 wrote:

On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote:
> I also do not think this is an IEEE/MAC assignement problem. This is a
> vendor's box can't forward a particular payload problem.

On Fri, Dec 02, 2016 at 04:59:37PM +, Nick Hilliard wrote:
> Job Snijders wrote:
> > Dear IEEE, please pause assigning MAC addresses that start with a 4
> > or a 6 for the next 6 years.
> 
> Disagree that this is an IEEE problem.  This is problem that vendors
> need to work around.  There is limited MAC space, and deprecating 1/8 of
> it due to the inability of vendors to cope properly with it seems like a
> really bad long term idea.

Yes the vendors are doing a poor job. I also appreciate the argument
that IEEE just manages that number space and we should consider these
'just numbers' and the vendors need to make do. On the other hand if
IEEE had just stuck to the original allocation plan, you and I wouldn't
be dealing with this garbage situation.

IEEE told one of my friends: "We changed our allocation methods to
prevent vendors using unregistered mac addresses."

Does the cost of some squatters on poorly usable MAC space outweight the
cost of the community spending countless hours tracking down where those
dropped packets went?

IEEE could've shown more restrain by (temporary, until IPv4 is dead?)
avoiding 4 and 6 and still accomplished some of their goal (if this
dubious strategy even is effective). 

I consider this a cascading failure. Clearly IEEE's change had a ripple
effect, and suprised a number of implementers, and ended up hurting us.

Kind regards,

Job

Anyone have contact info for NOC of PlayStation Network?

[Edmond M]

Hello,

I'm getting a lot of auto abuse notices stemming from 'account takeover
attempts' via 443 and would like to resolve it with someone directly there.

All I have is snei-noc-ab...@am.sony.com and not getting any response.

Thanks in advance

Extreme Networks Technical Contact

[Allan Liska]

Sorry to bother the whole list, but I am looking for help with a mail
issue from someone at Extreme Networks, if you work there would you
mind reaching out to me off-list? 

Thanks!

allan

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Alia Atlas]

On Fri, Dec 2, 2016 at 11:07 AM, Christopher Morrow  wrote:

> On Fri, Dec 2, 2016 at 11:02 AM, Simon Lockhart  wrote:
>
> > On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote:
> > > you'd think standard testing of traffic through the asic path somewhere
> > > between 'let's design an asic!' and 'here's your board ms customer!'
> > would
> > > have found this sort of thing, no? or does testing only use 1 mac
> address
> > > ever?
> >
> > Well, it's actually payload, rather than src/dst MAC used for forwarding,
> > so
> > there's quite a few more combinations to look for...
> >
> > 2^(8*9216) is quite a lot of different packets to test through the
> > forwarding
> > path... But, wait, that assumes every bit combination for 9216 byte
> > packets,
> > but the packet might be shorter than that... So multiply that by
> (9216-64).
> >
> >
> but  most/all forwarding asics (aside from perhaps extreme's?) only deal
> with the first N bits in the header (128 or so..) so... not quite as many
> right?


This sounds related to the well-known (at least 10+ years) issues around
guessing the
type of IP packet by looking at the first nibble of the encapsulated packet.
Take a quick look at RFC 7325, section 2.4.5.1 bullet 6.
This is what using the pseudo-wire code-word is meant to protect against.

I don't know if that's an option for networks using this.

Regards,
Alia



>
> > Anyone want to work out how many years that'd take to test, even at 100G?
> >
> > Simon
> >
>

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Nick Hilliard]

Sukumar Subburayan (sukumars) wrote:
> I just want to come back on behalf of Cisco on this. We just
> investigated this issue and the issue is not an ASIC bug, but a flag
> set wrong by SW. We will reach out to the original customer through
> TAC who posted this in NSP to resolve this issue.

oh cool - this is great.  Thanks for following up and clarifying.

Nick

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Nick Hilliard]

Job Snijders wrote:
> I consider this a cascading failure. Clearly IEEE's change had a ripple
> effect, and suprised a number of implementers, and ended up hurting us.

this would be credible if this were a previously unknown problem, but it
isn't.  It's been known for years that you need to be careful when
handling mpls encapsulated packets which encapsulate L2 frames and where
the source mac address starts with 4 or 6.  This is not a new problem
and because it's not new, there is no good reason for vendors to make
the same mistakes again and again.  TBH, it beggars belief that new L2
hardware is being thrown out the door which is unable to forward frames
of this form due to hardware limitations, and that it's apparently
unfixable.

Nick

Avalanche / domains / registrars & registries

[bzs]

FWIW one of the people involved in the takedown has reported that most
of the 800K domain names were DGA.

Here was my nutshell overview summary synopsis posted elsewhere:

DGA = Domain Generation Algorithm (term in wikipedia.)

So an infected bot and a C (command and control computer) have an
algorithm -- on the bot it's in the virus -- to generate seemingly
random domains using seeds such as the current date. Usually more
sophisticated but that's the idea, the goal is that both ends generate
the same seemingly random domain.

So they'll each generate for example xerv1dvm and attach it to a TLD,
it doesn't matter what, xerv1dvm.foo, or it could be .com or whatever.

They resolve it because they also infect the host's DNS resolver
software (or just inject their own, same thing) so it queries a
non-standard root server controlled by the attacker, could just be the
C computer, which will return an IP address for the infected bot to
use.

This set up allows these systems to change these parameters as often
as they like, every minute or less if needed tho that's probably not
necessary, every hour might do or even just once a day. Whatever it
takes to stay one step ahead of anyone seeking to interfere with them
such as law enforcement.

TL;DR: There needn't be any (accredited) registrars/registries involved.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Job Snijders]

On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote:
> I also do not think this is an IEEE/MAC assignement problem. This is a
> vendor's box can't forward a particular payload problem.

On Fri, Dec 02, 2016 at 04:59:37PM +, Nick Hilliard wrote:
> Job Snijders wrote:
> > Dear IEEE, please pause assigning MAC addresses that start with a 4
> > or a 6 for the next 6 years.
> 
> Disagree that this is an IEEE problem.  This is problem that vendors
> need to work around.  There is limited MAC space, and deprecating 1/8 of
> it due to the inability of vendors to cope properly with it seems like a
> really bad long term idea.

Yes the vendors are doing a poor job. I also appreciate the argument
that IEEE just manages that number space and we should consider these
'just numbers' and the vendors need to make do. On the other hand if
IEEE had just stuck to the original allocation plan, you and I wouldn't
be dealing with this garbage situation.

IEEE told one of my friends: "We changed our allocation methods to
prevent vendors using unregistered mac addresses."

Does the cost of some squatters on poorly usable MAC space outweight the
cost of the community spending countless hours tracking down where those
dropped packets went?

IEEE could've shown more restrain by (temporary, until IPv4 is dead?)
avoiding 4 and 6 and still accomplished some of their goal (if this
dubious strategy even is effective). 

I consider this a cascading failure. Clearly IEEE's change had a ripple
effect, and suprised a number of implementers, and ended up hurting us.

Kind regards,

Job

Re: [nanog] Avalanche botnet takedown

[Jason Hellenthal]

If I could have it my way, I would say no gTLD’s should be allowed to transmit 
any email messages whatsoever. And force them to either use something like 
sendgrid.com or to purchase a primary .com, .org, .net .co.uk whatever etc.. 

But thats just me.

It’s not a nice world but it is just the world we live in today.
 
> On Dec 2, 2016, at 05:28, Hugo Salgado-Hernández  wrote:
> 
> According to a 2015 paper, 85% of new gTLDs domains was some form
> of parking, defensive redirect, unused, etc:
> 
> 
> Hugo
> 
> On 15:02 01/12, J. Hellenthal wrote:
>> 99% ? That's a pretty high figure there.
>> 
>> -- 
>> Onward!, 
>> Jason Hellenthal, 
>> Systems & Network Admin, 
>> Mobile: 0x9CA0BD58, 
>> JJH48-ARIN
>> 
>> On Dec 1, 2016, at 14:56, Rich Kulawiec  wrote:
>> 
>>> On Thu, Dec 01, 2016 at 05:34:26PM -, John Levine wrote:
>>> [...] 800,000 domain names used to control it.
>> 
>> 1. Which is why abusers are registrars' best customers and why
>> (some) registrars work so very hard to support and shield them.
>> 
>> 2. As an aside, I've been doing a little research project for a
>> few years, focused on domains.  I've become convinced that *at least*
>> 99% of domains belong to abusers: spammers, phishers, typosquatters,
>> malware distributors, domaineers, combinations of these, etc. 
>> 
>> In the last year, I've begun thinking that 99% is a serious underestimate.
>> (And it most certainly is in some of the new gTLDs.)
>> 
>> ---rsk
>> 


-- 
 Jason Hellenthal
 JJH48-ARIN

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 03 Dec, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  623873
Prefixes after maximum aggregation (per Origin AS):  221154
Deaggregation factor:  2.82
Unique aggregates announced (without unneeded subnets):  303044
Total ASes present in the Internet Routing Table: 55364
Prefixes per ASN: 11.27
Origin-only ASes present in the Internet Routing Table:   36335
Origin ASes announcing only one prefix:   15281
Transit ASes present in the Internet Routing Table:6530
Transit-only ASes present in the Internet Routing Table:168
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  40
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:59
Unregistered ASNs in the Routing Table:  15
Number of 32-bit ASNs allocated by the RIRs:  16391
Number of 32-bit ASNs visible in the Routing Table:   12499
Prefixes from 32-bit ASNs in the Routing Table:   50896
Number of bogon 32-bit ASNs visible in the Routing Table:   507
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:409
Number of addresses announced to Internet:   2833731044
Equivalent to 168 /8s, 231 /16s and 77 /24s
Percentage of available address space announced:   76.5
Percentage of allocated address space announced:   76.5
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.3
Total number of prefixes smaller than registry allocations:  206138

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   156912
Total APNIC prefixes after maximum aggregation:   43068
APNIC Deaggregation factor:3.64
Prefixes being announced from the APNIC address blocks:  171108
Unique aggregates announced from the APNIC address blocks:70433
APNIC Region origin ASes present in the Internet Routing Table:5191
APNIC Prefixes per ASN:   32.96
APNIC Region origin ASes announcing only one prefix:   1150
APNIC Region transit ASes present in the Internet Routing Table:938
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 40
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2523
Number of APNIC addresses announced to Internet:  760055428
Equivalent to 45 /8s, 77 /16s and 134 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:188330
Total ARIN prefixes after maximum aggregation:89429
ARIN Deaggregation factor: 2.11
Prefixes being announced from the ARIN address blocks:   194748
Unique aggregates announced from the ARIN address blocks: 89435
ARIN Region origin ASes present in the Internet Routing Table:16118
ARIN Prefixes per ASN:12.08

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Leo Bicknell]

In a message written on Fri, Dec 02, 2016 at 03:32:13PM +0100, Job Snijders 
wrote:
> Dear Vendors, take this issue more serious. Realise that for operators
> these issues are _extremely_ hard to debug, this is an expensive time
> sink. Some of these issues are only visible under very specific, rare
> circumstances, much like chasing phantoms. So take every vague report of
> "mysterious" packetloss, or packet reordering at face value and
> immediately dispatch smart people to delve into whether your software or
> hardware makes wrong assumptions based on encountering a 4 or a 6
> somewhere in the frame. 

I also do not think this is an IEEE/MAC assignement problem.  This
is a vendor's box can't forward a particular payload problem.

If I had boxes with this issue, I would be talking to my vendor
about how:

  a) They were going to replace every single one of them with something
 that does not have the bug.

  b) What discount I would get on mainteance/support for having to swap
 all of the devices.

Then I would follow it up with the other vendors I'm talking to
about all of my future purchases if they are unable to produce boxes
that work.  And if the vendor who supplied these did not fix it, I
would give them no more business.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgpUIMyQ7cxeB.pgp
Description: PGP signature

Re: Looking for some Quagga experience to discuss 32 bit ASN + community issue with

[Job Snijders]

On Fri, Dec 02, 2016 at 09:13:25AM -0800, Eric Germann wrote:
> So from reading the draft, if I’m understanding it correctly, I should
> be able (with the patch) to encode the 32 bit ASN + a community in to
> this as
> 
> as32:x:y
> 
> Is that correct?

yes.

I recommend you take a look at 
https://tools.ietf.org/html/draft-snijders-grow-large-communities-usage-00
for inspiration on how to use Large Communities.

Kind regards,

Job

Re: Looking for some Quagga experience to discuss 32 bit ASN + community issue with

[Eric Germann]

So from reading the draft, if I’m understanding it correctly, I should be able 
(with the patch) to encode the 32 bit ASN + a community in to this as

as32:x:y

Is that correct?

EKG

> On Dec 2, 2016, at 2:27 AM, Job Snijders  wrote:
> 
> On Fri, Dec 02, 2016 at 09:00:57AM +, Nick Hilliard wrote:
>> Eric Germann wrote:
>>> Basically trying to advertise 4 byte ASN’s + communities, and then
>>> pick them off elsewhere in a private network.  Can’t get the config
>>> right for the route map to import them on the “receiving” side.
>> 
>> yes, sounds about right.  There is a massive feature deficit regarding
>> BGP communities suitable for asn32s, in that the feature just doesn't
>> really exist yet.  This is being remedied at the moment at the ietf,
>> which has just moved the draft-ietf-idr-large-community internet draft
>> to "Publication Requested" state.
>> 
>> The feature hasn't made it into mainline quagga yet, but there is a
>> patch.
> 
> The quagga patch is being developed against quagga 1.1.0, the latest
> version of the patch (0008-) is available here and would benefit from
> more testing: https://bugzilla.quagga.net/show_bug.cgi?id=875#c13
> 
> The patch should provide a feature-complete implementation of Large
> Communities, but the daemon crashes sometimes. We don't know why yet.
> However I am proud to report that it compiles! :-)
> 
>> Also, please prod your commercial vendors for support for this.
> 
> Yes!
> 
> Even if a vendor is listed as 'Planned' or 'Requested' on the
> http://largebgpcommunities.net/implementations/ page, it really helps if
> you email your account manager stating "Large Communities is what i want".
> 
> Most vendors have a big backlog of feature requests and no shortage of
> ideas. This operational community must make it unambiguously clear to
> the vendors that Large Communities is the thing that needs to be
> shipping in 2017. This peer pressure will help them to prioritize the
> development, testing, Q, documentation development, internal &
> external marketing etc to get it done.
> 
> So, pause your IPv6 deployments for one day, and start calling your
> Huawei, Cisco (ask separately for IOS and XR), Juniper, Nokia, Arista,
> Brocade, ZTE, or Microsoft representatives and ask for it by name! :-)
> 
> Kind regards,
> 
> Job



smime.p7s
Description: S/MIME cryptographic signature

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Nick Hilliard]

Job Snijders wrote:
> Dear IEEE, please pause assigning MAC addresses that start with a 4 or a
> 6 for the next 6 years.

Disagree that this is an IEEE problem.  This is problem that vendors
need to work around.  There is limited MAC space, and deprecating 1/8 of
it due to the inability of vendors to cope properly with it seems like a
really bad long term idea.

It seems that the problem that cropped up on cisco-nsp is that a layer 2
switch, the Nexus 92160 (and possibly everything else which uses the
same forwarding ASIC), cannot forward vpls frames with a 4 or 6 buried
at a specific location inside the contents of the frame.

This is an extraordinary bug which renders the hardware useless in
specific circumstances.  What makes it worse is that this is a well
known corner case which should have been shaken out during design, if
not found during QA.

Nick

Re:

[Roland Dobbins]

On 2 Dec 2016, at 22:31, Christopher Morrow wrote:

> that statement seems ... hard to prove.

Paging Geoff Huston to the white courtesy phone . . .

;>

---
Roland Dobbins 

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Christopher Morrow]

On Fri, Dec 2, 2016 at 11:07 AM, Christopher Morrow  wrote:

>
>
> On Fri, Dec 2, 2016 at 11:02 AM, Simon Lockhart  wrote:
>
>> On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote:
>>
>> 2^(8*9216) is quite a lot of different packets to test through the
>> forwarding
>> path... But, wait, that assumes every bit combination for 9216 byte
>> packets,
>> but the packet might be shorter than that... So multiply that by
>> (9216-64).
>>
>>
> but  most/all forwarding asics (aside from perhaps extreme's?) only deal
> with the first N bits in the header (128 or so..) so... not quite as many
> right?
>
>
>
and REALLY they could have just started ~9 yrs ago: "Hey, maybe this 4/6
thing is really a problem? how about we add 2 other things to our testing
framework?"

instead of: "High Five! First to market!"

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Christopher Morrow]

On Fri, Dec 2, 2016 at 11:02 AM, Simon Lockhart  wrote:

> On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote:
> > you'd think standard testing of traffic through the asic path somewhere
> > between 'let's design an asic!' and 'here's your board ms customer!'
> would
> > have found this sort of thing, no? or does testing only use 1 mac address
> > ever?
>
> Well, it's actually payload, rather than src/dst MAC used for forwarding,
> so
> there's quite a few more combinations to look for...
>
> 2^(8*9216) is quite a lot of different packets to test through the
> forwarding
> path... But, wait, that assumes every bit combination for 9216 byte
> packets,
> but the packet might be shorter than that... So multiply that by (9216-64).
>
>
but  most/all forwarding asics (aside from perhaps extreme's?) only deal
with the first N bits in the header (128 or so..) so... not quite as many
right?


> Anyone want to work out how many years that'd take to test, even at 100G?
>
> Simon
>

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Simon Lockhart]

On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote:
> you'd think standard testing of traffic through the asic path somewhere
> between 'let's design an asic!' and 'here's your board ms customer!'  would
> have found this sort of thing, no? or does testing only use 1 mac address
> ever?

Well, it's actually payload, rather than src/dst MAC used for forwarding, so
there's quite a few more combinations to look for...

2^(8*9216) is quite a lot of different packets to test through the forwarding
path... But, wait, that assumes every bit combination for 9216 byte packets,
but the packet might be shorter than that... So multiply that by (9216-64).

Anyone want to work out how many years that'd take to test, even at 100G?

Simon

Re:

[Christopher Morrow]

On Fri, Dec 2, 2016 at 6:08 AM, Rich Kulawiec  wrote:

>
> We are busy trying to support a domain name system that is two to
> three orders of magnitude larger (as measured by domains) than it
> should be or needs to be.
>
>
that statement seems ... hard to prove.
also, what does it matter the size of the domain system?
also, perhaps this is an incentives problem from the top down? (if it's
really a problem, I mean).

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Christopher Morrow]

On Fri, Dec 2, 2016 at 9:32 AM, Job Snijders  wrote:

>
> Dear Vendors, take this issue more serious. Realise that for operators
> these issues are _extremely_ hard to debug, this is an expensive time
> sink. Some of these issues are only visible under very specific, rare
> circumstances, much like chasing phantoms. So take every vague report of
> "mysterious" packetloss, or packet reordering at face value and
> immediately dispatch smart people to delve into whether your software or
> hardware makes wrong assumptions based on encountering a 4 or a 6
> somewhere in the frame.
>

you'd think standard testing of traffic through the asic path somewhere
between 'let's design an asic!' and 'here's your board ms customer!'  would
have found this sort of thing, no? or does testing only use 1 mac address
ever?

OT - Looking for a EU based equipment vendor

[Chris Boyd]

Sorry for the noise, but I need to find a company similar to ServerMonkey.com 
or Teksavers.com that’s based in France or Switzerland.  My google-fu seems to 
be weak on this.

Thanks!

—Chris

ATT Wireless

[Mark Stevens]

Good Morning,

If anyone from ATT wireless that is on this list, it would be 
appreciated if you could contact me offline concerning OCN routing 
problems with your network.



Thanks

Mark Stevens

Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

[Job Snijders]

Hi all,

Ever since the IEEE started allocating OUIs (MAC address ranges) in a
randomly distributed fashion rather then sequentially, the operator
community has suffered enormously.

Time after time issues pop up related to MAC addresses that start with a
4 or a 6. I believe IEEE changed their strategy to attempt to
purposefully higher the chance of collisions with MAC squatters, to
encourage people to register and pay the fee. 

The forwarded email at the bottom is yet another example of a widely
deployed, but fundamentally broken ASIC. The switch can't forward VPLS
frames which contain a payload where the inner packet is destined to a
MAC starting with a 4 or a 6. This is with the switch operating in pure
layer-2 mode, it doesn't know what MPLS or VPLS even are. The switch is
dropping packets on the floor, based on their _payload_. Try selling
such circuits to customers "discounted layer-2 service, some flows might
not be forwarded".

Had IEEE continued the sequential OUI allocations, it probably would've
taken many years before we ever reached MACs starting with a 4 or a 6,
but instead, in 2012 the first linecards started rolling out of
factories with MACs burned in which start with a 4 or a 6, and this took
some vendors by surpise.

There have been quite some issues, both in hardware and software:

Brocade produced a 24x10GE linecard to the market in 2013/2014, with
limited FIB scale, meant for a BGP-free MPLS core, but the card can't
keep flows together on LACP bundles if the inner packets in a pseudowire
were destined for a 4 or 6 MAC. The result: out of order delivery,
hurting performance.

Cisco ASR 9k's had a bug where if a payload started with a 6, it assumed
it would be an IPv6 packet, compare the calculated packet-length with
the packet-length in the packet and obviously fail because an ethernet
packet is not an IPv6 packet. The result: packets dropped on the floor.
(Fixed in 4.3(0.32)I)

The Nexus 9000 issue described at the top of this mail. Brocade IronWare
had an issue related to packet reordering for flows inside pseudowires,
fixed in 2013/2014. There are probably many more examples out there in
the wild, slowly driving operators insane.

At this moment, some issues related to MACs starting with a 4 or a 6 can
be mitigated if you enable Pseudowire Control-Word (RFC 4385) _AND_
Flow-Aware Transport (RFC 6391). You need both to mitigate certain issues
in multi-vendor networks (for instance if you have Cisco edge + Juniper
core). But what to do when the ASIC won't forward the payload? As ISP
you often don't control the payload.

Unfortunatly, I don't think we've seen the end of this. The linecards
bought in 2012 will trickle down to the grey/second-hand market about
now, often without accompanying support contracts. In a world with
increased complexity in our interconnectedness, and lack of visibility
into the underlaying infrastructure (think remote peering, cloud
connectivity, resellers reselling layer-2) it will hurt when some
flows inexplicably fail to arrive.

Dear IEEE, please pause assigning MAC addresses that start with a 4 or a
6 for the next 6 years. Or at least, next time you change the policy,
consult the operational community. This 4/6 MAC issue was well
documented in BCP128 back in 2007. The control-word drafts mentioned
that there would be dragons related to 4 and 6 back in 2004.

Dear Vendors, take this issue more serious. Realise that for operators
these issues are _extremely_ hard to debug, this is an expensive time
sink. Some of these issues are only visible under very specific, rare
circumstances, much like chasing phantoms. So take every vague report of
"mysterious" packetloss, or packet reordering at face value and
immediately dispatch smart people to delve into whether your software or
hardware makes wrong assumptions based on encountering a 4 or a 6
somewhere in the frame. 

And you, my fellow operators, please continue to publicly document these
issues and possible workarounds.

Kind regards,

Job

resources:

c-nsp thread "Wierd MPLS/VPLS issue": 
https://puck.nether.net/pipermail/cisco-nsp/2016-December/thread.html
https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf
BCP128: https://tools.ietf.org/html/bcp128

- Forwarded message from Simon Lockhart  -

Date: Fri, 2 Dec 2016 11:44:21 +
From: Simon Lockhart 
To: cisco-...@puck.nether.net
Subject: Re: [c-nsp] Wierd MPLS/VPLS issue

On Wed Nov 23, 2016 at 12:01:20PM +, Simon Lockhart wrote:
> On Fri Nov 04, 2016 at 03:40:05PM +, Simon Lockhart wrote:
> > To me, everything *looks* right, it's just that some VPLS traffic traversing
> > the new link gets lost.
> 
> For those who are interested...
> 
> Well, I finally got to the bottom of this, and have pushed it to Cisco TAC
> for a fix...

Cisco TAC finally accepted the issue. Bug CSCvc33783 has been logged.
Nexus BU has investigated.

Response is...

"[...] 

RE: BRAS/BNG Suggestion

[Krunal Shah]

Ericsson SSR 8010 is good platform. We have been using it since last 3 years 
with no major issues.

Havn't tested IPv6 though.




Krunal Shah
Network Analyst, IP & Transport Network Engineering
ks...@primustel.ca






-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Lorenzo Mainardi
Sent: Tuesday, November 29, 2016 1:34 PM
To: nanog@nanog.org
Subject: BRAS/BNG Suggestion

Good morning,
Could you suggest some vendors of BRAS/BNG for PPPoE termination?
We have more than 20.000 users.

In my short list there are already Juniper, Cisco and NOKIA/ALU.
Do you have any other honorable brand or good experiences?
Regards
digitel

Via della Fortezza 6 - 50129 Firenze
www.digitelitalia.com - 800 901 669

Ing. Lorenzo Mainardi

Tel +39 055 4624933
Fax +39 055 4624 947
l...@digitelitalia.com






This electronic message contains information from Primus Management ULC 
("PRIMUS") , which may be legally privileged and confidential. The information 
is intended to be for the use of the individual(s) or entity named above. If 
you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this information is prohibited. If you 
have received this electronic message in error, please notify us by telephone 
or e-mail (to the number or address above) immediately. Any views, opinions or 
advice expressed in this electronic message are not necessarily the views, 
opinions or advice of PRIMUS. It is the responsibility of the recipient to 
ensure that any attachments are virus free and PRIMUS bears no responsibility 
for any loss or damage arising in any way from the use thereof.The term 
"PRIMUS" includes its affiliates.

Pour la version en français de ce message, veuillez voir
http://www.primustel.ca/fr/legal/cs.htm

Re: Avalanche botnet takedown

[Rich Kulawiec]

[ Reposted with proper Subject line.  My apologies.  Insufficient coffee. ]

On Thu, Dec 01, 2016 at 03:01:50PM -0800, Ronald F. Guilmette wrote:
> As you probably know Rich, that's not exactly a novel observation.  Vixie
> was already saying it a full six years ago, and things have only gotten
> worse since then.

Yep.  I remember reading that.  The only change I would make is that
Paul wrote:

Most new domain names are malicious.

and I think a more accurate/updated/refined statement in 2016 would be:

Almost all new domain names are malicious.

We are busy trying to support a domain name system that is two to
three orders of magnitude larger (as measured by domains) than it
should be or needs to be.  And nearly all of what we're supporting
is malicious.

---rsk

Re: Spitballing IoT Security

[Roland Dobbins]

On 30 Oct 2016, at 7:32, Ronald F. Guilmette wrote:

 you don't need to be either an omnious "state actor" or even SPECTER 
to assemble a truly massive packet weapon.


I agree:



;>

Two kids with a modest amount of knowledge and a lot of time on their 
hands can do it from their mom's basement.


And indeed have done so, many times.

The *entire purpose* of Mirai is DDoS-for-hire - it's a foundation for 
so-called 'booter/stresser' services.  So, the various  articles about 
how these botnets 'might' be for sale are uninformed - they're *for 
rent*, that's their raison d'être.


And renting them is cheap.  The economic and resource asymmetries highly 
favor the attackers.


All the speculation about how 'state actors' are somehow 'learning how 
to take down the Internet' is equally uninformed.  State actors already 
know how to do this, they don't need to 'learn' or 'test' anything.


DDoS attacks are the Great Equalizer; when it comes to DDoS, 
nation-states are just another player.


---
Roland Dobbins 

Re: [nanog] Re: Avalanche botnet takedown

[Hugo Salgado-Hernández]

According to a 2015 paper, 85% of new gTLDs domains was some form
of parking, defensive redirect, unused, etc:


Hugo

On 15:02 01/12, J. Hellenthal wrote:
> 99% ? That's a pretty high figure there.
> 
> -- 
>  Onward!, 
>  Jason Hellenthal, 
>  Systems & Network Admin, 
>  Mobile: 0x9CA0BD58, 
>  JJH48-ARIN
> 
> On Dec 1, 2016, at 14:56, Rich Kulawiec  wrote:
> 
> > On Thu, Dec 01, 2016 at 05:34:26PM -, John Levine wrote:
> > [...] 800,000 domain names used to control it.
> 
> 1. Which is why abusers are registrars' best customers and why
> (some) registrars work so very hard to support and shield them.
> 
> 2. As an aside, I've been doing a little research project for a
> few years, focused on domains.  I've become convinced that *at least*
> 99% of domains belong to abusers: spammers, phishers, typosquatters,
> malware distributors, domaineers, combinations of these, etc. 
> 
> In the last year, I've begun thinking that 99% is a serious underestimate.
> (And it most certainly is in some of the new gTLDs.)
> 
> ---rsk
> 


signature.asc
Description: PGP signature

Re: BRAS/BNG Suggestion

[Mark Tinka]

On 2/Dec/16 12:37, t...@pelican.org wrote:

>
> I'd steer clear at a small scale like 20k subscribers.  In my experience, 
> Ericsson as an organisation just aren't set up to deal with a company that 
> want to buy a couple of boxes, install and run them themselves, and call 
> support when something breaks - it's all about multi-month PoCs and 
> fully-managed rollouts at incumbent-telco scale.  Think 20M subs, not 20k.

Agreed.

Mark.

[no subject]

[Rich Kulawiec]

Cc
Bcc: 
Subject: Re: Avalanche botnet takedown
Reply-To: 
In-Reply-To: <32993.1480633...@segfault.tristatelogic.com>

On Thu, Dec 01, 2016 at 03:01:50PM -0800, Ronald F. Guilmette wrote:
> As you probably know Rich, that's not exactly a novel observation.  Vixie
> was already saying it a full six years ago, and things have only gotten
> worse since then.

Yep.  I remember reading that.  The only change I would make is that
Paul wrote:

Most new domain names are malicious.

and I think a more accurate/updated/refined statement in 2016 would be:

Almost all new domain names are malicious.

We are busy trying to support a domain name system that is two to
three orders of magnitude larger (as measured by domains) than it
should be or needs to be.  And nearly all of what we're supporting
is malicious.

---rsk

Re: BRAS/BNG Suggestion

[Dragan Jovicic]

Our current deployment uses several Alcatel SR 7750 boxes - we pair these
with MX960 and MX2020 for CGNAT for several hundred thousand customers.
Alcatel and Juniper have been a rock solid combination so far.

Regards

Dragan

On Fri, Dec 2, 2016 at 11:53 AM, James Bensley  wrote:

> On 2 December 2016 at 10:37, t...@pelican.org  wrote:
>
> > On Friday, 2 December, 2016 05:55, "Mark Tinka" 
> > said:
> >
> > > Redback used to be popular - I believe they got picked up by Ericsson.
> >
> > I'd steer clear at a small scale like 20k subscribers.  In my experience,
> > Ericsson as an organisation just aren't set up to deal with a company
> that
> > want to buy a couple of boxes, install and run them themselves, and call
> > support when something breaks - it's all about multi-month PoCs and
> > fully-managed rollouts at incumbent-telco scale.  Think 20M subs, not
> 20k.
> >
> >
> I've heard Redback aren't so good anymore. We are very happy with Cisco
> (ASR1000s) and Juniper (MX480s) for this function.
>
> Cheers,
> James.
>

Re: BRAS/BNG Suggestion

[James Bensley]

On 2 December 2016 at 10:37, t...@pelican.org  wrote:

> On Friday, 2 December, 2016 05:55, "Mark Tinka" 
> said:
>
> > Redback used to be popular - I believe they got picked up by Ericsson.
>
> I'd steer clear at a small scale like 20k subscribers.  In my experience,
> Ericsson as an organisation just aren't set up to deal with a company that
> want to buy a couple of boxes, install and run them themselves, and call
> support when something breaks - it's all about multi-month PoCs and
> fully-managed rollouts at incumbent-telco scale.  Think 20M subs, not 20k.
>
>
I've heard Redback aren't so good anymore. We are very happy with Cisco
(ASR1000s) and Juniper (MX480s) for this function.

Cheers,
James.

Re: Avalanche botnet takedown

[Tony Finch]

Ronald F. Guilmette  wrote:
>
> P.P.S.  I love this part of the press release, because it is so telling:
>
>  "The successful takedown of this server infrastructure was supported
>  by ... Registrar of Last Resort, ICANN..."

Note that these are the names of two different organizations - the part
before the comma is not a description of the role played by ICANN.

http://tldcon.ru/docs/02-Addis.pdf
http://www.rolr.org/goals.en.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: Northwest 4 or 5, veering northeast 3 or 4. Moderate, becoming
slight later in Thames. Showers. Good.

Re: BRAS/BNG Suggestion

[t...@pelican.org]

On Friday, 2 December, 2016 05:55, "Mark Tinka"  said:

> Redback used to be popular - I believe they got picked up by Ericsson.

I'd steer clear at a small scale like 20k subscribers.  In my experience, 
Ericsson as an organisation just aren't set up to deal with a company that want 
to buy a couple of boxes, install and run them themselves, and call support 
when something breaks - it's all about multi-month PoCs and fully-managed 
rollouts at incumbent-telco scale.  Think 20M subs, not 20k.

Regards,
Tim.

Re: Looking for some Quagga experience to discuss 32 bit ASN + community issue with

[Job Snijders]

On Fri, Dec 02, 2016 at 09:00:57AM +, Nick Hilliard wrote:
> Eric Germann wrote:
> > Basically trying to advertise 4 byte ASN’s + communities, and then
> > pick them off elsewhere in a private network.  Can’t get the config
> > right for the route map to import them on the “receiving” side.
> 
> yes, sounds about right.  There is a massive feature deficit regarding
> BGP communities suitable for asn32s, in that the feature just doesn't
> really exist yet.  This is being remedied at the moment at the ietf,
> which has just moved the draft-ietf-idr-large-community internet draft
> to "Publication Requested" state.
> 
> The feature hasn't made it into mainline quagga yet, but there is a
> patch.

The quagga patch is being developed against quagga 1.1.0, the latest
version of the patch (0008-) is available here and would benefit from
more testing: https://bugzilla.quagga.net/show_bug.cgi?id=875#c13

The patch should provide a feature-complete implementation of Large
Communities, but the daemon crashes sometimes. We don't know why yet.
However I am proud to report that it compiles! :-)

> Also, please prod your commercial vendors for support for this.

Yes!

Even if a vendor is listed as 'Planned' or 'Requested' on the
http://largebgpcommunities.net/implementations/ page, it really helps if
you email your account manager stating "Large Communities is what i want".

Most vendors have a big backlog of feature requests and no shortage of
ideas. This operational community must make it unambiguously clear to
the vendors that Large Communities is the thing that needs to be
shipping in 2017. This peer pressure will help them to prioritize the
development, testing, Q, documentation development, internal &
external marketing etc to get it done.

So, pause your IPv6 deployments for one day, and start calling your
Huawei, Cisco (ask separately for IOS and XR), Juniper, Nokia, Arista,
Brocade, ZTE, or Microsoft representatives and ask for it by name! :-)

Kind regards,

Job

Re: Looking for some Quagga experience to discuss 32 bit ASN + community issue with

[Nick Hilliard]

Eric Germann wrote:
> Basically trying to advertise 4 byte ASN’s + communities, and then
> pick them off elsewhere in a private network.  Can’t get the config
> right for the route map to import them on the “receiving” side.

yes, sounds about right.  There is a massive feature deficit regarding
BGP communities suitable for asn32s, in that the feature just doesn't
really exist yet.  This is being remedied at the moment at the ietf,
which has just moved the draft-ietf-idr-large-community internet draft
to "Publication Requested" state.

There are implementations here:

http://largebgpcommunities.net/implementations/

The feature hasn't made it into mainline quagga yet, but there is a patch.

Also, please prod your commercial vendors for support for this.

Nick