Re: rfc 1812 third party address on traceroute

[Randy Bush]

>>.-.
>>| |
>>|   B |- D
>> S -| A  R|
>>|   C |- (toward S)
>>| |
>>`-'
>> 
>> of course, simpletons such as i would desire the source of the time
>> exceeded message to be A.  after all, this is the interface to which i
>> sent the icmp with the TTL to expire.
> 
> Do you mean the source address or the source interface?

the source address

> I'm not sure if you mean that, if sent through C it should have the
> source addres of A, or that it should actually be sent through A
> regardless of the routing table (which sounds better to me).

not to me.  i have kinda grown used to fibs

randy

Re: Verizon and Level3 DNS flush

[Hank Nussbacher]

On 01/06/2016 21:16, Mike wrote:
>
>
> On 06/01/2016 10:59 AM, Jürgen Jaritsch wrote:
>> Dear NANOGers,
>>
>> is there anyone from Verizon and Level3 who can help me with DNS
>> caching issue? We're running a global service for a customer and we
>> had to change to NS IPs via Glue Records. At the moment at least
>> Verizone and Level3 are caching old NS records. Looking for DNS
>> admins out there.
>>
>>
>> Please contact me off- or on-list!
>>
>
> I totally understand the desire to just be able to go ask major
> operators for a courtesy cache flush, but there are ways to update dns
> and procedures to engage that can eliminate the underlaying causes of
> same. Not that everyone, including myself, is prefect or godly (or has
> their name in the rfc...!), but at the same time, it's a learning
> experience being offered to you and I hope that whatever hole you shot
> in your foot heals soon and hopefull you never have to make another
> one like it.
>
> Mike-
>
Those "procedures" were attempted to be documented in an RFC:
https://tools.ietf.org/html/draft-jabley-dnsop-flush-reqs-00
https://tools.ietf.org/html/draft-jabley-dnsop-dns-flush-00
Unfortunately, nothing ever came of it, so people are forced to post to
NANOG pleading for help.

-Hank

Re: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed)

[Roland Dobbins]

On 2 Jun 2016, at 10:47, Paul Ferguson wrote:


There is an epic lesson here. I'm just not sure what it is. :-)


That Netflix offering free streaming to everyone over IPv6 (after fixing 
their VPN detection) would be the most effective way to convince 
end-users to demand IPv6 service from their ISPs?


;>

---
Roland Dobbins 

Re: Netflix VPN detection - actual engineer needed

[Josh Luthman]

Have you tried cdnet...@netflix.com ?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Jun 1, 2016 11:56 PM, "Bill Woodcock"  wrote:

>
> > On Jun 2, 2016, at 6:27 AM, Matthew Kaufman  wrote:
> >
> > Every device in my house is blocked from Netflix this evening due to
> their new "VPN blocker". My house is on my own IP space, and the outside of
> the NAT that the family devices are on is 198.202.199.254, announced by AS
> 11994. A simple ping from Netflix HQ in Los Gatos to my house should show
> that I'm no farther away than Santa Cruz, CA as microwaves fly.
> >
> > Unfortunately, when one calls Netflix support to talk about this, the
> only response is to say "call your ISP and have them turn off the VPN
> software they've added to your account". And they absolutely refuse to
> escalate. Even if you tell them that you are essentially your own ISP.
> >
> > So... where's the Netflix network engineer on the list who all of us can
> send these issues to directly?
> >
> > Matthew Kaufman
>
> Matthew, haven’t you told your ISP to stop using the dreaded 198 space?
> Everyone knows those are magic addresses that belong to NetGear!  :-)
>
> -Bill
>
>
>
>
>

Re: Netflix VPN detection - actual engineer needed

[Bill Woodcock]

> On Jun 2, 2016, at 6:27 AM, Matthew Kaufman  wrote:
> 
> Every device in my house is blocked from Netflix this evening due to their 
> new "VPN blocker". My house is on my own IP space, and the outside of the NAT 
> that the family devices are on is 198.202.199.254, announced by AS 11994. A 
> simple ping from Netflix HQ in Los Gatos to my house should show that I'm no 
> farther away than Santa Cruz, CA as microwaves fly.
> 
> Unfortunately, when one calls Netflix support to talk about this, the only 
> response is to say "call your ISP and have them turn off the VPN software 
> they've added to your account". And they absolutely refuse to escalate. Even 
> if you tell them that you are essentially your own ISP.
> 
> So... where's the Netflix network engineer on the list who all of us can send 
> these issues to directly?
> 
> Matthew Kaufman

Matthew, haven’t you told your ISP to stop using the dreaded 198 space?  
Everyone knows those are magic addresses that belong to NetGear!  :-)

-Bill






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed)

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is an epic lesson here. I'm just not sure what it is. :-)

- - ferg


On 6/1/2016 8:41 PM, Matthew Kaufman wrote:

> Turns out it has nothing to do with my IPv4 connectivity. Neither
> of my ISPs has native IPv6 connectivity, so both require tunnels
> (one of them to HE.net, one to the ISPs own tunnel broker), and
> both appear to be detected as a non-permitted VPN. As an early IPv6
> adopter, I've had IPv6 on all my household devices for years now.
> 
> So after having to temporarily turn off IPv6 at my desktop to fix 
> issues with pay.gov (FCC license payments), and issues with
> various other things, and then remember to turn it back on again...
> I now have the reason I've been waiting for to turn it off globally
> for the whole house.
> 
> Thanks Netflix for helping move us forward here.
> 
> Matthew Kaufman
> 
> ps. Would still be helpful if the support techs could tell from
> the error codes that the denied VPN is an IPv6 tunnel
> 
> -- Original Message -- From: "Matthew Kaufman"
>  To: "NANOG"  Sent: 6/1/2016
> 8:27:00 PM Subject: Netflix VPN detection - actual engineer needed
> 
>> Every device in my house is blocked from Netflix this evening due
>> to their new "VPN blocker". My house is on my own IP space, and
>> the outside of the NAT that the family devices are on is
>> 198.202.199.254, announced by AS 11994. A simple ping from
>> Netflix HQ in Los Gatos to my house should show that I'm no
>> farther away than Santa Cruz, CA as microwaves fly.
>> 
>> Unfortunately, when one calls Netflix support to talk about this,
>> the only response is to say "call your ISP and have them turn off
>> the VPN software they've added to your account". And they
>> absolutely refuse to escalate. Even if you tell them that you are
>> essentially your own ISP.
>> 
>> So... where's the Netflix network engineer on the list who all of
>> us can send these issues to directly?
>> 
>> Matthew Kaufman
> 
> 


- -- 
Paul Ferguson
ICEBRG.io
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAldPrG8ACgkQKJasdVTchbJ8lQEAgJrSwiKkyUcvoIoVp5gIBmkV
Dp1JqLdUtNphHTx4n2QA/jILspE24/BuY71211CSNqb3d5l9PH/udxyF2rN79ddL
=DLns
-END PGP SIGNATURE-

Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed)

[Matthew Kaufman]

 Turns out it has nothing to do with my IPv4 connectivity. Neither of my 
ISPs has native IPv6 connectivity, so both require tunnels (one of them 
to HE.net, one to the ISPs own tunnel broker), and both appear to be 
detected as a non-permitted VPN. As an early IPv6 adopter, I've had IPv6 
on all my household devices for years now.


 So after having to temporarily turn off IPv6 at my desktop to fix 
issues with pay.gov (FCC license payments), and issues with various 
other things, and then remember to turn it back on again... I now have 
the reason I've been waiting for to turn it off globally for the whole 
house.


 Thanks Netflix for helping move us forward here.

Matthew Kaufman

ps. Would still be helpful if the support techs could tell from the 
error codes that the denied VPN is an IPv6 tunnel


-- Original Message --
From: "Matthew Kaufman" 
To: "NANOG" 
Sent: 6/1/2016 8:27:00 PM
Subject: Netflix VPN detection - actual engineer needed

Every device in my house is blocked from Netflix this evening due to 
their new "VPN blocker". My house is on my own IP space, and the 
outside of the NAT that the family devices are on is 198.202.199.254, 
announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my 
house should show that I'm no farther away than Santa Cruz, CA as 
microwaves fly.


Unfortunately, when one calls Netflix support to talk about this, the 
only response is to say "call your ISP and have them turn off the VPN 
software they've added to your account". And they absolutely refuse to 
escalate. Even if you tell them that you are essentially your own ISP.


So... where's the Netflix network engineer on the list who all of us 
can send these issues to directly?


Matthew Kaufman

Re: Netflix VPN detection - actual engineer needed

[Pete Mundy]

Maybe it's time to use some reverse-psychology and try connecting through a 
VPN provider? ;-)

Pete

Ps, I hope you succeed in getting an answer from an actual engineer. But if I 
were a betting man...


> On 2/06/2016, at 3:27 pm, Matthew Kaufman  wrote:
> 
> Every device in my house is blocked from Netflix this evening due to their 
> new "VPN blocker". My house is on my own IP space, and the outside of the NAT 
> that the family devices are on is 198.202.199.254, announced by AS 11994. A 
> simple ping from Netflix HQ in Los Gatos to my house should show that I'm no 
> farther away than Santa Cruz, CA as microwaves fly.
> 
> Unfortunately, when one calls Netflix support to talk about this, the only 
> response is to say "call your ISP and have them turn off the VPN software 
> they've added to your account". And they absolutely refuse to escalate. Even 
> if you tell them that you are essentially your own ISP.
> 
> So... where's the Netflix network engineer on the list who all of us can send 
> these issues to directly?
> 
> Matthew Kaufman



smime.p7s
Description: S/MIME cryptographic signature

Netflix VPN detection - actual engineer needed

[Matthew Kaufman]

Every device in my house is blocked from Netflix this evening due to 
their new "VPN blocker". My house is on my own IP space, and the outside 
of the NAT that the family devices are on is 198.202.199.254, announced 
by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house 
should show that I'm no farther away than Santa Cruz, CA as microwaves 
fly.


Unfortunately, when one calls Netflix support to talk about this, the 
only response is to say "call your ISP and have them turn off the VPN 
software they've added to your account". And they absolutely refuse to 
escalate. Even if you tell them that you are essentially your own ISP.


So... where's the Netflix network engineer on the list who all of us can 
send these issues to directly?


Matthew Kaufman

Re: Google GeoIP issue

[Chris Boyd]

I too am having a similar problem.  Used the remediation link at 
https://support.google.com/websearch/contact/ip and it’s only partially 
corrected.  Users who log in to Google are seeing the US google.com page after 
they select the preferred country and languate, but everyone else is still 
getting google.ae.  208.81.245.226 is in Austin, TX.

—Chris

> On Jun 1, 2016, at 5:17 PM, Peter Loron  wrote:
> 
> Hello folks. An address we use is not identified as being in the correct 
> location by Google. Can someone from their NOC reach out off-list?
> 
> Thanks.
> 
> 
> Sent from my iPhone
> 

Re: Google GeoIP issue

[Paras Jha]

We had the same issue, there's a form you can fill out on Google's site if
you visit the homepage from one of the IPs in question. However, I don't
remember the exact link.

On Wed, Jun 1, 2016 at 6:17 PM, Peter Loron  wrote:

> Hello folks. An address we use is not identified as being in the correct
> location by Google. Can someone from their NOC reach out off-list?
>
> Thanks.
>
>
> Sent from my iPhone
>



-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

Google GeoIP issue

[Peter Loron]

Hello folks. An address we use is not identified as being in the correct 
location by Google. Can someone from their NOC reach out off-list?

Thanks.


Sent from my iPhone

Re: rfc 1812 third party address on traceroute

[Marc Storck]

I'm not saying anyone is wrong here. I merely want to point out eventual 
incompatabilities.

So please don't get me wrong.

Regards,

Marc

> On 1 juin 2016, at 23:46, William Herrin  wrote:
> 
> On Wed, Jun 1, 2016 at 3:16 PM, Marc Storck  wrote:
>>>  .-.
>>>  | |
>>>  |   B |- D
>>>   S -| A  R|
>>>  |   C |- (toward S)
>>>  | |
>>>  `-'
>> With BCP38 in mind, could there be situations
>> where Router R is not allowed to source packets
>> with address A out of interface C?
> 
> Hi Marc,
> 
> I think you're right. Address A in a /30 from ISP A. ISP C accepts
> source addresses from your /24 but not the A /30.  So if the router
> does not follow the RFC (sends an ICMP packet out C with a source
> address from A), typical asynchronous routing can result in
> black-holding the ICMP error message.
> 
> You've hit on a good reason to follow the RFC by default instead of
> doing what Randy wants. ;)
> 
> -Bill
> 
> 
> 
> 
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 

Re: rfc 1812 third party address on traceroute

[William Herrin]

On Wed, Jun 1, 2016 at 3:16 PM, Marc Storck  wrote:
>>   .-.
>>   | |
>>   |   B |- D
>>S -| A  R|
>>   |   C |- (toward S)
>>   | |
>>   `-'
>>
> With BCP38 in mind, could there be situations
> where Router R is not allowed to source packets
> with address A out of interface C?

Hi Marc,

I think you're right. Address A in a /30 from ISP A. ISP C accepts
source addresses from your /24 but not the A /30.  So if the router
does not follow the RFC (sends an ICMP packet out C with a source
address from A), typical asynchronous routing can result in
black-holding the ICMP error message.

You've hit on a good reason to follow the RFC by default instead of
doing what Randy wants. ;)

-Bill




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

Re: rfc 1812 third party address on traceroute

[William Herrin]

On Wed, Jun 1, 2016 at 5:03 PM, Octavio Alvarez  wrote:
> On 05/31/2016 11:22 AM, William Herrin wrote:
>>> I'm not sure if you mean that, if sent through C it should have the
>>> source addres of A, or that it should actually be sent through A
>>> regardless of the routing table (which sounds better to me).
>>
>> That doesn't make sense. There may be multiple next hops out A. If the
>> next hop in the FIB is out C, how would the router pick the next hop
>> to send to out A?
>
> Back to the physical address that sent the TTL-offending packet.

Howdy,

That would be an example of a layer violation. The only guarantee that
layer 2 makes to layer 3 is that if you tell the layer 2 stack the
layer 3 next hop address on that lan segment, it can figure out where
to deliver your packet (via arp on ethernet, but this is not
necessarily true of other layer 2s).

Long story short, layer violations break things. Indeed, many of BGP's
thornier problems and the mess that is mobile routing can all be
traced to a single layer violation that TCP commits on IP.

Regards,
Bill Herrin


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

Re: rfc 1812 third party address on traceroute

[Octavio Alvarez]

On 05/31/2016 09:52 AM, Hugo Slabbert wrote:
>> I'm not sure if you mean that, if sent through C it should have the
>> source addres of A, or that it should actually be sent through A
>> regardless of the routing table (which sounds better to me).
> 
> How is the latter better?  What guarantees are there that the 
> adjacent L3 device on R's interface A has a route for S [?]

Consider this scenario:

 .---.  ISP1ADDR/30{
D---|B   R  A|---[ ISP 1 ] {
 `---C---' {
 |(towards S)  { S is someplace
 | { over this side
.F---. {
 ---|G  R2  H|--*[ ISP 2 ] {
`'  ISP2ADDR/30{

In the asterisk there is BCP38 filtering which won't allow ISPADDR/30.
The packet expired on R incoming from ISP 1. Under Randy's scenario, the
TTL-exceeded packet would get dropped by ISP2.

The only way for the packet to get through is to follow RFC 1812, or to
send it back through A using A's address (this follows RFC 1812 4.3.2.4).

> and if such a route exists that it doesn't simply point at R?

If the route points back to R, then R just forwards it using the routing
table as with any packet.


Best regards.

Re: rfc 1812 third party address on traceroute

[Hugo Slabbert]

On Wed 2016-Jun-01 14:03:41 -0700, Octavio Alvarez  
wrote:


On 05/31/2016 11:22 AM, William Herrin wrote:

I'm not sure if you mean that, if sent through C it should have the
source addres of A, or that it should actually be sent through A
regardless of the routing table (which sounds better to me).


That doesn't make sense. There may be multiple next hops out A. If the
next hop in the FIB is out C, how would the router pick the next hop
to send to out A?


Back to the physical address that sent the TTL-offending packet.


Which comes back to my question:
What guarantees do you have that the device at that physical address (so, 
adjacent off of R's interface A) has a valid route for S, and that the 
route does not simply point back to R?



Anyway, Randy's comment was about source address selection, not
routing. With the packet coming from S into interface A, he'd prefer
that the ICMP error message be sourced from the IP address assigned to
A, not the IP address assigned to C or R.


Thanks.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: rfc 1812 third party address on traceroute

[Octavio Alvarez]

On 05/31/2016 11:22 AM, William Herrin wrote:
>> I'm not sure if you mean that, if sent through C it should have the
>> source addres of A, or that it should actually be sent through A
>> regardless of the routing table (which sounds better to me).
> 
> That doesn't make sense. There may be multiple next hops out A. If the
> next hop in the FIB is out C, how would the router pick the next hop
> to send to out A?

Back to the physical address that sent the TTL-offending packet.

> Anyway, Randy's comment was about source address selection, not
> routing. With the packet coming from S into interface A, he'd prefer
> that the ICMP error message be sourced from the IP address assigned to
> A, not the IP address assigned to C or R.

Thanks.

Re: rfc 1812 third party address on traceroute

[Marc Storck]

With BCP38 in mind, could therre be situations where Router R is not allowed to 
source packets with address A out of intergace C?

I think that the possibility does exist.

E.g. If interface A and C are upstream interfaces, router R may use an IP 
address from ISP A on interface A and an address from ISP C on interface C.

Obviously BCP38 is not widely deployed but yet...

Regards,

Marc

> On 31 mai 2016, at 07:05, Randy Bush  wrote:
> 
> rfc1812 says
> 
>   4.3.2.4 ICMP Message Source Address
> 
>   Except where this document specifies otherwise, the IP source address
>   in an ICMP message originated by the router MUST be one of the IP
>   addresses associated with the physical interface over which the ICMP
>   message is transmitted.  If the interface has no IP addresses
>   associated with it, the router's router-id (see Section [5.2.5]) is
>   used instead.
> 
> some folk have interpreted this to mean that, if a router R has three
> interfaces
> 
>   .-.
>   | |
>   |   B |- D
>S -| A  R|
>   |   C |- (toward S)
>   | |
>   `-'
> 
> if the source of a traceroute from S toward D with TTL to expire on R,
> and R's FIB wants to exit via C to get back to S (yes, virginia, the
> internet is highly asymmetric), the source address of the time exceeded
> message should be C.
> 
> of course, simpletons such as i would desire the source of the time
> exceeded message to be A.  after all, this is the interface to which i
> sent the icmp with the TTL to expire.
> 
> ras's preso,
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
> page 10 illustrates this issue with rfc1812
> 
> cursory research and talking with C & J seem to indicate that they do
> what i want not what some folk have interpreted 1812 to mean.  at least
> on some models.
> 
> is anyone seeing the dreaded rfc1812 behavior in a citable fashion?  how
> common is it?
> 
> randy

AW: Verizon and Level3 DNS flush

[Jürgen Jaritsch]

Hi Mike,

thanks for your (not so useful :)) answer ... I'm aware of things like TTL etc 
... but the situation is that customer is receiving ~130gbit of DNS reflection 
attack to their original DNS and that's the reason why we had to move over to a 
new NS set.

I'm not allowed to tell you the customers and/or project name but I guess many 
of you know them ... if you're reading Twitter or reddit you've probably 
recognized which global service is broken at the moment ...

Best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jjarit...@anexia-it.com 
Web: http://www.anexia-it.com 

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: NANOG [mailto:nanog-boun...@nanog.org] Im Auftrag von Mike
Gesendet: Mittwoch, 01. Juni 2016 20:17
An: nanog@nanog.org
Betreff: Re: Verizon and Level3 DNS flush



On 06/01/2016 10:59 AM, Jürgen Jaritsch wrote:
> Dear NANOGers,
>
> is there anyone from Verizon and Level3 who can help me with DNS caching 
> issue? We're running a global service for a customer and we had to change to 
> NS IPs via Glue Records. At the moment at least Verizone and Level3 are 
> caching old NS records. Looking for DNS admins out there.
>
>
> Please contact me off- or on-list!
>

I totally understand the desire to just be able to go ask major 
operators for a courtesy cache flush, but there are ways to update dns 
and procedures to engage that can eliminate the underlaying causes of 
same. Not that everyone, including myself, is prefect or godly (or has 
their name in the rfc...!), but at the same time, it's a learning 
experience being offered to you and I hope that whatever hole you shot 
in your foot heals soon and hopefull you never have to make another one 
like it.

Mike-

Re: Tracking traffic usage at router or switch port?

[Mark Tinka]

On 1/Jun/16 19:58, Jason Lee wrote:

> NANOG Community,
>
> Typically where would you expect a service provider to monitor bandwidth
> usage on your circuits? On the physical switch port interface or on the
> vlan interface at the router? In some of the field testing I've been doing
> there can be a difference in the bandwidth usage on the vlan interface at
> the router vs the physical switch port. Is there any particular reason for
> using one vs the other? Is there an industry best practice for this?

We track both.

Mark.

Re: Verizon and Level3 DNS flush

[Mike]

On 06/01/2016 10:59 AM, Jürgen Jaritsch wrote:

Dear NANOGers,

is there anyone from Verizon and Level3 who can help me with DNS caching issue? 
We're running a global service for a customer and we had to change to NS IPs 
via Glue Records. At the moment at least Verizone and Level3 are caching old NS 
records. Looking for DNS admins out there.


Please contact me off- or on-list!



I totally understand the desire to just be able to go ask major 
operators for a courtesy cache flush, but there are ways to update dns 
and procedures to engage that can eliminate the underlaying causes of 
same. Not that everyone, including myself, is prefect or godly (or has 
their name in the rfc...!), but at the same time, it's a learning 
experience being offered to you and I hope that whatever hole you shot 
in your foot heals soon and hopefull you never have to make another one 
like it.


Mike-

Re: Tracking traffic usage at router or switch port?

[Mel Beckman]

The reason there can be a (small) difference between those two test points is 
encapsulation overhead. If the provider is counting traffic that is still in an 
MPLS envelope, it will count more bytes than it will after the traffic has been 
stripped down to just the Ethernet frame on the switch port. This isn’t a big 
deal for large packets, but for small packets, such as those used for streaming 
protocol (e.g., VoIP) the percentage of overhead can be as high as 15%.

 -mel

> On Jun 1, 2016, at 10:58 AM, Jason Lee  wrote:
> 
> NANOG Community,
> 
> Typically where would you expect a service provider to monitor bandwidth
> usage on your circuits? On the physical switch port interface or on the
> vlan interface at the router? In some of the field testing I've been doing
> there can be a difference in the bandwidth usage on the vlan interface at
> the router vs the physical switch port. Is there any particular reason for
> using one vs the other? Is there an industry best practice for this?
> 
> Thanks,
> 
> Jason

Re: Tracking traffic usage at router or switch port?

[Hugo Slabbert]

On Wed 2016-Jun-01 12:58:15 -0500, Jason Lee  wrote:


NANOG Community,

Typically where would you expect a service provider to monitor bandwidth
usage on your circuits? On the physical switch port interface or on the
vlan interface at the router? In some of the field testing I've been doing
there can be a difference in the bandwidth usage on the vlan interface at
the router vs the physical switch port. Is there any particular reason for
using one vs the other? Is there an industry best practice for this?


How big of a difference?  Full frame / L2 (@ switch) vs. L3 payload (@ 
router)?




Thanks,

Jason


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Tracking traffic usage at router or switch port?

[Spencer Ryan]

I would monitor it wherever you would do traffic shaping/policing. If that
happens on the CPE monitor it there. If the CPE is just all Layer2 back to
a router or whatever and the router is doing rate limiting monitor it
there. For circuits that run at wirespeed with no limits
(10/100/1000/10k/etc) the same logic applies, just monitor the bandwidth
where you would normally do the policing.


*Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Wed, Jun 1, 2016 at 1:58 PM, Jason Lee  wrote:

> NANOG Community,
>
> Typically where would you expect a service provider to monitor bandwidth
> usage on your circuits? On the physical switch port interface or on the
> vlan interface at the router? In some of the field testing I've been doing
> there can be a difference in the bandwidth usage on the vlan interface at
> the router vs the physical switch port. Is there any particular reason for
> using one vs the other? Is there an industry best practice for this?
>
> Thanks,
>
> Jason
>

Verizon and Level3 DNS flush

[Jürgen Jaritsch]

Dear NANOGers,

is there anyone from Verizon and Level3 who can help me with DNS caching issue? 
We're running a global service for a customer and we had to change to NS IPs 
via Glue Records. At the moment at least Verizone and Level3 are caching old NS 
records. Looking for DNS admins out there.


Please contact me off- or on-list!


Thanks & best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jjarit...@anexia-it.com
Web: http://www.anexia-it.com

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Tracking traffic usage at router or switch port?

[Jason Lee]

NANOG Community,

Typically where would you expect a service provider to monitor bandwidth
usage on your circuits? On the physical switch port interface or on the
vlan interface at the router? In some of the field testing I've been doing
there can be a difference in the bandwidth usage on the vlan interface at
the router vs the physical switch port. Is there any particular reason for
using one vs the other? Is there an industry best practice for this?

Thanks,

Jason

Re: Public DNS64

[Ca By]

On Monday, May 30, 2016, Ca By  wrote:

>
>
> On Monday, May 30, 2016, Baldur Norddahl  > wrote:
>
>> >
>> > Like HE is doing?
>> >
>> > swmike@uplift:~$ dig +short  ipv4.swm.pp.se @nat64.he.net
>> > 2001:470:64:::d4f7:c88f
>> > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f
>> > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data
>> bytes
>> > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms
>> > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
>> >
>> > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means
>> > the NAT64 isn't very local to me... :P
>>
>>
>>
>> It goes to the USA and back again. They would need NAT64 servers in every
>> region and then let the DNS64 service decide which one is close to you by
>> encoding the region information in the returned IPv6 address. Such as
>> 2001:470:64:[region number]::/96.
>>
>> An anycast solution would need a distributed NAT64 implementation, such
>> that the NAT64 servers could somehow synchronize state. A more simple
>> solution is just to have the DNS64 be anycast and have a DNS64 at each
>> NAT64 location with the DNS64 returning pointers to the local NAT64.
>>
>> Now, can we have a public MAP server? That might scale. The geo blockers
>> will hate it. What is not to like?
>>
>>
> MAP scale. I know folks think it is theoretically nice but
>
>
> Just curious, has anyone yet deployed MAP at scale? I know of several
> production and large scale nat64s (usually mobile 464xlat related), and a
> few large ds-lite, but never MAP in production at scale.  Maybe i am
> missing something.
>
> CB
>
>
Tore's email reminded me that we got  no answers about a production large
scale MAP deployment.  I guess it is yet to be deployed.

Since it came up 2x in this thread, not only is MAP apparently not deployed
anywhere at scale and therefore unproven in the real world, it would not
fit this public usecase. MAP requires dhcpv6 and that dhcpv6 server must
statefully / tight-coordination assign the addresses and ports to the end
user.  This complexity and requirement, along with the unsavoriness of yet
another tunnel made MAP a deal breaker for my network. It also statically
assigns s fixed number of scarce ipv4 ports to users, this is inefficient
and not flexible.

I suppose some party could launch a public dhpv6 server. But the 2nd hop
routing would not work without several hacks

CB


> Regards,
>>
>> Baldur
>>
>

Re: Public DNS64

[Tore Anderson]

* Mark Andrews

> In message <20160601103707.7de9d...@envy.e5.y.home>, Tore Anderson writes:
> > Or you could simply accept that active sessions are torn down
> > whenever the routing topology changes enough to flip traffic to the
> > anycast prefix to another NAT64 instance in a different region.
> > 
> > It would be no different from any other anycasted service.  
> 
> But some services are inherently short lived.  NAT64 has no such
> property.

Well, yes - it depends on the service/application, right?

That is, anycasted_${service} will work pretty much the same as
${service}_via_anycasted_nat64 for most values of ${service}.

Assuming that:

1) most of your customer's sessions are short-lived and/or their
applications can handle failures reasonably gracefully, and/or
2) you have a stable and well-designed network where you can be
reasonably certain that the traffic from clients in city/region/country
X is going to consistently be routed to the NAT64 instance in
city/region/country X:

...you will have very little to gain by setting up some complicated
NAT64 session replication scheme to city/region/country Y, Z, and so on.

KISS: Just use different IPv4 source address pools in each location and
accept that any long-lived sessions are interrupted when your routing
turns really wonky once in a blue moon.

If on the other hand you cannot under any circumstance accept
disruption to existing sessions, you probably don't want to be using
any form of NAT in the first place. It's not like anycast routes
flipping is the only reason why sessions through a NAT can be
disrupted.

In that case, native IPv6 is probably better, or possibly MAP if you
have no control over the (presumably IPv4-only) remote ends of those
sessions.

Tore

Re: Public DNS64

[Mark Andrews]

In message <20160601103707.7de9d...@envy.e5.y.home>, Tore Anderson writes:
> * Baldur Norddahl
> 
> > It goes to the USA and back again. They would need NAT64 servers in
> > every region and then let the DNS64 service decide which one is close
> > to you by encoding the region information in the returned IPv6
> > address. Such as 2001:470:64:[region number]::/96.
> > 
> > An anycast solution would need a distributed NAT64 implementation,
> > such that the NAT64 servers could somehow synchronize state.
> 
> Or you could simply accept that active sessions are torn down whenever
> the routing topology changes enough to flip traffic to the anycast
> prefix to another NAT64 instance in a different region.
> 
> It would be no different from any other anycasted service.

But some services are inherently short lived.  NAT64 has no such
property.
 
> Tore
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP License in the USA?

[Jon Sands]

He might have meant one of these:

Consultants
Often
Adlib
License
Specifications

Re: PeeringDB ?

[Marty Strong via NANOG]

More issues? :(

Regards,
Marty Strong
--
CloudFlare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

http://www.peeringdb.com/view.php?asn=13335

> On 24 May 2016, at 12:43, Job Snijders  wrote:
> 
> On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote:
>> Whats happened today at PeeringDB web site ?
> 
> And PeeringDB is back in business! 
> http://instituut.net/~job/screenshots/2f255c17a8aa9cb99121b448.png
> 
> A post-mortem will be shared on the pdb-tech@ list later today.
> 
> Kind regards,
> 
> Job

Re: Public DNS64

[Tore Anderson]

* Baldur Norddahl

> It goes to the USA and back again. They would need NAT64 servers in
> every region and then let the DNS64 service decide which one is close
> to you by encoding the region information in the returned IPv6
> address. Such as 2001:470:64:[region number]::/96.
> 
> An anycast solution would need a distributed NAT64 implementation,
> such that the NAT64 servers could somehow synchronize state.

Or you could simply accept that active sessions are torn down whenever
the routing topology changes enough to flip traffic to the anycast
prefix to another NAT64 instance in a different region.

It would be no different from any other anycasted service.

Tore