Re: External BGP Controller for L3 Switch BGP routing

[Phil Bedard]

Cisco and Arista are both able to squeeze a current full Internet table into 
the base space on their Jericho boxes, using the right space partitioning.   
Cisco added this in 6.1.2  without anything in the release notes, but you’ll 
notice they bumped the datasheet spec on the base 5502 to 1M FIB now where it 
used to be 256K.It works with the standard Internet table, but may not work 
if you have a ton of routes with lengths that do not work well with how the 
memory is carved up.   Of course Jericho is more expensive than Trident.  

Phil 

-Original Message-
From: NANOG  on behalf of joel jaeggli 

Date: Tuesday, January 17, 2017 at 00:22
To: Yucong Sun , Tore Anderson , Saku Ytti 

Cc: nanog list 
Subject: Re: External BGP Controller for L3 Switch BGP routing

On 1/15/17 11:00 PM, Yucong Sun wrote:
> In my setup, I use an BIRD instance to combine multiple internet full
> tables,  i use some filter to generate some override route to send to my 
L3
> switch to do routing.  The L3 switch is configured with the default route
> to the main transit provider , if BIRD is down, the route would be
> unoptimized, but everything else remain operable until i fixed that BIRD
> instance.
> 
> I've asked around about why there isn't a L3 switch capable of handling
> full tables, I really don't understand the difference/logic behind it.

In practice there are several merchant silicon implmentations that
support the addition of external tcams. building them accordingly
increases the COGS and and various performance and packaging limitions.

arista 7280r and cisco ncs5500 are broadcom jericho based devices that
are packaged  accordingly.
 

Re: Questions on IPv6 deployment

[William Herrin]

On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker
 wrote:
> I’m looking for some direction/reading list of how to properly configure 
> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128 
> instead.Assign all loopbacks from the same /64, use a different /64 for 
> each loopback. Ect, ect.

Hi Matthew,

Suggest /128's for loopbacks and /124's for point to points, all from
the same /64. This way you don't burn space needlessly, don't open
yourself to neighbor discovery issues on point to points and can
filter inbound Internet packets to that /64 in one fell swoop so that
it's harder to hit your routers directly. Just make sure not to filter
the outbound packets.

Reminder: No matter what size you pick, use nibble boundaries for
visual and DNS convenience. So /124, not /126.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: BGP Route Reflector - Route Server, Router, etc

[Phil Bedard]

Cisco and Juniper both have working ORR implementations, although config on the 
Juniper one is a bit clunky right now.  One interesting thing is they also 
allow feeding topology data via BGP-LS, so BGP is the only protocol you need to 
run to/from it.  

Phil 

-Original Message-
From: NANOG  on behalf of Brandon Ewing 

Date: Friday, January 13, 2017 at 17:39
To: Justin Krejci 
Cc: 
Subject: Re: BGP Route Reflector - Route Server, Router, etc

On Thu, Jan 12, 2017 at 08:32:44PM +, Justin Krejci wrote:
> What are the pros and cons of one design over another? On list or private 
off list replies would be great; I'd welcome real world experiences (especially 
any big gotchas or caveats people learned the hard way) as well as just links 
to previous discussions, PDFs, slideshows, etc. Heck even a good book 
suggestion that covers this topic would be appreciated.
> 

One important thing to remember when migrating from full mesh to a RR design
is that you are reducing information available to the routers in the ASN.
When you had a full mesh, each router could select the best path from all
available paths, according to its position in the IGP.  In a RR environment,
by default, routers only have available to them the best routes from the
RR's position in the IGP, which can lead to suboptimal exits being selected.

Work is being done to allow RRs to compute metrics from the client's
position in the IGP: See
https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13
for more information

-- 
Brandon Ewing (nicot...@warningg.com)

Re: Questions on IPv6 deployment

[Sander Steffann]

Hi,

> Suggest /128's for loopbacks and /124's for point to points, all from
> the same /64. This way you don't burn space needlessly, don't open
> yourself to neighbor discovery issues on point to points

I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point 
connection and configure a /127 using ::a on one side and ::b on the other. All 
of these from a block reserved for infrastructure for filtering:

> and can
> filter inbound Internet packets to that /64 in one fell swoop so that
> it's harder to hit your routers directly. Just make sure not to filter
> the outbound packets.

Having a single block for infrastructure makes this very easy. In most cases I 
don't need to worry about "burning space needlessly" so I reserve /64s per 
point-to-point. Worrying about "wasting" address space is more often an 
IPv4-ism than good practice with IPv6 IMHO :-)  But it all depends on the 
complexity of your network. There are cases where it makes sense to think about 
this.

> Reminder: No matter what size you pick, use nibble boundaries for
> visual and DNS convenience. So /124, not /126.

Good advice!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions on IPv6 deployment

[Michael Still]

Hi, a few years back some in the community got together to write this:

On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker 
wrote:

>
> Hello,
>
> I’m AS7849 and I have an IP problem.
>
> I’m running IPv4 ( /16 legacy + /20) and have enough space to last me for
> a while,  multi-homed, BGP4 full tables + peering, ect.
> I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.
>
> I want to start building my IPv6 infrastructure.
>
> I have a /32 assigned from ARIN (2001:4918::/32)
>
> I’m looking for some direction/reading list of how to properly configure
> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
> instead.Assign all loopbacks from the same /64, use a different /64 for
> each loopback. Ect, ect.
>
> I’m trying not to light a religious war but what is the current best
> practice for IPv6 deployment in a service provider network?
>
> PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22
> years.  ☺
>
> -Matt
>
> --
> Matthew Crocker
> Crocker Communications, Inc.
> President
>



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Questions on IPv6 deployment

[Michael Still]

Oops:
http://nabcop.org/index.php/IPv6_Subnetting


On Tue, Jan 17, 2017 at 12:48 PM, Michael Still 
wrote:

> Hi, a few years back some in the community got together to write this:
>
> On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker <
> matt...@corp.crocker.com> wrote:
>
>>
>> Hello,
>>
>> I’m AS7849 and I have an IP problem.
>>
>> I’m running IPv4 ( /16 legacy + /20) and have enough space to last me
>> for  a while,  multi-homed, BGP4 full tables + peering, ect.
>> I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core.
>>
>> I want to start building my IPv6 infrastructure.
>>
>> I have a /32 assigned from ARIN (2001:4918::/32)
>>
>> I’m looking for some direction/reading list of how to properly configure
>> IPv6.  I’ve read to use a /64 for PtP interfaces and I’ve read use a /128
>> instead.Assign all loopbacks from the same /64, use a different /64 for
>> each loopback. Ect, ect.
>>
>> I’m trying not to light a religious war but what is the current best
>> practice for IPv6 deployment in a service provider network?
>>
>> PS.  I’ll be at NANOG69 in DC next month,  1st NANOG for me after 22
>> years.  ☺
>>
>> -Matt
>>
>> --
>> Matthew Crocker
>> Crocker Communications, Inc.
>> President
>>
>
>
>
> --
> [stillwa...@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com ~]$
>



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 12:48 PM, Michael Still  wrote:
> http://nabcop.org/index.php/IPv6_Subnetting

That's overall good advice. I quibble with a couple of points:

1. If you plan to use a /126 on a point to point and can't imagine how
you would use a /64 on that point to point, don't allocate a /64. Odds
are that by the time you can imagine some way to use a /64 there, the
details will require you to assign a new block anyway.

Why be concerned about resource consumption? Because it's a good
habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
is, but shrewd use of available resources is a good habit even when
resources are plentiful.

2. Make all your point to points /124. That will work for all your
point to points. Serial or ethernet. Even the ethernets which have two
high-availability routers on both ends along with the failover address
needing a total of 6 IPs plus 1 for your troubleshooting laptop.
Configuring /124 every time allows you to standardize your
configuration, the same way /64 standardizes the netmask on a LAN
deployment.



One additional point not brought up:

Minimum assignment to a customer: /60. Never ever /64 or /128. How
much more than a /60 you choose as your minimum is up to you. Common
choices are /56 and /48. But never, ever less than a /60.   Your
customer will want to deploy a /64 to each LAN. And there are so many
cases where he'll want to deploy more than one LAN.

I've noticed a lot of hosting providers getting this wrong. Some of
your customers do create VPNs on their VPC you know.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

RE: Questions on IPv6 deployment

[Matthew Huff]

The reason for allocating a /64 for a point to point link is due to various 
denial of service attack vectors. Just do it. The numbers in IPv6 are 
staggering. The generally accepted best practice is to allocate a /64 and use a 
/128 within that /64 for point to point links.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William
> Herrin
> Sent: Tuesday, January 17, 2017 4:02 PM
> To: Michael Still 
> Cc: nanog@nanog.org
> Subject: Re: Questions on IPv6 deployment
> 
> On Tue, Jan 17, 2017 at 12:48 PM, Michael Still 
> wrote:
> > http://nabcop.org/index.php/IPv6_Subnetting
> 
> That's overall good advice. I quibble with a couple of points:
> 
> 1. If you plan to use a /126 on a point to point and can't imagine how
> you would use a /64 on that point to point, don't allocate a /64. Odds
> are that by the time you can imagine some way to use a /64 there, the
> details will require you to assign a new block anyway.
> 
> Why be concerned about resource consumption? Because it's a good
> habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
> is, but shrewd use of available resources is a good habit even when
> resources are plentiful.
> 
> 2. Make all your point to points /124. That will work for all your
> point to points. Serial or ethernet. Even the ethernets which have two
> high-availability routers on both ends along with the failover address
> needing a total of 6 IPs plus 1 for your troubleshooting laptop.
> Configuring /124 every time allows you to standardize your
> configuration, the same way /64 standardizes the netmask on a LAN
> deployment.
> 
> 
> 
> One additional point not brought up:
> 
> Minimum assignment to a customer: /60. Never ever /64 or /128. How
> much more than a /60 you choose as your minimum is up to you. Common
> choices are /56 and /48. But never, ever less than a /60.   Your
> customer will want to deploy a /64 to each LAN. And there are so many
> cases where he'll want to deploy more than one LAN.
> 
> I've noticed a lot of hosting providers getting this wrong. Some of
> your customers do create VPNs on their VPC you know.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[Owen DeLong]

I think you mean /127 since a /128 would not support 2 points on the point to 
point.

Owen

> On Jan 17, 2017, at 13:07 , Matthew Huff  wrote:
> 
> The reason for allocating a /64 for a point to point link is due to various 
> denial of service attack vectors. Just do it. The numbers in IPv6 are 
> staggering. The generally accepted best practice is to allocate a /64 and use 
> a /128 within that /64 for point to point links.
> 
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-694-5669
> 
> 
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William
>> Herrin
>> Sent: Tuesday, January 17, 2017 4:02 PM
>> To: Michael Still 
>> Cc: nanog@nanog.org
>> Subject: Re: Questions on IPv6 deployment
>> 
>> On Tue, Jan 17, 2017 at 12:48 PM, Michael Still 
>> wrote:
>>> http://nabcop.org/index.php/IPv6_Subnetting
>> 
>> That's overall good advice. I quibble with a couple of points:
>> 
>> 1. If you plan to use a /126 on a point to point and can't imagine how
>> you would use a /64 on that point to point, don't allocate a /64. Odds
>> are that by the time you can imagine some way to use a /64 there, the
>> details will require you to assign a new block anyway.
>> 
>> Why be concerned about resource consumption? Because it's a good
>> habit. Don't overdo it, IPv6 is not resource constrained the way IPv4
>> is, but shrewd use of available resources is a good habit even when
>> resources are plentiful.
>> 
>> 2. Make all your point to points /124. That will work for all your
>> point to points. Serial or ethernet. Even the ethernets which have two
>> high-availability routers on both ends along with the failover address
>> needing a total of 6 IPs plus 1 for your troubleshooting laptop.
>> Configuring /124 every time allows you to standardize your
>> configuration, the same way /64 standardizes the netmask on a LAN
>> deployment.
>> 
>> 
>> 
>> One additional point not brought up:
>> 
>> Minimum assignment to a customer: /60. Never ever /64 or /128. How
>> much more than a /60 you choose as your minimum is up to you. Common
>> choices are /56 and /48. But never, ever less than a /60.   Your
>> customer will want to deploy a /64 to each LAN. And there are so many
>> cases where he'll want to deploy more than one LAN.
>> 
>> I've noticed a lot of hosting providers getting this wrong. Some of
>> your customers do create VPNs on their VPC you know.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
> The reason for allocating a /64 for a point to point link is due to various 
> denial of service attack vectors.

Hi Matthew,

I'm always interested in learning something new. Please explain the
DOS vectors you're referring to and how they're mitigated by
allocating a /64 to the point to point link.


> Just do it.

No. But if you offer a good reason, I'll factor your reason in to my
considerations.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[joel jaeggli]

On 1/17/17 1:55 PM, William Herrin wrote:
> On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
>> The reason for allocating a /64 for a point to point link is due to various 
>> denial of service attack vectors.


if you mean allocating a /127, then... sure.

Neighbor discovery on point to point links could be a problem as is the
poential for looping behavior . There are of course ways other than
allocating a longer prefix to a point to point link to achieve that, 
e.g. disabling it. among other things You have to disable DAD anyway if
you ever plan to loop them up for testing.

these are detailed in

https://tools.ietf.org/html/rfc6164
>> Hi Matthew,
>>
>> I'm always interested in learning something new. Please explain the
>> DOS vectors you're referring to and how they're mitigated by
>> allocating a /64 to the point to point link.
>>
>>
>> Just do it.
> No. But if you offer a good reason, I'll factor your reason in to my
> considerations.
>
> Regards,
> Bill Herrin
>




signature.asc
Description: OpenPGP digital signature

RE: Questions on IPv6 deployment

[Matthew Huff]

Please check the nanog archives. There were some arguments that I and I assume 
others felt compelling why allocating a /64 per point to point link was a good 
idea. Your network, your rules. I was just responding to the argument that a 
/64 is wasteful and serves little purpose.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: William Herrin [mailto:b...@herrin.us]
> Sent: Tuesday, January 17, 2017 4:56 PM
> To: Matthew Huff 
> Cc: Michael Still ; nanog@nanog.org
> Subject: Re: Questions on IPv6 deployment
> 
> On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
> > The reason for allocating a /64 for a point to point link is due to
> various denial of service attack vectors.
> 
> Hi Matthew,
> 
> I'm always interested in learning something new. Please explain the
> DOS vectors you're referring to and how they're mitigated by
> allocating a /64 to the point to point link.
> 
> 
> > Just do it.
> 
> No. But if you offer a good reason, I'll factor your reason in to my
> considerations.
> 
> Regards,
> Bill Herrin
> 
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[Sander Steffann]

Hi Bill,

> Op 17 jan. 2017, om 22:55 heeft William Herrin  het volgende 
> geschreven:
> 
> I'm always interested in learning something new. Please explain the
> DOS vectors you're referring to and how they're mitigated by
> allocating a /64 to the point to point link.

One thing that comes to mind is that it seems that some routers only have 
limited space in their routing tables for prefixes longer than a /64. If you 
would configure a /127 on the link but push the /64 to the routing table then 
you might both avoid ND Cache exhaustion and avoid the limitations on 
longer-than-/64 prefixes.

I personally prefer to set up my addressing plan that things like this are 
possible even if I don't do it today, but I also understand the choices you 
make. I don't think any of the choices is wrong. It mostly depends on 
expectations, used equipment and personal preference.

And thanks for mentioning "Minimum assignment to a customer: /60". That is 
indeed a very important one!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Safe IPv4 Was: Re: premiumcolo.net IP address rental

[Martin Hannigan]

On Mon, Jan 9, 2017 at 2:34 PM, Robert Story  wrote:

> On Mon, 9 Jan 2017 13:40:23 -0500 Martin wrote:
> MH> 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this.
>
> Not quite everyone. You have to be a RIPE NCC member, which not everyone
> can do.
>
> "Who can become a Local Internet Registry (LIR)/RIPE NCC member?
>
> Any organisation with a legally established office in the RIPE NCC
> service region can become a member of the RIPE NCC."
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/faq/faq-ipv4-
> address-space
>
>
>

I'm not sure this applies to the situation we're discussing. For example, a
US based corporation can apply and will receive an allocation of a /22 from
the RIPE last /8. I believe they do become an LIR. That does not require an
EU subsidiary or physical office. This is "good" for a variety of reasons
including providing for need and rushing towards exhaustion. This isn't
surreptitious. It is within policy.


Best,

-M<

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 6:06 PM, Sander Steffann  wrote:
> One thing that comes to mind is that it seems that some routers only have 
> limited space in their routing tables for prefixes longer than a /64. If you 
> would configure a /127 on the link but push the /64 to the routing table then 
> you might both avoid ND Cache exhaustion and avoid the limitations on 
> longer-than-/64 prefixes.

Hi Sander,

IIRC, the problem was that some routers could only fit the first 64
bits in the TCAM so routes longer than /64 fell out of the fast path.
That was about half a decade ago. No idea if anything modern still
suffers from this.

That would impact every route in Matthew's proposed solution: the
loopbacks from the infrastructure /64 and the /127's from otherwise
unpopulated /64's. Because programmatically those /64's don't have one
prefix, they have two: the /127 for the link and the implicit null
route for everything else. The router has to honor the implicit null
route so it can't aggregate the /127 to /64 and keep it in the fast
path.

Regards,
Bill Herrin




-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Questions on IPv6 deployment

[William Herrin]

On Tue, Jan 17, 2017 at 5:13 PM, Matthew Huff  wrote:
> Please check the nanog archives.
> I was just responding to the argument that a /64 is wasteful and serves 
> little purpose.

Then respond. With explanation, reasoning and evidence. Telling me to
search a massive archive for nebulous discussions is a total cop-out.

Regards,
Bill


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

DNS CAA records...

[Eric Tykwinski]

So I’ve come across this on Qualys and just wondering if there’s any practical 
examples out there in the wild.
I know some BIND guys are on here, so I’m sure I’m missing something from the 
RFCs.
Just wanted to test this out on my play domains before putting it out in the 
wild...

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

Level3 Internet service, out of order packets causing issues

[Mark Wicker]

Hi,

I have 1G Level3 ethernet dedicated internet service as one of my ISP's at my 
company based in the Los Angeles (Inland Empire) area. After seeing strange 
application behavior while using this circuit, I failed it out of service and 
have been troubleshooting it with a directly connected machine (publically 
addressed, no firewall, nothing between this machine and our Level3 router). I 
have taken several packet captures while accessing various sites and have 
noticed large numbers of out of order packets which are wreaking havoc with TCP 
connections and other traffic. In my experience, per-packet load balancing 
across various different links can cause this issue. I do not see this behavior 
with my other ISP's. I have had several tickets opened with Level3 but have had 
no success. Any help here? Anyone out there seen this and have any contacts 
that may be able to help?


FYI - we own our own public IP space and advertise via BGP to Level3. Currently 
I am using a dedicated /24 of our space advertised to Level3 only to ensure 
that the return path is through Level3 and not another ISP. Also, everything is 
single linked from a layer 2 and 3 perspective from the router to the test 
machine to ensure that the cause of any out of order packets is not on our end.


Thanks,


--
Mark Wicker | Senior Network Engineer
Esri | 380 New York St | Redlands, CA  92354 | USA
T 909 793 2853 x2741 | mwic...@esri.com | 
esri.com

Common Reliable Out Of Band Management Options at Carrier Hotels

[Darin Herteen]

Greetings list,


We are exploring standardizing our Out Of Band options across our network and 
various off-net locations and the question was brought up "What about carrier 
hotels? What constraints might present themselves at those locations?"


Assuming each hotel we are located in can provide either Ethernet or DSL I'm 
guessing that is going to come a cost (cross-connects, rack space etc..) that 
might end up being cost prohibitive.


So my inquiry is... What does the list find to be a reasonably priced yet 
reliable solution in carrier hotels for OOB? Or is that contradictory :)


Thoughts on Cellular?


Any experience/insight would be appreciated.


Thanks,


Darin

Anyone from Frontier? Reachability Issues to AS5650

[Matt Peterman]

Hello all!

I have been unable to find a good contact for Frontier’s NOC, so I am hoping to 
have success here. I have reached out to the listed contacts in AS5650’s ARIN 
record to no avail.

I am having issues reaching seemingly all IPs announced from AS5650. I am an 
AT&T customer with IP block 76.233.227.0/25 assigned to me. My connectivity 
seems to die somewhere in the handoff between AT&T and Frontiers network. 
Looking glasses show that AT&T is announcing my IPs as the aggregate 
76.224.0.0/11, however bgp.he.net seems to also show that Frontier is 
announcing 76.233.226.0/23 somewhere (although all looking glasses show the 
only route to me is 76.224.0.0/11). I’m thinking somewhere in the AT&T/Frontier 
DSL sell-off Frontier is either not accepting the /11 from AT&T or has a hold 
down route for 76.233.226.0/23 somewhere in their network. Any help or contacts 
are appreciated as there are a number of sites and services I am unable to 
reach. All MTRs to networks in AS5650 die at the edge of AT&Ts network.

Matt

MTR to 107.191.134.73 from 76.233.227.54

Jan 16 20:26:35 2017
Keys:  Help   Display mode   Restart statistics   Order of fields   quit

   Packets   Pings
 Host   
 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 76.233.227.1
  0.0%271.6   2.0   1.2   4.1   0.7
 2. 10.11.8.1   
  0.0%272.2   2.1   1.0   4.6   1.0
 3. 172.17.17.129   
  0.0%271.9   3.2   1.6  14.8   2.7
 4. ???
 5. 71.145.0.184
  0.0%27   22.6  23.6  20.2  47.0   5.3
 6. 12.83.39.177
  0.0%27   24.4  24.9  21.0  34.7   3.0
 7. 12.123.15.125   
  0.0%27   33.6  45.6  21.0 154.1  37.1
 8. ???

Re: DNS CAA records...

[Nolan Berry]

So a quick look into this I see one potential real world example:


;; ANSWER SECTION:
google.com.129INA216.58.218.142
google.com.74411INNSns4.google.com.
google.com.74411INNSns1.google.com.
google.com.74411INNSns2.google.com.
google.com.74411INNSns3.google.com.
google.com.3054INTXT"v=spf1 include:_spf.google.com ~all"
google.com.64IN2607:f8b0:4000:802::200e
google.com.54475INTYPE257\# 19 
0005697373756573796D616E7465632E636F6D


In RFC 6844 section 7.1 it states


"IANA has assigned Resource Record Type 257 for the CAA Resource Record Type"


and I am seeing:


google.com.54475INTYPE257\# 19 
0005697373756573796D616E7465632E636F6D



Nolan Berry

Linux Systems Engineer

DNS Engineering

Rackspace Hosting


From: NANOG  on behalf of Eric Tykwinski 

Sent: Tuesday, January 17, 2017 6:04:31 PM
To: nanog list
Subject: DNS CAA records...

So I’ve come across this on Qualys and just wondering if there’s any practical 
examples out there in the wild.
I know some BIND guys are on here, so I’m sure I’m missing something from the 
RFCs.
Just wanted to test this out on my play domains before putting it out in the 
wild...

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

Re: DNS CAA records...

[Royce Williams]

On Tue, Jan 17, 2017 at 3:04 PM, Eric Tykwinski  wrote:
> So I’ve come across this on Qualys and just wondering if there’s any 
> practical examples out there in the wild.
> I know some BIND guys are on here, so I’m sure I’m missing something from the 
> RFCs.
> Just wanted to test this out on my play domains before putting it out in the 
> wild...

As of 2016-12-31, here are CAA records for 143 domains:

https://gist.github.com/roycewilliams/a5b2d26edf3b64ecf77a75f943de079f

That gist contains all CAA (or unparsed/raw type 257) records as seen
in the Rapid7 "DNS ANY" dataset [1] from 2016-12-31.

Interestingly, google.com as noted by Nolan side-thread isn't in this
dataset. Since "DNS ANY" is a superset of all DNS picked up by other
scans, it may be that Rapid7's scanning isn't incidentally catching
many CAA records. An explicit scan for CAA records (against, say, in
all domains seen in DNS ANY) would likely be interesting.

Also, I've requested that cPanel add CAA support to the DNS management
tools. If that would be of use to you, feel free to upvote the feature
[2].

Some good CAA refs are [3],[4],and [5].

Royce

1. https://scans.io/study/sonar.fdns
2. https://features.cpanel.net/topic/add-support-for-caa-dns-records-type-257
3. https://tools.ietf.org/html/rfc6844
4. https://sslmate.com/labs/caa/ (includes info on which CAs support
them; it's early)
5. https://blog.dnsimple.com/2017/01/introducing-caa-records/

Re: Level3 Internet service, out of order packets causing issues

[Jason Rokeach]

Hi Mark,
I'm going to throw out a guess here.  By any chance, is the first octet of
your router's MAC address a 4 or a 6?
In general, modern routers do not load balance per-packet, which is what
caused out-of-order issues in days gone.  Load balancing is usually done
based on a hash of the source and/or destination IP of the packet, MPLS
label, or Ethernet (on a switched interface).  The most common cause for
actual unordering of packets/frames in a modern service provider network,
in my experience, is actually this hashing mechanism.  Many vendor's
hashing implementations assume, based on position in the frame, that a
frame with a MAC address beginning with 4 or 6 is an IPv4 or IPv6 frame,
not an MPLS frame.  This can result in out of order packets.  The most
common fix is control word being applied on a pseudowire (assuming you are
being carried across a pseudowire in the SP network), but if this *is* what
is occurring, you could also resolve the issue by changing your MAC address.

___
*Jason R. Rokeach*
m: 603.969.5549
e: ja...@rokeach.net

On Tue, Jan 17, 2017 at 2:12 PM, Mark Wicker  wrote:

> Hi,
>
> I have 1G Level3 ethernet dedicated internet service as one of my ISP's at
> my company based in the Los Angeles (Inland Empire) area. After seeing
> strange application behavior while using this circuit, I failed it out of
> service and have been troubleshooting it with a directly connected machine
> (publically addressed, no firewall, nothing between this machine and our
> Level3 router). I have taken several packet captures while accessing
> various sites and have noticed large numbers of out of order packets which
> are wreaking havoc with TCP connections and other traffic. In my
> experience, per-packet load balancing across various different links can
> cause this issue. I do not see this behavior with my other ISP's. I have
> had several tickets opened with Level3 but have had no success. Any help
> here? Anyone out there seen this and have any contacts that may be able to
> help?
>
>
> FYI - we own our own public IP space and advertise via BGP to Level3.
> Currently I am using a dedicated /24 of our space advertised to Level3 only
> to ensure that the return path is through Level3 and not another ISP. Also,
> everything is single linked from a layer 2 and 3 perspective from the
> router to the test machine to ensure that the cause of any out of order
> packets is not on our end.
>
>
> Thanks,
>
>
> --
> Mark Wicker | Senior Network Engineer
> Esri | 380 New York St | Redlands, CA  92354 | USA
> T 909 793 2853 x2741 | mwic...@esri.com |
> esri.com
>
>

Re: Level3 Internet service, out of order packets causing issues

[Jason Rokeach]

Hi Mark,
I'm going to throw out a guess here.  By any chance, is the first octet of
your router's MAC address a 4 or a 6?
In general, modern routers do not load balance per-packet, which is what
caused out-of-order issues in days gone.  Load balancing is usually done
based on a hash of the source and/or destination IP of the packet, MPLS
label, or Ethernet (on a switched interface).  The most common cause for
actual unordering of packets/frames in a modern service provider network,
in my experience, is actually this hashing mechanism.  Many vendor's
hashing implementations assume, based on position in the frame, that a
frame with a MAC address beginning with 4 or 6 is an IPv4 or IPv6 frame,
not an MPLS frame.  This can result in out of order packets.  The most
common fix is control word being applied on a pseudowire (assuming you are
being carried across a pseudowire in the SP network), but if this *is* what
is occurring, you could also resolve the issue by changing your MAC address.


On Tue, Jan 17, 2017 at 2:12 PM, Mark Wicker  wrote:

> Hi,
>
> I have 1G Level3 ethernet dedicated internet service as one of my ISP's at
> my company based in the Los Angeles (Inland Empire) area. After seeing
> strange application behavior while using this circuit, I failed it out of
> service and have been troubleshooting it with a directly connected machine
> (publically addressed, no firewall, nothing between this machine and our
> Level3 router). I have taken several packet captures while accessing
> various sites and have noticed large numbers of out of order packets which
> are wreaking havoc with TCP connections and other traffic. In my
> experience, per-packet load balancing across various different links can
> cause this issue. I do not see this behavior with my other ISP's. I have
> had several tickets opened with Level3 but have had no success. Any help
> here? Anyone out there seen this and have any contacts that may be able to
> help?
>
>
> FYI - we own our own public IP space and advertise via BGP to Level3.
> Currently I am using a dedicated /24 of our space advertised to Level3 only
> to ensure that the return path is through Level3 and not another ISP. Also,
> everything is single linked from a layer 2 and 3 perspective from the
> router to the test machine to ensure that the cause of any out of order
> packets is not on our end.
>
>
> Thanks,
>
>
> --
> Mark Wicker | Senior Network Engineer
> Esri | 380 New York St | Redlands, CA  92354 | USA
> T 909 793 2853 x2741 | mwic...@esri.com |
> esri.com
>
>

Re: DNS CAA records...

[Mark Andrews]

Or use up-to-date code.  CAA support was added in BIND 9.8.8 (already
end of lifed), BIND 9.9.6, BIND 9.10.1 and BIND 9.11.0.

[rock:~/git/bind9] marka% dig caa google.com
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> caa google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42490
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5f52c5d222feb5c9583cb70c587ee11a8f16c403c5fdbbd5 (good)
;; QUESTION SECTION:
;google.com.IN  CAA

;; ANSWER SECTION:
google.com. 86400   IN  CAA 0 issue "symantec.com"

;; Query time: 192 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 18 14:29:30 EST 2017
;; MSG SIZE  rcvd: 98

[rock:~/git/bind9] marka% 

Anyway this is a good real life example of how you can add new types
and have them be looked up without having to update the servers or
the clients.  "dig TYPE257 google.com" would have also worked.

Mark


In message , Nolan Berry writes:
> So a quick look into this I see one potential real world example:
>
>
> ;; ANSWER SECTION:
> google.com.129INA216.58.218.142
> google.com.74411INNSns4.google.com.
> google.com.74411INNSns1.google.com.
> google.com.74411INNSns2.google.com.
> google.com.74411INNSns3.google.com.
> google.com.3054INTXT"v=spf1 include:_spf.google.com
> ~all"
> google.com.64IN2607:f8b0:4000:802::200e
> google.com.54475INTYPE257\# 19
> 0005697373756573796D616E7465632E636F6D
>
>
> In RFC 6844 section 7.1 it states
>
>
> "IANA has assigned Resource Record Type 257 for the CAA Resource Record
> Type"
>
>
> and I am seeing:
>
>
> google.com.54475INTYPE257\# 19 
> 0005697373756573796D616E7465632E636F6D
>
>
>
> Nolan Berry
>
> Linux Systems Engineer
>
> DNS Engineering
>
> Rackspace Hosting
>
> 
> From: NANOG  on behalf of Eric Tykwinski
> 
> Sent: Tuesday, January 17, 2017 6:04:31 PM
> To: nanog list
> Subject: DNS CAA records...
>
> So I've come across this on Qualys and just wondering if there's any
> practical examples out there in the wild.
> I know some BIND guys are on here, so I'm sure I'm missing something from
> the RFCs.
> Just wanted to test this out on my play domains before putting it out in
> the wild...
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org