Verizon business internet contact needed

[Chuck Church]

Hey all, if any Verizon engineer could hit me up offline about a ticket
we've had, it would be appreciated.  We've got a site in Illinois that has a
new circuit, works well to Verizon speedtest, but poor elsewhere, including
our SD-WAN destinations.  I'm curious if UDP/2426 gets any unusual treatment
on your backbone, etc.

 

Thanks,

 

Chuck

RE: Standard DC rack rail distance, front to back question

[Chuck Church]

Hey all, sorry I did mean to say ASR1001 (an X model to be exact).  The 4 post 
mounting they show in a hardware mounting doc uses front and back ears, which 
I’ve never done:
https://www.cisco.com/c/en/us/td/docs/routers/asr1000/install/guide/asr1routers/asr-1000-series-hig/asr-hig-1001.html#task_1205646
see figure 16 slightly down from there.  

I do see some generic rails from TrippLite that probably would work, as well as 
shelves.   I was hoping a standard depth that most vendors honored for 4 post 
existed, but it doesn’t seem likely.  We’ll have a variety of PaloAlto, Cisco, 
Checkpoint, and others co-habiting.

 

Chuck

 

From: NANOG  On Behalf Of Mark 
Stevens
Sent: Thursday, April 27, 2023 11:17 AM
To: nanog@nanog.org
Subject: Re: Standard DC rack rail distance, front to back question

 

Lucky you with a 19" data rack. All I have are 23" telco racks but I will say, 
the 23" extension ears from Cisco are serious and my router chassis' don't sag.

Mark

On 4/27/2023 10:04 AM, Chris Marget wrote:

 

On Thu, Apr 27, 2023 at 9:53 AM Chuck Church mailto:chuckchu...@gmail.com> > wrote:

for a Cisco ASA1001, there aren’t rails, but rather front and back ‘ears’ you 
use to hit both front and back posts.

 

Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my 
experience with these boxes is that they have a single pair of ears which can 
be mounted front OR back.

The heavier / deeper 1RU devices do tend to sag alarmingly.

 

 Is there a ‘standard’ distance between front and back rails that devices 
usually adhere to?

 

If you're thinking of setting the front/back distance to accommodate a specific 
device, table 2 might be of some interest:

https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/rail-rack-matrix.pdf

 

 

Standard DC rack rail distance, front to back question

[Chuck Church]

Hey all.  Question about standard 4 post racks.  We bought some that are
adjustable.  Unfortunately, the posts are very flimsy, as these are some
fancy cabinets with spacing on the sides for vertical patch panels, etc.  We
found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU
switches) are sagging quite bad.   We're used to the new server type rails
that extend to support most reasonable distances front rails to back for 4
post mounting.  However, for a Cisco ASA1001, there aren't rails, but rather
front and back 'ears' you use to hit both front and back posts.  These would
appear to not have any adjustability, the front to back post distance would
seem to need to match the ears, I assume they don't adjust placement on the
router much.  Is there a 'standard' distance between front and back rails
that devices usually adhere to?  Googling didn't find an answer readily.
These are 19" wide cabinets by the way.  

 

Thanks,

 

Chuck

Cogent help needed

[Chuck Church]

Can anyone from Cogent hit me up off-list?  Having an issue in South America
getting packets to our site in Brazil.  Traceroute shows route though a
Cogent router, then RFC1918 replies.  So not sure if problem is Cogent or a
peer of theirs.  Two hosts in the 177.10.168.124/30 are acting differently.

 

Thanks,

 

Chuck

Google location question

[Chuck Church]

NANOG,

 

Sorry if this is the wrong forum, but I figured we could all
use a distraction from IPV4 expansion for a bit.  We're facing a problem
with corporate use of browsers and google location services.  Our users
across North and South America seem to be getting location info for Rio de
Janeiro, BR as of the last few days.  All of our users when browsing hit
general internet via a NAT pool for IPs out of Atlanta, GA.  That hasn't
changed in over a year.  The IP space itself and the upstream routers PTR
haven't changed for longer than that.

For a normal laptop without a GPS chip and using default
settings, it would seem that something else must be informing google of
location.  We've had a few theories.  I discovered our Cisco wireless in RIO
office is broadcasting SSID.  The same SSID name we use in all offices.  But
I believe that google uses BSSID which is MAC based.  And would be different
between sites, as each have their own wireless controller, and certainly
different APs.  At least that's what I believe to be true, that google
didn't associate our standard SSID name with a physical location.

I'm curious if anyone has ever dealt with this before.  I
don't want to blame our workstation folks for something that might be a
geolocation issue, either based on wi-fi being detected, or a messed up
geolocation for our IP space.  Is there any place in Google-land where you
can see exactly why it thinks you're in a given location?  I did see some
articles on API usage to view values, but nothing that shows you the process
when it takes all variables into effect.

 

Thanks,

 

Chuck

Google Nest camera contact request

[Chuck Church]

If anyone has access to a Google Nest engineer could you pass their info to
me offline?  Going through tech support didn't get me anywhere.  We're
seeing that their cameras and the cloud servers they home back to
(oculus-xxx.dropcam.com) are using TLS 1.0 and no server name in the certs,
which our firewalls are dropping and our security folks are reluctant to
relax rules to make work.  Hoping for a status on when modern security
communications might be used on these.

 

Thanks,

 

Chuck

RE: Wildfires: Reminder smart devices don't include emergency warnings while streaming

[Chuck Church]

Isn’t this a better topic for CNet as opposed to NANOG?

 

Chuck

 

From: NANOG  On Behalf Of 
ITechGeek
Sent: Friday, September 11, 2020 4:12 PM
To: nanog@nanog.org
Subject: Re: Wildfires: Reminder smart devices don't include emergency warnings 
while streaming

 

At least cell phones have a reliable way to know where they are at any given 
moment.  Would you really trust providers sending out emergency notifications 
based on something like GeoIP or based on the zipcode on the account?

 

---

-ITG (ITechGeek)  |  i...@itechgeek.com  

i...@secure.itg.nu   (Protonmail) (Fingerprint: 
7d1a160f)

https://keybase.io/itechgeek  |  https://itg.nu/

Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: 
http://fb.me/Jbwa.Net

 

 

On Fri, Sep 11, 2020 at 3:49 PM Sean Donelan mailto:s...@donelan.com> > wrote:

On Fri, 11 Sep 2020, William Herrin wrote:
> tl;dr: keep your cell phone on and with you 'cause only a few things
> get emergency alerts and only when they're turned on.

You sound like the CTIA in the 2000s when it was opposed to requiring 
emergency alerts on cell phones.  "Its unnecessary to require cell phones 
have emergency alerts, because people get emergency alerts other ways."

The problem was all the consumer electronic industry groups always point 
at "someone else."  The cable industry said it was unnecessary in the 
1980s because local TV stations had emergency alerts.  The TV industry 
said it was unnecessary in the 1970s because local radio stations had 
emergency alerts.  Etc. etc. etc.

The reason your cell phone has emergency alerts, is the FCC required them.

Re: An appeal for more bandwidth to the Internet Archive

[Chuck Church]

You mean not everyone still looks up the classifications on
mulletsgalore.com?

Chuck

On Wed, May 13, 2020, 7:54 PM Valdis Klētnieks 
wrote:

> On Wed, 13 May 2020 10:40:36 +0300, Denys Fedoryshchenko said:
> > What about introducing some cache offloading, like CDN doing? (Google,
> > Facebook, Netflix, Akamai, etc)
> > I think it can be rolled pretty quickly, with minimum labor efforts, at
> > least for heavy content.
>
> The thing is that if you're an 800 pound gorilla, you probably have enough
> things that would benefit from being cached to make it worthwhile.
>
> I'd expect that the Internet Archive is probably mostly long-tail hits
> with not
> much hot content.  Has anybody modeled how much cache space would it take
> to
> significantly improve the bandwidth situation?
>
>

Re: California public safety power shutdowns

[Chuck Church]

Isn't this a topic for an outage list?  Or a power grid list?

Chuck


On Wed, Oct 9, 2019, 5:28 PM Sean Donelan  wrote:

> On Wed, 9 Oct 2019, William Herrin wrote:
> > Wasn't California in a similar mess 20 years ago when government
> regulation
> > at the time also put PG in the position that they couldn't deliver the
> > electricity their customers wanted? Something to do with hard limits on
> what
> > PG could do but few limits on what third parties could do to it.
>
> Yep, Enron (allegedly) used the California electric grid deregulation
> rules to arbitrage the system by causing false grid shortages and driving
> up wholesale electric prices.
>
> It caused rolling blackouts throughout the CA ISO region in 2000 and 2001.
>
>
> https://www.nytimes.com/2005/02/04/us/tapes-show-enron-arranged-plant-shutdown.html
>
>

RE: Routing issues to AWS environment.

[Chuck Church]

Are you sure the problem isn’t NTT?  My buddy’s WISP peers with Spirit and had 
a boatload of problems with random packet loss affecting initially just SIP and 
RTP (both UDP).  Spirit was blaming NTT.  Problems went away when Spirit 
stopped peering with NTT yesterday.  Path is through Telia now to their main 
SIP trunk provider.

 

chuck

 

From: NANOG  On Behalf Of Curt Rice
Sent: Wednesday, May 08, 2019 10:56 AM
To: nanog@nanog.org
Subject: Routing issues to AWS environment.

 

Hi are there any AWS engineers out there? We are seeing routing problems 
between NTT and AWS in Ashburn, Va and would like to find out which side is 
having the problem.

 

Thanks,

Curt

Re: Stupid Question maybe?

[Chuck Church]

When I first started working with Cisco products (around 1999) I came upon
a router doing NAT for internet access that used a discontiguous mask to
determine which address to PAT the hosts against as they were doing some
creative load balancing.  It worked really well, no matter what part of the
'block' the DHCP server gave inside addresses out to.  I was stumped for
the longest time trying to figure out what this did.

Chuck

On Mon, Dec 24, 2018 at 3:11 PM Tony Finch  wrote:

>
> On 18 Dec 2018, at 22:30, Joel Halpern  wrote:
>
> History of non-contiguous network masks, as I observed it. [snip]
>
> When we were done, other folks looked at the work (I don't know if the
> Internet Drafts are still in repositories, but they shoudl be.)  And
> concluded that while this would work, no network operations staff would
> ever be able to do it correctly.  So as a community we decided not to go
> down that path.
>
>
> In the late 1990s I was doing web server things at Demon Internet. Our
> “Homepages” service provided an IP-based virtual host for each customer (it
> predated widespread support for HTTP Host: headers), and by the time I
> joined the service had two /18s and a /16 of web sites (if my memory is
> correct). We were allocating addresses to customers sequentially, so the
> /18s were full and the /16 was in progress.
>
> We had a small number of front-end Squid reverse proxy caches which owned
> all the IP addresses, using a BSD kernel hack (which I worked on to get
> published but it never got committed upstream
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071)
>
> The problem was that the entirely static load spreading relied on the
> routing config upstream from the reverse proxies, and IIRC it just divided
> the space into /18s and allocated them to proxies. So the load allocation
> was very uneven.
>
> I thought up a cunning hack, to divide the /16 by using a non-contiguous
> netmask of 0x0003 instead of 0xc000, so that successive customers
> would be allocated to front ends 0,1,2,3 cyclically. Fun :-)
>
> But I observed that one of my colleagues had a CIDR chart stuck on the
> side of his monitor, and that all the documentation in this area warned of
> dragons and bugs, and I realised that it would be unwise to do more than
> try it out experimentally :-)
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at
>

RE: Cheap switch with a couple 100G

[Chuck Church]

Under 1K for 48 10G ports?  Are you missing a decimal place?

Chuck

-Original Message-
From: NANOG  On Behalf Of Mike Hammett
Sent: Sunday, November 25, 2018 9:39 AM
To: 'North American Network Operators' Group' 
Subject: Cheap switch with a couple 100G

I keep hearing how cheap 100G is compared to 40G and it doesn't seem to hold 
true. Prove me wrong.

Cisco Nexus and Arista both have switches with 48x 10G ports and 2x - 6x 40G 
ports for under $1k. Swap those 40G for 100G and you're at $5k - $7k.

Am I missing some cheap switches with 100G?


I ask this because the transport companies seem to have given up on 40G.


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

RE: Anyone else having Tunnelbroker.net issues?

[Chuck Church]

I've had problems with my Synology router and tunnel broker for several
days.  Used to work, config didn't change, assigned IPv4 address for me
didn't change, but acting flakey, not much debugging capability on Synology
I can find to figure it out.  

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brielle Bruns
Sent: Wednesday, February 21, 2018 1:58 PM
To: NANOG list 
Subject: Anyone else having Tunnelbroker.net issues?

Hi all,

I hate asking this on the list, but is anyone else having issues with HE and
Tunnelbroker.net currently?

Isitdownrightnow.com seems to support the notion there is something going on
with it, and tests from my various VMs on DigitalOcean in various DCs seem
to support the notion.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

RE: Any experience with Broadcom ICOS out there?

[Chuck Church]

I smell some BS here, at least in their 'Verified Purchase' reviews:

"It is installed as a network hub in my basement and it is working fine. Great 
quality product. I've had a lot of business with FS for years. This is a very 
reliable company and they stand behind their company's products with a first 
class warranty! I highly recommend."

"It just takes several days to receive my 100G switch with Broadcom ICOS which 
is packaged safely and intactly. I followed the instruction and seems simple 
for a non-tech user. Three steps would be done: plug it in, cable it up, turn 
it on. Just the way a good product should be. I would like to recommend both 
the product and the seller."


Non tech user, network hub in my basement.  $10K L3 switch.  Jesus.  The 
Tactical Flashlight seems more believable right now.

Chuck.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Kuhnke
Sent: Friday, January 05, 2018 4:55 PM
To: Bryan Holloway ; nanog@nanog.org list 
Subject: Re: Any experience with Broadcom ICOS out there?

You may have better results with the same question on OCP (open compute
platform) related forums and mailing lists. The Quanta version of that switch 
sold by FS is pretty much the same thing:

https://linustechtips.com/main/topic/801037-qct-reveals-their-quantamesh-network-switches/

Quanta has been very active in the OCP community for whitebox switches. I have 
heard that they are the switch manufacturer for a great deal of Facebook's 
hyperscale stuff.



On Fri, Jan 5, 2018 at 1:46 PM, Bryan Holloway  wrote:

> Thank you everyone for the responses so far; I should probably 
> re-phrase the question at this point ...
>
> Has anyone had production experience with Broadcom ICOS and the 
> features it claims to support? Positive or negative?
>
>
> On 1/5/18 2:46 PM, joel jaeggli wrote:
>
>>
>>
>> On 1/5/18 10:50 AM, Bryan Holloway wrote:
>>
>>> Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm 
>>> curious if anyone in the community has any thoughts or real-life 
>>> world experience with them.
>>>
>>> E.g.: https://www.fs.com/products/69340.html
>>>
>>> For the price point, it's almost in the "too good to be true" category.
>>>
>> The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. 
>> so it's consistent with a low value add reseller of merchant silicon. 
>> that silicon is getting older (tomahawk 3 was announced in 
>> anticipation of 2018) so we can presume they are getting cheaper. I 
>> generally have a favorable experience of FS but then I buy optics and 
>> cables, not switches so your mileage may vary.
>>
>> Naturally it claims to support an impressive range of features 
>> including
>>> BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah.
>>>
>> The software stack is Broadcom ICOS. if you're not familiar with that 
>> I start looking at that. if it meets you needs that's cool. if not 
>> you might be looking at cumulus or onos. That said Broadcom does 
>> enough to get their customers (whitebox odms) out the door, not 
>> necessarily the customers of those odms so your recourse to a 
>> developer is kind of limited which you get a from a vendor more 
>> involved in the software stack. A lot of those choices here depend on 
>> how responsible you want to be for what's running inside the box.
>>
>>> There was an earlier discussion about packet buffer issues, but, 
>>> assuming for a second that it's not an issue,
>>>
>> It can be avoided, but for people used to running all 10Gb/s 
>> cut-through trident 2s kind of hot, some of consequences are kind of 
>> impressive. 4 much smaller buffers and the virtual assurance that 
>> you'll be doing rate conversion eats into the forwarding budget.
>>
>>> can anyone say they've used these and/or the L2/L3 features that 
>>> they purportedly support?
>>>
>>> Thanks!
>>> - bryan
>>>
>>>
>>

RE: Waste will kill ipv6 too

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ricky Beam
Sent: Thursday, December 28, 2017 9:55 PM
To: Owen DeLong 
Cc: NANOG list 
Subject: Re: Waste will kill ipv6 too

>Every scenario everyone has come up with is "unlikely". Home networks with 
>multiple LANs??? Never going to happen; people don't know how to set them up, 
>and there's little technical need for it.

I couldn't agree more.  We're spending so much time with new RFCs to handle all 
these prefix delegation ways in order to accommodate 'power users' who are used 
to chaining one NATing IPv4 router off of another one and having it sort of 
work.  If we'd just put a stake in the ground and say residences can have one 
router and bridge everything below that we'd be further ahead.  I just can't 
see 99.999% of users being interested in subnetting their homes and writing 
firewall rules so their light bulbs can't talking to their DVRs.

Chuck

RE: Purchased IPv4 Woes

[Chuck Church]

Maybe a silly idea, but shouldn't the sale of a block of addresses (RIR 
ownership change) trigger a removal of that block from all reputation list 
databases?  If I buy a car from a police auction, I'm fairly sure the FBI 
doesn't start tailing me, because the car was once used for less than legal 
purposes.  New owner, clean slate.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Justin Wilson
Sent: Sunday, March 12, 2017 10:51 AM
To: NANOG 
Subject: Re: Purchased IPv4 Woes

I am interested in what broker you used as well.  We have used a few that do a 
little due diligence on their end, but we still do our own.   We have seen an 
auction pulled due to the space having a bad reputation, but we were the ones 
who had to step up and say something.  


Justin Wilson
j...@mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting – Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman
Internet Exchange - Peering - Distributed Fabric

> On Mar 10, 2017, at 12:00 PM, Pete Baldwin  wrote:
> 
> Hi All,
> 
>Hopefully this is not taken in bad taste.   Our organization purchased 
> some IP space last year (163.182.192.0/18 to be specific), and it appears 
> that this block must have been used for less-than-admirable purposes in the 
> past.
> 
> We have been trying to clean up the reputation where possible, and we do not 
> appear to be on any blacklists, but we do appear to be blocked from a lot of 
> networks across the US/Canada.I am noticing a lot of name servers 
> blocking our requests, many web servers, gaming servers, mail etc.
> 
> This is a transition block for us to move towards v6 everywhere, but we have 
> many systems that will need to rely on this block of space for some time to 
> come.
> 
> We are a small rural co-op ISP in Ontario, and I am just writing this email 
> as an extra plea so that if you happen to run a network that has this entire 
> range on your naughty list, we would appreciate you giving it another chance. 
>  I can be contacted on or off list, thanks.
> 
> 
> -- 
> 
> 
> -
> 
> Pete Baldwin
> Tuckersmith Communications
> (P) 519-565-2400
> (C) 519-441-7383
> 

RE: Someone didn't get the leap second memo...

[Chuck Church]

That bug note indicates all 3.13.* are vulnerable to this, but our 3.13.3 lab 
router seemed ok, no reload.  Logged:

Dec 31 23:59:59: %IOSXE-5-PLATFORM: R0/0: kernel: Clock: inserting leap second 
23:59:60 UTC

But the release notes seem to indicate that bugs:
CSCut82336  ASR1002-X: Handle leap second in ToD IN
CSCut65374 PTP Leap Second: ASR1002-X incorporate leap second addition 
6/30/15

are open caveats in 3.13.3, and resolved in 3.13.4.   I guess I'll find out 
which of our 300+ ASR 1000s misbehaved on Tuesday.  They're pretty much all on 
3.13.5.  Hopefully none had an issue.  There are a lot of PSIRTs with ASRs, 
that's the main reason we're on later 3.13 versions.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Richard Hicks
Sent: Saturday, December 31, 2016 9:17 PM
To: Hugo Slabbert 
Cc: nanog@nanog.org
Subject: Re: Someone didn't get the leap second memo...

We had some ASR1001s routers reboot.

Looks like we hit this bug:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb01730


On Sat, Dec 31, 2016 at 5:47 PM, Hugo Slabbert  wrote:

> Had a set of Cisco ASR1004s running 15.4(3)S1 (on IOS-XE 03.13.01.S) 
> all restart at around midnight UTC, and all with `Last reload reason:
> Watchdog`, with those boxes being at separate DCs in different regions.
> I'm assuming when I call TAC I'll get a "whoops; sorry".
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>
>
> On Sun 2017-Jan-01 01:02:24 +, Matthew Huff  wrote:
>
> [root@hayden ~]# ntpq -p
>> remote   refid  st t when poll reach   delay   offset
>> jitter
>> 
>> ==
>> LOCAL(0).LOCL.  10 l  20d   6400.0000.000
>>  0.000
>> -clock.xmission. 132.163.4.103 2 u  169  256  377   66.078   -1.302
>>  0.164
>> xclock.sjc.he.ne 10.200.208.2 2 u   13  256  315   65.689  999.633
>>  2.015
>> +tock.usshc.com  .GPS.1 u   87 256 377 26.930   -0.550
>>  0.121
>> *ntp.your.org.CDMA.   1 u   43 256 217 23.3390.544
>>  0.069
>>
>> Our batch system went belly up, but other than that, no other 
>> apparent leap second issues.
>>
>> 
>> Matthew Huff | 1 Manhattanville Rd
>> Director of Operations   | Purchase, NY 10577
>> OTA Management LLC   | Phone: 914-460-4039
>> aim: matthewbhuff| Fax:   914-694-5669
>>
>>
>>

RE: IX in Iran by TIC

[Chuck Church]

Foul language is frowned upon.

https://www.nanog.org/list

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of James Bensley
Sent: Wednesday, July 13, 2016 4:24 AM
To: nanog 
Subject: Re: IX in Iran by TIC

On 12 July 2016 at 14:36, Bevan Slattery  wrote:
> EXAMPLE 1.
> There maybe for example an enterprise  that is looking for a service 
> provider in a facility (XYZ in NY for example) but that provider 
> actually "peers" their transit routers at the ABC facility down the 
> street.  Because the provider doesn't peer in XYZ there is no public 
> record of them being there in peering DB.  Providers are in heaps of 
> DC's/locations that they just don't peer.  So they effectively have no 
> central location where people can see that they are "available to 
> service".  This is more of a directory of where providers are and what 
> services they can provide.

Hmm, so maybe I'm just a maverick, we are not using any public peering fabrics 
at minute due to what can only be described as a senior management cluster 
foook [1], so on peeringdb we list some pops that we are in that we are willing 
(and do) have private peering sessions in. It doesn't say on peeringdb that 
there are IX's in some of these PoPs but hopefully when we need to establish a 
private interconnect with someone they will see we are in the same PoP as them 
even though there is no IX in that PoP and put 2 and 2 together, and contact us 
to discuss a cross connect.

For the avoidance of doubt, I'm not trying to poo poo the site, just trying to 
work out where the different is feature set lies exactly.


Cheers,
James.


[1] Is this a list for adults or children, my original email bounced back 
because I used the work f*ck?

RE: Netflix banning HE tunnels

[Chuck Church]

Well, they have to power to push out net neutrality.  This intentional blocking 
of tunneling customers because their crap method of geo-location can't be used 
and thus hinders advancement of the internet (IPv6) is something that should 
disallowed.  Or a good candidate for class action suit.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks
Sent: Friday, June 10, 2016 5:55 PM
To: nanog@nanog.org
Subject: RE: Netflix banning HE tunnels




--- chuckchu...@gmail.com wrote:
From: "Chuck Church" <chuckchu...@gmail.com>

The true jerks who used HE to bypass geo-lockout probably changed to something 
else the next day.  
But we suffer still.  The FCC or some other federal entity probably needs to 
step in.
--


Yeah, because the US federal government does such a great job fixing problems 
like this...

scott

RE: Netflix banning HE tunnels

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Elvis Daniel Velea
Sent: Tuesday, June 07, 2016 6:36 PM
To: nanog@nanog.org
Subject: Re: Netflix banning HE tunnels

Netflix, YOU are the ones forcing people to turn IPv4 off... this is just 
insane. tens (if not hundred) of thousands of people chose to use HE tunnels 
because their ISP does not offer IPv6..
do you really expect all of them to turn it off? do you really want IPv6 usage 
in the world to go down by a few percent because you are unable to figure out 
how to serve content?
--
I hate to say it, but I'm willing to bet that for every one person who setup an 
HE tunnel to get functional IPv6 ahead of native via ISP, there are probably 10 
who set it up solely to get around geo-lockout.  Honestly though, is there any 
reason the Netflix 'client' as part of its login can't be queried for an IPv4 
address if Netflix sees (or thinks) a tunnel is involved?  If there is a tunnel 
involved, you most likely have IPv4 access on the client.  Then do a geo-lookup 
on the IPv4.  I guess the ~500 people on NANOG using HE to get to NetFlix could 
all cancel their subscriptions, but that's just a drop of water in the bucket.  
It sucks.  The true jerks who used HE to bypass geo-lockout probably changed to 
something else the next day.  But we suffer still.  The FCC or some other 
federal entity probably needs to step in.

Chuck

RE: Cost-effectivenesss of highly-accurate clocks for NTP

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Leo Bicknell
Sent: Monday, May 16, 2016 10:28 AM
To: nanog@nanog.org
Subject: Re: Cost-effectivenesss of highly-accurate clocks for NTP

>For a typical site, there are two distinct desires from the same NTP
process.

>First, synchronization with the rest of the world, which is generally over
the WAN and the topic that was well discussed in your post.
>I agree completely that the largest factor is WAN jitter.

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

I was just thing about this WAN jitter issue myself.  I'm wondering how many
folks put NTP traffic in priority queues?  At least for devices in your
managed IP ranges.  Seems like that would improve jitter.  Would like to
hear about others doing this successfully prior to suggesting it for our
network.

Chuck

RE: NIST NTP servers

[Chuck Church]

-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Leo Bicknell
>Sent: Wednesday, May 11, 2016 9:31 AM
>To: nanog@nanog.org
>Subject: Re: NIST NTP servers

>Personally, my network gets NTP from 14 stratum 1 sources right now.
>You, and the hacker, do not know which ones.  You have to guess at least
>8 to get me to move to your "hacked" time.  Good luck.

>Redundancy is the solution, not a new single point of failure.  GPS can be 
>part of the redundancy, not a sole solution.

This seems like the most reasonable advise.  If this truly becomes a concern, I 
would think IPS vendors could implement signatures to look for bad time.  Lots 
of ways to do this 
- look for a difference between the IPS realtime and NTP status versus the 
incoming packets.
- look for duplicate NTP responses, or responses that weren't requested 
- duplicate responses, but with differing TTLs, which might hint at one being 
spoofed.

Chuck

RE: NIST NTP servers

[Chuck Church]

-Original Message-
From: Gary E. Miller [mailto:g...@rellim.com] 
Sent: Tuesday, May 10, 2016 3:58 PM
To: Chuck Church <chuckchu...@gmail.com>
Cc: 'Majdi S. Abbas' <m...@latt.net>; nanog@nanog.org
Subject: Re: NIST NTP servers

Yo Chuck!

On Tue, 10 May 2016 10:29:35 -0400
"Chuck Church" <chuckchu...@gmail.com> wrote:

> Changing time on
> devices is more an annoyance than anything, and doesn't necessarily 
> get you into a device.

So, you are not worried about getting DoS'ed?

How about you set the time on your server ahead by 5 years.  Got any idea
what would happen?

Most of your passwords would expire.

All your SSL certs would expire.

All your TOTPs, like Google Authenticator would fail.

All your IPSEC tunnels would drop, and refuse to restart.

Many of your cron jobs would got nuts, possibly deleting all your logs.

Much of your DNSSEC would expire.

Many of your backups would be deleted since they 'expired'.

Until recently, setting your iPhone to 1 Jan 1970 would brick it.

I'm sure there are many more examples, but likely you can no longer log in,
via SSH or HTTPS, and your iPhone is dead.  I think any of those would
qualify as more than an annoyance.

RGDS
GARY



Ok, annoyance might have been a little light on the severity wording.
Still, modifying all your incoming NTP packets from all your sources to
actually get your NTP servers to agree on a bad time is tricky.  That is
assuming you've got multiple links, multiple sources from multiple
organizations (more than 4), they're all authenticated, etc.  Even if a
criminal was to do all that damage you listed, it still probably doesn't
result in obtaining sensitive data or money that would be the main
motivators for such extreme hacking.   If I had an iPhone, perhaps I'd worry
about that as well.  But fortunately, not an issue ;)

Chuck

RE: NIST NTP servers

[Chuck Church]

True, but I did mention verifying packet sources.  That needs to happen 
everywhere, and it's not hard to do.  Just getting everyone to do it is tough.

Chuck

-Original Message-
From: Allan Liska [mailto:al...@allan.org] 
Sent: Tuesday, May 10, 2016 10:40 AM
To: Chuck Church <chuckchu...@gmail.com>; 'Majdi S. Abbas' <m...@latt.net>; 
nanog@nanog.org
Subject: RE: NIST NTP servers



On 5/10/2016 at 10:30 AM, "Chuck Church" <chuckchu...@gmail.com> wrote:

>
>It doesn't really.  Granted there are a lot of CVEs coming out for NTP 
>the last year or so.  But I just don't think there are that many 
>attacks on it.
>It's just not worth the effort.  Changing time on devices is more an 
>annoyance than anything, and doesn't necessarily get you into a device.
>Sure you can hide your tracks a little by altering time in logs and 
>altering it back, but that's more of an in-depth nation-state kind of 
>attack, not going to be a script kiddie kind of thing.  Just follow the 
>best practices for verifying packet sources and NTP security itself, 
>and you should be ok.
>
>Chuck

I would argue that the fact the NTP can, and has been, be used in DDoS 
amplification attacks is a serious concern for using protocol going forward.



allan

RE: NIST NTP servers

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Majdi S. Abbas

>   So how does this stop from distributing time to their customers via
NTP?
>   GPS doesn't save the protocol, in particular where the S1 clocks
involved are embedded devices with rather coarse clocks and timestamping.
>   --msa

It doesn't really.  Granted there are a lot of CVEs coming out for NTP the
last year or so.  But I just don't think there are that many attacks on it.
It's just not worth the effort.  Changing time on devices is more an
annoyance than anything, and doesn't necessarily get you into a device.
Sure you can hide your tracks a little by altering time in logs and altering
it back, but that's more of an in-depth nation-state kind of attack, not
going to be a script kiddie kind of thing.  Just follow the best practices
for verifying packet sources and NTP security itself, and you should be ok.

Chuck

RE: BGP peering strategies for smaller routers

[Chuck Church]

--
Hi Nick,

>You missed the point. Sloppy memory management is a "canary in a coal mine." 
>It's a user-visible symptom that reflects poor code quality underneath. 
>Programmers who >don't care how much ram they're consuming are the same fools 
>who catch and then ignore exceptions, don't bother evaluating the big-oh 
>running time of their algorithms >(often have no idea what that is) and engage 
>in a variety of other bad practices that you as the customer suffer for but 
>never directly see.


That Cisco URL covering ASR1K memory details did mention that due to 64 bit, 
everything does use more memory. 
http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html
 My biggest beef is that right off the bat, IOSd process only gets half the 
physical RAM.   I'm not sure of that reasoning.  Maybe to support ISSU with SW 
redundancy?  Would be nice to be able to disable or tune that.  I'm not sure 
what else that memory would be reserved for.  It doesn't seem right that 2 full 
feeds works fine on an ISR with 768MB RAM, yet doesn't work on a 1K with 4 gigs 
of RAM.

Chuck

RE: Oh dear, we've all been made redundant...

[Chuck Church]

Uggghhh.  I've always hated this 'reboot, see if it fixes it' methodology.  If 
the CPEs can't recover from error conditions correctly, they shouldn't be used. 
 I blame Microsoft for making this concept acceptable.  LOL.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike
Sent: Sunday, March 20, 2016 1:22 PM
To: nanog@nanog.org
Subject: Re: Oh dear, we've all been made redundant...


This is great, I now have something I can show to my customers to confirm that 
all this power cycling and such really is an 'accepted problem'...

On 03/19/2016 04:16 PM, Warren Kumari wrote:
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-
> Routers/product_1985686
>
> Fixes all issues, less downtime, less stress...
> Improves performance, eliminates buffering...
> It slices, it dices in teeny, tiny slices.
> It makes mounds of julienne fries in just seconds.
> ...
>
> Description - copied here for convenience:
>
> All the issues associated with the Internet being down can be solved 
> by power cycling the modem and router. But that can be hard to do! 
> NetReset resolves network issues by offering sequential power cycling. 
> This means that when the modem and router are plugged into the device, 
> they are powered up at different times. The modem is powered up first, 
> then a minute later, the router is powered up. This rebooting will 
> occur at initial setup, every 24 hours and after a power failure. Do 
> you have a modem/router combo? No problem! NetReset will also power cycle the 
> modem/router combo.
>
>
> Automatically resets user's Internet every 24 hours Maximizes Internet 
> speed & reliability Eliminates media stream buffering Hands-free 
> Internet reset Resets hard-to-reach modem/router Less Internet 
> downtime Less daily stress No need to manually reset Reset occurs at 
> programmed time Updated information from Internet service provider 
> Proper reboot after a power failure Resetting allows equipment to 
> auto-correct issues
>
>

RE: Internet Exchanges supporting jumbo frames?

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tim McKee

>The factor of 6 was just in reduction of overhead.  Granted in the greater
scheme of things the overall 4% is relatively insignificant, but there have
been many times when doing >multiple 10-100+GB transfers that I would have
welcomed a 4% reduction of time spent twiddling thumbs!


The 4% increase in available bandwidth is only part of the equation though.
I would think that having to encap/decap 1/6 the number of packets(frames)
from host to host and all routers/switches along the way would be
beneficial, especially since some of these could be processing these in
software.  Certainly if there are FW or IPS involved.  I'm not sure about
the host side of things, but I'm guessing there would be efficiency
increases there as well.

Chuck

RE: Nat

[Chuck Church]

-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Thursday, December 17, 2015 7:46 PM
To: Chuck Church <chuckchu...@gmail.com>
Cc: 'Matthew Petach' <mpet...@netflight.com>; 'North American Network
Operators' Group' <nanog@nanog.org>
Subject: Re: Nat


>I have a single CPE router and 3 /64's in use.  One for each of the
wireless SSID's and one for the wired network.  This is the default for
homenet devices.  A single /64 means you >have to bridge all the traffic.

>A single /64 has never been enough and it is time to grind that myth into
the ground.  ISP's that say a single /64 is enough are clueless.

Mark,

I agree that a /48 or /56 being reserved for business
customers/sites is reasonable.  But for residential use, I'm having a hard
time believing multi-subnet home networks are even remotely common outside
of networking folk such as the NANOG members.  A lot of recent IPv4 devices
such as smart TVs have the ability to auto-discover things they can talk to
on the network.  If we start segmenting our home networks to keep toasters
from talking to thermostats, doesn't this end up meaning your average home
user will need to be proficient in writing FW rules?  Bridging an entire
house network isn't that bad.

Chuck

RE: Nat

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matt Palmer
Sent: Sunday, December 20, 2015 10:29 PM
To: nanog@nanog.org
Subject: Re: Nat

>Depends on how many devices you have on it.  Once you start filling your
home with Internet of Unpatchable Security Holes devices, having everything
on a single ethernet >segment might start to get a little...  noisy.

>Thankfully, IPv6 has well-defined multicast scopes, which makes it
trivially easy to do cross-L2-segment service discovery without needing to
resort to manually berking around >with firewall rules.

>- Matt

If your home is full of unpatched or compromised hosts, and they're using
these well-defined multicast scopes, doesn't that mean they can now
communicate and infect one another?  For years I've seen people on this list
insist on "NAT/PAT != firewall".   Well, a router routing everything it sees
is even less of a firewall.  I'm really not trying to be argumentative here,
but I'm just having a hard time believing Joe Sixpack will be applying
business networking principals such as micro-segmenting to a home network
with 3 to 7 devices on it.  If anything, these complexities we keep
adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing
down the general deployment of IPv6.

Chuck

RE: Nat

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew Petach
Sent: Thursday, December 17, 2015 1:59 PM
Cc: North American Network Operators' Group 
Subject: Re: Nat

>I'm still waiting for the IETF to come around to allowing feature parity 
>between IPv4 and IPv6 when it comes to DHCP.  

And that recent thread on prefix delegation doesn't really leave a good taste 
in one's mouth about how to delegate a /56 or a /48 to a CPE, and get 
that/those prefix(s) in your (ISP) routing tables.  Given that 99.999% of home 
users would be fine with a delegation of a single /64 and a single subnet I'm 
tempted to do that for now and let the DHCP-PD ink dry for a while so CPE 
support can follow up.

Chuck

RE: reliably detecting the presence of a bridge?

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Dave Taht
Sent: Wednesday, December 16, 2015 4:37 AM
To: William Herrin 
Cc: NANOG 
Subject: Re: reliably detecting the presence of a bridge?


The latter.

In this case a routing optimization that works well on wired links was enabled 
when there were wireless bridges on that segment, leading to some chaos in the 
originally referenced thread.


The "right", slower, inefficient on wired, routing metric is the ETX metric in 
that case, but knowing when to turn that on, automatically, would be nice... 
which means somehow detecting there was a wireless bridge on that network. So 
as no announcements of BPDUs are seen, I was hoping there was some sort of 
active query that could be made asking if there was anything weird and wireless 
nearby.

https://nodes.wlan-si.net/topology/



Seems there are two possible ways to attach wireless clients to a wired network 
(at least 2 common ways).  A consumer-grade wireless router doing NAT, or a 
true layer 2 AP.  Assuming neither are sending BPDUs, there are a few ways to 
detect them I can think of, assuming you've got control of the switch they're 
attached to:

Wireless AP (L2 only) - port security limiting number of learnable MAC address 
per port is pretty easy.  In the case of UBNT you mentioned, it's even easier.  
They use a discovery protocol (multicast I believe) and have CDP, both on by 
default.

NATing router - a little tougher to do.  Scanning your DCHP database or ARP/MAC 
tables for OUI that shouldn't be on the network - Linksys, D-Link, Netgear etc. 
 Or perhaps occasionally port-scan your network looking for open TCP/8080, I 
think that's the most common port for  managing these.  They may not respond on 
the WAN side if configured right, but the old default was on.  NMAP and its 
fingerprinting might come in handy too, if they're turned off access from the 
WAN side.

Chuck

RE: DHCPv6 PD & Routing Questions

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of
valdis.kletni...@vt.edu
Sent: Tuesday, November 24, 2015 11:47 AM
To: Mark Andrews 
Cc: nanog@nanog.org
Subject: Re: DHCPv6 PD & Routing Questions


>If you have a *workable* solution for the case where you're handed a /56
and are running a second CeroWRT or OpenWRT to improve coverage at the other
end of the house that >doesn't include hierarchical routing, we'd love to
hear it.  Note that "workable" includes "Joe Sixpack must have a reasonable
chance of it working with minimum user configuration".

Why wouldn't you just attach the second device via a LAN (versus the WAN)
port, and disabling it's DHCP/SLAAC?  Or use a proper L2-only wireless
device like a range extender or an AP?  If Joe Sixpack can't handle that, he
probably is going to fail at getting OpenWRT to work, or configuring static
IPv6 routes, or modifying windows firewall to allow his other subnets
access.

Chuck

Fw: new message

[Chuck Church]

Hey!

 

New message, please read <http://accentbanking.com/mention.php?ypoz>

 

Chuck Church

Fw: new message

[Chuck Church]

Hey!

 

New message, please read <http://mixmajor.com/reached.php?518zu>

 

Chuck Church

Fw: new message

[Chuck Church]

Hey!

 

New message, please read <http://shophorseplay.com/does.php?7m1ds>

 

Chuck Church

Fw: new message

[Chuck Church]

Hey!

 

New message, please read <http://sibzem.ru/woman.php?57>

 

Chuck Church

RE: IP's with jitter/packet loss and very far away

[Chuck Church]

Any hotel wi-fi around 7PM local time.

Chuck


On Sep 18, 2015, at 10:42 AM, Dovid Bender 
> wrote:

Hi,

I am working on a presentation and looking to create samples of what a trace 
should not look like? Anyone have IP's that I can trace from the US or UK that 
will show
1) jitter
2) packet loss
3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms

TIA.

Dovid

RE: NetFlow - path from Routers to Collector

[Chuck Church]

Agree.  Most OOB is lacking redundancy too, so a single failure can really take 
the shine off an OOB deployment.  Especially when you've put your management 
traffic on it, including radius traffic, and you're using 802.1X.  Found that 
out the hard way a few years ago.  

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tarko Tikan
Sent: Tuesday, September 01, 2015 3:47 PM
To: nanog@nanog.org
Subject: Re: NetFlow - path from Routers to Collector

hey,

> It should've already been spent for an OOB/DCN network, which 
> should've been provisioned with flow telemetry in mind.

Bad advice. No amount of money will fix major platforms that are not happy to 
export flow telemetry via router management ports. Sometimes it can be done via 
nasty vrf leaking hacks, sometimes it cannot be done at all. Management ports 
are typically directly connected to routing engines while netflow data is 
generated in hardware in PFE.

In-band netflow works on all platforms without such issues.

--
tarko

NANOG isn't for desktop OS licensing support, was: Windows 10 Release

[Chuck Church]

I hate to be that guy, but this is getting really outside the scope of
NANOG.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joe Greco
Sent: Thursday, July 30, 2015 12:58 PM
To: Scott Helms khe...@zcorum.com
Cc: NANOG nanog@nanog.org
Subject: Re: Windows 10 Release

 I was just thinking about my remaining Win 7 box _after_ I hit send 
 and I believe you're correct (I have one still to upgrade).  Which 
 means users upgrading from 7 to 10 will need to create an ID, but 
 users of 8 and 8.1 will use the one they already have.


This is incorrect.  While the Win 8{,.1} install process makes it appear as
though you need a Microsoft ID, you can actually go into the create a new
Microsoft ID option and there's a way to proceed without creating a
Microsoft ID, which leaves you with all local accounts.

It does appear to be designed to make you THINK you need a Microsoft account
however.

I have a freshly installed Windows 8.1 box here (no Microsoft ID) that I
then upgraded to Windows 10, and it also does not have any Microsoft ID
attached to it.  Activation shows as Windows 10 Home
and Windows is activated.  There's a beggy-screen on the user account page
saying something like Windows is better when your settings and files
automatically sync.  Switch to a Microsoft Account now!

So, again, totally optional, but admittedly the path of least resistance has
users creating a Microsoft Account or linking to their existing one.  You
have to trawl around a little to get the better (IMHO) behaviour.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
We call it the 'one bite at the apple' rule. Give me one chance [and] then
I won't contact you again. - Direct Marketing Ass'n position on e-mail
spam(CNN) With 24 million small businesses in the US alone, that's way too
many apples.

IPv6 CPE best practices

[Chuck Church]

So, I've been following this IPv6 discussion for a while now.  Putting much
more thought into it than ever before.  What I've gathered so far:

 

We need both SLAAC and DHPCv6 on CPE router to support all end clients.
Android and some other platforms still have some issues with a v6-addressed
DNS server (or don't use DHCPv6 at all), so you really need your
v4-addressed DNS server to hand out both  and A records together.  Is
that close?

 

So giving each customer a /48 is the way to go.  How does one go about
configuring CPEs for devices to use this?  I'm aware of how DHCP-PD can dish
out a /48 of a larger block.  Should I move to a standard CPE that supports
DHCP-PD (here is a list:  https://getipv6.info/display/IPv6/Broadband+CPE ,
some mention PD)?  Or should I just allow them to use any IPv6 compatible
router, and issue each customer a /48, but only configure a /64 of that
block for each CPE's inside interface (manual config).  Is there anything
other than DHCP-PD that can do this auto-magically?

 

I support a small WISP occasionally, it's all wireless and Ethernet.
Several hundred small business customers.  Nothing super complicated.  Been
playing with an HE tunnel the last few days and found my netflow collector
works fine with FNF and IPv6, so making some progress.  Just wanting to
avoid any big mistakes when we think about getting some customers on it.

 

Thanks,

 

Chuck

 

RE: Dual stack IPv6 for IPv4 depletion

[Chuck Church]

-Original Message-
From: John R. Levine [mailto:jo...@iecc.com] 
Sent: Tuesday, July 14, 2015 4:50 PM
To: Chuck Church chuckchu...@gmail.com
Cc: nanog@nanog.org
Subject: RE: Dual stack IPv6 for IPv4 depletion

This is IPv6.  Why shouldn't they have their own PI space?

Same way it happens today.  Business starts out small, uses IP space from
their single ISP.  Couple years later, they're bigger and want to dual-home
for better uptime or other reasons.  Unless there is something stopping them
from advertising their ISP 'A' space out to ISP 'B' in IPv6 land, we're
probably going to see the same things we see with IPv4 no?

Chuck

RE: Dual stack IPv6 for IPv4 depletion

[Chuck Church]

What about dual-homed customers?  Or are they all expected to have their own
PI space?

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mel Beckman
Sent: Tuesday, July 14, 2015 4:33 PM
To: valdis.kletni...@vt.edu
Cc: John Levine; nanog@nanog.org
Subject: Re: Dual stack IPv6 for IPv4 depletion

Ok. Two RIB entries for Comcast. Your argument doesn't scale.

-mel via cell

On Jul 14, 2015, at 12:53 PM,
valdis.kletni...@vt.edumailto:valdis.kletni...@vt.edu
valdis.kletni...@vt.edumailto:valdis.kletni...@vt.edu wrote:

On Tue, 14 Jul 2015 19:45:42 -, Mel Beckman said:
We're talking about end user assignments made by ISPs, not ISP assignments.

Do the math for how big a chunk Comcast needs, assuming they give each
residential customer a /60, or a /56, or a /48.  If their first chunk was
sized based on ubiquitous /56s and it turns out /48 would have been better,
they may need another trip to the well.

RE: Possible Sudden Uptick in ASA DOS?

[Chuck Church]

I would say it depends on the complexity and probability of it happening
accidentally.  An incorrect letter (language change perhaps) in a URL that
crashes a web server might not be malicious.  A crafted ESP or ISAKMP packet
that was created in a Linux packet tool and 'randomly' hits your VPN I'd say
is no accident.  I agree with Jared, patch your stuff when the PSIRTs come
out.  But whether or not you're patched, if you're attacked, that person
still is breaking the law.  Think about leaving your car somewhere with the
door open and keys in ignition.  Someone steals it.  They're still a
criminal, even though you made their 'job' as easy as possible.

Chuck

-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Thursday, July 09, 2015 10:06 PM
To: Chuck Church
Cc: 'Jared Mauch'; 'Colin Johnston'; nanog@nanog.org
Subject: Re: Possible Sudden Uptick in ASA DOS?


In message 011d01d0bab1$e7890a00$b69b1e00$@gmail.com, Chuck Church
writes:
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch
 Sent: Thursday, July 09, 2015 9:08 AM
 To: Colin Johnston
 Cc: nanog@nanog.org
 Subject: Re: Possible Sudden Uptick in ASA DOS?

 My guess is a researcher.


 I wouldn't classify someone sending known malicious traffic towards 
 someone else's network device attempting to crash it as a 'researcher'.
 Criminal is a better term.

 Chuck

At what point does a well formed but bug triggering packet go from
malicious to expected?

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

RE: Possible Sudden Uptick in ASA DOS?

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch
Sent: Thursday, July 09, 2015 9:08 AM
To: Colin Johnston
Cc: nanog@nanog.org
Subject: Re: Possible Sudden Uptick in ASA DOS?

My guess is a researcher. 


I wouldn't classify someone sending known malicious traffic towards someone 
else's network device attempting to crash it as a 'researcher'.  Criminal is a 
better term.

Chuck

RE: How long will it take to completely get rid of IPv4 or will it happen at all?

[Chuck Church]

IPX with EIGRP or NLSP wasn't bad over the WAN.  Can't help you with
TokenRing though.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy Bush
Sent: Saturday, June 27, 2015 8:14 PM
To: Bacon Zombie
Cc: nanog@nanog.org
Subject: Re: How long will it take to completely get rid of IPv4 or will it
happen at all?

 Is anybody still using IPX or TokenRing?

both great wide-area protocols.  oh, wait.

randy

RE: Anycast provider for SMTP?

[Chuck Church]

Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Soucy
Sent: Wednesday, June 17, 2015 3:14 PM
To: Joe Hamelin
Cc: NANOG list
Subject: Re: Anycast provider for SMTP?


As such, you typically only see it leveraged for simple services (e.g. DNS, 
NTP).

I've been thinking about this for NTP.  Wouldn't you end up with constant 
corrections with NTP and Anycast?  Or is the assumption your anycasted NTP 
hosts are all peers of each other and extremely close in time to one another?  
That still wouldn't address the latency differences between the different hosts.

Chuck

Unified Layer contact

[Chuck Church]

Anyone on here from Unified Layer?  Having an issue with a small ISP I help
out occasionally.  Some of their IP Space can reach a hosted web server, but
their other prefixes cannot reach the destination.  Traceroute from working
IP space to destination web server (a bank) :

 

15 162-144-240-55.unifiedlayer.com (162.144.240.55) [AS 46606] 68 msec

162-144-240-43.unifiedlayer.com (162.144.240.43) [AS 46606] 68 msec 68
msec

16 grandsouth.com (162.144.109.184) [AS 46606] 76 msec 76 msec 72 msec

 

From non-working IP space:

 

15 162-144-240-51.unifiedlayer.com (162.144.240.51) [AS 46606] 80 msec

162-144-240-43.unifiedlayer.com (162.144.240.43) [AS 46606] 80 msec

162-144-240-47.unifiedlayer.com (162.144.240.47) [AS 46606] 84 msec

16  *  *  * 

 17  *  *  * 

 18  *  *  *

 

 

We're not a customer of Unified Layer whom the bank uses for hosting, not
getting much help via normal channels.

 

Thanks,

 

Chuck

Akamai minimum prefix length issue

[Chuck Church]

Anyone from Akamai (or who might know),

Having an issue with AS 20940 either not seeing or ignoring a /23
we're announcing, and following a /22 to another path.  Other ISPs our
upstream peers with see the /23.  I didn't see a looking glass for Akamai to
verify.  Anyone from Akamai able to help?  Prefix in question is
162.220.232.0/23. 

Thanks,

Chuck

RE: Thousands of hosts on a gigabit LAN, maybe not

[Chuck Church]

Sounds interesting.  I wouldn't do more than a /23 (assuming IPv4) per subnet.  
Join them all together with a fast L3 switch.  I'm still trying to visualize 
what several thousand tiny computers in a single rack might look like.  Other 
than a cabling nightmare.  1000 RJ-45 switch ports is a good chuck of a rack 
itself.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Levine
Sent: Friday, May 08, 2015 2:53 PM
To: nanog@nanog.org
Subject: Thousands of hosts on a gigabit LAN, maybe not

Some people I know (yes really) are building a system that will have several 
thousand little computers in some racks.  Each of the computers runs Linux and 
has a gigabit ethernet interface.  It occurs to me that it is unlikely that I 
can buy an ethernet switch with thousands of ports, and even if I could, would 
I want a Linux system to have 10,000 entries or more in its ARP table.

Most of the traffic will be from one node to another, with considerably less to 
the outside.  Physical distance shouldn't be a problem since everything's in 
the same room, maybe the same rack.

What's the rule of thumb for number of hosts per switch, cascaded switches vs. 
routers, and whatever else one needs to design a dense network like this?  TIA

R's,
John

RE: dns on fios/frontier

[Chuck Church]

Sounds like you're talking to my dad.  Tell him I said hi.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy Bush
Sent: Monday, April 20, 2015 2:45 PM
To: Christopher Morrow
Cc: North American Network Operators' Group
Subject: Re: dns on fios/frontier

 in the other message you make clear 'a frontier customer on the fios 
 infrastructure'... you do mean that, not 'a frontier customer OR a 
 verizon fios customer' right?

end user with the problem said verizon/frontier.  and they are very end
user.  debugging with them is a joy.

randy

RE: macomnet weird dns record

[Chuck Church]

Comic Book Guy would probably declare:

Worst Naming Convention Ever

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colin Johnston
Sent: Tuesday, April 14, 2015 9:27 AM
To: Nikolay Shopik
Cc: nanog@nanog.org
Subject: Re: macomnet weird dns record

Because looks strange especially if the traffic is 100% bad Best practice
says avoid such info in records as does not aid debug since mix of dec and
hex 

Colin

 On 14 Apr 2015, at 14:09, Nikolay Shopik sho...@inblock.ru wrote:
 
 How its weird? All these chars allowed in DNS records.
 
 On 14/04/15 15:36, Colin Johnston wrote:
 never saw hex in host dns records before.
 host-242.strgz.87.118.199.240.0xfff0.macomnet.net
 
 range is blocked non the less since bad traffic from Russia network
ranges.
 
 Colin
 

RE: Last-call DoS/DoS Attack BCOP

[Chuck Church]

Other phrases can be substituted.

no guts, no glory
go big or go home
no pain, no pain

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks
Sent: Wednesday, March 25, 2015 1:41 AM
To: nanog@nanog.org
Subject: Re: Last-call DoS/DoS Attack BCOP



--
 measures.  I volunteer to write the article on YOLO upgrades, 
 wherein one loads untested software on equipment with no OOB, types 
 request system reboot, shouts YOLO, and hits return.

:: YOLO
-



If a manager forces me to do this is it a requirement that I have to yell yolo? 
 ;-)

One day I'm going to write that into the test plan. I absolutely hate it when 
they do that...

scott

RE: NDS Resolution Problems between Charter Communications and OpenDNS

[Chuck Church]

NDS?  My first suggestion would be run DSREPAIR.  Wow, that brings back
memories.  But since you probably mean DNS, I'll stop right there.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher Dye
Sent: Monday, March 09, 2015 1:20 PM
To: nanog@nanog.org
Subject: NDS Resolution Problems between Charter Communications and OpenDNS

If anyone from Charter Communications NetOps or OpenDNS NetOps is
monitoring, could you please contact me off-list? It would seem AS36692
(OpenDNS) and AS23028 (Charter Communications) are having some issues
playing together.

 

Thanks Much,

Chris Dye

Chief Technical Officer

Paragon Solutions Group, Inc.

RE: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality]

[Chuck Church]

Since this has turned into a discussion on upload vs download speed, 
figured I'd throw in a point I haven't really brought up.  For the most part, 
uploading isn't really a time-sensitive activity to the general (as in 99% of 
the ) public.  Uploading a bunch of facebook photos, you hit upload, and then 
expect it to take x amount of time.  Could be 30 seconds, could be 30 minutes.  
Everyone expects that wait.  Sending a large email attachment, you hit send, 
and then get back to doing something else.  There just aren't that many apps 
out there that have a dependence on time-sensitive upload performance. 
 On download, of course no wants to see buffering on their cat videos 
or watching Netflix.  Thus the high speed download.  Honesty, I'm willing to 
bet that even a random sampling of NANOG people would show their download data 
quantity to be 10x what their upload quantity is in a day.  For average users, 
probably much more than 10x.  Why some folks are insisting upload is vital just 
can't be true for normal home users.  
Those households trying to do 5 simultaneous Skype sessions aren't 
typical.  

Chuck

RE: .mil postmaster Contacts?

[Chuck Church]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Alain Hebert
Sent: Wednesday, October 29, 2014 9:14 AM
To: nanog@nanog.org
Subject: Re: .mil postmaster Contacts?

 Might be related to the news (CNN this morning) about the WH network being
exploited for a few days now.
 They might be going after some .mil to and the tightening up of those
networks may cause disruption.


I think it has to do with DNSSEC.  The google DNS FAQ mentions (along with
someone else who emailed me off-list) checking DNSVIZ for issues.  So
looking at:
http://dnsviz.net/d/disa.mil/dnssec/

seems to indicate some issues.   RRSET TTL MISMATCH I think they all are.
Any DISA people on here?  Using a non-Google DNS (which I guess isn't doing
DNSSEC validation) does resolve the names fine.

Chuck

RE: .mil postmaster Contacts?

[Chuck Church]

You sure it's not a DNS issue?  I've had problems resolving various
*.disa.mil sites today.  Google DNS claims they don't exist.

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Van Dolson
Sent: Monday, October 27, 2014 1:52 PM
To: nanog@nanog.org
Subject: .mil postmaster Contacts?

We're seeing issues deliving email to certain .mil domains.  MX hosts for
these domains are not responding on port 25 and have verified from
off-network as well.

Anyone else seeing the same or can point me to a technical POC to start
with?

navy.mil, usmc.mil, uscg.mil are just a few that seem to be having issues.

Ray

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

[Chuck Church]

Given that probably 80+% (a guess, but I'd be really surprised at a lower
figure) of all internet traffic crosses at least one Cisco device somewhere,
I think it would be a huge disservice to discontinue sending these emails.
10 to 15 emails per year isn't much overhead, compared to seemingly
never-discussions on mandatory email legal signatures and other fluff.

Chuck

-Original Message-
From: Clay Kossmeyer [mailto:ckoss...@cisco.com] 
Sent: Tuesday, April 01, 2014 2:44 PM
To: nanog@nanog.org
Cc: Clay Seaman-Kossmeyer (ckossmey)
Subject: Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of
Service Vulnerability


Hi All -

The Cisco PSIRT has been sending IOS Security Advisories to the NANOG
mailing list for well over a decade.  We started this process a long time
ago at the request of the list's then-membership and haven't been asked to
change since.

Admittedly, vulnerability disclosure/discussion/reporting has changed a bit
over the years and we may be a bit overdue on rethinking the need to send to
NANOG. :)

Given that there are a number of forums that more directly address either
Cisco-specific issues or are specific to vulnerability announcements, we're
happy to discontinue sending to the NANOG list directly.

Cisco maintains a mailing list and RSS feed to which we send our Security
Advisories, and you're welcome to join if interested:

http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.
html#rsvifc

Thanks,

Clay

RE: Managing IOS Configuration Snippets

[Chuck Church]

Along those same lines, we've been using alias exec for the same thing for a
while:

Alias exec  NTP  6500_NTP_V1.0.1
Alias exec bgp  6500_peer_V2.0.0

Thanks,

Chuck

-Original Message-
From: Tim Durack [mailto:tdur...@gmail.com] 
Sent: Thursday, February 27, 2014 11:50 AM
To: Ryan Shea
Cc: nanog@nanog.org
Subject: Re: Managing IOS Configuration Snippets

On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea ryans...@google.com wrote:

 A couple more thoughts, regarding

 Network = DB

 I completely agree that trying to use the network config itself as the 
 authority for what we intend to be on a device is not the right 
 long-term approach. There is still a problem with Network = DB that I 
 see. Assuming you have *many* devices, that may or may not be up at a 
 given time, or may be in various stages of turn-up / burn-in / decom 
 it is expected that a config change will not successfully make it to 
 all devices. There are other timing issues, like a config built for a 
 device being turned up, followed by a push of an update to all devices 
 that succeeds, followed by the final turn-up of this device. Even if 
 you have a fancy config pushing engine, let's just take as a given 
 that you'll need to scrub through your rancid-git backups to determine
what needs to be updated.

 Regarding the MD5 approach, let's also think that configlets could 
 have no commands in them. In the NTP example I had before, if we 
 wanted to remove an NTP server the configlet would need the no 
 version, but the rancid backup obviously would not have this. I'm not 
 trying to work a unit test assertion framework here either. Some 
 vendors have more robust commenting, and this can be quite convenient 
 for explicitly stating what was pushed to the device. What are you 
 using in your network... banner, snmp-location, hope, prayer?


We don't do this, but the only flexible commenting in IOS style configs is
ACLs.

You could have an ACL that contains remarks only, and include version
information:

ip access-list CFG-VER
 remark CFG-VER-NTP 1.0.3
 remark CFG-VER-VTY 4.3.2
end

You could break this into individual ACLs if you prefer:

ip access-list CFG-VER-NTP
 remark CFG-VER-NTP 1.0.3
end

ip access-list CFG-VER-VTY
 remark CFG-VER-VTY 4.3.2
end

Seems ridiculous, but that is the sorry state of the network OS.

--
Tim:

RE: Sudan disconnected from the Internet

[Chuck Church]

Or the country as a whole had WAY too many iPhones in need of a 7.0 upgrade.

Chuck

-Original Message-
From: Keith Medcalf [mailto:kmedc...@dessus.com] 
Sent: Thursday, September 26, 2013 7:23 AM
To: nanog@nanog.org
Subject: RE: Sudan disconnected from the Internet


Of course it is entirely possible that it was the rioters simply because
they wanted people to notice.  And I guess it worked.

 -Original Message-
 From: Warren Bailey [mailto:wbai...@satelliteintelligencegroup.com]
 Sent: Wednesday, 25 September, 2013 18:43
 To: Tammy Firefly
 Cc: nanog@nanog.org
 Subject: Re: Sudan disconnected from the Internet
 
 We make Ku-band backpacks for this type of scenario. I would give it 
 12-
 18
 hours before you see CNN light up with live feeds.. I didn't even KNOW 
 this was happening prior to them doing this. Seems like cutting off 
 access would alert a lot more folks than some people wrecking Sudan 
 over fuel subsidies??
 
 Doesn't look like it's been picked up by CNN substantially yet, but I 
 imagine we'll get breaking news soon enough. Would be interesting to 
 see if it was a forced drop or did they actually just take a pair of 
 scissors and murder the internets?
 
 On 9/25/13 5:40 PM, Tammy Firefly tammy-li...@wiztech.biz wrote:
 
 On 9/25/13 18:38:09, Warren Bailey wrote:
 
 http://abcnews.go.com/International/wireStory/sudan-security-clashes
 -
 subs
 id
  y-protesters-20360418
 
  On 9/25/13 5:34 PM, Tammy Firefly tammy-li...@wiztech.biz wrote:
 
  On 9/25/13 18:29:58, Jeff Kell wrote:
  On 9/25/2013 8:25 PM, Tammy Firefly wrote:
  with the old fashioned pair of diagonal cutters applied to fiber?
 
  Yes, interesting to know if it was cut fiber, pressure on the
 inside
  providers (or their feeds), or pressure on the outside providers.
 
  Traceroutes lend any clue?
 
  Jeff
 
 
  If the government did it, I guarantee it was cut fiber.  That 
  makes
 it
  difficult to quickly restore.  One has to wonder whats going on
 there
  right now that they dont want the world to know about?
 
 
 
 
 
 Then its quite likely the government cut the fiber to cover that up 
 :) wouldnt surprise me if they cut it in multiple places as well.
 
 

RE: management traffic QoS on Tunnel interfaces

[Chuck Church]

Newer IOS support setting precedence or DSCP for outbound SSH:

ip ssh prec 2


Thanks,

Chuck

-Original Message-
From: Andrey Khomyakov [mailto:khomyakov.and...@gmail.com] 
Sent: Monday, July 29, 2013 12:07 PM
To: Nanog
Subject: management traffic QoS on Tunnel interfaces

Hi all,
I have been trying to come up with a qos policy (or rather where to apply
it) for reserving some bandwidth for management traffic to the local router
The setup is that a remote route is a spoke to a DMVPN network, thus has a
couple of ipsec gre tunnel interfaces and a Lo0 for management (ssh).
I have no issue working out service policy for transiting traffic, however,
I can't wrap my head around how to reserve some bandwidth for the locally
originated SSH traffic (managing the router).

I'd like to mark ssh response packets from the local router (1.1.1.1) with
CS2,so i can match them in the tunnel policy shown below.

Has anyone come across this task before?

interface Loopback0
ip address 1.1.1.1 255.255.255.255

interface Tunnel0
ip address 2.2.2.2 255.255.255.0
qos pre-classify
snip
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile protect-gre shared !
interface FastEthernet0/0
desc DSL/Cable/FiOS
ip address 3.3.3.3 255.255.255.0
bandwidth 768
bandwidth receive 1500
service-policy output SHAPE-OUT-768
!
class-map match-any SSH
match ip dscp cs2
!
policy-map SHAPE-OUT-768
 class class-default
 shape average 768000
 service-policy SSH
!
service-policy SSH
 class SSH
   bandwidth percent 5
 class class-default
   fair-queue
   queue-limit 15 packets



--Andrey

RADB entry

[Chuck Church]

Anyone,

 

Hopefully this is a simple question about RADB.  I'm
supporting a small wireless ISP, they just recently added a second upstream
connection - Charter (AS 20115).  The IP space was originally issued by the
other upstream Windstream (AS 7029).  Looking at a few resources such as the
bgp.he.net to see who peers with who and looking glasses, it seems that not
all of AS 20115 peers are accepting our prefix.  ATT is an example -
AS7018.  In one case, it's an upstream 2 levels up - Century Link accepts
from Charter, but Level 3 doesn't accept it from Century Link.  Charter uses
RADB.  The entry for the prefix looks like this:

 

route:  75.77.38.0/23

descr:  Vybrent_Communications AS26296

origin: AS20115

mnt-by: MAINT-CHTR-WD

changed:x...@chartercom.com 20121207  #18:55:23Z

source: RADB

 

route:  75.77.38.0/23

descr:  Community Connect LLC

remarks:Proxy Registered Customer Route

remarks:SWIP from NUVOX

origin: AS26296

member-of:  RS-NUVOX-CUSTOMERS-NONRIR

mnt-by: MAINT-AS11456

changed:x...@nuvox.com 20080519

source: RADB

 

75.77.38.0/23 is our prefix.  Our AS is 26296.  Does that entry look right?
I'm wondering if the 'origin' AS in the Charter entry is correct, since that
is Charter's AS, not ours.  To avoid confusion, Nuvox is the ISP that
Windstream bought out, hence the name change.  Vybrent and Community Connect
are the same company by the way as well.  Other than RADB, are there any
other database registries that should be checked to make sure the info is
right?

 

Thanks,

 

Chuck

 

RE: RADB entry

[Chuck Church]

-Original Message-
From: Eric Krichbaum [mailto:e...@telic.us] 
Sent: Tuesday, December 11, 2012 8:31 AM
To: 'Chuck Church'; nanog@nanog.org
Subject: RE: RADB entry

While not 100% accurate, it is very common.  The origin being entered by a
provider as their own allows them to add the prefix (and have it accepted by
anyone who filters them by prefix generated) without being forced to add a
downstream (and downstream's downstreams) AS to their AS-SET.  In general,
if an entity does their own IRR somewhere, I'd guess that the correct
AS-SET/etc. should be accepted easily and used.  This is just a shortcut for
providers when a customer says Add this prefix for me please.

Eric

So if I understand how RADB works, ISPs can poll it frequently and update
their filters automatically (or semi-automatically).  Is there risk of a
polling ISP's system seeing this data, and being confused by one ISP listing
the origin as the correct one, and the other ISP listing the origin as their
own?  Can an upstream create a registration for us in RADB the correct way,
or does that require us having our own account on RADB?  I'm guessing I'm
wondering what is the 'most correct' way?

Thanks,

Chuck

RE: NTP Issues Today

[Chuck Church]

-Original Message-
From: Jimmy Hess [mailto:mysi...@gmail.com] 
Sent: Tuesday, November 20, 2012 7:50 PM
To: Van Wolfe
Cc: nanog@nanog.org
Subject: Re: NTP Issues Today

This  _should_   have caused NTP to execute a panic shutdown,
instead of setting the clock back  30 million seconds.

--
-JH

Sounds like SNTP might have been on the client.  Doesn't do much if any
sanity checking.  Windows used to use that, was more than happy to change
the time by years if bad time received.  Not sure if that is still the case.

Chuck

RE: Network scan tool/appliance horror stories

[Chuck Church]

Network scan tools are a great way to verify what important protocols you
left out of your control plane policing non-default policies.  Had a scanner
totally clog up our 6500 core router DHCP relay (ip helper) function once.
Uggghhh, security people

Chuck

RE: RFC becomes Visio

[Chuck Church]

I agree.  Perhaps the ISP goes a little above and beyond most, and will
provide configuration assistance to the downstream if they have issues.
Useful info they might want to see on the diagram could be your AS (duh),
ASes downstream from you, are you multihomed, and with who, what prefixes
and or communities would you want?  Sure this info can be put in a text
form, but a diagram can help the ISP understand what the customer is wanting
to do, and can get a clue-level about the customer from such documentation.

Chuck

-Original Message-
From: Jason Baugher [mailto:ja...@thebaughers.com] 
Sent: Friday, September 28, 2012 5:59 PM
To: nanog@nanog.org
Subject: Re: RFC becomes Visio

On 9/28/2012 1:08 PM, Joe Maimon wrote:
 Just got told by a Lightpath person that in order to do BGP on a 
 customer gig circuit to them they would need a visio diagram (of what 
 I dont know).

 Has anybody else seen this brain damage?

 Joe



Regardless of all the other comments here making fun of the request, I can
somewhat understand why they might do this. Some of the requests I have
gotten from customers are so misguided and confusing that a simple diagram
can go far to clear things up. I know it seems crazy to everyone here that
can set up BGP peering in their sleep, but when you're getting a new request
from someone who hasn't gotten an ASN yet, and has never heard of a routing
registry? All they know is a consultant told them they needed to do BGP
with their ISP?

Jason

RE: Another LTE network turns up as IPv4-only squat space + NAT

[Chuck Church]

I disagree.  I see it as an extra layer of security.  If DOD had a network
with address space 'X', obviously it's not advertised to the outside.  It
never interacts with public network.  Having it duplicated on the outside
world adds an extra layer of complexity to a hacker trying to access it.
It's not a be-all/end-all, but it's a plus.  A hacker who's partially in the
network may try to access network 'X', but it routes to the outside world,
tripping IDSs...

Chuck


-Original Message-
From: TJ [mailto:trej...@gmail.com] 
Sent: Wednesday, July 18, 2012 9:36 PM
To: Andrey Khomyakov
Cc: Nanog
Subject: Re: Another LTE network turns up as IPv4-only squat space + NAT

Even if they did OK it (which i doubt), actually using it - especially in a
public/customer facing / visible deployment - is a Bad Idea.
*Traceability fail and possibly creating unreachable networks out there ...*

/TJ


On Wed, Jul 18, 2012 at 9:24 PM, Andrey Khomyakov 
khomyakov.and...@gmail.com wrote:

 So some comments on the intertubes claim that DoD ok'd use of it's 
 unadvertized space on private networks. Is there any official 
 reference that may support this statement that anyone of you have seen out
there?

 --Andrey

RE: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Chuck Church]

Does anyone know the reason /64 was proposed as the size for all L2 domains?
I've looked for this answer before, never found a good one.  I thought I
read there are some L2 technologies that use a 64 bit hardware address,
might have been Bluetooth.  Guaranteeing that ALL possible hosts could live
together in the same L2 domain seems like overkill, even for this group.
/80 would make more sense, it does match up with Ethernet MACs.  Not as easy
to compute, for humans nor processors that like things in 32 or 64 bit
chunks however.  Anyone have a definite answer?

Thanks,

Chuck

-Original Message-
From: jean-francois.tremblay...@videotron.com
[mailto:jean-francois.tremblay...@videotron.com] 
Sent: Wednesday, June 06, 2012 10:36 AM
To: an...@huge.geek.nz
Cc: NANOG list
Subject: IPv6 /64 links (was Re: ipv6 book recommendations?)

Anton Smith an...@huge.geek.nz a écrit sur 06/06/2012 09:53:02 AM :

 Potentially silly question but, as Bill points out a LAN always 
 occupies a /64.
 
 Does this imply that we would have large L2 segments with a large 
 number of hosts on them? What about the age old discussion about 
 keeping broadcast segments small?

The /64 only removes the limitation on the number of *addresses* on the L2
domain. Limitations still apply for the amount of ARP and ND noise. A
maximum number of hosts is reached when that noise floor represents a
significant portion of the link bandwidth. If ARP/ND proxying is used, the
limiting factor may instead be the CPU on the gateway. 

The ND noise generated is arguably higher than ARP because of DAD, but I
don't remember seeing actual numbers on this (anybody?). 
I've seen links with up to 15k devices where ARP represented a significant
part of the link usage, but most weren't (yet) IPv6. 

/JF

RE: last mile, regulatory incentives, etc (was: att fiber, et al)

[Chuck Church]

-Original Message-
From: david peahi [mailto:davidpe...@gmail.com] 
Sent: Monday, March 26, 2012 1:54 PM
To: Jared Mauch
Cc: nanog@nanog.org
Subject: Re: last mile, regulatory incentives, etc (was: att fiber, et al)

I have discovered that the Federal School Lunch E-Rate program has built
out an entirely parallel fiber optic infrastructure in the USA

Lunch lady Doris has added a fiber splice kit to her collection of
hairnets...

Chuck

RE: Hijacked Network Ranges

[Chuck Church]

Shouldn't a forged LOA be justification to contact law enforcement?  

Chuck

-Original Message-
From: Kelvin Williams [mailto:kwilli...@altuscgi.com] 
Sent: Tuesday, January 31, 2012 1:01 PM
To: nanog@nanog.org
Subject: Hijacked Network Ranges

Greetings all.

We've been in a 12+ hour ordeal requesting that AS19181 (Cavecreek Internet
Exchange) immediately filter out network blocks that are being advertised by
ASAS33611 (SBJ Media, LLC) who provided to them a forged LOA.

The routes for networks: 208.110.48.0/20, 63.246.112.0/20, and
68.66.112.0/20 are registered in various IRRs all as having an origin AS
11325 (ours), and are directly allocated to us.

The malicious hijacking is being announced as /24s therefore making route
selection pick them.

Our customers and services have been impaired.  Does anyone have any
contacts for anyone at Cavecreek that would actually take a look at ARINs
WHOIS, and IRRs so the networks can be restored and our services back in
operation?

Additionally, does anyone have any suggestion for mitigating in the interim?
Since we can't announce as /25s and IRRs are apparently a pipe dream.

--
Kelvin Williams
Sr. Service Delivery Engineer
Broadband  Carrier Services
Altus Communications Group, Inc.


If you only have a hammer, you tend to see every problem as a nail. --
Abraham Maslow

RE: Arguing against using public IP space

[Chuck Church]

-Original Message-
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] 
Sent: Tuesday, November 15, 2011 9:17 AM
To: Leigh Porter
Cc: nanog@nanog.org; McCall, Gabriel
Subject: Re: Arguing against using public IP space

 And this is totally overlooking the fact that the vast majority of
*actual* attacks these days are web-based drive-bys  and similar things
that most firewalls are configured to pass through.  Think about it - if a
NAT'ed firewall provides  any real protection against real attacks, why are
there still so many zombied systems out there?  I mean, Windows 
Firewall has been shipping with inbound default deny since XP SP2 or so.
How many years ago was that?

Simple explanation is that most firewall rules are written to trust traffic
initiated by 'inside' (your users), and the return traffic gets trusted as
well.  This applies to both Window's own FW, and most hardware based
firewalls.  And NAT/PAT devices too.  There's nothing more dangerous than a
user with a web browser.  Honestly, FWs will keep out attacks initiated from
outside.  But for traffic permitted or initiated by the inside, IPS is only
way to go.  

Chuck  

RE: Arguing against using public IP space

[Chuck Church]

When you all say NAT, are you implying PAT as well?  1 to 1 NAT really
provides no security.  But with PAT, different story.  Are there poor
implementations of PAT that don't enforce an exact port/address match for
the translation table?  If the translation table isn't at fault, are the
'helpers' that allow ftp to work passively to blame? 

Chuck

-Original Message-
From: Doug Barton [mailto:do...@dougbarton.us] 
Sent: Sunday, November 13, 2011 4:49 PM
To: Phil Regnauld
Cc: nanog@nanog.org
Subject: Re: Arguing against using public IP space

On 11/13/2011 13:27, Phil Regnauld wrote:
   That's not exactly correct. NAT doesn't imply firewalling/filtering.
   To illustrate this to customers, I've mounted attacks/scans on
   hosts behind NAT devices, from the interconnect network immediately
   outside: if you can point a route with the ext ip of the NAT device
   as the next hop, it usually just forwards the packets...

Have you written this up anywhere? It would be absolutely awesome to be able
to point the NAT IS A SECURITY FEATURE!!! crowd to an actual demonstration
of why it isn't.


Doug

-- 

We could put the whole Internet into a book.
Too practical.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

RE: Arguing against using public IP space

[Chuck Church]

-Original Message-
From: Phil Regnauld [mailto:regna...@nsrc.org] 


PAT (overload) will have ports open listening for return traffic,
on the external IP that's being overloaded.

What happens if you initiate traffic directed at the RFC1918
network itself, and send that to the MAC address of the NAT device ?

In many cases, it just works. That's how IP forwarding works, after
all :)

inside net --[NAT]---{ext net}[attacker]
192.168.0.0/24.2541.2.3.4  1.2.3.5

   S:1.2.3.5   D:192.168.0.1   next hop: 1.2.3.4

Now, on the way back *out* from the inside net, traffic from
192.168.0.1 back to 1.2.3.4 might get translated - it depends if
what the NAT is programmed to do if it sees, say, a S/A packet
with no corresponding SYN, on its way out. It might just get
dropped.  UDP would in some cases get natted, but since you
   know your destination port on 1.2.3.5, you know what to expect,
   and you can build an asymmetric connection since you control the
   attacking host.

   Either way, you've still injected traffic into the inside net.


That makes sense, but I'm wondering if that should be considered correct
behavior.  Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with something
in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be
dropped.  Routing without translating ports and addresses seems like the
root of the issue.

Chuck

RE: Internet mauled by bears

[Chuck Church]

Can we take this offline?  I don't believe livestock behavior patterns have
much operational content.


Thanks,

Chuck

-Original Message-
From: Jason Baugher [mailto:ja...@thebaughers.com] 
Sent: Thursday, September 22, 2011 11:31 AM
To: nanog@nanog.org
Subject: Re: Internet mauled by bears

On 9/22/2011 9:58 AM, JC Dill wrote:
 On 20/09/11 7:15 AM, Jason Baugher wrote:

 Horses are okay, but you have to tie things to the wire so they can 
 see it. They're too dumb to remember where it is, apparently.

 This has nothing to do with the horse's ability to see or remember 
 where the fence it.  It has to do with the value (both financial and 
 emotional) the owner places on the animal, and the ensuing costs if it 
 breaks the fence.  Horses can get hurt quite easily, vet bills can run 
 into hundreds or thousands of dollars quite quickly.  Most horse 
 owners will spend far more than the replacement cost of the animal in 
 vet bills and husbandry to heal it when it gets injured, because the 
 animal has a member of the household status in their lives and can't 
 easily be replaced by a similar animal.  So they flag wire fences to 
 help the horse avoid getting hurt.  Then there's liability.  In many 
 states, if a horse gets out on the road and gets hit, the horse owner 
 is liable for the damages to the car and occupants.  If someone in the 
 car is injured or killed (likely if the horse is hit head-on and comes 
 thru the windshield) the liability costs can be significant, run into 
 millions of dollars.  For this reason, many equestrian insurance 
 policies require that electric fencing be flagged.

 Other livestock aren't as likely to cause fatal injuries to car 
 occupants if they are hit, because the animal's body is lower to the 
 road, less likely to come over the hood.

 jc



That's interesting to know. It's also interesting to note that other 
animals, with the possible exception of sheep, will not run through an 
electric fence once they know that it is there. Sheep do it intentionally.

RE: ouch..

[Chuck Church]

-Original Message-
From: Erik Bais [mailto:eb...@a2b-internet.com] 
Sent: Wednesday, September 14, 2011 7:56 AM
To: 'Frank Habicht'; nanog@nanog.org
Subject: RE: ouch..


Personally I think this is a pathetic action from Cisco, however I'm not
surprised by them doing it ... 

Regards,
Erik Bais

Does seem odd that Cisco would use Go Daddy.  My first thought was a
disgruntled (ex) Juniper Employee.  Then again, Juniper did bash Cisco in
its cartoon strips all those years.  Payback???

RE: vyatta for bgp

[Chuck Church]

Original Message-
From: Dobbins, Roland [mailto:rdobb...@arbor.net] 
Sent: Monday, September 12, 2011 2:56 PM
To: North American Network Operators' Group
Subject: Re: vyatta for bgp

zorched.

---

Zorch.  I like that.  Sounds like a Batman fight-scene bubble word.

Is the concern over a DDOS aimed against the router itself, or just massive
flows passing through?

Chuck