Re: Modem as a service?

[b]

What about a $20 android phone, when it detects a power loss (stops charging), 
send an sms.

On Mon, Dec 07, 2015 at 12:03:48PM +1100, Karl Auer wrote:
> On Sun, 2015-12-06 at 18:13 -0600, Josh Reynolds wrote:
> > You could always just use UPS equipment that can send out alerts on power
> > outages and low bat voltage. Or, use equipment that supports dying gasp.
> 
> The equipment you have needs to be able to send the alert, which means
> SMS or email-capable equipment needs to stay powered up long enough to
> do that.
> 
> There might be a product idea here, if no-one's done it already:
> Something like a RaspBerry Pi, running off a lithium battery, with a
> recharge circuit and something to detect a power outage. Add a 3G/4G
> card to send an SMS alert, put it all in a box, plug it into power. Only
> configuration needed is setting the SMS target(s)... If you made it
> network addressable (on 3G/4G) it could send emails as well.
> 
> Regards, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
> 
> GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
> Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
> 
> 

Re: mrtg alternative

[B]

Welcome to the future.
Graphite/grafana.

On Fri, Feb 26, 2016 at 06:30:02PM -0500, Shawn L wrote:
> 
> We use observium.  It has most of what you're looking for.   Used to use 
> cacti but switched a couple of months ago
> 
> 
> -Original Message-
> From: "Baldur Norddahl" 
> Sent: Friday, February 26, 2016 6:18pm
> To: "nanog@nanog.org" 
> Subject: mrtg alternative
> 
> 
> 
> Hi
> 
> I am currently using MRTG and RRD to make traffic graphs. I am searching
> for more modern alternatives that allows the user to dynamically zoom and
> scroll the timeline.
> 
> Bonus points if the user can customize the graphs directly in the
> webbrowse. For example he might be able to add or remove individual peers
> from the graph by simply clicking a checkbox.
> 
> What is the 2016 tool for this?
> 
> Regards,
> 
> Baldur

Re: mrtg alternative - librenms

[B]

An alternative to Observium is LibreNMS, with a more liberal license/community.

Cheers,
B

On Sat, Feb 27, 2016 at 12:18:16AM +0100, Baldur Norddahl wrote:
> Hi
> 
> I am currently using MRTG and RRD to make traffic graphs. I am searching
> for more modern alternatives that allows the user to dynamically zoom and
> scroll the timeline.
> 
> Bonus points if the user can customize the graphs directly in the
> webbrowse. For example he might be able to add or remove individual peers
> from the graph by simply clicking a checkbox.
> 
> What is the 2016 tool for this?
> 
> Regards,
> 
> Baldur

Re: AS4788 Telecom Malaysia major route leak?

[B]

In addition to that, losing face in SE Asia is "not done".

On Mon, Jun 15, 2015 at 12:14:43AM +, ryanL wrote:
> keep in mind their target audience with that message is probably local
> malaysian customers, not the world.
> 
> On Sun, Jun 14, 2015 at 5:09 PM Mel Beckman  wrote:
> 
> > SLAs are part of a contract, and thus only apply to the parties of the
> > contract. There are no payments due to other parties. The Internet is a
> > "best effort" network, with zero guarantees.
> >
> >  -mel beckman
> >
> > On Jun 14, 2015, at 4:06 PM, Rafael Possamai  > raf...@gav.ufsc.br>> wrote:
> >
> > Does anyone know if there's an official "ruling" as to who gets to pay for
> > the SLA breaches?
> >
> > On Sun, Jun 14, 2015 at 5:56 PM, Mel Beckman  > m...@beckman.org>> wrote:
> > Raymond,
> >
> > But you said "A simple 'sorry' would have done." Now you're asking for
> > lots more detail. Why the change?
> >
> >  -mel beckman

AWS using 169.254.0.0/30 for ptp VPNs.

[B F]

Hello all,
Looking for any fresh experience with this:
https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNTunnels.html
Any problems experienced with using that reserved space as a non-local 
destination? Seems like it might not be wise WRT RFC3927.Apparently space from 
RFC1918 is not an option.Found a few hits in the archives (2012) but looking 
recent experience.
Thank you very much in advance.Blake

Re: (Slightly OT?) K8S Platform As A Service Recommendations

[M B]

You could look at the combo of Tinkerbell and CAPI (ClusterAPI). Happy to
chat more off list.

-matt

On Wed, Apr 7, 2021, 10:42 AM Charles N Wyble  wrote:

> Hello all,
>
>
> I know this is primarily a networking list, but I know lots of server
> admins hang out here.
>
> Does anyone have a recommendation for a self-hosted, on premise, platform
> as a service layer for k8s (specifically k3s)?
>
> I have written up some context here:
>
>
> https://github.com/TSYSGroup/docs-techops/blob/master/Applications/AppRuntimeLayerTodo.md
>
> tl:dr : I have about 70 to 200 apps / (micro) services that will need to
> run across a handful of k3s servers . I already have HA
> database/networking/certificate/application load balanacer/authentication
> stacks in production use, I am currently running the actual
> websites/applications on a single Ubuntu LAMP server and want to build out
> an HA runtime layer for all the properties/applications and need a way to
> orchestrate k3s/metallb
>
> Rancher rio has come up a few times in my research:
> https://bram.dingelstad.works/blog/finding-the-right-paas-for-k8s/
> In addition to the web apps , I will also will be running a number of r&d
> applications and CUDA enabled containers (across a mix of physical
> x86/jetson/tegra machines with k3s workers).
>
> Suggestions/comments/questions/flames welcome :)
>
> On or off list as you prefer.
>

DDoS Attacks targeting VPN/IPSEC endpoints

[Dennis B]

Any one else seeing this? Hearing some isolated events across different
industry segments. If you are, can you provide any TTPs?

Re: Article: DoD, DoJ press FCC for industry-wide BGP security standard

[Dennis B]

Way overdue! In the last 4 weeks, I've had at least 20 diff conversations
with FSI Network operators re: BGP hijacking, how to detect and in the
future, mitigate with higher levels of success. Come on BGP RPKI/ROA
adaption. I found the easiest way is via ISP pressure to implement dropping
invalid routes.

On Mon, Sep 19, 2022, 6:29 PM Fletcher Kittredge 
wrote:

>
> Fierce Telecom: DoD, DoJ press FCC for industry-wide BGP security standard
> 
>

Firewall list recommendations (config conversion options)

[b f]

Hi list,

Could any one recommend any firewall related mailing lists?

Looking for options on converting a large amount of Fortinet rules to
Checkpoint.  Ultimately converting the entire configuration to Checkpoint
would be nice.

Thank you for any advice you can provide.

Respectfully,

Ed

NIST NTP servers

[b f]

Hello List,


In search of stable, disparate stratum 1 NTP sources.

Looking for anyone’s advice/experiences (good/bad/ugly/weird) using NIST’s
NTP servers per: http://tf.nist.gov/tf-cgi/servers.cgi

We tried using “time.nist.gov” which returns varying round-robin addresses
(as the link says), but Cisco IOS resolved the FQDN and embedded the
numeric address in the “ntp server” config statement.



After letting the new server config go through a few days of update cycles,
the drift, offset and reachability stats are not anywhere as good as what
the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil.


I would greatly appreciate and feedback / advice, etc.


Thanks!!!


Ed

Re: NIST NTP servers

[B F]

All,  
Thanks very much for all the replies. Extremely helpful.
"...ask someone what time it is and they'll tell you how to build a watch."
Luckily I got both.
Ed



 Original message 
From: Lamar Owen  
Date: 5/14/2016  10:27 AM  (GMT-05:00) 
To: NANOG  
Subject: Re: NIST NTP servers 

On 05/13/2016 04:38 PM, Mel Beckman wrote:
> But another key consideration beyond accuracy is the reliability of a 
> server's GPS constellation view. If you can lose GPS sync for an hour or more 
> (not uncommon in terrain-locked locations), the NTP time will go free-running 
> and could drift quite a bit. You need an OCXO to minimize that drift to 
> acceptable levels.
While this is drifting a bit off-topic for NANOG (and drifting into the 
topic range for time-n...@febo.com), I'll just add one more thing to 
this.  The Hold time (when the oscillator is free-running) is a very 
important consideration, especially, as you say, when terrain is an 
issue. For us it is even more important, as the 10MHz output from the 
timing rack is used as a site-wide frequency standard.  Of course, you 
never discipline a cesium PRS, but the rubidium secondary is disciplined 
by circuitry in the SSU2000.

Back in the days of common backbone delivery over SONET discussion of 
cesium standards would have been on-topic, as some SONET gear (Nortel 
Optera for instance) needs a master clock; especially if you were 
delivering channelized circuits or interfacing with customers and telcos 
with DS3 or even DS1 circuits or DS0 fractions within them.  Ethernet is 
far more forgiving.

automated site to site vpn recommendations

[c b]

Situation: We have salespeople/engineers holding temporary 
seminars/training/demonstrations in hotel meeting rooms.
Requirements: 
field people need a very plug-n-play, simple, reliable vpn back to corporate 
offices to present videos/slides/demonstrations. The materials are not 
accessible via the internet directly, they are in a contained environment at 
corporate HQ locations but not necessarily on the corp network.the solution 
should be able to provide wireless to attendees. In some cases, guest login 
will be fine but in some cases the attendees will have registered and provided 
login creds prior to the event, and these creds will need to be checked before 
providing accessthe solution should have the option to split tunnel internet 
traffic out, but in some cases they need all traffic tunneled and internet will 
be via our corporate offices (NDA/legal, don't ask, it's just a requirement 
provided)
Nice-to-have:
 field person should be able to not only access the presentation materials (in 
their contained network) but also the corporate network. Some early attempts 
required a user-vpn connection by the field person over the S2S VPN, but it 
made it clunky to switch back and forth. This isn't mandatory, but it would be 
nice to provide one solution providing dual-level access: restricted to 
attendees, less-restricted to field people
Tried this in the past with basic router/switch/wireless and captive portals 
because we had some inventory available... it was workable but not quick or 
easy. We really could use a simple solution that you just flip on, it calls 
home, and works... or as close to that as possible.
Have been looking at Meraki and a couple other low-touch solutions and they may 
do the trick, but we are hoping there are lower cost options that people have 
used successfully? We don't mind dealing with some off brands and even some 
custom coding (within reason) as long as the end result is a low-touch, 
reliable solution.
Thanks in advance.

RE: automated site to site vpn recommendations

[c b]

Guys, thanks for all the responses. Thanks to everyone's feedback, we have a 
number of options that were not on the original list and that is what I was 
hoping for. Now it's a matter of comparing 
cost/learning-curve/support-challenge/compatibility with tools/monitoring, 
etc...
Thanks again.

> From: r...@tehorange.com
> Date: Wed, 29 Jun 2016 09:03:06 -0400
> Subject: Re: automated site to site vpn recommendations
> To: p...@nashnetworks.ca
> CC: nanog@nanog.org
> 
> For several of our clients, we use Sophos UTMs coupled with their RED
> units.  Once registered with the UTM, the RED unit auto creates an SSL
> based VPN back to the UTM.  The RED unit is managed from the UTM and pulls
> it's config when it boots. It's similar to the function of Meraki without
> the direct cloud management portion, though the config profile does get
> pushed to a section of Sophos' cloud.
> 
> -Rich
> 
> On Wed, Jun 29, 2016 at 8:55 AM, Paul Nash  wrote:
> 
> > My biggest issue with Meraki is that their tech staff can run tcpdump on
> > the wired or wireless interface of your Meraki box without having to leave
> > their desk.  I have no reason to believe that they are malicious, or in the
> > pay of the NSA, but I am too paranoid to allow their equipment anywhere
> > near me.
> >
> > Yes, they work well and the cloud control panel makes remote support a
> > breeze; you have to decide how you feel about the insecurity.
> >
> > paul
> >
> > > On Jun 27, 2016, at 6:28 PM, Dan Stralka  wrote:
> > >
> > > I would second Meraki for the situation you describe. I don't feel that
> > > they are the most capable platform, they're expensive, and don't always
> > > present you with all the information you'd need for troubleshooting.
> > > However, the VPN offers great dynamic tunneling, instant-on performance,
> > > and are by far the simplest platform to offer a field person.  They're
> > also
> > > tenacious - I've had them connect to the cloud management platform and
> > > build a VPN under some trying circumstances.
> > >
> > > From a security standpoint, they will offer features that will impress
> > for
> > > the price (Sourcefire, inability to use if stolen, 802.1x, and remote VPN
> > > tunnel control), and we've found they punch above their weight and their
> > > APs perform fantastically.
> > >
> > > We deploy them worldwide many times per year in similar use cases,
> > > sometimes with 150 users on the LAN. If your routing is simple, you can
> > > define your security policies, and don't need crazy throughput on your
> > VPN,
> > > Meraki is the way to go.  Be careful though: they have to be continually
> > > licensed to work and can get pretty expensive if you go for the higher
> > end
> > > gear.  Thus far, we've been able to stick to the cheaper stuff and
> > > accomplish our goals.
> > >
> > > Dan
> > >
> > > (end)
> > > On Jun 27, 2016 6:01 PM, "Karl Auer"  wrote:
> > >
> > >> On Mon, 2016-06-27 at 13:08 -0700, c b wrote:
> > >>> In some cases...
> > >>
> > >> The words "in some cases" are a problem with any supposedly plug and
> > >> play solution.
> > >>
> > >>> We really could use a simple solution that you
> > >>> just flip on, it calls home, and works...
> > >>
> > >> ...but still requiring someone to enter credentials of some sort,
> > >> right? Otherwise you have a device wandering about that provides look
> > >> -mum-no-hands access to your corporate network.
> > >>
> > >> MikroTik stuff is cheap as chips, small, comes with wifi, ethernet, USB
> > >> for a wireless dongle or storage, and has a highly-scriptable operating
> > >> system. Not a bad platform.
> > >>
> > >> Regards, K.
> > >>
> > >> --
> > >> ~~~
> > >> Karl Auer (ka...@biplane.com.au)
> > >> http://www.biplane.com.au/kauer
> > >> http://twitter.com/kauer389
> > >>
> > >> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
> > >> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
> > >>
> > >>
> > >>
> > >>
> >
> >
  

Bat Blue cloud security

[B F]

Happy Friday list,
Any experiences/opinions to share about batblue.Com ?
tia, ed

Arbor Reports 540Gbps "Sustained" Attack

[Dennis B]

https://www.arbornetworks.com/blog/asert/rio-olympics-take-gold-540gbsec-sustained-ddos-attacks/

I've used SP Peakflow before and I have my opinions. With all the
intelligence out there about DDoS attacks, DDoS attackers, DDoS tools and
techniques this article leaves me with ton's of questions.

IE: What industry was the attack target? Was it a single customer or
multiple customers at the same time? What was the attack vector? Was it
multi-vector? What was the duration of the 540Gbps attack? Did you actually
block the attack or did you just report on it from your cloud signaling
alliance aka cloud offering? Could you help explain if the peak of the
attack lasted X minutes, Y hours, Z days? What was the attack targeted
protocol? Was it TCP against TCP or UDP against UDP or UDP against TCP?

I have to be honest, IDK if Arbor is attempting to claim the largest
recorded DDoS attack in the world cup of DDoS attacks but the fact that
your a local appliance shop. Selling to the global 100 and T1-3 ISPs - I'd
hope for more than a marketing ploy to take the top attack vector.

Thought I'd ask Nanog if they heard any whispers about this "white
buffalo", which ISPs were Transiting the event, what course of actions were
taken.

Thanks!

Need recommendation on an affordable internet edge router

[c b]

We have a number of internet edge routers across several data centers 
approaching EOL/EOS, and are budgeting for replacements. Like most enterprises, 
we have been Cisco-centric in our routing/switching platforms. The ASR1Ks are 
too small for our needs and the ASR9Ks are prohibitively expensive and probably 
overkill. That being said, our IT staff is willing to look at other vendors if 
they are the right fit.


Requirements:

  *   Can handle full internet tables, both v4 and v6 with room for reasonable 
growth over the next 5 years.
  *   VRF capability.
  *   About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if they are 
1Gb/10Gb select-rate ports.)
  *   Full-Feature BGP (address-families, communities, peer-groups, etc...)
  *   Used by carriers or large enterprises in a production role for at least a 
year (and not causing ulcers)
  *   Affordable. I know that's subjective, but we need a solution that is as 
close as possible to commodity-pricing if this modernization effort balloons to 
include all of our data centers.

We are open to named vendors and even so-called brite-box solutions. A little 
nervous about fringe solutions like pure whitebox with Quagga, but if the 
savings are there and people can vouch for it, we will consider it.

In other words, if you've used it and stand by it, we value that input and will 
put it on the initial list. Also, if you chose solution-X after comparing it to 
solution-Y it would be very helpful to detail what you tested and why you chose.

Thanks in advance.

Re: Need recommendation on an affordable internet edge router

[c b]

The ASR9k is certainly up to the task and it's one of the few we looked at 
initially, but the pricing is nowhere near commodity even if we got a minimal 
build.


As far as volume, the initial purchase for this round of budget will be an HA 
pair. If the solution works well, we have potential to replace 12 or so 
throughout FY17, maybe into FY18.


Lots of responses very quickly, thanks. Definitely appreciate the suggestions 
from people who have selected and operated.



From: Saku Ytti 
Sent: Thursday, May 4, 2017 2:43 PM
To: c b
Cc: nanog@nanog.org
Subject: Re: Need recommendation on an affordable internet edge router

On 4 May 2017 at 23:39, c b  wrote:

>   *   Affordable. I know that's subjective, but we need a solution that is as 
> close as possible to commodity-pricing if this modernization effort balloons 
> to include all of our data centers.

How many? For any non-trivial volume devices with equal ports and
features tend to cost the same from every vendor.  Unfortunately your
density requirements are very modest.
Also are you sure you are as price sensitive as you think you are?
I.e. maybe not look just your BU's budget, but impact on bottom line.
Since saving here some, may end up costing in OPEX significantly more
over time, and that case may be easier to make than you think. Usually
router/switch CAPEX isn't even a blip in enterprises bottom line.

But you probably should review at least:
  - Juniper MX204, MX480
  - Cisco ASR9k
  - Huawei NE20, NE40
  - Alcatel 7750SR

Personally I'm bit worried about Cisco's transition to newish OS and
new linecard architecture. Might come out good, might have some
rearing issues.

Alcatel is expensive to automate, as you cannot ship it new full
config and have it roll-forward to it from old config. I am also
worried that they are essentially developing their own booting OS,
instead of developing routing suite on existing OS, I'm not sure if
that is good investment of engineering hours, and if that's reason why
they're stuck in PowerPC, while others rock XEON. However Alcatel's
SMP capability is probably currently best of the bunch.


All of the stated options are NPU/run-to-completion boxes which have
higher port-price and better features than pipeline boxes. However
pipeline boxes are far denser and cheaper per port, but from your POV
they'll be even more expensive as your density requirement is so
modest. You have no stated features which couldn't be met by their
pipeline portfolios, so if you had the scale, pipeline box, like PTX1k
or any of the BRCM Jericho boxes might be more interesting to you.


--
  ++ytti

Re: Need recommendation on an affordable internet edge router

[c b]

Can someone toss in a brief testimonial for huawei? In the US, I never hear 
that name in enterprise space, only in carriers. No idea what day-to-day ops or 
support is like with that vendor. All the others I am quite familiar with to 
one degree or another.



From: Dragan Jovicic 
Sent: Thursday, May 4, 2017 3:20 PM
To: Saku Ytti
Cc: c b; nanog@nanog.org
Subject: Re: Need recommendation on an affordable internet edge router

Hi,

But you probably should review at least:
  - Juniper MX204, MX480
  - Cisco ASR9k
  - Huawei NE20, NE40
  - Alcatel 7750SR

Having all of these somewhere in our network, and my heart being with JNPR 
boxes, I'll say have a look at Huawei offerings.

+Dragan

On Fri, May 5, 2017 at 12:10 AM, Saku Ytti mailto:s...@ytti.fi>> 
wrote:
On 5 May 2017 at 01:04, c b 
mailto:bz_siege...@hotmail.com>> wrote:

Hey,

> The ASR9k is certainly up to the task and it's one of the few we looked at
> initially, but the pricing is nowhere near commodity even if we got a
> minimal build.

What is commodity? Where are you comparing it to which satisfies your
requirements?

> As far as volume, the initial purchase for this round of budget will be an
> HA pair. If the solution works well, we have potential to replace 12 or so
> throughout FY17, maybe into FY18.

Yeah sales droids likely won't be interested in 2 at all. But if you
commit on those 12, even if you'll order them separately. I think
that's something sales droid will care about, and you'll have
negotiation leverage as you can keep bouncing between several vendors
seeing who gets your business.
You should really expect at least 70% discount on 12 units, 80% would
be good. Under 70% would be walk out the room.

--
  ++ytti

Re: Is Cisco equpiment de facto for you?

[b nickell]

Cisco and my new Love; Juniper.. for Tier I / Peer

On Mon, Jan 10, 2011 at 10:43 AM, Jack Bates  wrote:

>
>
> On 1/10/2011 11:03 AM, Greg Whynott wrote:
>
>> Brocade device's pre Foundry purchase correct?  I can't see anyone that
>> large using Foundry in large deployments..
>>
>>
> People (who should know) have told me L3 does for some of their 10GE
> bonding. If you want high end at low cost, the box does it. Just price 100GE
> cards at the different vendors. :)
>
>
> Jack
>
>


-- 
-B

Re: How are you aggregating WAN customers these days?

[b nickell]

The ASRs seem to be the consensus in a lot of places. Wondering if
anyone has tried anything like aggregating T1 customers onto a mux
box, then connecting that back to a 6500.

I work in that kind of topology all day long/ both in 6500 & ASR's.
All is well/

On Mon, Jan 10, 2011 at 7:51 AM, Chris  wrote:

> Hello,
>
> I'm looking to put some feelers out there and see what people are
> doing to aggregate WAN customers (T1,T3, etc...) these days. What
> platforms/devices are you using? What seems to be working/not working?
> Any insights would be great!
>
> Thanks,
>


> Chris
>
>


-- 
-B

Re: Is Cisco equpiment de facto for you?

[b nickell]

Cheers.. to M.A.R.'s related view

On Jan 13, 2011 12:37 PM, "Michael Ruiz"  wrote:

I know where I have worked we have had a mixture of Juniper and Cisco
equipment.  Personally buying a Juniper Router like a M or a T series is
like buying a Ferrari. I like Cisco personally and they are cheaper than
buying a Juniper.  For example a M-series is always going to cost some
bucks after you factor the FPC and the PICS that need to be loaded.
Personally I like the JUNOS system better than the Cisco IOS, it is more
tech friendly when troubleshooting issues.  I have not worked on the new
IOS-NX system, but if I understand it correctly it is modular.  If Cisco
can the really cool Monitor command and the structure the command tree
like a Juniper.  I would think Cisco did something totally right.



M.A.R

Re: Ipv6 for the content provider

[George B.]

On Fri, Jan 28, 2011 at 8:04 PM, Owen DeLong  wrote:

> The IPv6 geo databases actually tend to be about on par with the IPv4
> ones from what I have seen so far (which is admittedly limited as I don't
> really use geolocation services). However, I still think it is important
> for
> people considering deploying something as you described to be aware
> of the additional things that may break and factor that into their
> decision about how and what to deploy.
>
> Owen
>
>
>
That isn't going to be the case going forward, I don't believe because our
allocation from ARIN will likely be used globally and others are likely to
come to the same conclusion.  While I had initially considered obtaining
regional allocations for operations in that region, the overhead of dealing
with multiple registries, differing policies, multiple fees, etc. didn't
seem worth the trouble.  The ARIN allocation will likely be used in EU and
APAC regions in addition to NA.

Re: TWC (AS11351) blocking all NTP?

[Cb B]

On Feb 2, 2014 8:35 AM, "Jonathan Towne"  wrote:
>
> The provider has kindly acknowledged that there is an issue, and are
> working on a resolution.  Heads up, it may be more than just my region.
>

And not just your provider, everyone is dealing with UDP amp attacks.

These UDP based amp attacks are off the charts. Wholesale blocking of
traffic at the protocol level to mitigate 10s to 100s of gigs of ddos
traffic is not "knee jerk", it is the right thing to do in a world where
bcp 38 is far from universal and open dns servers, ntp, chargen, and
whatever udp 172 is run wild.

People who run networks know what it takes to restore service. And
increasingly, that will be clamping ipv4 UDP in the plumbing,  both
reactively and proactively.

And, i agree bcp38 would help but that was published 14 years ago.

CB

> -- Jonathan Towne
>
>
> On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled:
> # This evening all of my servers lost NTP sync, stating that our on-site
NTP
> # servers hadn't synced in too long.
> #
> # Reference time noted by the local NTP servers:
> #   Fri, Jan 31 2014 19:11:29.725
> #
> # Apparently since then, NTP has been unable to traverse the circuit.  Our
> # other provider is shuffling NTP packets just fine, and after finding an
> # NTP peer that return routed in that direction, I was able to get NTP
back
> # in shape.
> #
> # Spot checking various NTP peers configured on my end with various
looking
> # glasses close to the far-end confirm that anytime the return route is
> # through AS11351, we never get the responses.  Outbound routes almost
always
> # take the shorter route through our other provider.
> #
> # Is anyone else seeing this, or am I lucky enough to have it localized to
> # my region (Northern NY)?
> #
> # I've created a ticket with the provider, although with it being the
weekend,
> # I have doubts it'll be a quick resolution.  I'm sure its a strange
knee-jerk
> # response to the monlist garbage.  Still, stopping time without warning
is
> # Uncool, Man.
> #
> # -- Jonathan Towne
> #
>

Re: TWC (AS11351) blocking all NTP?

[Cb B]

On Feb 2, 2014 2:54 PM, "Matthew Petach"  wrote:
>
> On Sun, Feb 2, 2014 at 2:17 PM, Cb B  wrote:
>
> > On Feb 2, 2014 8:35 AM, "Jonathan Towne"  wrote:
> > >
> > > The provider has kindly acknowledged that there is an issue, and are
> > > working on a resolution.  Heads up, it may be more than just my
region.
> > >
> >
> > And not just your provider, everyone is dealing with UDP amp attacks.
> >
> > These UDP based amp attacks are off the charts. Wholesale blocking of
> > traffic at the protocol level to mitigate 10s to 100s of gigs of ddos
> > traffic is not "knee jerk", it is the right thing to do in a world where
> > bcp 38 is far from universal and open dns servers, ntp, chargen, and
> > whatever udp 172 is run wild.
> >
> > People who run networks know what it takes to restore service. And
> > increasingly, that will be clamping ipv4 UDP in the plumbing,  both
> > reactively and proactively.
> >
>
>
> Please note that it's not that UDP is at fault here; it's
> applications that are structured to respond to small
> input packets with large responses.
>

I dont want to go into fault, there is plenty of that to go around.

> If NTP responded to a single query with a single
> equivalently sized response, its effectiveness as
> a DDoS attack would be zero; with zero amplification,
> the volume of attack traffic would be exactly equivalent
> to the volume of spoofed traffic the originator could
> send out in the first place.
>
> I agree the source obfuscation aspect of UDP can be
> annoying, from the spoofing perspective, but that
> really needs to be recognized to be separate from
> the volume amplification aspect, which is an application
> level issue, not a protocol level issue.
>

Source obfuscation is not annoying. Combined with amplification, it is the
perfect storm for shutting down networks... whereby the only solution is to
shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal,
patches boxes, and so on.

My point is: dont expect these abbused services on UDP to last. We have
experience in access networks on how to deal with abused protocols. Here is
one reference

http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/

My crystal ball says all of UDP will show up soon.

CB

> Thanks!
>
> Matt
> PS--yes, I know it would completely change the
> dynamics of the internet as we know it today to
> shift to a 1:1 correspondence between input
> requests and output replies...but it *would*
> have a nice side effect of balancing out traffic
> ratios in many places, altering the settlement
> landscape in the process.  ;)

Re: TWC (AS11351) blocking all NTP?

[Cb B]

On Feb 2, 2014 7:41 PM, "Larry Sheldon"  wrote:
>
> On 2/2/2014 9:17 PM, ryang...@gmail.com wrote:
>>
>> I'd hate to think that NetOps would be so heavy handed in blocking
>> all of UDP, as this would essentially halt quite a bit of audio/video
>> traffic. That being said, there's still quite the need for protocol
>> improvement when making use of UDP, but blocking UDP as a whole is
>> definitely not a resolution, and simply creating a wall that not only
>> keeps the abusive traffic out, but keeps legitimate traffic from
>> flowing freely as it should.
>
>
> "We had to burn down the village to save it."
>
>

Close. More like a hurricane is landing in NYC so we are forcing an
evacuation.

But. Your network, your call.

CB

> --
> Requiescas in pace o email   Two identifying characteristics
> of System Administrators:
> Ex turpi causa non oritur actio  Infallibility, and the ability to
> learn from their mistakes.
>   (Adapted from Stephen Pinker)
>

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Cb B]

On Feb 3, 2014 10:23 AM, "Paul Ferguson"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2/2/2014 2:17 PM, Cb B wrote:
>
> > And, i agree bcp38 would help but that was published 14 years ago.
>
> But what? Are you somehow implying that because BCP38 was
> "...published 14 years ago" (RFC2267 was initially published in 1998,
> and it was subsequently replaced by RFC2827)?
>
> I hope not, because  BCP38 filtering would still help stop spoofed
> traffic now perpetuating these attacks, 14 years after BCP38 was
> published, because spoofing is at the root of this problem
> (reflection/amplification attacks).
>
> This horse is not dead, and still deserves a lot of kicking.
>
> $.02,
>
> - - ferg (co-author of BCP38)
>

I completely agree.  My sphere of influence is bcp38 compliant.  And,
networks that fail to support some form of bcp38 are nothing short of
negligent.

That said, i spend too much time taking defensive action against ipv4 amp
udp attacks. And wishing others would deploy bcp38 does not solve today's
ddos attacks.

CB
>
> - --
> Paul Ferguson
> VP Threat Intelligence, IID
> PGP Public Key ID: 0x54DC85B2
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlLv3ocACgkQKJasdVTchbLhowEAuO9DSQiRswVeqpHSccHo060h
> cqmIB8XlaNkzEPQw1w0A/0G6cjvtWBiJfwWbWoTY7X3RRMHeN36RkYR+2TonyNBi
> =W2wU
> -END PGP SIGNATURE-

ddos attack blog

[Cb B]

Good write up, includes name and shame for AT&T Wireless, IIJ, OVH,
DTAG and others

http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack

Standard plug for http://openntpproject.org/ and
http://openresolverproject.org/ and bcp38 , please fix/help.

For those of you paying attention to the outage list, this is a pretty
big deal that has had daily ramification for some very big networks
https://puck.nether.net/pipermail/outages/2014-February/date.html

In general, i think UDP is doomed to be blocked and rate limited --
tragedy of the commons.  But, it would be nice if folks would just fix
the root of the issue so the rest of us don't have go there...

Regards,

CB

Re: Filter NTP traffic by packet size?

[Cb B]

On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher  wrote:
> On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch  wrote:
>>
>>  On Feb 20, 2014, at 3:51 PM, John Weekes  wrote:
>> > On 2/20/2014 12:41 PM, Edward Roels wrote:
>> >> Curious if anyone else thinks filtering out NTP packets above a certain
>> >> packet size is a good or terrible idea.
>> >>
>> >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6
>> are
>> >> typical for a client to successfully synchronize to an NTP server.
>> >>
>> >> If I query a server for it's list of peers (ntpq -np ) I've seen
>> >> packets as large as 522 bytes in a single packet in response to a 54
>> byte
>> >> query.  I'll admit I'm not 100% clear of the what is happening
>> >> protocol-wise when I perform this query.  I see there are multiple
>> packets
>> >> back forth between me and the server depending on the number of peers it
>> >> has?
>> >
>> > If your equipment supports this, and you're seeing reflected NTP
>> attacks, then it is an effective stopgap to block nearly all of the inbound
>> attack traffic to affected hosts. Some still comes through from NTP servers
>> running on nonstandard ports, but not much.
>>
>
> Also, don't forget to ask those sending the attack traffic to trace where
> the spoofed packets ingressed their networks.
>
>  > Standard IPv4 NTP response packets are 76 bytes (plus any link-level
>> headers), based on my testing. I have been internally filtering packets of
>> other sizes against attack targets for some time now with no ill-effect.
>>
>> You can filter packets that are 440 bytes in size and it will do a lot to
>> help the problem, but make sure you conjoin these with protocol udp and
>> port=123 rules to avoid collateral damage.
>>
>
> Preferably just source-port 123.
>
> You may also want to look at filtering UDP/80 outright as well, as that is
>> commonly used as an "I'm going to attack port 80" by attackers that don't
>> quite understand the difference between UDP and TCP.
>>
>
> Please don't filter UDP/80.  It's used by QUIC (
> http://en.wikipedia.org/wiki/QUIC).
>
> Damian

The folks at QUIC have been advised to not use UDP for a new protocol,
and they would be very well advised to not use UDP:80 since that is a
well known target port used in the DDoS reflection attacks.

As Jared noted, UDP:80 is a cesspool today.  Attempting to use it for
legit traffic is not smart.

CB

Re: Filter NTP traffic by packet size?

[Cb B]

On Feb 22, 2014 5:30 AM, "Damian Menscher"  wrote:
>
> On Fri, Feb 21, 2014 at 1:22 PM, Cb B  wrote:
>>
>> On Thu, Feb 20, 2014 at 2:12 PM, Damian Menscher 
wrote:
>> > On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch 
wrote:
>> > You may also want to look at filtering UDP/80 outright as well, as
that is
>> >> commonly used as an "I'm going to attack port 80" by attackers that
don't
>> >> quite understand the difference between UDP and TCP.
>> >
>> > Please don't filter UDP/80.  It's used by QUIC (
>> > http://en.wikipedia.org/wiki/QUIC).
>>
>> The folks at QUIC have been advised to not use UDP for a new protocol,
>> and they would be very well advised to not use UDP:80 since that is a
>> well known target port used in the DDoS reflection attacks.
>
>
> Please suggest which protocol has less blocking on the internet today
(keeping in mind the full end-to-end stack of CPE, various ISPs,
country-level proxies, backbone providers, etc).
>
> Damian

Tcp.

But the actual answer is , if you want a new transport protocol, create a
new transport protocol with a new protocol number. Overloading the clearly
polluted UDP pool will have problems. Happy eyeballs negotiation may be
required for L4.

QUIC can do what it wants.  Like anyone else, they pay their money and take
their chances. But, the data point that UDP is polluted is clearly
documented with several folks on this list suggesting tactical fixes that
involve limiting UDP, especially udp:80

Re: Filter NTP traffic by packet size?

[Cb B]

On Sat, Feb 22, 2014 at 12:38 AM, Carsten Bormann  wrote:
> On 22 Feb 2014, at 08:47, Saku Ytti  wrote:
>
>> I'm surprised MinimaLT and QUIC have have not put transport area people in
>> high gear towards standardization of new PKI based L4 protocol, I think its
>> elegant solution to many practical reoccurring problem, solution which has
>> become practical only rather recently.
>
> Oh, the transport area people *are* in their high gear.
> Their frantic movements may just seem static to you as they operate on more 
> drawn-out time scales.
> (The last transport protocol I worked on became standards-track 16 years 
> after I started working on it.)
>
> At this IETF, there will be a "Transport Services" BOF to help find out what 
> exactly the services are that a new transport protocol should provide to the 
> applications.  Research platforms such as QUIC, tcpcrypt, MINION etc. are 
> very much in the focus of attention.
>
> This time, it would be nice if the operations people got to have a say early 
> on in what gets standardized.
> (Just be careful not to try to "fight yesterday's war".)
>
> Grüße, Carsten
>
>

yesterday's war = don't bring up that operators are having a real
problem with UDP, and that operators have and will continue to block
it?  Because, i think that is what this thread is about.

i did bring yesterday's war to the IETF RTCWweb group and got the
expected answer

My concern:

https://www.ietf.org/mail-archive/web/rtcweb/current/msg11425.html

Summary IETF response:  The problem i described is already solved by
bcp38, nothing to see here, carry on with UDP

 https://www.ietf.org/mail-archive/web/rtcweb/current/msg11477.html

CB

Re: Filter NTP traffic by packet size?

[Cb B]

On Tue, Feb 25, 2014 at 8:58 AM, Blake Hudson  wrote:
> I talked to one of our upstream IP transit providers and was able to
> negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by UDP
> port within our aggregate policer. As mentioned, the legitimate traffic
> levels of these services are near 0. We gave each service many times the
> amount to satisfy subscribers, but not enough to overwhelm network links
> during an attack.
>
> --Blake
>

Blake,

What you have done is common and required to keep the network up at
this time. It is perfectly appropriate to have a baseline and enforce
some multiple of the baseline with a policer.

People who say this is the wrong thing to do are not running a network
of significant size, end of story.

CB


> Chris Laffin wrote the following on 2/23/2014 8:58 AM:
>
>> Ive talked to some major peering exchanges and they refuse to take any
>> action. Possibly if the requests come from many peering participants it will
>> be taken more seriously?
>>
>>> On Feb 22, 2014, at 19:23, "Peter Phaal"  wrote:
>>>
>>> Brocade demonstrated how peering exchanges can selectively filter
>>> large NTP reflection flows using the sFlow monitoring and hybrid port
>>> OpenFlow capabilities of their MLXe switches at last week's Network
>>> Field Day event.
>>>
>>>
>>> http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_1986.html
>>>
>>>> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin  wrote:
>>>> Has anyone talked about policing ntp everywhere. Normal traffic levels
>>>> are extremely low but the ddos traffic is very high. It would be really 
>>>> cool
>>>> if peering exchanges could police ntp on their connected members.
>>>>
>>>>> On Feb 22, 2014, at 8:05, "Paul Ferguson" 
>>>>> wrote:
>>>>>
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA256
>>>>>
>>>>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote:
>>>>>>>
>>>>>>> On 22/02/2014 09:07, Cb B wrote:
>>>>>>> Summary IETF response:  The problem i described is already solved
>>>>>>> by bcp38, nothing to see here, carry on with UDP
>>>>>>
>>>>>> udp is here to stay.  Denying this is no more useful than trying to
>>>>>> push the tide back with a teaspoon.
>>>>>
>>>>> Yes, udp is here to stay, and I quote Randy Bush on this, "I encourage
>>>>> my competitors to block udp."  :-p
>>>>>
>>>>> - - ferg
>>>>>
>>>>>
>>>>> - --
>>>>> Paul Ferguson
>>>>> VP Threat Intelligence, IID
>>>>> PGP Public Key ID: 0x54DC85B2
>>>>>
>>>>> -BEGIN PGP SIGNATURE-
>>>>> Version: GnuPG v2.0.22 (MingW32)
>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>>
>>>>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS
>>>>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M
>>>>> =FTxg
>>>>> -END PGP SIGNATURE-
>
>
>

Re: Ipv4 end, its fake.

[Cb B]

On Mar 22, 2014 12:08 AM, "Bryan Socha"  wrote:
>
> As someone growing in the end of ipv4, its all fake.Sure, the rirs
will
> run out, but that's boring.Don't believe the fake auction sites.
> Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3 for
no
> spam and $4 for legacy.Stop the inflation. Millions of IPS exist,
> there is no shortage and don't lie for rirs with IPS left.

That's cute that you think "millions" of ipv4 on the market solves anything
for someone who "growing"  end-points ... especially the VM business, you
can only sell as many VMs as you have IPv4. Your business is tightly
coupled to ipv4, so i  understand you *want* to believe.

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

Google, Yahoo, Wikipedia and Facebook all have v6 today, and Facebook is
shifting to an ipv6-only data center

https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf

T-Mobile US is also close to 10% ipv6-only end-points a la rfc6877/464xlat
today

So, perhaps, what you are saying is, ipv4 address utility has peaked, the
price is coming down due to supply/demand forces (less people need ipv4, so
more are willing to sell, more sellers with less demand equals lower prices)

That said,  have a ball with that. I bet there is someone out there that is
buying x.25 switches for pennies on the dollar by the pallet.

But you may find that performance of ipv4-only service will struggle to get
through transition mechansism that are rationing and ipv4 ports ...after
all, google and facebook just work on v6, so your ipv4 quality issue may
not bubble up so quick.

CB

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

[Cb B]

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

You seem to be missing something, it is called Metcalfe's Law, google it.

There is no long-term solution for you using ipv4 and me using ipv6. To
derive value from the internet, we all need to be on one technology that
supports end to end communication for us all.

CB

> On Mar 22, 2014 4:36 AM, "TJ"  wrote:
>
> > Millions of IPs don't matter in the face of X billions of people, and
> > XX-XXX billions of devices - and this is just the near term estimate.
> > (And don't forget utilization efficiency  - Millions of IPs is not
> > millions of customers served.)
> >
> > Do IPv6.
> > /TJ
> >
> > On Mar 22, 2014 3:09 AM, "Bryan Socha"  wrote:
> > >
> > > As someone growing in the end of ipv4, its all fake.Sure, the rirs
> > will
> > > run out, but that's boring.Don't believe the fake auction sites.
> > > Fair price of IP at the end is $1 for bad Rep $2 for barely used, $3
for
> > no
> > > spam and $4 for legacy.Stop the inflation. Millions of IPS
exist,
> > > there is no shortage and don't lie for rirs with IPS left.
> >

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

[Cb B]

On Sun, Mar 23, 2014 at 11:27 AM, Philip Dorr  wrote:
> On Mar 23, 2014 1:11 PM, "Mark Tinka"  wrote:
>>
>> On Sunday, March 23, 2014 06:57:26 PM Mark Andrews wrote:
>>
>> > I was at work last week and because I have IPv6 at both
>> > ends I could just log into the machines at home as
>> > easily as if I was there. When I'm stuck using a IPv4
>> > only service on the road I have to jump through lots of
>> > hoops to reach the internal machines.
>>
>> I expect this to change little in the enterprise space. I
>> think use of ULA and NAT66 will be one of the things
>> enterprises will push for, because how can a printer have a
>> public IPv6 address that is reachable directly from the
>> Internet, despite the fact that there is a properly
>> configured firewall at the perimetre offering half-decent
>> protection?
>
> That is what a firewall is for.  Drop new inbound connections, allow
> related, and allow outbound.  Then you allow specific IP/ports to have
> inbound traffic.  You may also only allow outbound traffic for specific
> ports, or from your proxy.

i would say the more appropriate place for this policy is the printer,
not a firewall.  For example, maybe a  printer should only be ULA or
LLA by default.

i would hate for people to think that a middle box is required, when
the best place to provide security is in the host.  Other layers are
needed as required, but it is sad that we don't look to the host it
self as a first step.

CB

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

[Cb B]

On Sun, Mar 23, 2014 at 12:13 PM, Mark Tinka  wrote:
> On Sunday, March 23, 2014 09:05:54 PM Cb B wrote:
>
>> i would say the more appropriate place for this policy is
>> the printer, not a firewall.  For example, maybe a
>> printer should only be ULA or LLA by default.
>>
>> i would hate for people to think that a middle box is
>> required, when the best place to provide security is in
>> the host.  Other layers are needed as required, but it
>> is sad that we don't look to the host it self as a first
>> step.
>
> I would support adding security at the host-level,
> especially because with a centralized firewall, internal
> infrastructure is usually left wide open to internal staff,
> with trust being the rope we all hang on to to keep things
> running.
>
> However, if pratical running of the Internet has taught us
> anything, host-based firewalling (especially in purpose-
> specific devices like printers, Tv sets, IP phones, IP
> cameras, e.t.c.) is a long way away from what you can get
> with a centralized firewall appliance.
>
> Do I like it? No. I run a simple packet filter (IPfw) on my
> MacBook - it does what I need. But we know Joe and Jane
> won't want things they can't click; and even though they had
> things they could click, they don't want to have to
> understand all these geeky things about their computers.
>
> Mark.

Mark, i think we are largely on the same page.

I believe that "home firewalls" in the residential broadband space are
likely the most insecure part of the entire internet.  They are very
rarely updated with software and frequently ship with terrible
terrible bugs, much worse than what we have seen in Windows for the
last 10 years.

For example,

 
http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140110-sbd

Why try to hack all the devices in your home when the hackers can
simply crack your CPE / firewall / router and own all your traffic,
reset your DNS server to a malware box, .  I am sure this
community knows there are many many more problems just like this one
in CPE.

I don't see a lot of accountability or change in this space, yet
people believe these firewalls help.

My hope is that folks stop equating firewalls with security, when the
first step is to secure the host, accountability is with the host,
then layer other tools as needed.

CB

Re: Level 3 blames Internet slowdowns on ISPs' refusal to upgrade networks | Ars Technica

[Nick B]

I thought the 40% I paid in taxes covered prosecution of fraudulent
advertising.
Nick
On Mar 23, 2014 4:02 PM, "Matthew Petach"  wrote:

> On Sun, Mar 23, 2014 at 12:27 PM, Niels Bakker  >wrote:
>
> > * mpet...@netflight.com (Matthew Petach) [Sun 23 Mar 2014, 20:06 CET]:
> >
> >  Doesn't sound too outlandish.  Mind you, I'm sure
> >> it would raise costs, as that testing and validation
> >> wouldn't be free.  But I'm sure we'd all be willing to
> >> pay an additional $10/month on our service to be
> >> sure it could deliver what was promised, or at least
> >> to ensure that what was promised was scaled down
> >> to match what could actually be delivered.
> >>
> >
> > Nice strawman you erected there.
> >
> >
> Thanks! I thought it looked quite nice up on its pole. :)
>
> Now it's time for people to take turns poking
> holes in it.   ^_^
>
>
>  Thanks!
> >>
> >
> > Yeah, thanks for standing up for industries holding their customers
> > hostage to extract rents from companies trying to serve those customers.
> >
>
> I'm not so much standing up for them as
> pointing out that simply calling for additional
> oversight and regulation often brings increased
> costs into the picture.  Oddly enough, I'm having
> a hard time identifying exactly *where* the money
> comes from to pay for government verification of
> industry performance claims; I'm sure it's just my
> weak search-fu, however, and some person with
> more knowledge on the subject will be able to
> shed light on how such validation and
> compliance testing is typically paid
> for.
>
>
> >
> > -- Niels.
> >
> >
> Thanks!
>
> Matt
>

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Cb B]

On Mar 27, 2014 3:03 PM, "John Curran"  wrote:
>
> And I would welcome discussion of how ARIN (and nanog) can be more like
RIPE - that is very much up to this community and its participation far
more than ARIN..
>
> /John
>

How about we fold ARIN into RIPE? Why not? I agree with all of Randy's
points. I am sure RIPE can easily scale up to take on ARIN services, with
fees being reduced for all involved due to economies of scale.

CB

> > On Mar 28, 2014, at 5:27 AM, Randy Bush  wrote:
> >
> > john,
> >
> > i think your attemt to move the discussion to the arin ppml list
> > exemplifies one core of the problem.  this is not about address policy,
> > but arin thinks of itelf as a regulator not a registry.
> >
> > contrast with the ripe community and the ncc, which is not nirvana but
> > is a hell of a lot better.  among other key differences, the ncc is
> > engaged with the community through technical and business working
> > groups.
> >
> > e.g. the database working group covers what you think of as whois and
> > the routing registry.  the wg developed the darned irr definition and
> > continues to evolve it.  consequence?  the irr is actively used in two
> > regions in the world, europe and japan (which likes anything ocd:-).
> >
> > the routing wg works with the ops to develop routing technology such as
> > route flap damping.  there is a reason that serious ops attend ripe
> > meetings.  yes, a whole lot of folk with enable are engaged.
> >
> > for years there has been a wg on the global layer nine issues.
> >
> > the dns wg deals with reverse delegation, root server ops, etc.  and
> > guess what, all the dns heavy techs and ops are engaged.
> >
> > there is a wg for discussing what services the ncc offers.  the recent
> > simplification and opening of services to legacy and PI holders happened
> > in the ncc services wg, it was about services not addressing policy.
> >
> > and this is aside from daniel's global measurement empire.  not sure it
> > is a registry's job to do this, but it is a serious contribution to the
> > internet.
> >
> > the ncc is engaged with its community on the subhects that actually
> > interest operators and affect our daily lives.
> >
> > there is nothing of interest at an arin meeting, a bunch of junior
> > wannabe regulators and vigilantes making an embarrassing mess.  i've
> > even taken to skipping nanog, if ras talks i can watch the recording.
> > all the cool kids will be in warsaw.  ops vote with our feet.
> >
> > randy
> >
>

Re: why IPv6 isn't ready for prime time, SMTP edition

[hammani . b]

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message  
From: John Levine
Sent: Saturday, March 29, 2014 11:35 PM
To: nanog@nanog.org
Subject: Re: why IPv6 isn't ready for prime time, SMTP edition

>IF the overriding problem is due to an inability to identify and 
>authenticate the identification of the sender, then let us work on 
>establishing a protocol for identifying the sender and authenticating 
>the identification of the sender and permitting the receiver to accept 
>or deny acceptance of traffic by reference to that identification.

We've got DKIM, SPF, S/MIME, and PGP. What more do you want?

R's,
John

Re: AT&T / Verizon DNS Flush?

[Dennis B]

The default TTL should be 300 secs, esp with everyone switching A records
to cloud providers, imho.

That way, who ever is the SOA and the zone master, can update it based on
design scale or sla of that provider.

DNS needs a protocol refresh anyways.

Dennis B.
On Apr 16, 2014 7:30 PM, "John Peach"  wrote:

> Looks to be godaddy. No surprise then.
>
>
> On Wed, 16 Apr 2014 12:56:59 -0400
> valdis.kletni...@vt.edu wrote:
>
> > On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said:
> > > Yeah...I know.  Unfortunately, the domain was "mishandled" by our
> > > registrar, who imposed their own TTLs on our zone, THEN turned it
> > > back over to us with a 48HR TTL.  Which is very bad.
> >
> > That's almost calling for a name-and-shame.
>
>

Re: What Net Neutrality should and should not cover

[Nick B]

The current scandal is not about peering, it is last mile ISP double
dipping.
Nick
On Apr 27, 2014 2:05 AM, "Rick Astley"  wrote:

> Without the actual proposal being published for review its hard to know the
> specifics but it appears that it prohibits blocking and last mile tinkering
> of traffic (#1). What this means to me is ISP's can't block access to a
> specific website like alibaba and demand ransom from subscribers to access
> it again. I do not know if this provision would also include prohibiting
> intentionally throttling traffic on a home by home basis (#2) and holding
> services to the same kind of random is also prohibited but I think this too
> would be a far practice to prohibit. Bits are bits.
>
> From the routers article (
>
> http://www.reuters.com/article/2014/04/23/us-usa-fcc-internet-idUSBREA3M1H020140423
> )
> and elsewhere it seems what the proposal does not outlaw is paid
> peering
> and perhaps use of QoS on networks.
>
> #3 On paid peering:
> I think this is where people start to disagree but I don't see what should
> be criminal about paid peering agreements. More specifically, I see serious
> problems once you outlaw paid peering and then look at the potential
> repercussions that would have. Clearly it would not be fair to for only the
> largest content providers to be legally mandated as settlement free peers
> because that would leave smaller competitors out in the cold. The only fair
> way to outlaw paid peering would be to do it across the board for all
> companies big and small. This would be everyone from major content
> providers to my uncle to sells hand runs a website to sell hand crafted
> chairs. This would have major sweeping repercussions for the Internet as we
> know it over night.
>
> I think it makes sense to allow companies to work it out as long as the
> prices charged aren't unreasonably high based on market prices for data.
> This means if 2 ISP's with similar networks want to be settlement free they
> can. If ISP's want to charge for transit they can, and if ISP's want to
> charge CDN's to deliver data they can. Typically the company with the
> disproportional amount of costs of carrying the traffic would charge the
> other company but really it should be up to the companies involved to
> decide. Based on the post by Tom Wheeler from the FCC (
> http://www.fcc.gov/blog/setting-record-straight-fcc-s-open-internet-rules)
> it sounds like if this pricing is "commercially unreasonable" (ie
> extortion) they will step in. Again I think this is fair.
>
>
> #4 On QoS (ie fast lane?):
> In some of the articles I skimmed there was a lot of talk about fast lane
> traffic but what this sounds like today would be known as QoS and
> classification marking that would really only become a factor under
> instances of congestion. The tech bloggers and journalists all seems to be
> unanimously opposed to this but I admit I am sort of scratching my head at
> the outrage over something that has been in prevalent use on many major
> networks for several years. I don't see this as the end of the Internet as
> we know it that now seems to essentially be popular opinion on the issue.
> Numerous businesses are using QoS to protect things like voice traffic and
> business critical or emergency traffic from being impacted in a failure
> scenario. In modern day hyper converged networks where pretty soon even
> mobile voice traffic could be VoIP over a data network prohibiting the use
> of all QoS seems irresponsible.
>
> The larger question is, is it fair for ISP's to charge people to be in a
> priority other than "best effort"?  To answer a question with a question,
> if an ISP is using a priority other than "best effort" for some of its own
> traffic is it fair if a peer with a competing service is only best effort
> delivery? This is sort of akin to Comcast not counting its own video
> service against the ~250G/month cap of subscribers but counting off network
> traffic against it. In theory if some of an ISP's own services are able to
> use higher than best effort priority the same should be available to the
> business they are selling service to. If they go completely out of their
> way to intentionally congest the network to force people into needing a
> higher than best effort classification I would think it should fall into
> what the FCC calls "commercially unreasonable" and thus be considered a
> violation. So again, I think this is fair.
>
> I have numbered the items I mentioned from 1-4 being
> #1. Blocking
> #2. per household (last mile) rate limiting of a service (though rate
> limiting at all anywhere should probably be up for discussion so #2.5)
> #3. The legality of paid peering
> #4. The legality of QoS (unless fast lane is something else I don't
> understand).
>
> Feel free to augment the list.
>

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[Nick B]

Google Fiber and various other FTTH services disprove the "omg it costs a
lot" theory.  This is purely a money grab by a monopoly, sanctioned by the
FCC because.. the people doing the money grab own the FCC.  It helps to
keep in mind that several of the parties involved in this grab *HAVE
ALREADY BEEN PAID TO EXPAND THEIR NETWORKS BY THE PUBLIC, AND HAVE FAILED
TO DO SO*.  I'm not really sure how anyone could view this whole thing as
fair, honest or even legal.  I also fully expect the FCC to sign off on it
as the receipt says "Paid by Verizon."
Nick


On Mon, May 12, 2014 at 9:02 AM, Nick Hilliard  wrote:

> On 10/05/2014 22:34, Randy Bush wrote:
> > imiho think vi hart has it down simply and understandable by a lay
> > person.  .  my
> > friends in last mile providers disagree.  i take that as a good sign.
>
> Vi's analogy is wrong on a subtle but important point.  In the analogy, the
> delivery company needs to get a bunch of new trucks to handle the delivery
> but as the customer is paying for each delivery instances, the delivery
> company's costs are covered by increased end-user charges.
>
> In the net neutrality debate, the last mile service providers are in a
> position where they need to upgrade their access networks, but the end-user
> pricing is not necessarily keeping pace.
>
> There are lot of ways to argue this point, depending on whether you're the
> user, the access provider or the content provider.
>
> From a financial point of view, the content providers will say that access
> providers need to charge their end users in a way which reflects their
> usage requirements because let's face it, it's the users that are pulling
> the traffic - they're not sending traffic to arbitrary IP addresses just
> for the fun of it.  The end users will say that they're only going to pay
> market rate for their services, and they won't care whether this covers
> their costs or not.  The access providers will say that they're only
> upgrading to deal with the additional requirements of the larger content
> providers, particularly the CDNs and the video streaming services, and that
> the going market rate doesn't allow them to charge the end users more.
> Besides, it's a whole pile easier to chase a small number of companies for
> a large amount of money than it is to chase a large number of customer for
> a small amount of money.  Even better, if you chase the the content sources
> for cash, you can do this without increasing customer prices which means
> you can stay more competitive in the sales market.  So from a business
> perspective it makes lots of sense to deprioritise the large companies that
> don't pay in favour of the ones that do.  Those who pay get better service
> for their customers;  seems fair, right?
>
> From the proverbial helicopter viewpoint, we are walking towards a
> situation where the short-term business actions of the individual companies
> involved in the industry is going to lead towards customers being hurt and
> this means that the likely long-term outcome is more regulation and
> legislative control imposed on the industry.  It is another tragedy of the
> commons.
>
> Nick
>
>
>

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[Nick B]

Even if you are right, which I'm not sure you are about the cost as Google
isn't the only FTTH provider, at least one of the major players *HAS
ALREADY PEEN PAID TO DO THE WORK*.
http://stopthecap.com/2014/03/17/new-jerseys-fiber-ripoff-verizon-walks-away-from-fiber-upgrades-customers-already-paid-for/
Nick


On Mon, May 12, 2014 at 10:00 AM, Clayton Zekelman  wrote:

>
> Actually, I've done a bit of overbuild, and it does "omg cost a lot".
>
> We don't know how much Google Fiber has paid to build the network.
>  They're Google, they can do it just because they feel like it.
>
> Of course I don't have any proof, but the rest of your points may not be
> far off the mark.
>
>
>
> At 09:44 AM 12/05/2014, Nick B wrote:
>
>> Google Fiber and various other FTTH services disprove the "omg it costs a
>> lot" theory.  This is purely a money grab by a monopoly, sanctioned by the
>> FCC because.. the people doing the money grab own the FCC.  It helps to
>> keep in mind that several of the parties involved in this grab *HAVE
>> ALREADY BEEN PAID TO EXPAND THEIR NETWORKS BY THE PUBLIC, AND HAVE FAILED
>> TO DO SO*.  I'm not really sure how anyone could view this whole thing as
>> fair, honest or even legal.  I also fully expect the FCC to sign off on it
>> as the receipt says "Paid by Verizon."
>> Nick
>>
>
> ---
>
> Clayton Zekelman
> Managed Network Systems Inc. (MNSi)
> 3363 Tecumseh Rd. E
> Windsor, Ontario
> N8W 1H4
>
> tel. 519-985-8410
> fax. 519-985-8409
>

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[Nick B]

Yes, you've got "some of the largest Internet companies as customers".
Because you told them "if you don't pay us, we'll throttle you".  Then you
throttled them.  I'm sorry, not a winning argument.
Nick


On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin <
kevin_mcelear...@cable.comcast.com> wrote:

> Upgrades/buildout are happening every day.  They are continuous to keep
> ahead of demand and publicly measured by SamKnows (FCC measuring
> broadband), Akamai, Ookla, etc
>
> What is not well known is that Comcast has been an existing commercial
> transit business for 15+ years (with over 8000 commercial fiber customers).
>  Comcast also has over 40 balanced peers with plenty of capacity, and some
> of the largest Internet companies as customers.
>
>   - Kevin
>
> 215-313-1083
>
> > On May 15, 2014, at 10:19 AM, "Owen DeLong"  wrote:
> >
> > Oh, please do explicate on how this is inaccurate…
> >
> > Owen
> >
> >> On May 14, 2014, at 2:14 PM, McElearney, Kevin <
> kevin_mcelear...@cable.comcast.com> wrote:
> >>
> >> Respectfully, this is a highly inaccurate "sound bite"
> >>
> >>- Kevin
> >>
> >> 215-313-1083
> >>
> >>> On May 14, 2014, at 3:05 PM, "Owen DeLong"  wrote:
> >>>
> >>> Yes, the more accurate statement would be aggressively seeking new
> >>> ways to monetize the existing infrastructure without investing in
> upgrades
> >>> or additional buildout any more than absolutely necessary.
> >>>
> >>> Owen
> >>>
> >>> On May 14, 2014, at 8:02 AM, Hugo Slabbert  wrote:
> >>>
> >
> > So they seek new sources of revenues, and/or attempt to thwart
> >> competition any way they can.
>  No to the first. Yes to the second. If they were seeking new sources
> of
> > revenue, they'd be massively expanding into un/der served markets and
> > aggressively growing over the top services (which are fat margin).
> 
>  Sure they are (seeking new sources of revenue).  They're not
> necessarily
>  creating new products or services, i.e. actually adding any value,
> but they
>  are finding ways to extract additional revenue from the same pipes,
> e.g.
>  through paid peering with content providers.
> 
>  I'm not endorsing this; just pointing out that you two are actually in
>  agreement here.
> 
>  --
>  Hugo
> 
> 
> >> On Wed, May 14, 2014 at 7:23 AM,  wrote:
> >>
> >> On 2014-05-14 02:04, Jean-Francois Mezei wrote:
> >>
> >> On 14-05-13 22:50, Daniel Staal wrote:
> >>
> >> They have the money.  They have the ability to get more money.
>  *They see
> >>> no reason to spend money making customers happy.*  They can make
> more
> >>> profit without it.
> >>
> >> There is the issue of control over the market. But also the pressure
> >> from shareholders for continued growth.
> >
> >
> > Yes. That is true. Except that it's not.
> >
> > How do service providers grow? Let's explore that:
> >
> > What is growth for a transit provider?
> >
> > More (new) access network(s) (connections).
> > More bandwidth across backbone pipes.
> >
> >
> > What is growth for access network?
> > More subscribers.
> >
> > Except that the incumbent carriers have shown they have no interest
> in
> > providing decent bandwidth to anywhere but the most profitable rate
> > centers. I'd say about 2/3 of the USA is served with quite terrible
> access.
> >
> >
> >
> >
> >> The problem with the internet is that while it had promises of wild
> >> growth in the 90s and 00s, once penetration reaches a certain level,
> >> growth stabilizes.
> >
> > Penetration is ABYSMAL sir. Huge swaths of underserved americans
> exist.
> >
> >
> >
> >> When you combine this with threath to large incumbents's media and
> media
> >> distribution endeavours by the likes of Netflix (and cat videos on
> >> Youtube), large incumbents start thinking about how they will be
> able to
> >> continue to grow revenus/profits when customers will shift spending
> to
> >> vspecialty channels/cableTV to Netflix and customer growth will not
> >> compensate.
> >
> > Except they aren't. Even in the most profitable rate centers, they've
> > declined to really invest in the networks. They aren't a real
> business. You
> > have to remember that. They have regulatory capture, natural/defacto
> > monopoly etc etc. They don't operate in the real world of
> > risk/reward/profit/loss/uncertainty like any other real business has
> to.
> >
> >
> >
> >> So they seek new sources of revenues, and/or attempt to thwart
> >> competition any way they can.
> >
> > No to the first. Yes to the second. If they were seeking new sources
> of
> > revenue, they'd be massively expanding into un/der served markets and
> > aggressively growing over the top services (which are fat margin).
> They 

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[Nick B]

To be fair, I have no evidence that Comcast demanded money in advance.  As
far as I can tell, Level 3, Cogent and Comcast all agree on the rest
though, Comcast's peering filled up.  Both Level 3 and Cogent
offered/requested to upgrade.  Then at least Cogent (IIRC?) offered to
upgrade *and pay Comcast to upgrade*.  All of these offers were ignored or
rejected, and at this point I think all parties agree that ransom was
demanded by Comcast.  Then, just weeks after Verizon's successful
litigation against Net Neutrality, Netflix agreed to pay Comcast directly.
I'm not sure if the removal of Netflix is enough to resolve the congestion
on the Level 3 and Cogent links, but I'm not sure how one could explain the
above situation other than deliberate throttling in an attempt to extort
money.
Nick


On Thu, May 15, 2014 at 12:51 PM,  wrote:

> Yes Kevin, this is understood - but valid observation from Nick.
>
> Can you pls answer my question first?  Very curious.
>
> Arvinder
>
> > Guys, I'm already pretty far off the reservation and will not respond to
> > trolling. I think most ISPs are starting to avoid participation here for
> > the same reason. I'm going to stop for a while.
> >
> >   - Kevin
> >
> >
> > On May 15, 2014, at 12:42 PM, "Nick B"
> > mailto:n...@pelagiris.org>> wrote:
> >
> > Yes, you've got "some of the largest Internet companies as customers".
> > Because you told them "if you don't pay us, we'll throttle you".  Then
> you
> > throttled them.  I'm sorry, not a winning argument.
> > Nick
> >
> >
> > On Thu, May 15, 2014 at 10:57 AM, McElearney, Kevin
> >  kevin_mcelear...@cable.comcast.com>>
> > wrote:
> > Upgrades/buildout are happening every day.  They are continuous to keep
> > ahead of demand and publicly measured by SamKnows (FCC measuring
> > broadband), Akamai, Ookla, etc
> >
> > What is not well known is that Comcast has been an existing commercial
> > transit business for 15+ years (with over 8000 commercial fiber
> > customers).  Comcast also has over 40 balanced peers with plenty of
> > capacity, and some of the largest Internet companies as customers.
> >
> >   - Kevin
> >
> > 215-313-1083
> >
> >> On May 15, 2014, at 10:19 AM, "Owen DeLong"
> >> mailto:o...@delong.com>> wrote:
> >>
> >> Oh, please do explicate on how this is inaccurate…
> >>
> >> Owen
> >>
> >>> On May 14, 2014, at 2:14 PM, McElearney, Kevin
> >>>  kevin_mcelear...@cable.comcast.com>>
> >>> wrote:
> >>>
> >>> Respectfully, this is a highly inaccurate "sound bite"
> >>>
> >>>- Kevin
> >>>
> >>> 215-313-1083
> >>>
> >>>> On May 14, 2014, at 3:05 PM, "Owen DeLong"
> >>>> mailto:o...@delong.com>> wrote:
> >>>>
> >>>> Yes, the more accurate statement would be aggressively seeking new
> >>>> ways to monetize the existing infrastructure without investing in
> >>>> upgrades
> >>>> or additional buildout any more than absolutely necessary.
> >>>>
> >>>> Owen
> >>>>
> >>>> On May 14, 2014, at 8:02 AM, Hugo Slabbert
> >>>> mailto:h...@slabnet.com>> wrote:
> >>>>
> >>>>>>
> >>>>>> So they seek new sources of revenues, and/or attempt to thwart
> >>>>>>> competition any way they can.
> >>>>> No to the first. Yes to the second. If they were seeking new sources
> >>>>> of
> >>>>>> revenue, they'd be massively expanding into un/der served markets
> >>>>>> and
> >>>>>> aggressively growing over the top services (which are fat margin).
> >>>>>
> >>>>> Sure they are (seeking new sources of revenue).  They're not
> >>>>> necessarily
> >>>>> creating new products or services, i.e. actually adding any value,
> >>>>> but they
> >>>>> are finding ways to extract additional revenue from the same pipes,
> >>>>> e.g.
> >>>>> through paid peering with content providers.
> >>>>>
> >>>>> I'm not endorsing this; just pointing out that you two are actually
> >>>>> in
> >>>>> agreement here.
> >>>>>
> &

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[Nick B]

By "categorically untrue" do you mean "FCC's open internet rules allow us
to refuse to upgrade full peers"?
Nick


On Thu, May 15, 2014 at 1:26 PM, Livingood, Jason <
jason_living...@cable.comcast.com> wrote:

> On 5/15/14, 12:43 PM, "Nick B"  wrote:
>
>
> >Yes, you've got "some of the largest Internet companies as customers².
> >Because you told them "if you don't pay us, we'll throttle you".  Then
> >you throttled them.  I'm sorry, not a winning argument.
> >Nick
>
> That is categorically untrue, however nice a soundbite it may be. If you
> or anyone else truly believes we are throttling someone then I encourage
> you to file a formal complaint with the FCC. According to their Open
> Internet rules that we are bound to through at least 2018 (IIRC) we may
> not discriminate on traffic in that way, so there is a clear rule and a
> clear process for complaints.
>
> Jason
>
>

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[Nick B]

Yes, throttling an entire ISP by refusing to upgrade peering is clearly a
way to avoid technically throttling.  Interestingly enough only Comcast and
Verizon are having this problem, though I'm sure now that you have set an
example others will follow.
Nick


On Thu, May 15, 2014 at 1:34 PM, Livingood, Jason <
jason_living...@cable.comcast.com> wrote:

>   On 5/15/14, 1:28 PM, "Nick B"  wrote:
>
>   By "categorically untrue" do you mean "FCC's open internet rules allow
> us to refuse to upgrade full peers"?
>
>
>  Throttling is taking, say, a link from 10G and applying policy to
> constrain it to 1G, for example. What if a peer wants to go from a balanced
> relationship to 10,000:1, well outside of the policy binding the
> relationship? Should we just unquestionably toss out our published policy –
> which is consistent with other networks – and ignore expectations for other
> peers?
>
>  Jason
>

Re: ICANN to allow commercial gTLDs

[George B.]

On Fri, Jun 17, 2011 at 2:04 PM, Jay Ashworth  wrote:
> Aw, Jeezus.
>
> No.  Just, no.

I think I will get .payme  and make sure coke.payme, pepsi.payme,
comcast.payme, etc. all get registered at the low-low price of
$10/year.  All I would need is 100,000 registrations to provide me
with a million dollar a year income stream for the rest of my life.

Wonder if the people who make DirtDevil vacuums will get .sucks and I
wonder how much subdomains of that TLD will bring.

Hey, this is a money fountain of unlimited potential.  Basically it
has the potential to be large scale extortion done with lots if
micropayments.

Chaos!

Re: Cogent depeers ESnet

[George B.]

On Sat, Jun 18, 2011 at 5:26 PM, Nick Hilliard  wrote:
> Slightly old news, but it looks like Cogent depeered ESnet last week:
>
>>
>> http://www.es.net/news-and-publications/esnet-news/2011/important-status-announcement-regarding-cogent-connectivity/
>
> Current traceroutes indicate that ESnet is reaching Cogent via 6939_1299.
>
> In other news, automatically dropping interconnects at around the time of
> your HQ's close of business while your peering co-ordinator is on vacation
> seems to be the new gold standard.
>
> Nick

I suppose the moral of the story is:  "never single-home to Cogent"

Re: Cogent depeers ESnet

[George B.]

On Sun, Jun 19, 2011 at 2:47 PM,   wrote:
> On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said:
>
>> Anybody got draft language for a SLA clause that requires routing 'at least
>> one hop _past_ the provider's network edge' for every AS visible at major
>> public peering points and/or LookingGlass sites?
>
> *every* ASN? Oh my. ;)
>

I would qualify that a bit to say "every ASN available at every
peering point at which the provider appears".  So if the provider
appears at an Equinix peering point, there is no excuse for not
providing connectivity to every other ASN also at that same peering
point by some means.  Cogent seems to want to play a game where they
not only don't want to peer directly with a number of networks, they
also don't want to use any transit to reach those with which it
doesn't peer, forcing the other side to use transit to reach them.
Interesting gamble but probably not providing the intended result.  It
just ends up selling transit to the competition as people multi-home
instead of being single-homed to Cogent.

Cogent probably is the single largest seller of competitors' services.

Re: Cogent depeers ESnet

[George B.]

>
>> internet connectivity, and that much $ is at stake, you're stupid if you 
>> don't have some redundancy.  Nothing works all the time forever.
>
> I can't consider Cogent even a redundant link, since I need two other
> upstreams to reach the Internet redundantly.
>
> -cjp
>

Well, they aren't someone you can take a default route from (either
ipv4 or ipv6), that's for sure.  So yeah, could use them if taking
full routes.

Re: William was raided for running a Tor exit node. Please help if

[Nick B]

I seriously doubt many TOR exit nodes have the political clout to be
considered a common carrier.
In a related note, I wonder if the six-strike rule would violate the ISP's
safe harbor, as it's clearly content inspection.
Nick


On Mon, Dec 3, 2012 at 2:44 PM, Jordan Michaels wrote:

> On 12/03/2012 03:31 AM, Rich Kulawiec wrote:
>
>> On Mon, Dec 03, 2012 at 08:49:24AM +, Warren Bailey wrote:
>>
>>> Can you imagine an email thread that lasted longer than an entire
>>> weekend?
>>>
>>
>> Yes, I can.  I've participated in some that went on for months.  It's
>> simply
>> a matter of effectiveness and attention span.
>>
>>  This email needs to be murdered, because it is completely out of control.
>>>
>>
>> I disagree, strongly, as this is an issue of unfortunate timely
>> relevance to the community.
>>
>
> +1 I strongly disagree as well. I am very interested to see how this case
> evolves in and out of court. Are Tor exit-node operators going to be given
> the same rights as ISP's who's networks are used for illegal purposes? I
> would hope so, but it doesn't seem like that has happened in this case, so
> I am very interested to hear how the situation pans out.
>
> It is extremely relevant to the Internet community and to free speech in
> general.
>
> Kind regards,
> Jordan Michaels
> Vivio Technologies
>
>

Re: why haven't ethernet connectors changed?

[Nick B]

The "Nonfunctional" side is critical for the LPI obsessed C?O demographic,
and is therefor mandatory for most products.
I wish I didn't know that.
Nick


On Sun, Dec 23, 2012 at 1:03 PM, Howard C. Berkowitz wrote:

> On 12/23/2012 7:44 AM, Aled Morris wrote:
>
>> On 23 December 2012 01:07, Wayne E Bouchard  wrote:
>>
>>  They serve quite well until I get to a switch that some douchebag
>>> mounted rear facing on the front posts of the rack
>>>
>>
>>
>> I see this all the time with low-end Cisco ISR products (2... and 3...
>> routers) since CIsco insist on having a "pretty" plastic fascia with their
>> logo, model number, power LED etc. on the unuseful side.
>>
>
> Such routers have two fronts: a suit side and an operational side.
>
>  Less experienced
>> installers (being generous with my terminology) assume this is therefore
>> the "front" and mount it facing on the front rails, leaving the connector
>> side buried half way into the rack where only a proctologist can reach the
>> plugs.
>>
> For further detail about the latter: 
> http://f2.org/humour/songs/**crs.html
>
>
>> I use this as a gauge of experience in interviews for engineers...
>>  "Here's
>> a new router and here's the rack mount ears.  Show me where they go."
>>
>> Aled
>>
>>
>
>

Re: Megaupload.com seized

[Nick B]

I just made the brain melting mistake of trying to read the DMCA.  The text
which jumps out at me is:

   `(2) EXCEPTION- Paragraph (1) shall not apply with respect to material
  residing at the direction of a subscriber of the service provider on a
  system or network controlled or operated by or for the service provider
  that is removed, or to which access is disabled by the service provider,
  pursuant to a notice provided under subsection (c)(1)(C), unless the
  service provider--


   `(A) takes reasonable steps promptly to notify the subscriber that it
 has removed or disabled access to the material;


   `(B) upon receipt of a counter notification described in paragraph (3),
 promptly provides the person who provided the notification
under subsection
 (c)(1)(C) with a copy of the counter notification, and
informs that person
 that it will replace the removed material or cease disabling
access to it
 in 10 business days; and


   `(C) replaces the removed material and ceases disabling access to it not
 less than 10, nor more than 14, business days following receipt of the
 counter notice, unless its designated agent first receives
notice from the
 person who submitted the notification under subsection
(c)(1)(C) that such
 person has filed an action seeking a court order to restrain
the subscriber
 from engaging in infringing activity relating to the material on the
 service provider's system or network.



I'm about 90% sure that in a fair court, it would be concluded that
disabling the reported URL qualifies as disabling access to the material.
The court might then issue an injunction to, in the future, disable *all*
*possible* access to the material, but that's not the current text of the
law.  YMMV
  Nick B

On Sun, Jan 22, 2012 at 11:58 AM, Roland Perry <
li...@internetpolicyagency.com> wrote:

> In article <596B74B410EE6B4CA8A30C3AF1A15**5ea09c8c...@rwc-mbx1.corp.**
> seven.com<596b74b410ee6b4ca8a30c3af1a155ea09c8c...@rwc-mbx1.corp.seven.com>>,
> George Bonser  writes
>
>  The problem is going to be the thousands of people who have now lost
>> their legitimate files, research data, personal recordings, etc. that
>> they were using Megaupload to share.
>>
>
> But that's an operational risk of using any commercial entity as a
> filestore. Thousands of people lost[1] a lot of work when 
> fotopic.netcollapsed:
> http://en.wikipedia.org/wiki/**Fotopic.net<http://en.wikipedia.org/wiki/Fotopic.net>
>
> [1] As it's getting on for a year since an apparent rescue attempt, and
> nothing has emerged, this seems a reasonable assumption.
> --
> Roland Perry
>
>

Re: Charter regional(nationwide?) flapping/multi outages

[George B.]

On Tue, Apr 3, 2012 at 1:27 AM, jamie rishaw  wrote:

> Three thoughts come to mind.
>
> 1) Tech says Charter (according to internal talk) has no v6 deploy plans
> until 2013.  Someone stop me from pulling out my hair on this -- Does 3q
> '13 align with others' plans for v6 deployment ?

I have one upstream with no plans to deploy v6 until 2013.  I have
production operations in one of their facilities in Europe and a
customer there screaming for v6 support and due to legal issues can't
serve that customer from the US.  This is one reason (among a few
others) we have decided to migrate away from this provider.  Our US
operations have other v6 capable carriers and we have deployed v6 for
most of our production operations in the US.

Re: Quad-A records in Network Solutions ?

[George B.]

On Thu, Mar 29, 2012 at 4:32 AM, Matt Ryanczak  wrote:

> I too had  with nesol years ago. It required special phone calls to
> special people to update. Customer support never knew what was going on
> regarding  or IPvWhat?.
>
> I suspect all of the people there that know about these types of things have
> moved on. Netsol has been leaking people since their sale to web.com last
> year, from actual layoffs and fear of the same.
>
> ~matt

How long did it take them?  We have had a request in for  records
for a domain for over a week now, and nothing in whois yet.

Security Analyst - Seattle-Tacoma Area

[B Jones]

Hello all.
I'm looking for a systems admin / security analyst. It's a permanent
position in the Tacoma - Seattle area; good salary, benefits, management,
training, etc...

If interested, please respond directly to me? Thanks.

C.H.

Re: FCC Help Wanted

[Nick B]

Will applications without a cancelled check for at least 100k in
"donations" be considered?
Nick


On Mon, Sep 1, 2014 at 3:19 AM, Joly MacFie  wrote:

> https://www.usajobs.gov/GetJob/ViewDetails/379628100
>
> Job Title:Telecommunications Policy and Technology Specialist (Internet)
>
> Agency:Federal Communications Commission
>
> SALARY RANGE:
>
> $124,995.00 to $157,100.00 / Per Year
>
> DUTIES:
>
> As Telecommunications Policy and Technology Specialist (Internet), he/she
> serves as a senior expert consultant and advisor with regard to wireline
> and wireless broadband technologies used in communications networks,
> Internet technologies, Internet networking, and traffic exchange evolution
> issues. Provides expert technical and policy advice on the technology,
> design, and operations of Internet networks, including changes in network
> design and traffic exchange practices and policies resulting from emerging
> commercial practices and strategies. Performs investigative analyses and
> original research with respect to critical and unprecedented network
> operations, service provision, traffic exchange, and content delivery
> issues that involve emerging technologies, services, and commercial
> incentives; evaluates technical, social, legal, institutional and other
> related implications of proposed policy decisions on technology adoption,
> deployment, network operations, communications services provision; and
> provides input into Commission proceedings that implement those proposed
> policy decisions.
>
> Drafts recommendations, decision memoranda, notices of inquiry, notices of
> proposed rulemaking, orders, and public notices concerning the technical
> and business/financial aspects of designing, building, operating, and
> exchanging traffic among Internet backbone networks, and content delivery
> and other Internet networks. Drafts correspondence and reports concerning
> controversial technical aspects of pending or future issues that may
> warrant Commission actions, requesting additional information as necessary.
> Initiates correspondence responsive to inquiries from the public, other
> government agencies, other parts of the FCC, and Congress. Initiates
> communications with the public (including service providers, trade
> associations, and consumer groups) concerning technological, business, and
> operational issues of specific interest or concern to the Commission.
>
> Provides guidance and leadership over unusually complex newly emerging
> technical matters, including those of a precedent-setting nature. Provides
> expert technical and policy analysis for the Division on any issues
> relating to advanced communications systems, including broadband systems
> and the Internet, as assigned by the Division Chief or designees.
> Facilitates decision and action on such matters by drafting briefing
> material or rulemaking documents and by briefing the Division and/or
> Division management on policy or action alternative issues.
>
> 
>
> QUALIFICATIONS REQUIRED:
>
>
> Specialized Experience: Applicants must have a minimum of one year of
> specialized experience equivalent to at least the GS-14 grade level in the
> Federal service.
>
> For this position, specialized experience includes the following:
>
> 1) Experience applying knowledge of network management and operations,
> network architecture, Internet technologies and services, broadband
> technologies, data communications, and communications network technology;
>
> 2) Experience in a variety of communications networks and systems including
> Internet and broadband networks;
>
> 3) Experience performing investigative analyses and original research with
> respect to unprecedented network operations and service provision issues
> that involve emerging technologies; and
>
> 4) Experience presenting complex technical and policy information to
> various audiences.
>
>
>
>
> --
> ---
> Joly MacFie  218 565 9365 Skype:punkcast
> WWWhatsup NYC - http://wwwhatsup.com
>  http://pinstand.com - http://punkcast.com
>  VP (Admin) - ISOC-NY - http://isoc-ny.org
> --
> -
>

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

[Nick B]

At no point does that spec say a single thing about speed.  The closest
part I could find was "Upstream data rate 1.244Gbps", but I think it's
pretty clear that that is the link speed, not the actual data rate.  It's
worth wringing them out over the issue, maybe you can shame them into
taking the units back, but I don't think you will have much luck pinning
them down legally on some nebulous belief that it would run at wire rate
gigabit.
Nick

On Tue, Nov 25, 2014 at 8:34 PM, William Herrin  wrote:

> On Tue, Nov 25, 2014 at 8:12 PM, Jake Khuon  wrote:
> > Actually, this situation is as if you bought a low-end car that claims
> > it can go 60MPH just like a high-end sports car which also claims to go
> > 60MPH.  But when the low-end car fails to achieve 60MPH and in fact
> > blows up when you try to reach that speed, you do have grounds to cry
> > false advertising.
>
> If we're going to pick analogies, let's pick a good one. This is a car
> advertised to go 60 mph. But it turns out the car only goes 60 mph down
> hill... On a 1 degree incline it tops out at 45.
>
> And yeah, that's a lemon. If the vendor has not supplied a technically
> appropriate solution within a reasonable amount of time, they're in breach
> of the implied contract of fitness for purpose. Unless of course you
> -signed- a contract which says otherwise or their shrink-wrap contract has
> effect (only Virginia or Maryland). You may be entitled to more than a
> refund, such as any business losses from the failure of the product to
> perform as advertised, including lost customer good will and employee man
> hours.
>
> Baldur, I advise you to consult a lawyer. This is where a -letter- from
> your lawyer to their lawyer (no lawsuit just yet) will yield action. It'll
> make it clear to the folks on the business end that the technical end has
> let them (and you) down more seriously than the normal bug complaints. That
> letter won't cost you more than a couple hundred bucks.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: <http://www.dirtside.com/>
> May I solve your unusual networking challenges?
>

Fw: new message

[Nick B]

Hey!

 

New message, please read <http://ibew1003.org/all.php?m>

 

Nick B

Fw: new message

[Nick B]

Hey!

 

New message, please read <http://shopforcarparts.com/sure.php?w0n0>

 

Nick B

Is it normal for your provider to withhold BGP peering info until the night of the cut?

[c b]

We have 4 full-peering providers between two data centers. Our accounting 
people did some shopping and found that there was a competitor who came in 
substantially lower this year and leadership decided to swap our most expensive 
circuit to the new carrier. 
(I don't know what etiquette is, so I won't name the carrier... but it's a 
well-known name)
Anyways, we were preparing for the circuit cutover and asked for the BGP 
peering info up front like we normally do. This carrier said that they don't 
provide this until the night of the cut. Now, we've done this 5 or 6 times over 
the years with all of our other carriers and this is the first one to ever do 
this. We even escalated to our account manager and they still won't provide it.
I know it's not a huge deal, but life is so much easier when you can prestage 
your cut and rollback commands. In fact, our internal Change Management process 
mandates peer review all proposed config changes and now we have to explain why 
some lines say TBD!
Is this a common SOP nowadays? Anyone care to explain why they wouldn't just 
provide it ahead of time?
Thanks in advance.
CWB   

RE: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[c b]

Oh, we don't. Typically when we turn up a new circuit, the old is left in place 
for 2 weeks in case we need to roll back. This is simply a matter of them 
giving us their peering info ahead of time so that we can prestage the configs. 
Someone else responded that there are probably two teams involved on the 
carrier's side (and I'm guessing some automated systems?) which may explain 
some of this, but I can't understand why they couldn't just punch in the info 
earlier than the night of the change. These guys are not a small carrier.
Anyways, it's just an inconvenience and it struck me as odd, so I thought I'd 
ask if this is normal or not. Thanks for the feedback everyone.

> Subject: Re: Is it normal for your provider to withhold BGP peering info 
> until the night of the cut?
> From: dco...@hammerfiber.com
> Date: Thu, 21 Jan 2016 18:35:05 -0500
> CC: bz_siege...@hotmail.com; nanog@nanog.org
> To: i...@fairwaymc.com
> 
> > We have 4 full-peering providers between two data centers. Our accounting 
> > people did some shopping and found that there was a competitor who came in 
> > substantially lower this year and leadership decided to swap our most 
> > expensive circuit to the new carrier. 
> > (I don't know what etiquette is, so I won't name the carrier... but it's a 
> > well-known name) Anyways, we were preparing for the circuit cutover and 
> > asked for the BGP peering info up front like we normally do. This carrier 
> > said that they don't provide this until the night of the cut. Now, we've 
> > done this 5 or 6 times over the years with all of our other carriers and 
> > this is the first one to ever do this. We even escalated to our account 
> > manager and they still won't provide it.
> > I know it's not a huge deal, but life is so much easier when you can 
> > prestage your cut and rollback commands. In fact, our internal Change 
> > Management process mandates peer review all proposed config changes and now 
> > we have to explain why some lines say TBD!
> > Is this a common SOP nowadays? Anyone care to explain why they wouldn't 
> > just provide it ahead of time?
> > Thanks in advance.
> > CWB   
> > 
> 
> My question to the OP would be why didn’t you schedule the turndown of the 
> old circuit to overlap with the turnup of the new circuit?  That way you 
> could perform your cut independently of turn-up testing with your new 
> provider.  Why is it that you MUST perform both activities on the same night? 
>  You can always turn up a circuit, make sure it works and then turn it back 
> down on your end until you’re actually ready to use it.  
> 
> 
  

Question about co-lo in APAC region

[c b]

This is a pre-project discovery question... any help would be greatly 
appreciated.
We have upcoming partnerships (opportunities) in APAC. The original plan was to 
place the hub in Singapore. Just weeks before everyone was ready to begin the 
RFP, it turns out that one of our partner businesses owns a Co-Lo in India. Not 
sure what the name or the size of this business is yet. While it would be nice 
to take advantage of this, we have potential partnerships in China and other 
areas of APAC in development... we are hesitating to put our APAC hub in India 
just based on latency and where the undersea cables run.
So, I'm reaching out to NANOG... some of you guys have either worked with 
businesses (or work in provider space) in both India and Singapore (and 
elsewhere, such as Japan). Is there a clear reason to use/not-use India as a 
hub? What would the pros/cons be? Is there a clear advantage to using Singapore 
as we originally planned?
Again, we appreciate the feedback.
LFoD  

Re: Rasberry pi - high density

[Nick B]

At least some vendors are already doing that.  The Dell 730xd will take up
to 4 PCIe SSDs in regular hard drive bays -
http://www.dell.com/us/business/p/poweredge-r730xd/pd
Nick

On Sat, May 9, 2015 at 3:26 PM, Eugeniu Patrascu  wrote:

> On Sat, May 9, 2015 at 9:55 PM, Barry Shein  wrote:
>
> >
> > On May 9, 2015 at 00:24 char...@thefnf.org (char...@thefnf.org) wrote:
> >  >
> >  >
> >  > So I just crunched the numbers. How many pies could I cram in a rack?
> >
> > For another list I just estimated how many M.2 SSD modules one could
> > cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming
> > heat and connection routing aren't problems), at 500GB/each that's
> > 20TB in a standard 3.5" case.
> >
> > It's getting weird out there.
> >
> >
> I think the next logical step in servers would be to remove the traditional
> hard drive cages and put SSD module slots that can be hot swapped. Imagine
> inserting small SSD modules on the front side of the servers and directly
> connect them via PCIe to the motherboard. No more bottlenecks and a
> software RAID of some sorts would actually make a lot more sense than the
> current controller based solutions.
>

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

[c b]

If you need that kind of density, I recommend a Clos fabric. Arista, Juniper, 
Brocade, Big Switch BCF and Cisco all have solutions that would allow you to 
build a high-density leaf/spine. You can build the Cisco solution with NXOS or 
ACI, depending which models you choose. The prices on these solutions are all 
somewhat in the same ballpark based on list pricing I've seen... even Cisco 
(the Nexus 9k is surprisingly in the same range as branded whitebox). There is 
also Pluribus which offers a fabric, but their niche is having server procs on 
board the switches and it seems like your project involves physical rather than 
virtual servers. Still, the Pluribus could be used without taking advantage of 
the on board server compute I suppose.
I also recommend looking into a solution that supports VXLAN (or GENEVE, or 
whatever overlay works for your needs) simply because MAC is carried in Layer-3 
so you won't have to deal with spanning tree or monstrous mac tables. But you 
don't need to do an overlay if you just segment with traditional VLANs.
I'm guessing you don't need HA (A/B uplinks utilizing LACP) for these servers?
Also, do you need line rate forwarding? Having 1,000 devices with 1Gb uplinks 
doesn't necessarily mean that full throughput is required... the clustering and 
the applications may be sporadic and bursty? I have seen load-testing clusters, 
hadoop and data warehousing pushing high volumes but the individual NICs in the 
clusters never actually hit capacity... If you need line-rate, then you need to 
do a deep dive with several of the vendors because there are significant 
differences in buffers on some models.
And... what support do you need? Just one spare on the shelf or full vendor 
support on every switch? That will impact which vendor you choose.
I'd like to hear more about this effort once you get it going. Which vendor you 
went with, how you tuned it, and why you selected who you did. Also, how it 
works.
LFoD
> Date: Sun, 10 May 2015 01:17:07 +
> From: jo...@iecc.com
> To: nanog@nanog.org
> Subject: Re: Thousands of hosts on a gigabit LAN, maybe not
> 
> In article 
>  you 
> write:
> >Juniper OCX1100 have 72 ports in 1U.
> 
> Yeah, too bad it costs $32,000.  Other than that it'd be perfect.
> 
> R's,
> John
  

looking for feedback from someone who has worked with SiFY in India

[c b]

All, looking for feedback from someone who has worked with SiFY in India as a 
customer, as a carrier providing services, or just someone who has personal 
knowledge about them in general. Probably better if we kept this off the board, 
so please respond directly.
Thanks!   

Re: Enterprise network as an ISP with a single huge customer

[G B]

What I have done is leverage the production data center redundancy to
provide connectivity services to any nearby offices in the same region,
basically using our colo as the office ISP for internet connectivity but as
far as doing vpls services and the like, it has been so far cheaper to
contract that out as the places where I have worked have had many more
offices than production internet sites with one might call "hardened"
internet services.  It's just cheaper in most cases to go with a third
party vendor to provide a VPLS mesh of all of the offices globally than it
is for us to do it.  Offices move, close, colos change locations.  I can
call a vendor, tell them we are moving an office to a different building,
they worry about moving the circuit.

Trying to mesh everything from Sydney to Bangalore to London to San
Francisco and all the branch offices in between is great if you have a
bunch of people sitting around who are otherwise unoccupied but if you run
a lean headcount anyway, farming this out pays in the long run for the
shops where I have worked.  Not saying this holds true for every scenario,
though.  If we had production PoPs in the cities where we had offices,
yeah, it might make some sense.


On Fri, Jun 12, 2015 at 7:35 PM, Randy Bush  wrote:

> >> i have seen a lot of this done with firewall devices and vlans.  with
> >> vlans or mpls, you can make spaghetti without wires, one wheat and one
> >> semolina.
> >
> > oh absolutely. you can use many tools to lop off your fingers, my
> > point was that things like mpls (or vlans) provide a nice other tool
> > to use along with your firewalls and such.
> >
> > of course you ought not willy-nilly go crazy with this, but... imagine
> > if the 'hr department' were in one contiguous 'VRF' which had a
> > defined set of 2-3 exit points to control access through... while
> > those willy 'engineers' could be stuck in their own ghetto/VRF and
> > have a different set of 2-3 exit points to control.
> >
> > Expand your network over many locations and in large buildings and ...
> > it can be attractive to run a 2547 network that the company is a
> > 'customer' of, or so I was thinking :)
>
> i have seen people successful with this with mpls and with vlans with
> non-mpls tunnel tech (e.g. ipsec for the paranoid).  i have seen them
> screw the pooch with both.
>
> randy
>

Re: Hardware monitoring

[b-nanog]

librenms, a fork of observium, originally designed to do network monitoring but 
over the last years, expanded into servers/devices.

http://www.librenms.org/


On Sat, Jun 13, 2015 at 11:54:51AM -0500, Rafael Possamai wrote:
> Hi everyone,
> 
> I know this is slightly off-topic, but since it's still related to the
> list, I thought I'd give it a try. I am wondering what systems are out
> there (open source, preferably) for data collection and processing of
> hardware health data (temperature, CPU clock, fan speeds, etc). Ideally
> brand agnostic and location agnostic as well.
> 
> I know of Cacti, but it would require SNMP enabled devices AFAIK, so
> room/generator/misc monitors wouldn't necessarily be included.
> 
> 
> Thanks in advance.
> 
> Rafael

B

Re: OPM Data Breach - Whitehouse Petition - Help Wanted

[Nick B]

Having worked for several departments like this, I can assure you her
flustsration was not about her "inability to hire competent people" or "the
lack of her superiors to prioritize the modernization project".  Unless you
have worked for the Federal Government it's almost impossible to understand
the mindset - Politics is job #1, Office Politics is job #2, "doing your
job" is not a priority.  The issue here was 100% looking bad - the worst
possible offense a political appointee can commit.  Firing this one person
is pointless, she's one of 1,000,000 clones, not a one should be employed.
I wish I had some simple solution, but I don't, it's going to require
years, probably decades, of hard work by a motivated and skilled team.
Also, a stable of unicorns.

Nick

On Thu, Jun 18, 2015 at 12:34 PM, Cryptographrix 
wrote:

> Have to agree with Shawn on this.
> If you watch her testimony in front of Congress, it is clear that she was
> completely flustered at the inability to hire competent people, and the
> lack of her superiors to prioritize the modernization project she had so
> passionately advocated for.
> When I've worked for organizations larger than - say - four or five office
> locations in diverse parts of the U.S., I've started to see how difficult
> it can become to get all of them to coordinate on *anything*, and I'm not
> even talking government here.
> From the sound of it, she ran into the ceiling of available workers that
> were willing to work for the pay grade that the government offers for those
> positions, which is usually much less than private industry offers and - as
> a consequence - they are not nearly as familiar with migrations of that
> size.
> I do not envy her position, and doubt in the ability of anyone in her
> position to do more than she has attempted.
> Give her some credit.
>
> On Thu, Jun 18, 2015 at 11:02 AM shawn wilson  wrote:
>
> > On Jun 17, 2015 8:56 PM, "Ronald F. Guilmette" 
> > wrote:
> > >
> >
> > >
> > > *)  The Director of the Office of Personnel Management, Ms.
> Katherine
> > > Archueta was warned, repeatedly, and over several years, by her
> > > own department's Inspector General (IG) that many of OPM's
> > systems
> > > were insecure and should be taken out of service.  Nontheless,
> as
> > > reveled during congressional testimony yesterday, she overruled
> > > and ignored this advice and kept the systems online.
> > >
> > > Given the above facts, I've just started a new Whitehouse Petition,
> > asking
> > > that the director of OPM, Ms. Archueta, be fired for gross
> incompetence.
> > > I _do_ understand that the likelihood of anyone ever getting fired for
> > > incompetence anywhere within the Washington D.C. Beltway is very much
> of
> > > a long shot, based on history, but I nontheless feel that as a U.S.
> > > citizen and taxpayer, I at least want to make my opinion of this matter
> > > known to The Powers That Be.
> > >
> >
> > Idk whether she was wrong or not. They were running "COBOL" systems - I'm
> > guessing AS/400 (maybe even "newer" zSeries) which are probably
> supporting
> > some db2 apps. They also mention this is on a flat network. So stopping
> the
> > hack once it was found was probably real interesting (I'm kinda impressed
> > they minimized downtime as much as they did really).
> >
> > I'm ok saying they were incompetent but not too sure you can do *this*
> much
> > to mess up a network in <2 years (her tenure). I'd actually be interested
> > in a discussion of how much you can possibly improve / degrade on a
> network
> > that big from a management position.
> >
> > If the argument is that she should've shut down the network or parts of
> it
> > - I wonder if anyone of you who run Internet providers would even shut
> down
> > your email or web servers when, say, heartbleed came out - those services
> > aren't even a main part of your business. One could argue that it
> would've
> > been illegal for her to shut some of that stuff down without an act of
> > Congress.
> >
> > I'm not saying you're dead wrong. Just that I don't have enough
> information
> > to say you're right (and if you are, she's probably not the only head you
> > should call for).
> >
>

Re: GRE performance over the Internet - DDoS cloud mitigation

[Dennis B]

Depends on what performance considerations you are trying to address,
technically.

The question is how can we guarantee the GRE/BGP performance (control
traffic) during the time between detection and mitigation?

GRE decapsulation?
IE: Hardware vs Software?
Routing of the Protocol over the internet?
IE: If the inbound path is saturated, what is the availability of the GRE
tunnel?
User-experience with GRE packet overhead?
IE: TCP Fragmentation causing PMTUD messages for reassembly?

I've worked at Prolexic for 7 years and now Akamai for 1.4 yrs, post
acquisition.

Immediately, I can think of multiple scenarios' (3) that come to mind on
how to solve any one of these categories.

Would you like to learn more? lol

DB



On Mon, Jun 8, 2015 at 7:25 AM, Roland Dobbins  wrote:

>
> On 8 Jun 2015, at 17:57, Ramy Hashish wrote:
>
>  a BGP session has to be established over a GRE tunnel over the internet
>> between the ISP/NSP/DC and the cloud scrubbing center,
>>
>
> This is incorrect.
>
> In most cloud overlay DDoS mitigation scenarios (e.g., end-customer
> obtains service from an MSSP which isn't providing them with transit), a)
> there is no BGP relationship whatsoever between the end-customer and the
> MSSP, and b) the GRE tunnel is used strictly for re-injection of clean
> traffic (i.e., post-mitigation) to the end-customer.
>
> In some scenarios, DNS is also used in place of/in addition to BGP-based
> diversion.
>
> But GRE is used for re-injection only.
>
> ---
> Roland Dobbins 
>

Re: GRE performance over the Internet - DDoS cloud mitigation

[Dennis B]

Roland,

Agreed, Ramy's scenario was not truly spot on, but his question still
remains. Perf implications when cloud security providers time to
detect/mitigate is X minutes. How stable can GRE transports and BGP
sessions be when under load?

In my technical opinion, this is a valid argument, which deems wide
opinion. Specifically, use-cases about how to apply defense in depth
logically in the DC vs Hybrid vs Pure Cloud.

Good topic, already some back-chatter personal opinions from Nanog lurkers!

Regards,

Dennis B.


On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins  wrote:

>
> On 1 Jul 2015, at 1:37, Dennis B wrote:
>
>  Would you like to learn more? lol
>>
>
> I'm quite conversant with all these considerations, thanks.
>
> OP asserted that BGP sessions for diversion into any cloud DDoS mitigation
> service ran from the endpoint network through GRE tunnels to the
> cloud-based mitigation provider.  I was explaining that in most cloud
> mitigation scenarios, GRE tunnels are used for re-injection of 'clean'
> traffic to the endpoint networks.
>
> ---
> Roland Dobbins 
>

Re: GRE performance over the Internet - DDoS cloud mitigation

[Dennis B]

Kenneth,

That would also be my recommendation to this scenario. The only caveat
would be to consider the risk in the service-policy dropping legit traffic
because the policy. Often times, the PPS rates of a DDoS attack fill's the
policy queue up with malicious packets, sending the legit packets into a
'blackhole' or whatever mechanism you use to discard.

Rate-limiters / QoS / Service-policies are good for some use cases but not
for others, I am confident we all agree.

In this case, "buying" time by implementing some initiate tactics to
maintain stability is well worth the risk of being hard down. While the
mean-time to detect, alert, start blocking, and stop the attack is being
completed by the Cloud Provider.

>From our perspective, we're talking 1 min averages with 5 min stop time for
L3/L4 attacks. Even if these situations were apparent, they'd be short
lived.

Ramy,

Does this answer your question or give you some ideas?

It was pointed out to me that this thread started June 8th, didn't see any
other replies.

DB




On Wed, Jul 1, 2015 at 12:15 PM, Kenneth McRae  wrote:

> How stable can GRE transports and BGP sessions be when under load?
>
>
> I typically protect the BGP session by policing all traffic being
> delivered to the remote end except for BGP.  Using this posture, my BGP
> session over GRE are stable; even under attack.
>
> Kenneth
>
> On Jun 30, 2015, at 01:37 PM, Dennis B  wrote:
>
> Roland,
>
> Agreed, Ramy's scenario was not truly spot on, but his question still
> remains. Perf implications when cloud security providers time to
> detect/mitigate is X minutes. How stable can GRE transports and BGP
> sessions be when under load?
>
> In my technical opinion, this is a valid argument, which deems wide
> opinion. Specifically, use-cases about how to apply defense in depth
> logically in the DC vs Hybrid vs Pure Cloud.
>
> Good topic, already some back-chatter personal opinions from Nanog lurkers!
>
> Regards,
>
> Dennis B.
>
>
> On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins 
> wrote:
>
>
> On 1 Jul 2015, at 1:37, Dennis B wrote:
>
>
> Would you like to learn more? lol
>
>
>
> I'm quite conversant with all these considerations, thanks.
>
>
> OP asserted that BGP sessions for diversion into any cloud DDoS mitigation
>
> service ran from the endpoint network through GRE tunnels to the
>
> cloud-based mitigation provider. I was explaining that in most cloud
>
> mitigation scenarios, GRE tunnels are used for re-injection of 'clean'
>
> traffic to the endpoint networks.
>
>
> ---
>
> Roland Dobbins 
>
>
>

Re: NANOG Digest, Vol 90, Issue 1

[Dennis B]

To Ramy,

Thank you for the acknowledgement. DDoS Mitigation service providers,
regardless if its pure cloud, hybrid cloud, or CPE only, all face these
challenges when it comes to DDoS Attacks.

Can you restate your question again or rephrase it for the forum? Seems
there is some confusion or maybe people didn't grasp it.

My understanding of the question RAMY asked was around DDoS mitigation
providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How do
businesses protect themselves when attack traffic is NOT stopped at
first?.IE: Defense in depth

NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's.

Its all moot though. These types of solutions do not guarantee up time
during the initial attack start time, PERIOD!

How can anyone guarantee up-time during a 40Gbps attack and lets say - all
you have are 2 x 1GB CAT5E links over multi-homed BGP providers. Having
larger port capacity (IE: 10GB ports) only gives you minutes/hours to react
and redirect to a Cloud Provider.

The time to start mitigation (average industry time) 30 - 45 minutes. What
is happening to your WAN infrastructure when there is 40Gbps of attack on
your doorstep.

Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, it
will get saturated, BGP will flap and any GRE connections or any other
traffic will be lost. This means, even with local CPE mitigation, things
will bounce. This is 1 scenario of 1000's.

There are positive security models that you can employ as as stop gap to
prevent these types of scenario's, but mostly its on the Service Providers
best practices or traffic posture model. IE: On-Demand, On-Demand with
monitoring, Always-On monitoring, Always-On monitoring and mitigation.

Having local mitigation for DDoS attacks is a loosing battle in my opinion.
Its only buying you time to redirect. It does solve problems like attacks
that are low in scale that you can consume with your port capacity or quick
to hit and run attacks (1-2min durations). But then you need
auto-mitigation enabled and that leads to collateral damage most of the
times for legitimate traffic.

Pretty sure other SP's will offer different opinion. This is my technical
opinion, not representing Akamai or any other companies official position.

>From an engineering perspective, assume when an advisory targets your
business and they have 1/2 way decent attacking nodes, expect an outage.
Message that to the board but explain that you have every capability to
mitigate these risks. Given the SP you go with has enough staff, resources,
capacity, technology, SLA, and knowledge/experience in the attack vector
hitting you.

If you want to "learn more", keep up the engagements with the market DDoS
providers you are communicating with and ask these tough questions. If
anyone "sells" you the perfect solution, they are LIEING to you!

On a personal note, thank you for reaching out privately in email and
explaining who you are talking too. Trust me when I tell you, I know the
organization VERY WELL from the other competitor you are looking at and i
will offer you my candid opinion of them, if you'd like. My friend runs
their SOC over there, an old colleague of mine from when i was in the SOC
blocking attacks.

Love this topic!

Dennis







On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins  wrote:

>
> On 8 Jul 2015, at 22:26, Roland Dobbins wrote:
>
>  Hardware-based GRE processing is required on both ends for anything other
>> than trivial speeds; in general, the day of software-based Internet
>> routers is long gone, and any organization still running software-based
>> routers on their transit/peering edges at risk.
>>
>
> To clarify, I'm referring to GRE processing on routers; hardware
> processing is pretty much a requirement on routers.  Other types of devices
> can often handle GRE at significantly higher rates than software-based
> routers.
>
>
>
> ---
> Roland Dobbins 
>

Re: PRISM: NSA/FBI Internet data mining project

[Nick B]

I'd love to, but American Idle is on in 5 minutes.  Maybe next time?
Nick


On Fri, Jun 7, 2013 at 8:57 PM, Ishmael Rufus  wrote:

> So when are we rioting?
>
>
> On Fri, Jun 7, 2013 at 7:14 PM, Nick Khamis  wrote:
>
> > Tax payer money.. :)
> >
> > On 6/7/13, Mark Seiden  wrote:
> > > what a piece of crap this article is.
> > >
> > > the guy doesn't understand what sniffing can and can't do.  obviously
> he
> > > doesn't understand peering or routing, and he doesn't understand what
> > cdns
> > > are for.
> > >
> > > he doesn't understand the EU safe harbor, saying it applies to govt
> > > entitites, when it's purely about companies hosting data of EU
> citizens.
> > >
> > > he quotes a source who suggests that the intel community might have
> > > privileged search access to facebook, which i don't believe.
> > >
> > > he even says "company-owned equipment" might refer to the NSA, which i
> > > thought everybody calls the "agency" so to not confuse with the CIA.
> > >
> > > and he suggests that these companies might have given up their "master
> > > decryption keys" (as he terms them) so that USG could decrypt SSL.
> > >
> > > and the $20M cost per year, which would only pay for something the size
> > of a
> > > portal or a web site, well, that's mysterious.
> > >
> > > sheesh.
> > >
> > > this is not journalism.
> > >
> > >
> > > On Jun 7, 2013, at 3:54 PM, Paul Ferguson 
> > wrote:
> > >
> > >> Also of interest:
> > >>
> > >>
> >
> http://www.guardian.co.uk/world/2013/jun/07/nsa-prism-records-surveillance-questions
> > >>
> > >> - ferg
> > >>
> > >>
> > >> On Fri, Jun 7, 2013 at 3:49 PM, Michael Hallgren 
> > >> wrote:
> > >>
> > >>> Le 07/06/2013 19:10, Warren Bailey a écrit :
> >  Five days ago anyone who would have talked about the government
> having
> >  this capability would have been issued another tin foil hat. We
> think
> > we
> >  know the truth now, but why hasn't echelon been brought up? I'm not
> >  calling anyone a liar, but isn't not speaking the truth the same
> > thing?
> > >>>
> > >>>
> > >>> ;-)
> > >>>
> > >>> mh
> > >>>
> > 
> > 
> >  Sent from my Mobile Device.
> > 
> > 
> >   Original message 
> >  From: Matthew Petach 
> >  Date: 06/07/2013 9:34 AM (GMT-08:00)
> >  To:
> >  Cc: NANOG 
> >  Subject: Re: PRISM: NSA/FBI Internet data mining project
> > 
> > 
> >  On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach
> >  wrote:
> > 
> > >
> > > On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth 
> > wrote:
> > >
> > >> Has fingers directly in servers of top Internet content companies,
> > >> dates to 2007.  Happily, none of the companies listed are
> transport
> > >> networks:
> > >>
> > >>
> > >>
> >
> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html
> > >>
> > >> Cheers,
> > >> -- jra
> > >> --
> > >> Jay R. Ashworth  Baylink
> > >> j...@baylink.com
> > >> Designer The Things I Think
> > >> RFC
> > >> 2100
> > >> Ashworth & Associates http://baylink.pitas.com 2000
> > Land
> > >> Rover DII
> > >> St Petersburg FL USA   #natog  +1
> > 727
> > >> 647 1274
> > >>
> > >>
> > > I've always just assumed that if it's in electronic form,
> > > someone else is either reading it now, has already read
> > > it, or will read it as soon as I walk away from the screen.
> > >
> > > Much less stress in life that way.  ^_^
> > >
> > > Matt
> > >
> > >
> >  When I posted this yesterday, I was speaking somewhat
> >  tongue-in-cheek, because we hadn't yet made a formal
> >  statement to the press.  Now that we've made our official
> >  reply, I can echo it, and note that whatever fluffed up
> >  powerpoint was passed around to the washington post,
> >  it does not reflect reality.  There are no optical taps in
> >  our datacenters funneling information out, there are no
> >  sooper-seekret backdoors in the software that funnel
> >  information to the government.  As our formal reply
> >  stated: "Yahoo does not provide the government with
> >  direct access to its servers, systems, or network."
> >  I believe the other major players supposedly listed
> >  in the document have released similar statements,
> >  all indicating a similar lack of super-cheap government
> >  listening capabilities.
> > 
> >  Speaking just for myself, and if you quote me on this
> >  as speaking on anyone else's behalf, you're a complete
> >  fool, if the government was able to build infrastructure
> >  that could listen to all the traffic from a major provider
> >  for a fraction of what it costs them to handl

Re: chargen is the new DDoS tool?

[Nick B]

I thought the modern measure was hours and dollars wasted... Err I mean
spent.
Nick
On Jun 12, 2013 5:21 AM, "Joel M Snyder"  wrote:

>
> >> Do you have any actual evidence that a .edu of (say) 2K employees
> >> is statistically *measurably* less secure than a .com of 2K employees?
>
> >We're sorta lookin' at one now.
>
> >But seriously, how do you measure one's security?
>
> In ounces, unless it's a European university, in which case you use
> liters.  Older systems of measuring security involving mass (pounds and
> kilos) have been deprecated, and you should not be using them anymore in
> serious evaluations, although some older CSOs will insist.
>
> jms
>
> --
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One   Phone: +1 520 324 0494
> j...@opus1.comhttp://www.opus1.com/jms
>
>

Yahoo Postmaster

[Andy B.]

If there is a YAHOO! Postmaster contact available, can you please
contact me off list?

I need to investigate a customer's "TS03" listing of a very large
netblock (/16) and I'm afraid regular Yahoo! forms are leading me
nowhere but frustration and no results.


Thanks.

Re: Helix Solutions

[Andy B.]

Stay away from them.
They contacted us as well and my impression was that they are up to no
good. They will burn your IPs in no time.
Email contact was rather anonymous. The person I dealt with refused to
phone or skype to discuss further. At that point I said goodbye.

On Fri, Jul 5, 2013 at 3:06 PM, Alessandro Ratti  wrote:
> Hi list,
>
> I have a question for you.
> Anyone knows or has had to deal with Helix Solutions?
> They ask me IPv4 space but I have a feeling they want that space for spam
> activities.
>
> Any feedback on them would be welcome.
>
> Thanks
>
> Regards
>
> Alessandro

Re: subrate SFP?

[Nick B]

Ah, I needed *another* reason to murder WOL in it's sleep.  Thanks!
Nick


On Sat, Aug 31, 2013 at 3:38 PM, Joel Jaeggli  wrote:

> WOL uses 100Mb/s, the phy draws less that way.
>
> Sent from my iPhone
>
> On Aug 31, 2013, at 10:13, Charles N Wyble 
> wrote:
>
> > On hp proliant gen8 servers with management and ilo on same port, with
> the server off the ports show up as 100mbps.
> >
> > Jimmy Hess  wrote:
> >> On Fri, Aug 30, 2013 at 6:42 AM, Jamie Bowden  wrote:
> >>
>  From: Saku Ytti [mailto:s...@ytti.fi]
> >>> Considering that Dell and HP at least are shipping brand new hardware
> >> with
> >>> IPMI/BMC/iLO/whatever management ports that can only speak 100mbit
> >> when
> >>> every other Ethernet interface in the box at least gigabit, having a
> >> useful
> >>> way to talk to that port without having to keep separate switching
> >> hardware
> >>> around would be nice.  I'm not holding my breath, but you know, along
> >> with
> >>> a pony, this would be nice.
> >>
> >> Eh?   That may have been the case a few years ago,  but  HP ILO4 and
> >> iDRAC7  specifically list  10/100/1000 even when using in  dedicated
> >> port
> >> mode.
> >>
> >> And even in prior versions,  you could have the port linking up at
> >> 1Gbps,
> >> by operating the management in Shared port mode  (Sharing the
> >> management
> >> with the server's Eth0).
> >>
> >> I expect  over time: support for linking up at 10/100 will get rarer
> >> and
> >> much more expensive.
> >>
> >>
> >> The niche status a 10/100 media converter as an SFP  would have if
> >> produced
> >> is likely to mean it would retail at $2000+ per port device.
> >>
> >>
> >> It probably just makes more sense to go find an old obsolete  top of
> >> rack
> >> switch,  like a Cat3750  to get the small fraction of legacy copper
> >> ports
> >> required for  out of band network and server management, which:  by the
> >> way,   should be part of a separate switching infrastructure anyways,
> >> to
> >> increase the chance it stays operational and useful for
> >> troubleshooting, in
> >> the event the production network experiences outage or has other issues
> >> requiring diagnosis.
> >>
> >>
> >>
> >>> Jamie
> >>
> >> --
> >> -JH
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
>
>

Routes from AS17299 via AS24246

[George B.]

I would be much obliged of folks (peers of AS24246 -- InterNAP Hong Kong --
in particular) would adjust their filters to accept 216.239.98.0/24 and
216.231.203.0/24 announced from AS17299 via AS24246.  You should also see
those routes from AS17819 but it is the 24246 path that causing me hardship.

Thanks

g

(yeah, I'll get them in a routing registry next week if that will help)

Re: Routes from AS17299 via AS24246

[George B.]

Because it is being announced by the ASN that is owned by the same company
that owns the address block.  Look up the originating ASN,  look up the IP
block.  You don't have to take MY word for it but I am employed by that
company.  That's why.


On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow  wrote:

> On Sat, Sep 21, 2013 at 10:41 PM, George B.  wrote:
> > 216.231.203.0/24
>
> you don't appear to be on the whois list for that block nor asn... so,
> why would someone accept this block on your say-so? Are you asking as
> a customer of the ASN or as the ASN owner/operator?
>

Re: Routes from AS17299 via AS24246

[George B.]

And yeah, I am still associated with my former employer, I'm not on the new
employer's stuff yet.

G


On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow  wrote:

> On Sat, Sep 21, 2013 at 10:41 PM, George B.  wrote:
> > 216.231.203.0/24
>
> you don't appear to be on the whois list for that block nor asn... so,
> why would someone accept this block on your say-so? Are you asking as
> a customer of the ASN or as the ASN owner/operator?
>

Re: Routes from AS17299 via AS24246

[George B.]

Sorry if I a bit testy.  Have a typhoon bearing down on the region and the
primary connectivity for a site is apparently useless as the routes are not
propagating from them and I have only one single connection to the
alternate provider.  I'm trying to make the site as resilient as possible
under the circumstances.  InterNAP claims peers are filtering the routes so
I am asking for a favor.  Thanks.

G


ASN

ASNumber:   17299
ASName: IPASS-4
ASHandle:   AS17299
RegDate:2006-03-27
Updated:2012-07-24
Ref:http://whois.arin.net/rest/asn/AS17299

OrgName:iPass Incorporated
OrgId:  IPAS
Address:3800 Bridge Parkway
City:   Redwood Shores
StateProv:  CA

Address block 1:

NetRange:   216.239.96.0 - 216.239.111.255
CIDR:   216.239.96.0/20
OriginAS:
NetName:IPASS-1BLK
NetHandle:  NET-216-239-96-0-1
Parent: NET-216-0-0-0-0
NetType:Direct Allocation
Comment:ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate:2000-11-29
Updated:2012-07-24
Ref:http://whois.arin.net/rest/net/NET-216-239-96-0-1

OrgName:iPass Incorporated
OrgId:  IPAS
Address:3800 Bridge Parkway
City:   Redwood Shores
StateProv:  CA
PostalCode: 94065
Country:US

Second block:

NetRange:   216.231.192.0 - 216.231.207.255
CIDR:   216.231.192.0/20
OriginAS:   AS17398, AS32199, AS22665, AS17299
NetName:NET-216-231-192-0-1
NetHandle:  NET-216-231-192-0-1
Parent: NET-216-0-0-0-0
NetType:Direct Assignment
RegDate:1999-06-29
Updated:2012-07-24
Ref:http://whois.arin.net/rest/net/NET-216-231-192-0-1

OrgName:iPass Incorporated
OrgId:  IPAS
Address:3800 Bridge Parkway
City:   Redwood Shores
StateProv:  CA



On Sat, Sep 21, 2013 at 8:48 PM, Christopher Morrow  wrote:

> $ whois AS17299 | grep -i bos
> $
>
> $ whois 216.239.98.0 | grep -i bos
> $
>
> don't see you on either of the whois contact sets... which was what
> prompted my question originally.
>
> $ whois -h whois.cymru.com 216.239.98.0
> AS  | IP   | AS Name
> 17299   | 216.239.98.0 | IPASS-4 - iPass Incorporated
>
> that seems kosher though.
>
> On Sat, Sep 21, 2013 at 11:41 PM, George B.  wrote:
> > And yeah, I am still associated with my former employer, I'm not on the
> new
> > employer's stuff yet.
> >
> > G
> >
> >
> > On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow
> >  wrote:
> >>
> >> On Sat, Sep 21, 2013 at 10:41 PM, George B.  wrote:
> >> > 216.231.203.0/24
> >>
> >> you don't appear to be on the whois list for that block nor asn... so,
> >> why would someone accept this block on your say-so? Are you asking as
> >> a customer of the ASN or as the ASN owner/operator?
> >
> >
>

Re: best practice for advertising peering fabric routes

[Cb B]

On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>
> I have a connection to a peering fabric and I'm not distributing the
peering fabric routes into my network.
>
> I see three options
> 1. redistribute into my igp (OSPF)
>
> 2. configure ibgp and route them within that infrastructure.  All the
default routes go out through the POPs so iBGP would see packets destined
for the peering fabric and route it that-a-way
>
> 3. leave it "as is", and let the outbound traffic go out my upstreams and
the inbound traffic come back through the peering fabric
>
>
> Advantages and disadvantages, pros and cons?  Recommendations?
Experiences, good and bad?
>
>
> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
POPs yet.  That's another issue completely from a planning perspective.
>
> thanks
> Eric
>

http://tools.ietf.org/html/rfc5963

I like no-export

Re: best practice for advertising peering fabric routes

[Cb B]

On Jan 14, 2014 7:13 PM, "Patrick W. Gilmore"  wrote:
>
> Pardon the top post, but I really don't have anything to comment below
other than to agree with Chris and say rfc5963 is broken.
>
> NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An
IXP LAN should not be reachable from any device not directly attached to
that LAN. Period.
>
> Doing so endangers your peers & the IX itself. It is on the order of not
implementing BCP38, except no one has the (lame, ridiculous, idiotic, and
pure cost-shifting BS) excuse that they "can't" do this.
>

+1.  Rfc5963 needs to update that guidance. Set next hop self loopback0 and
done

CB
> --
> TTFN,
> patrick
>
>
> On Jan 14, 2014, at 21:22 , Christopher Morrow 
wrote:
>
> > On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
> >> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
> >>>
> >>> I have a connection to a peering fabric and I'm not distributing the
> >> peering fabric routes into my network.
> >>>
> >
> > good plan.
> >
> >>> I see three options
> >>> 1. redistribute into my igp (OSPF)
> >>>
> >>> 2. configure ibgp and route them within that infrastructure.  All the
> >> default routes go out through the POPs so iBGP would see packets
destined
> >> for the peering fabric and route it that-a-way
> >>>
> >>> 3. leave it "as is", and let the outbound traffic go out my upstreams
and
> >> the inbound traffic come back through the peering fabric
> >>>
> >>>
> >
> > 4. all peering-fabric routes get next-hop-self on your peering router
> > before going into ibgp...
> > all the rest of your network sees your local loopback as nexthop and
> > things just work.
> >
> >>> Advantages and disadvantages, pros and cons?  Recommendations?
> >> Experiences, good and bad?
> >>>
> >>>
> >>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
> >> POPs yet.  That's another issue completely from a planning perspective.
> >>>
> >>> thanks
> >>> Eric
> >>>
> >>
> >> http://tools.ietf.org/html/rfc5963
> >>
> >> I like no-export
> >
>
>

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

[Cb B]

On Jan 16, 2014 9:08 AM, "Andrew Sullivan"  wrote:
>
> On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote:
> >
> > I totally agree... I was actually joking in my last note :( sorry for
> > not adding the ":)" as requisite in email.
>
> I'm sorry my humour is now so impaired from reading 1net and other
> such things that I didn't figure it out!
>
> > So... what other options are there to solve the larger problem […]
>
> If I knew, I'd run out an implement it rather than talk about it!
>
> A
>

Well. These reflection attacks have something in common. The big ones
(chargen, dns, ntp) are all IPv4 UDP. And these are all *very* big.

I hate to throw the baby out with the bathwater, but in my network, IPv4
UDP is overstaying it's welcome. Just like IPv4  ICMP in 2001 - 2003, its
fate is nearly certain.

I hope QUIC does not stay on UDP, as it may find itself cut off at the
legs.

CB

> --
> Andrew Sullivan
> Dyn, Inc.
> asulli...@dyn.com
> v: +1 603 663 0448
>

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

[Cb B]

On Jan 16, 2014 9:31 AM, "Andrew Sullivan"  wrote:
>
> On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote:
> > I hate to throw the baby out with the bathwater, but in my network, IPv4
> > UDP is overstaying it's welcome. Just like IPv4  ICMP in 2001 - 2003,
its
> > fate is nearly certain.
>
> I won't speak about the other protocols, but I encourage you to turn
> off DNS using UDP over IPv4 in your network and report back to us all
> on how that works out.  You may not be able to do it by email,
> however.
>

I white listed google and facebooks auth servers, so its cool.

CB

> Best regards,
>
> A
>
> --
> Andrew Sullivan
> Dyn, Inc.
> asulli...@dyn.com
> v: +1 603 663 0448
>

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

[Cb B]

On Jan 16, 2014 10:16 AM, "Saku Ytti"  wrote:
>
> On (2014-01-16 09:19 -0800), Cb B wrote:
>
> > I hope QUIC does not stay on UDP, as it may find itself cut off at the
> > legs.
>
> Any new L4 would need to support both flavours, over UDP and native. Over
UDP
> is needed to be deployable right now and be working to vast majority of
the
> end users.
> Native-only would present chicken and egg problem, goog/fb/amzn/msft etc
won't
> add support to it, because failure rate is too high, and stateful box
vendors
> won't add support, because no customer demand.
>
> And what becomes to deployment pace, good technologies which give
benefits to
> end users can and have been deployed very fast.
> IPv6 does not give benefit to end users, EDNS does not give benefit to end
> users.
>
> QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to
end
> users, all persistent connections like ssh would keep running when you
jump
> between networks.
> You could in your homeserver specifically allow /you/ to connect to any
> service, regardless of your IP address, because key is your identity, not
your
> IP address. (So sort of LISPy thing going on here, we'd make IP more
low-level
> information which it should be, it wouldn't be identity anymore)
> Parity packets have potential to give much better performance in packet
loss
> conditions. Packet pacing seems much better on fast to slow file
transfers.
>
> --
>   ++ytti
>

Then let's go all the way with ILNP. I like that.

CB

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

[Cb B]

On Jan 16, 2014 5:10 PM, "Mark Andrews"  wrote:
>
>
> In message <
caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com>
> , Jimmy Hess writes:
> > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews  wrote:
> >
> > > We don't need to change transport, we don't need to port knock.  We
> > > just need to implementent a slightly modified dns cookies which
> > > reminds me that I need to review Donald Eastlake's new draft to be.
> > >
> >
> > But a change to DNS doesn't solve the problem for the other thousand or
so
> > UDP-based protocols.
>
> What thousand protocols?  There really are very few protocols widely
> deployed on top of UDP.
>
> > What would your fix be for the Chargen and SNMP protocols?
>
> Chargen is turned off on many platforms by default.  Turn it off
> on more.  Chargen loops are detectable.
>

Somebody has it on.

I can confirm multi gb/s size chargen attacks going on regularly.

I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big
problem here and now

CB

> SNMP doesn't need to be open to the entire world.  It's not like
> authoritative DNS servers which are offering a service to everyone.
>
> New UDP based protocols need to think about how to handle spoof
> traffic.
>
> You look at providing extending routing protocols to provide
> information about the legitimate source addresses that may be emitted
> over a link.  SIDR should help here with authentication of the data.
> This will enable better automatic filtering to be deployed.
>
> You continue to deploy BCP38.  Every site that deploys BCD is one
> less site where owened machines can be used to launch attacks from.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

BGP convergence problem

[Andy B.]

Hi,

This morning there was an ethernet loop problem on DECIX, causing many
BGP sessions to flap throughout the entire platform.
While this can happen, I am myself facing with BGP convergence
problems on our DECIX router (SUP720-3BXL with IOS SXI3).

De DECIX loop has been solved two hours ago, but my BGP sessions are
still flapping and not converging at all. This has been flooding our
logs, and is still going on:

Jun  8 11:47:03 x.x.x.131 239447: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.32 Up
Jun  8 11:47:03 x.x.x.131 239448: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.231 Up
Jun  8 11:47:03 x.x.x.131 239449: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.109 Up
Jun  8 11:47:03 x.x.x.131 239450: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.50 Up
Jun  8 11:47:03 x.x.x.131 239451: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.81 Up
Jun  8 11:47:03 x.x.x.131 239452: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.28 Up
Jun  8 11:47:03 x.x.x.131 239453: Jun  8 11:48:38.364 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.193.212 Up
Jun  8 11:47:03 x.x.x.131 239454: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.193.147 Up
Jun  8 11:47:03 x.x.x.131 239455: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.74 Up
Jun  8 11:47:03 x.x.x.131 239456: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.241 Up
Jun  8 11:47:03 x.x.x.131 239457: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.5 Up
Jun  8 11:47:03 x.x.x.131 239458: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.40 Up
Jun  8 11:47:03 x.x.x.131 239459: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::1A44:0:1 Up
Jun  8 11:47:03 x.x.x.131 239460: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::8605:0:1 Up
Jun  8 11:47:03 x.x.x.131 239461: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::1A0B:0:1 Up
Jun  8 11:47:03 x.x.x.131 239462: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::3029:0:1 Up
Jun  8 11:47:03 x.x.x.131 239463: Jun  8 11:48:38.368 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::6E4:0:1 Up
Jun  8 11:47:03 x.x.x.131 239464: Jun  8 11:48:38.372 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::CB0:0:1 Up
Jun  8 11:47:03 x.x.x.131 239465: Jun  8 11:48:38.372 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::21C8:0:1 Up
Jun  8 11:47:03 x.x.x.131 239466: Jun  8 11:48:38.372 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::8463:0:2 Up
Jun  8 11:47:04 x.x.x.131 239467: Jun  8 11:48:38.372 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::31AA:0:1 Up
Jun  8 11:47:04 x.x.x.131 239468: Jun  8 11:48:38.372 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.29 Up
Jun  8 11:47:04 x.x.x.131 239469: Jun  8 11:48:38.372 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::62BF:0:1 Up
Jun  8 11:47:04 x.x.x.131 239470: Jun  8 11:48:39.656 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.101 Down BGP Notification sent
Jun  8 11:47:04 x.x.x.131 239471: Jun  8 11:48:39.656 CEST:
%BGP-3-NOTIFICATION: sent to neighbor 80.81.192.101 4/0 (hold time
expired) 0 bytes
Jun  8 11:47:07 x.x.x.131 239472: Jun  8 11:48:41.696 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.104 Up
Jun  8 11:47:10 x.x.x.131 239473: Jun  8 11:48:44.488 CEST:
%BGP-3-BGP_NO_REMOTE_READ: 80.81.193.187 connection timed out - has
not accepted a message from us for 2ms (hold time), 1 messages
pending transmition.
Jun  8 11:47:10 x.x.x.131 239474: Jun  8 11:48:44.488 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.193.187 Down BGP Notification sent
Jun  8 11:47:10 x.x.x.131 239475: Jun  8 11:48:44.488 CEST:
%BGP-3-NOTIFICATION: sent to neighbor 80.81.193.187 4/0 (hold time
expired) 0 bytes
Jun  8 11:47:10 x.x.x.131 239476: Jun  8 11:48:44.900 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.61 Up
Jun  8 11:47:10 x.x.x.131 239477: Jun  8 11:48:44.900 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.149 Up
Jun  8 11:47:10 x.x.x.131 239478: Jun  8 11:48:44.900 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.136 Up
Jun  8 11:47:10 x.x.x.131 239479: Jun  8 11:48:44.904 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::8463:0:1 Up
Jun  8 11:47:10 x.x.x.131 239480: Jun  8 11:48:46.352 CEST:
%BGP-5-ADJCHANGE: neighbor 2001:7F8::6268:0:1 Up
Jun  8 11:47:14 x.x.x.131 239481: Jun  8 11:48:48.084 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.193.78 Up
Jun  8 11:47:14 x.x.x.131 239482: Jun  8 11:48:49.172 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.193.239 Up
Jun  8 11:47:14 x.x.x.131 239483: Jun  8 11:48:49.172 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.24 Up
Jun  8 11:47:17 x.x.x.131 239484: Jun  8 11:48:52.160 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.194.45 Up
Jun  8 11:47:17 x.x.x.131 239485: Jun  8 11:48:52.160 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.108 Up
Jun  8 11:47:17 x.x.x.131 239486: Jun  8 11:48:52.160 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.192.164 Up
Jun  8 11:47:17 x.x.x.131 239487: Jun  8 11:48:52.164 CEST:
%BGP-5-ADJCHANGE: neighbor 80.81.193.49 Up
Jun  8 11:47:17 x.x.x.131 239488

Re: BGP convergence problem

[Andy B.]

I finally decided to shut down all peerings and brought them back one by one.

Everything is stable again, but I don't like the way I had to deal
with it since it will most likely happen again when DECIX or an other
IX we're at is having issues.

I've seen a few BGP convergence discussions on NANOG, but none about
deadlock situations and what could be done to avoid them. Setting
higher MTU or bigger hold queues did not help.

- Andy

On Tue, Jun 8, 2010 at 2:35 PM, Ingo Flaschberger  wrote:
> Dear Andy
>
>> This morning there was an ethernet loop problem on DECIX, causing many
>> BGP sessions to flap throughout the entire platform.
>> While this can happen, I am myself facing with BGP convergence
>> problems on our DECIX router (SUP720-3BXL with IOS SXI3).
>>
>> De DECIX loop has been solved two hours ago, but my BGP sessions are
>> still flapping and not converging at all. This has been flooding our
>> logs, and is still going on:
>
> route half or more of the peering-network to Null -> lowering bgp session
> up's.
> (at the other side, your bgp-router seems to be overloaded).
>
> Kind regards,
>        Ingo Flaschberger
>
>

Upstream BGP community support

[Andy B.]

Hi,

Quick question: Would you buy transit from someone who does not
support BGP communities?

Here is the story:

My company is pushing several GBit/s through various upstream
providers. We have reached the point where we rely on BGP communitiy
support, especially communities that can be sent to the upstream to
change the way he announces our prefixes to his peers/transits.

While most decent upstream providers support this kind of traffic
engineering, one of them refuses to send and accept BGP communities. I
tried to contact my upstream several times through different channels
to get some background as to why they would not be able to provide us
this service, but all we get is tickets that get closed without an
answer. Management itself does not seem to bother either.

Is this normal or is it too much to ask for BGP communities from an
upstream who has points of presence in the US, Europe and Asia?


Andy

Re: Upstream BGP community support

[Andy B.]

On Sat, Oct 31, 2009 at 11:09 PM, Richard A Steenbergen
 wrote:
> Yes and no. There are a handful of old stodgy networks who are of the
> belief that this kind of information is "proprietary", and therefore
> should not be sent to customers or other networks on the Internet. My
> opinion is that those networks are "idiots", and therefore money should
> not be sent to them.

I would not say that my upstream is an old stodgy network and
certainly will I not consider them as "idiots", because they seem to
know what they are doing. I'd rather say they are pretty ignorant when
it comes to some "advanced" customer requirements.

By "they", I am referring myself to Hurricane Electric. But you are
right: money should not be sent to them while they lack any kind of
BGP community support.


> Even if (for whatever reason) you don't need a particular set of
> features in BGP communities, I personally think that they are an
> excellent indicator of the networks' general technical competence and
> ability to work with them on a wide variety of other issues. In this day
> and age a robust and functional set of communities should really be a
> requirement for any network provider.

We're almost 2010. Hurricane Electric, please do something about it!


Andy

Re: Upstream BGP community support

[Andy B.]

On Sun, Nov 1, 2009 at 2:13 AM, Tim Jackson  wrote:
> Being the architect/head-nerd-in-charge of a fairly new network.
>
> Not reading ras's HOWTOs and others is suicide There's no
> excuse... It really makes running your network easier.. If my customer
> needs to prepend X to Y transit/peer/customer or not announce to them
> at 3am, that means they don't have to call me...

That's exactly what I expect from a decent upstream.
So far all our upstreams (Level3, Cogent, Tata), with the exception of
HE, provide this service.

I don't even care about receiving their communities which describe
where the prefix has been injected, since I can handle outbound
traffic more or less myself. It's a nice-to-have feature though.
It's the inbound that I cannot control without a little help from my
upstreams, hence our desperate need to send BGP communities.

Andy

Re: Upstream BGP community support

[Andy B.]

On Mon, Nov 2, 2009 at 11:56 AM, Richard A Steenbergen  
wrote:
> But seriously now, the reason we have these squishy things taking up
> space between our ears in the first place is so we can come up with new
> ideas and better ways to solve our problems. Obviously you can take it
> too far, I'm sure we've all seen examples of absurdly over-complicated
> designs which existed only for the edification of someone's ego, but I
> have never seen a intelligent and well thought out BGP community system
> do anything other than make everyone's life easier. I don't know who
> these people are who you claim are busy breaking things with
> communities, but I've never seen them. Being clever is a good thing when
> it helps you find new ways to do more with less, and those who can't
> innovate in this industry are dooming themselves to obsolescence.

That being said, how can we (me, my company, nanog, ...) possibly do
to convince someone like HE, who wants to be a global player, to
support BGP communities?
I'm not that good at baking cakes, but HE seems to be doing pretty well at that.
I know that some engineers from HE are in this list; maybe they can
give us some insight as to why they believe communities are worthless.

Andy

Re: Telecom Collapse?

[b nickell]

I believe its still the case, but you can order from the local LEC a
soft-dial tone. You hear dial tone, however the only calls that can be made
are to the LEC's Billing & to the PSAP(911). This might be a good option for
people w/ kids, etc. without paying the full price of a land line. I used to
work for Hawaiian Tel and we had an earthquake. It knock out the power for
several days. Most of our CO's stayed up & supported PSTN due to generators
& DC. People who had telephony w/ the cable company lost communications
along with their TV. Just a thought.

BN

On Thu, Dec 4, 2008 at 5:47 AM, Russell J. Lahti <[EMAIL PROTECTED]> wrote:

> That is the one and only thing keeping a land line at my home.  I
> have two young children, and I need to be sure that if something
> were to ever happen that: 1.) The phone would work even if the
> power was out, or the Internet connectivity was flaking out.
> 2.) 911 would function exactly the way it is supposed to, and
> not be routed to some 3rd party call center which could potentially
> delay a response.
>
> I haven't found the power to be reliable, and the cable Internet
> tends to go down when the power goes out.  There's always cellular,
> but then you have to depend on there being someone with a cell phone
> around to make the call, and my kids aren't to the age yet that I
> would want them toting around their own cell phones.  As long as
> my POTS line is more reliable than VoIP, I'll probably keep it.
>
> -Russell
>
>
>
> > -Original Message-
> > From: Mike Lyon [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, December 04, 2008 2:11 AM
> > To: Alex Rubenstein
> > Cc: nanog@nanog.org
> > Subject: Re: Telecom Collapse?
> >
> > That makes two of us...
> >
> > Anyways, for residential VOIP, where are we these days with
> > E911? Are providers like Vonage and such providing reliable
> > E911 when people call 911? That is one of the major problems
> > I see with the residential realm going with VOIP offerings...
> >
> > -Mike
> >
> >
> > On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein
> > <[EMAIL PROTECTED]> wrote:
> > >
> > >> I deliberated for a while on whether to send this, or not, but  I
> > >> figure it might be of interest to this community:
> > >>
> > >> http://techliberation.com/2008/12/04/telecom-collapse/
> > >
> > > Good god. If there is even the mention of a LEC bailout, I
> > am going to go insane and probably shoot someone (those who
> > know me know this is a actual possibility).
> > >
> > > If the phone companies had actually focused on providing
> > good, competitive service, this would have never happened.
> > Instead, they spent money and time on figuring out ways to
> > screw with their competition, and have legislation passed
> > that protects them.
> > >
> > > People (at least the ones I know) are fed up with dealing
> > with these companies, and many people I know don't have land
> > lines and never intend on having them again.
> > >
> > > Let them collapse. It's good for them, us, and the
> > capitalist in you and me. Go buy a cell phone, and have a coke.
> > >
> > >
> > >
> > >
> >
> >
>
>
>


-- 
-B

Re: Comcast DNS

[b nickell]

Live in littleton CO. Having the same issue.

On Mon, Dec 8, 2008 at 10:27 PM, S. Ryan <[EMAIL PROTECTED]> wrote:

> I'm in Fresno, California and having these exact same issues with ATT/Level
> 3 connectivity to Google.
>
>
>
> randal k wroteth on 12/8/2008 9:11 PM:
>
>  I'll second that. My Google-everything has been totally rocked all
>> evening from my home comcast connection.
>>
>> Randal/Colorado Springs, CO
>>
>> On Mon, Dec 8, 2008 at 9:48 PM, Mike Lewinski <[EMAIL PROTECTED]> wrote:
>>
>>> There are issues between Google and Comcast in the Denver area for at
>>> least
>>> the last 12 hours. Pages are sporadically stalling before load
>>> (indefinitely
>>> as far as I can tell). I found a gmail message I'd sent more than 30
>>> minutes
>>> prior still processing. This is affecting all google services that I've
>>> tried so far.
>>>
>>> However, I don't see any evidence this problem is DNS-related, and have
>>> not
>>> otherwise been experiencing name resolution problems or had any other
>>> recent
>>> Comcast connectivity issues.
>>>
>>> So, if there's a clue-wielder from either company around, I'm happy to
>>> provide traces and dumps if you want to ping me offlist.
>>>
>>>
>>>
>>
>>
>


-- 
-B

Paypal DNS Problems?

[B C]

As the subject says really, paypal's DNS servers don't appear to be
responding for me...


[r...@oracle1 oracle]# dig @a.gtld-servers.net paypal.com

; <<>> DiG 9.2.4 <<>> @a.gtld-servers.net paypal.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38254
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;paypal.com.IN  A

;; AUTHORITY SECTION:
paypal.com. 172800  IN  NS  ppns1.den.paypal.com.
paypal.com. 172800  IN  NS  ppns1.phx.paypal.com.
paypal.com. 172800  IN  NS  ppns2.den.paypal.com.
paypal.com. 172800  IN  NS  ppns2.phx.paypal.com.

;; ADDITIONAL SECTION:
ppns1.den.paypal.com.   172800  IN  A   216.113.188.121
ppns1.phx.paypal.com.   172800  IN  A   66.211.168.226
ppns2.den.paypal.com.   172800  IN  A   216.113.188.122
ppns2.phx.paypal.com.   172800  IN  A   66.211.168.227

;; Query time: 32 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net)
;; WHEN: Thu Jan 29 21:34:58 2009
;; MSG SIZE  rcvd: 180

[r...@oracle1 oracle]# dig @216.113.188.121 paypal.com ns

; <<>> DiG 9.2.4 <<>> @216.113.188.121 paypal.com ns
;; global options:  printcmd
;; connection timed out; no servers could be reached
[r...@oracle1 oracle]#
[r...@oracle1 oracle]# dig @66.211.168.226 paypal.com ns

; <<>> DiG 9.2.4 <<>> @66.211.168.226 paypal.com ns
;; global options:  printcmd
;; connection timed out; no servers could be reached

Re: Paypal DNS Problems?

[B C]

On Thu, Jan 29, 2009 at 10:03 PM, Gary E. Miller  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yo John!
>
> On Thu, 29 Jan 2009, John Martinez wrote:
>
>> > As the subject says really, paypal's DNS servers don't appear to be
>> > responding for me...
>
>> I'm not seeing any issues.
>> Is anyone else?
>
> That, and payflow.verisign.com, were down for me two.  From East and
> West coasts.  Back now.  Fingers crossed.
>

Yes came back up about 10 mins after I posted. Guess we'll never know
unless there is a paypal network person on the list.

Brett

Re: downloading speed

[b nickell]

Duplex Mismatch looks to be the problem.

On Fri, Apr 17, 2009 at 3:23 PM, chandrashakher pawar <
learn.chan...@gmail.com> wrote:

> Dear Group member,
>
> We are level one ISP. one of my customer is connected to fast ethernet.
> His link speed 100,000 kbps. while downloading any thing from net he
> downloading speed donot go above 200 kbps.
> While doing multiple download he get aroung 200 kbps in every window. But
> when he close all the windows no change in downloading speed is observed.
>
> our router is C12KPRP-K4P-M
>
> Please advise what could be the cause?
>
> --
> Regards
>
> Chandrashakher Pawar
> IPNOC
> Customer & Services Operations
> Tata communication AS6453
> mobil + 91 9225633948 + 91 9324509268
> learn.chan...@gmail.com
>



-- 
-B

Re: Christchurch New Zealand

[b nickell]

prayers.hopes. anything i can do  I will

On 2/21/11, Marshall Eubanks  wrote:
> Here is an animated seismic map
>
> http://www.christchurchquakemap.co.nz/today
>
> Marshall
>
> On Feb 21, 2011, at 10:46 PM, Mark Foster wrote:
>
>> Folks on Twitter should search for hashtag #eqnz.
>>
>> Major news sites in NZ:
>>
>> www.stuff.co.nz
>> www.nzherald.co.nz
>> www.tvnz.co.nz
>> www.3news.co.nz
>>
>> Plenty of Vids, Stills and some Streaming available.
>>
>> Can confirm the reports of multiple casualties.  TV News is live
>> broadcasting reports of many folks trapped within buildings, largely
>> because of things like stairwells collapsing, etc. A few buildings have
>> been hit pretty hard, with some notable collapses, damage to vehicles,
>> etc.
>>
>> The 111 network (911 equiv) is experiencing problems in the South Island,
>> folks are being asked to stay the phones (etc) except for genuine
>> emergencies.
>>
>> Urban Search and Rescue teams in NZ are based in Christchurch, Palmerston
>> North and Auckland. I gather all three teams are stood-to, and an offer
>> from Australia for additional USAR resource has been accepted.  CD
>> Emergency has been declared and the Military are already getting involved.
>>
>> Christchurch experienced a major quake (magnitude 7.2) in September last
>> year, which received a lot of press as its effects were widespread and
>> severe - but there was little loss of life.  This quake, magnitute 6.3,
>> hit much closer to the CBD and during a business day, so the casualty
>> count is much higher.  Being a more shallow quake, much closer to town,
>> but also lesser in magnitude, my uneducated view based on media coverage
>> is that the effects are not as widespread, but where they're felt, are
>> very significant.
>>
>> Mark.
>> (in Auckland, some 1000 km away...)
>>
>> On Tue, 22 Feb 2011, Daniel Richards wrote:
>>
>>> There aren't any major international cables to the south island. The big
>>> one is the southern Cross cable that lands on either side of Auckland,
>>> which is the north of the North Island, which is operating normally.
>>>
>>> KAREN (The Kiwi Advanced Research Network) core in the south island is
>>> still operating, but most of the member sites in Christchurch are down:
>>> http://karen.net.nz/news-earthquake-network-update/
>>>
>>> News is reporting deaths now, sadly.
>>>
>>> On 22/02/11 16:04, Marshall Eubanks wrote:
>>>> There has been a bad Earthquake in Christchurch New Zealand with reports
>>>> of
>>>> fatalities.
>>>> http://www.facebook.com/photo.php?fbid=10150099324847752&set=a.125583977751.103665.119452527751&theater
>>>> Telecom New Zealand reports "Heavy damage" to their Christchurch
>>>> building, but no deaths there.
>>>> Is there any report of issues with the undersea cables to / from the
>>>> South Island ?
>>>> Regards
>>>> Marshall
>>>> P.S. On a more personal note,
>>>> Google has a people finder up @
>>>> http://christchurch-2011.person-finder.appspot.com/
>>>> There is a DFAT # - 1300 555 135 - for people outside of NZ to call.
>>>> Telecom New Zealand has asked people to stay off of the wireless network
>>>> except for true emergencies.
>>>
>>>
>>>
>>
>>
>
>
>


-- 
-B