Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[Colin Johnston]

backup monitoring via ipv6 and network monitoring via ipv6 now  
required for big telco in UK so that testing can be done before  
implementation.
I guess quite a few networks will be both ipv4-ipv6 type for a long  
long time :)


Colin

Re: Apple Catalina Appears to Introduce Massive Jitter

[colin johnston]

Hey Mark,
Good shout with debug, same issue seen on MacBook Air with Catalina 10.15.6 
beta, pings upto 150ms seen
iMac with Sierra zero jitter and usually sub 1m pings
Now need to find out why, I never noticed as wife using the MacBook Air :(
I cant yet update to big sur since need lots of sad space, need to cutdown on 
university docs me thinks

Col

> On 29 Oct 2020, at 12:07, Mark Tinka  wrote:
> 
> Hi all.
> 
> I've been on High Sierra for several years now due to a limitation with an 
> app that couldn't deal with Apple's latest rounds of system permissions since 
> Mojave. Eventually, I gave up on waiting for them to fix it and upgraded my 
> older Butterfly keyboard laptop to Catalina 4 weeks ago.
> 
> At the same time, I picked up the new Magic keyboard laptop 2 weeks ago which 
> came with Catalina.
> 
> Over the past week, I've been troubleshooting a massive jitter issue on 
> Catalina, just between itself and my home router. For control, I have a 
> Windows PC (tower-top) using a wireless adapter to connect to my home 
> network. That has no jitter at all.
> 
> I have noticed as much as 300ms+ jitter on Catalina.
> 
> I then asked a few friends around the world to run tests for me on their own 
> Catalina installations to their local router over wi-fi, and the results are 
> the same. Jitter so high that what should be a 1ms - 5ms latency can (for a 
> short period) jump to 200ms+, 300ms+, 400ms+.
> 
> On the off-chance that it is an issue with the new wireless chips on the 
> later MacBook models, one of my friends tested the same on a 2013 MacBook Pro 
> running a beta version of Big Sur. Same story!
> 
> Another friend in South East Asia, testing on a 2018 13-inch MacBook Pro 
> running Catalina, also had the same issue.
> 
> A Google search suggests that this is some known issue since Mojave, to do 
> with Location Services, and some other apps, in a non-deterministic way:
> 
> 
> https://apple.stackexchange.com/questions/263638/macbook-pro-experiencing-ping-spikes-to-local-router
>  
> 
> 
> For me, even after disabling all or some Location Services features, the 
> problem remains.
> 
> Is anyone else seeing this on their Catalina Mac's while on wi-fi? If so, 
> does anyone know what's going on here?
> 
> Ideally, this wouldn't matter if it was just a cosmetic issue - but I do 
> actually see physical impact to performance of network access to/from the 
> laptop, which has all the hallmarks of high jitter and/or packet loss. 
> 
> An app like Zoom, which can display network performance data for a session in 
> real-time, does indicate nominal packet loss for audio and video on this 
> device, while other devices on the same WLAN are happy.
> 
> Thoughts?
> 
> Mark.

Re: Apple Catalina Appears to Introduce Massive Jitter

[colin johnston]

This does seem to be solved with the checksum disable below, or at least pings 
down to sub 10ms on Mac book air with Catalina beta 10.15.6, why aim performs 
far better I don’t know. I tried to introduce load after cksum disable and it 
did not see ping spikes as before

How do we now explain to Apple to fix ?

Col


> On 29 Oct 2020, at 14:08, J. Hellenthal via NANOG  wrote:
> 
> I believe I have seen the same thing with a Mid 2015 11,4 running catalina. 
> Not diagnosing further because I could not find a reason for it fast enough 
> and not sure if it really had an impact at the moment…. but could you try the 
> following 
> 
> 
> sudo sysctl net.link.generic.system.hwcksum_tx=0
> sudo sysctl net.link.generic.system.hwcksum_rx=0
> sudo ifconfig en0 -rxcsum
> 
> 
> in reverse … to restore the settings 
> 
> sudo sysctl net.link.generic.system.hwcksum_tx=1
> sudo sysctl net.link.generic.system.hwcksum_rx=1
> sudo ifconfig en0 rxcsum
> 
> 
> If you have some specific tests to run I would be willing to run them here on 
> Big Sur with the same laptop but I have nothing now that runs Catalina
> 
> 
> Wireshark used to in Catalina rack up cksum errors a lot while these were all 
> at their defaults.
> 
> 
> 
>> On Oct 29, 2020, at 08:23, Mark Tinka  wrote:
>> 
>> 
>> 
>> On 10/29/20 15:04, Cory Sell wrote:
>> 
>>> Might be worth disabling each AP to see if there's one out there having an 
>>> issue playing nice with the MacBook. Also try different combinations of two 
>>> APs working together. It's possible the MacBook is flip flopping because 
>>> the power levels are fighting each other.
>> 
>> Tested all that, as well as dropping Tx power levels on each of the AP's to 
>> Low so that there isn't any power coming from any other AP (despite being 
>> quite far, already).
>> 
>> And to confirm, when the laptop locks into an AP, it doesn't try to join 
>> another one. When in range, power is very good (between -37dB and -52dB). 
>> When I walk away, that AP becomes too far (as bad as -80dB), but the next 
>> one close by is far better (same good values as before) and laptop connects 
>> and sticks to that.
>> 
>> Again, only impacts Catalina. No other Apple device, or the Windows PC that 
>> is on the same WLAN.
>> 
>> 
>>> Does the Mac have this issue at your local coffee shop or another 
>>> establishment with Wi-Fi? You can try to rule out the AirPort card in the 
>>> Mac itself.
>> 
>> Never tried, I generally work from home. If I'm out, it's faster to tether 
>> to my 4G service rather than any public wi-fi.
>> 
>> Mark.
> 
> 
> -- 
> 
> J. Hellenthal
> 
> The fact that there's a highway to Hell but only a stairway to Heaven says a 
> lot about anticipated traffic volume.
> 
> 
> 
> 
> 
> 

Re: Apple Catalina Appears to Introduce Massive Jitter

[colin johnston]

Be careful using Apple wireless diagnostic package, uses a lot of /var/tmp 
space on a small Macbook air 128ssd

Col

 
> On 29 Oct 2020, at 17:24, colin johnston  wrote:
> 
> This does seem to be solved with the checksum disable below, or at least 
> pings down to sub 10ms on Mac book air with Catalina beta 10.15.6, why aim 
> performs far better I don’t know. I tried to introduce load after cksum 
> disable and it did not see ping spikes as before
> 
> How do we now explain to Apple to fix ?
> 
> Col
> 
> 
>> On 29 Oct 2020, at 14:08, J. Hellenthal via NANOG  wrote:
>> 
>> I believe I have seen the same thing with a Mid 2015 11,4 running catalina. 
>> Not diagnosing further because I could not find a reason for it fast enough 
>> and not sure if it really had an impact at the moment…. but could you try 
>> the following 
>> 
>> 
>> sudo sysctl net.link.generic.system.hwcksum_tx=0
>> sudo sysctl net.link.generic.system.hwcksum_rx=0
>> sudo ifconfig en0 -rxcsum
>> 
>> 
>> in reverse … to restore the settings 
>> 
>> sudo sysctl net.link.generic.system.hwcksum_tx=1
>> sudo sysctl net.link.generic.system.hwcksum_rx=1
>> sudo ifconfig en0 rxcsum
>> 
>> 
>> If you have some specific tests to run I would be willing to run them here 
>> on Big Sur with the same laptop but I have nothing now that runs Catalina
>> 
>> 
>> Wireshark used to in Catalina rack up cksum errors a lot while these were 
>> all at their defaults.
>> 
>> 
>> 
>>> On Oct 29, 2020, at 08:23, Mark Tinka  wrote:
>>> 
>>> 
>>> 
>>> On 10/29/20 15:04, Cory Sell wrote:
>>> 
>>>> Might be worth disabling each AP to see if there's one out there having an 
>>>> issue playing nice with the MacBook. Also try different combinations of 
>>>> two APs working together. It's possible the MacBook is flip flopping 
>>>> because the power levels are fighting each other.
>>> 
>>> Tested all that, as well as dropping Tx power levels on each of the AP's to 
>>> Low so that there isn't any power coming from any other AP (despite being 
>>> quite far, already).
>>> 
>>> And to confirm, when the laptop locks into an AP, it doesn't try to join 
>>> another one. When in range, power is very good (between -37dB and -52dB). 
>>> When I walk away, that AP becomes too far (as bad as -80dB), but the next 
>>> one close by is far better (same good values as before) and laptop connects 
>>> and sticks to that.
>>> 
>>> Again, only impacts Catalina. No other Apple device, or the Windows PC that 
>>> is on the same WLAN.
>>> 
>>> 
>>>> Does the Mac have this issue at your local coffee shop or another 
>>>> establishment with Wi-Fi? You can try to rule out the AirPort card in the 
>>>> Mac itself.
>>> 
>>> Never tried, I generally work from home. If I'm out, it's faster to tether 
>>> to my 4G service rather than any public wi-fi.
>>> 
>>> Mark.
>> 
>> 
>> -- 
>> 
>> J. Hellenthal
>> 
>> The fact that there's a highway to Hell but only a stairway to Heaven says a 
>> lot about anticipated traffic volume.
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: Layer 2 based anycast - Kind like GLBP - Research

[colin johnston]

Bigip with each host having two nics on public and private via inter switch 
shared vlan.
Should not cause issue so long as you know service comes via bigip to debug 
usage of kit via private ip side


Sent from my iPod

> On 1 Jul 2021, at 19:04, Douglas Fischer  wrote:
> 
> 
> I'm looking for solutions do deploy some type of selective high availability 
> and load balance based on the glue between Layer 2 and Layer 3 (ARP or ND).
> 
> And I'm coming here to ask help to avoid reinventing the wheel.
> 
> I know VRRP / Heartbeat, and their downside is the Active/Passive 
> characteristic.
>  -> But this project demands something that allows-me to have Active/Active 
> deployments.
> I know GLBP, and it almost fits on the needed requirements.
>  -> Except by his load-balancing methods that do not allow-me define priority 
> and affinity between server nodes and clients.
> 
> The basic ideia is something like Cisco GLBP with steroids:
>  - Multiple server nodes of same service running on a common bus and 
> answering the "L2 anycast requests" of the clients that are on the same bus 
> and same subnet.
>  - Some type of signaling between the multiple nodes making known the status 
> of the other nodes, their load. Maybe complementary information like "which 
> node is serving which client?"
>  - Resource Pools and Client Pools, and the crossing between then based on 
> priorities and affinities (Here is the Gotcha!).
> - I want to be able to say "Node X will priorly serve clients A, E, G, 
> and T. Node Y will serve priorly clients B, C D, F. And node Z will server 
> everyone else."
> 
> Answering suggestions in advance:
> (I discussed that with some friends and based on those talks I will try to 
> predict some suggestions that we already considered.)
> - No, unfortunately tradicional L3 anycast will not fit on the requirements. 
> Servers and clients to be at the same bus, on the same subnet. No L3 hops 
> between then.
> - No, the use of some type of connection broker in L2 does not satisfy one of 
> the requirements. Beyond the load balance, that this approach will address, 
> the high availability in case on L2 segregation is also needed.
> 
> 
> My v0 draft of idea was using GLBP, and L2 Firewall rules dynamically 
> adjusted, based on the Master-Status, to allow and block L2 communications 
> between each of those nodes and lists of client pools.
> (Actually, I'm coming back to this idea again... Since I still don't have any 
> other better idea until now.)
> 
> I friend Suggested that EVPN could help-me, but I must confess that is a hard 
> topic to me.
> Unless it can be used depending exclusively on software (no special hardware 
> required), it won't fit.
> 
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

Re: Do you care about "gray" failures? Can we (network academics) help? A 10-min survey

[colin johnston]

Uucp using tcp does work to overcome packet size problems but limited usage but 
did work in the past

Col

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[colin johnston]

UK gov notification of key worker status inc Telecommunication/Data Centre 
workers
https://www.gov.uk/government/publications/coronavirus-covid-19-maintaining-educational-provision/guidance-for-schools-colleges-and-local-authorities-on-maintaining-educational-provision
 


Col


> 
> 
>> On 19 Mar 2020, at 21:36, Sean Donelan > > wrote:
>> 
>> 
>> The U.S. Cyber and Infrastructure Security Agency (part of the U.S. 
>> Department of Homeland Security) has issued new Guidance on the Essential 
>> Critical Infrastructure Workforce.
>> 
>> The memorandum is advisory, not presecriptive.  DHS is only one of several 
>> agencies assigned some National Essential Functions so it is not exhaustive 
>> list.  It looks like someone found the three-ring emergency plan binders. 
>> Sad its needed, but appreciative of the experts which helped write those 
>> planning documents over the years.
>> 
>> 
>> https://www.cisa.gov/publication/guidance-essential-critical-infrastructure 
>> 
>> -workforce
>> 
>> [...]
>> The attached list identifies workers who conduct a range of operations and 
>> services that are essential to continued critical infrastructure viability, 
>> including staffing operations centers, maintaining and repairing critical 
>> infrastructure, operating call centers, working construction, and performing 
>> management functions, among others. The industries they support represent, 
>> but are not necessarily limited to, medical and healthcare, 
>> telecommunications, information technology systems, defense, food and 
>> agriculture, transportation and logistics, energy, water and wastewater, law 
>> enforcement, and public works.
>> 
>> We recognize that State, local, tribal, and territorial governments are 
>> ultimately in charge of implementing and executing response activities in 
>> communities under their jurisdiction, while the Federal Government is in a 
>> supporting role. As State and local communities consider
>> 
>> COVID-19-related restrictions, CISA is offering this list to assist 
>> prioritizing activities related to continuity of operations and incident 
>> response, including the appropriate movement of critical infrastructure 
>> workers within and between jurisdictions.
>> 
>> Accordingly, this list is advisory in nature. It is not, nor should it be 
>> considered to be, a federal directive or standard in and of itself.
>> [...]
> 

Re: free collaborative tools for low BW and losy connections

[colin johnston]

> 
> Actual text traffic has been slowly dying off for years as webforums
> have matured and become a better choice of technology for nontechnical
> end users on high speed Internet connections.
> 

The solaris groups for info worked great
Psinet uk liked using the sun kit for great nntp even uucp nntp as well


Col

Re: An appeal for more bandwidth to the Internet Archive

[colin johnston]

Is the increased usage due to more users or more existing users having higher 
bandwidth at home to request faster ?
Would be interested if IPS configured firewall used to block out invalid 
traffic/spam traffic and if such traffic increased when back end network 
capacity increased ?
What countries are requesting the most data and does this analysis throw up 
questions as to why ?
Are there high network usage hitters which raise question as to why asking for 
so much data time and time again and is this valid traffic use ?

Colin


> On 12 May 2020, at 17:33, Tim Požár  wrote:
> 
> Jared...
> 
> Thanks for sharing this.  I was the first Director of Operations from '96 to 
> '98, at was was then Internet Archive/Alex.  I was the network architect back 
> then got them their ASN and original address space. Folks may also know, I 
> help start SFMIX with Matt Peterson.
> 
> A bit more detail in this...  Some of this I got from Jonah Edwards who is 
> the current Network Architect at IA.  Yes, the bottle neck was the line 
> cards.  They have upgraded and that has certainly helped the bandwidth of 
> late.
> 
> Peering would be a big help for IA. At this point they have two 10Gb LAG 
> interfaces that show up on SFMIX that was turned up last February. Looking at 
> the last couple of weeks the 95th percentile on this 20Gb LAG is 3 Gb.  As 
> they just turned up on SFMIX, they are just starting to get peers turned up 
> there. Eyeball networks that show up on SFMIX are highly encouraged to start 
> peering with them.  Alas, they are v4 only at this point.
> 
> Additionally, if folks do have some fat pipes that can donate bandwidth at 
> 200 Paul, I am sure Jonah won't turn it down.
> 
> Tim
> 
> On 5/12/20 4:45 AM, Jared Brown wrote:
>> Hello all!
>> Last week the Internet Archive upgraded their bandwidth 30% from 47 Gbps to 
>> 62 Gbps. It was all gobbled up immediately. There's a lovely solid green 
>> graph showing how usage grows vertically as each interface comes online 
>> until it too is 100% saturated. Looking at the graph legend you can see that 
>> their usage for the past 24 hours averages 49.76G on their 50G of transport.
>> To see the pretty pictures follow the below link:
>> https://blog.archive.org/2020/05/11/thank-you-for-helping-us-increase-our-bandwidth/
>> Relevant parts from the blog post:
>> "A year ago, usage was 30Gbits/sec. At the beginning of this year, we were 
>> at 40Gbits/sec, and we were handling it. ...
>> Then Covid-19 hit and demand rocketed to 50Gbits/sec and overran our network 
>> infrastructure’s ability to handle it.  So much so, our network statistics 
>> probes had difficulty collecting data (hence the white spots in the graphs).
>> We bought a second router with new line cards, and got it installed and 
>> running (and none of this is easy during a pandemic), and increased our 
>> capacity from 47Gbits/sec peak to 62Gbits/sec peak.   And we are handling it 
>> better, but it is still consumed."
>> It is obvious that the Internet Archive needs more bandwidth to power the 
>> Wayback machine and to fulfill its mission of being the Internet library and 
>> the historic archive of our times.
>> The Internet Archive is present at Digital Realty SFO (200 Paul) and a 
>> member of the San Francisco Metropolitan Internet Exchange (SFMIX).
>> I appeal to all list members present or capable of getting to these 
>> facilities to peer with and/or donate bandwidth to the Internet Archive.
>> I appeal to all vendors and others with equipment that they can donate to 
>> the Internet Archive to contact them so that they can scale their services 
>> and sustain their growth.
>> The Internet Archive is currently running 10G equipment. If you can help 
>> them gain 100G connectivity, 100G routing, 100G switching and/or 100G DWDM 
>> capabilities, please reach out to them. They have the infrastructure and 
>> dark fiber to transition to 100G, but lack the equipment. You can find the 
>> Internet Archive's contact information below or you can contact Jonah at the 
>> Archive Org directly either by email or via the contact information 
>> available on his Twitter profile @jonahedwards.
>> You can also donate at https://archive.org/donate/
>> The Internet Archive is a 501(c)(3) non-profit. Donations are  
>> tax-deductible.
>> Contact information:
>> https://archive.org/about/contact.php
>> Volunteering:
>> https://archive.org/about/volunteerpositions.php
>> Disclaimer: I am not affiliated with the Internet Archive. Nobody asked me 
>> to write this post. If something angers you about this post, be angry at me. 
>> I merely think that the Internet Archive is a good thing and deserves our 
>> support.
>> Jared

Re: netflix proxy/unblocker false detection

[colin johnston]

> On Fri, 2020-06-26 at 12:45 -0500, Mike Hammett wrote:
>> I believe they're only blocking the HE v6 prefixes used for the VPN
>> service. 
> 

I don’t understand the rational to block specific ipv6 ranges, for example the 
UK ipv6 ranges and Africa ipv6 ranges are not blocked from testing done here 
with satellite comms and fibre backhaul uk comms

Col

Re: ASNs decimation in ZW this morning

[Colin Johnston]

sorry top posting,
yup whatsup doesnt work in harare.
phone circuits land ok though and checked ok

col

Sent from my iPod

> On 15 Jan 2019, at 15:42, C. A. Fillekes  wrote:
> 
> 
> 
>> On Tue, Jan 15, 2019 at 10:34 AM C. A. Fillekes  wrote:
>> 
>> So @meileaben on twitter this morning notes:
>> 
>> Many #Zimbabwe Internet routes withdrawn around 9:30 UTC amidst civil unrest 
>> in the country. near-realtime on #RIPEstat here: https://stat.ripe.net/ZW  
>> #OpenNetworkIntelligence #ZimbabweShutdown
>> 
>> https://twitter.com/meileaben/status/1085118237157851136
>> 
>> wondering if anyone here has additional info on that.  Looing at 
>> stat.ripe.net/ZW now it looks as though one (out of an original 18, current 
>> 9) ASN has recovered, but kind of curious as to what exactly happened there. 
> 
> So Bloomberg notes that a number of ISPs were shut down to quell online 
> protest
> https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-zimbabwe-kills-commerce-and-the-lights
>  but are there no work-arounds available, if implemented? 

Re: ASNs decimation in ZW this morning

[Colin Johnston]

> On 15 Jan 2019, at 17:03, C. A. Fillekes  wrote:
> 
> 
> Whole countries falling off the net?  BUT TEH TOP POSTINGS!!!
> 
> I'm a little frustrated with the very existence of that thread.
> 
> Trying to constructively change the topic to something more interesting lol. 
> 
> I guess the concerning thing to me is that the whole point of packet switched 
> networks was to provide resilience in the face of e.g. civil disorder. 
> 
> On Tue, Jan 15, 2019 at 11:50 AM Colin Johnston  <mailto:col...@gt86car.org.uk>> wrote:
> sorry top posting,
> yup whatsup doesnt work in harare.
> phone circuits land ok though and checked ok
> 
> col
> 
> Sent from my iPod
> 
> On 15 Jan 2019, at 15:42, C. A. Fillekes  <mailto:cfille...@gmail.com>> wrote:
> 
>> 
>> 
>> On Tue, Jan 15, 2019 at 10:34 AM C. A. Fillekes > <mailto:cfille...@gmail.com>> wrote:
>> 
>> So @meileaben on twitter this morning notes:
>> 
>> Many #Zimbabwe <https://twitter.com/hashtag/Zimbabwe?src=hash> Internet 
>> routes withdrawn around 9:30 UTC amidst civil unrest in the country. 
>> near-realtime on #RIPEstat <https://twitter.com/hashtag/RIPEstat?src=hash> 
>> here: https://stat.ripe.net/ZW  <https://t.co/sgJ4O3310z> 
>> #OpenNetworkIntelligence 
>> <https://twitter.com/hashtag/OpenNetworkIntelligence?src=hash> 
>> #ZimbabweShutdown <https://twitter.com/hashtag/ZimbabweShutdown?src=hash>
>> 
>> https://twitter.com/meileaben/status/1085118237157851136 
>> <https://twitter.com/meileaben/status/1085118237157851136>
>> 
>> wondering if anyone here has additional info on that.  Looing at 
>> stat.ripe.net/ZW <http://stat.ripe.net/ZW> now it looks as though one (out 
>> of an original 18, current 9) ASN has recovered, but kind of curious as to 
>> what exactly happened there. 
>> 
>> So Bloomberg notes that a number of ISPs were shut down to quell online 
>> protest
>> https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-zimbabwe-kills-commerce-and-the-lights
>>  
>> <https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-zimbabwe-kills-commerce-and-the-lights>
>>  but are there no work-arounds available, if implemented? 



zimbabwe situation link below re telecom problems
https://www.zimbabwesituation.com/news/zimbabwe-telecoms-jammed-after-violent-protests-report/
 
<https://www.zimbabwesituation.com/news/zimbabwe-telecoms-jammed-after-violent-protests-report/>


I was back in Zim myself last month as well to see family children, internet 
was working well then inc whats up, mobile and adsl.

I wonder how they block social media sites/whats up, is it null routing on 
peering cores or filtering since did not see filtering in place from ZIM<>UK 
last month...

Colin

Re: ASNs decimation in ZW this morning

[Colin Johnston]

> On 17 Jan 2019, at 09:07, Mark Tinka  wrote:
> 
> 
> 
> On 16/Jan/19 19:49, John Von Essen wrote:
> 
>> Im confused as to what exactly happened and how it was implemented. I
>> assume the government wanted to restrict access to sites like
>> whatsapp, facebook, twitter, etc.,. So did they tell national
>> ISPs/Mobile (strong-arm) to simply block access to those sites, or
>> they did they tell them to completely shutdown and go dark until the
>> protests were over. Im just curious as to how an ISP/Mobile would
>> selectively block access under government influence, reason being...
>> understanding how can help us think of ways to get around it.
>> 
>> For example, lets say the mobile networks null routed all traffic
>> destined to twitter and facebook networks... not a complete IP
>> shutdown. So a local citizen is using email from a local provider
>> (non-gmail, etc.,.) and still has access to email, Twitter knows they
>> are blocked in ZW, but they still try to email updates to this example
>> citizen. If their networks are being null routed, they can simply
>> deliver the email via an alternate network/platform.
>> 
>> The whole thing is very disturbing, I mean this is 2019 right? Not
>> 1984...
> 
> It's not unusual for networks to be shutdown, particularly during riots
> and/or elections. I'm not saying it's right or wrong, I'm just saying
> it's not unusual.
> 
> This happened during the recent elections in Uganda and Kenya, for example.
> 
> Typically, the operating licenses issued by the gubbermints to operators
> provide for legal avenues by the gubbermint to shutdown services. It is
> not the gubbermint's responsibility as to how this is implemented by the
> operators, just that it be done.
> 
Would a service be viewed as the same as (layer2 connectivity to a out of 
country layer3/layer4 endpoint).
ie ip source out of country but connectivity layer in country ?
satcomms in effect but terrestrial based pvc with leaf router out of country.

Colin


> In recent years, social media resources have been targets, so Facebook,
> WhatsApp, Twitter et al. However, if the gubbermint takes a broader
> approach, it's up to the operator to figure out how to do it. Failure to
> comply can result in arrests, fines, jail or even revocation of the license.
> 
> All mobile operators have terribly advanced DPI infrastructure, so it's
> not difficult to shut services down at a very granular level.
> 
> Operators that deliver services via terrestrial means also employ DPI
> infrastructure, because selling bandwidth access by the Gig-loads is big
> business :-\. So they, too, can implement shutdowns with a reasonable
> degree of granularity.
> 
> Mark.
> 

Re: ASNs decimation in ZW this morning

[Colin Johnston]

> On 18 Jan 2019, at 11:52, Mark Tinka  wrote:
> 
> 
> 
> On 17/Jan/19 16:57, Keith Medcalf wrote:
> 
>> However, like the Internet Off switch installed in the Pentagon after 911 
>> (which shutdown the DNS Severs), you may find that you have to reboot the 
>> Internet so you can upload your Save the World video to Twitter ...
> 
> https://www.youtube.com/watch?v=RYHci_KYIT4
> 
> Mark.


someone needs to tell Zim Gov that BACS-IP payroll needs IP connectivity to 
banks to pay gov employees otherwise

Col

Clueful Contact at IPVolume.net ?

[Colin Johnston]

Anyone know knowledgeable contact at IPvolume.net  ?
Having weird advance threat protection events from 93.174.93.73 and unable to 
get abuse contact to answer.
Must be nice monitoring kit in London/NL/Frankfurt from Seychelles :(


inetnum: 93.174.93.0 - 93.174.93.255 

netname: NET-3-93
descr:   IPV NETBLOCK
country: NL
geoloc:  52.370216 4.895168
org: ORG-IVI1-RIPE 

admin-c: IVI24-RIPE 

tech-c:  IVI24-RIPE 

status:  ASSIGNED PA
mnt-by:  IPV 

mnt-lower:   IPV 

mnt-routes:  IPV 

created: 2008-06-29T21:36:16Z
last-modified:   2019-02-04T13:12:31Z
source:  RIPE
Highlight RIPE NCC managed values
Login to update  

organisation:ORG-IVI1-RIPE 

org-name:IP Volume inc
org-type:OTHER
address: Suite 9
address: Victoria, Mahe
address: Seychelles
e-mail:  ab...@ipvolume.net 
abuse-c: IVNO1-RIPE 

mnt-ref: IPV 

mnt-by:  IPV 

created: 2018-05-14T11:46:50Z
last-modified:   2019-01-31T14:39:36Z
source:  RIPE
Login to update  

role:IPV
address: Suite 9
address: Victoria, Mahe
address: Seychelles
e-mail:  ab...@ipvolume.net 
nic-hdl: IVI24-RIPE 

mnt-by:  IPV 

created: 2018-05-16T13:28:41Z
last-modified:   2019-01-31T21:21:20Z
source:  RIPE
Login to update  

 RIPEstat  
route:   93.174.93.0/24 

origin:  AS202425
remarks: +---
remarks: | For abuse e-mail ab...@ipvolume.net 

remarks: | We do not always reply to abuse.
remarks: | But we do take care your report is dealt with!
remarks: +---
mnt-by:  IPV 

created: 2019-02-08T16:07:14Z
last-modified:   2019-02-08T16:07:14Z
source:  RIPE

Colin

Re: NTP for ASBRs?

[colin johnston]

> On 14 May 2019, at 08:41, Mark Tinka  wrote:
> 
> 
> 
> On 9/May/19 02:47, Bryan Holloway wrote:
> 
>>  
>> 
>> Hawai'i and Arizona can add/subtract without looking at the damn
>> calendar. I'm just sayin' I'd like to see more of that.
> 
> Well, 2 months ago, the EU parliament voted to scrap daylight saving
> time from 2021. This would also apply to the UK if it chooses to remain
> in the EU, or during the extended transition period that Theresa May is
> currently working.
> 
> It's now up to the various EU member states to decide whether they want
> to remain permanently in winter or permanently in summer.
> 
> Of course, the UK government aren't necessarily amused.
> 
> Mark.
> 

Dst Time works great for Scotland as allows kids to go to school during lighter 
hours.
It has been proved to save road deaths

Col

Re: SSL VPN

[Colin Johnston]

sophos utm vm cant beat that

Sent from my iPod

> On 1 Jun 2019, at 15:53, Mehmet Akcin  wrote:
> 
> Hey there
> 
> I am trying to choose SSL VPN for a remote office 3-4 people max each any 
> given time.
> 
> I have looked at Pulse and Cisco, and wanted to check in here for 
> recommendations on latest trends.
> 
> Trying to get a solution easy to manage and won’t break the bank with 
> licenses when team grows to 10.
> 
> Thanks in advance.
> 
> Mehmet
> -- 
> Mehmet
> +1-424-298-1903

Re: Spamming of NANOG list members

[colin johnston]

See this as well today

But gmail auto trashed it :)

Col


> On 1 Jun 2019, at 14:50, Niels Bakker  wrote:
> 
> * s...@ottie.org (Scott Christopher) [Sat 01 Jun 2019, 12:04 CEST]:
>> I wonder if this crap corresponds positively with the price of Bitcoin.
> 
> Only speculation (read: market manipulation) by holders of massive amounts of 
> bitcoin drives the price of cryptocurrencies: 
> https://davidgerard.co.uk/blockchain/2019/05/18/number-go-down-the-single-trade-that-crashed-bitcoin/
> 
> 
>   -- Niels.

Re: Dial Up Solutions

[Colin Johnston]

ipass worldwide aka psinet did such with end auth on psinet radius 
infrastructure

Sent from my iPhone

> On 17 Oct 2015, at 16:54, Stephen Satchell  wrote:
> 
>> On 10/17/2015 07:29 AM, Jason Canady wrote:
>> I'm going to go with Justin's suggestion and go with a wholesale
>> provider such as DialupUSA.  It's not worth paying for the lines and
>> keeping a T1 or better for just a few users.  DialupUSA use to charge
>> around $5/user.  They also had hourly and per port options. Looks like
>> you can port existing numbers to them now.  I used them 9-10 years ago
>> and they were great to work with!  IKANO bought them out since then, but
>> they still operate under DialupUSA.net.  They have DSL and T1 options too.
> 
> The ISP I consult to uses an outsource dial service (don't remember which 
> one).  They require us to maintain a RADIUS server accessible from the public 
> internet, to validate callers and handle options and restrictions.  You 
> probably have a RADIUS server already, but you may need to make minor (but 
> tedious) modifications.
> 
> Factor that into your planning.

Re: BGP hold timer on IX LAN

[Colin Johnston]

low bgp timers usually done to allow faster hsrp failover result

colin

Sent from my iPhone

> On 27 Oct 2015, at 08:20, Nick Hilliard  wrote:
> 
>> On 27/10/2015 08:31, marcel.durega...@yahoo.fr wrote:
>> I'm asking because we see more and more peering partners which force the
>> hold timer to a lower value, and when BGP negotiate the timer, the lowest
>> hold timer is the winner.
> 
> You need to be careful with this.  On larger IXPs, there will be a wide
> variety of kit with different capabilities, which will usually work well in
> most circumstances, but which may not have enough cpu power to handle edge
> cases like e.g. ixp maintenance or flaps when you get large amounts of bgp
> activity.  A low bgp timer might be fine for, say an asr9k or an mx960 with
> the latest RE/RSP, but would be actively harmful if one of your peers is
> using an mx80 or a sup720.
> 
> Nick
> 
> 

Re: Uptick in spam

[Colin Johnston]

hosted gmail did catch some of the spam but not all , into auto junk filter due 
to some of the weblinks were spammy

Colin

> On 27 Oct 2015, at 14:18, Ian Smith  wrote:
> 
> I'm not making any argument about the relation of SPF compliance to message
> quality or spam/ham ratio.  You are no doubt correct that at this point in
> the game SPF doesn't matter with respect to message quality in a larger
> context, because these days messages that are not SPF compliant will simply
> never arrive, and therefore aren't sent.
> 
> I'm saying that SPF helps prevent envelope header forgery, which is what it
> was designed to do.  The fact that NANOG isn't checking SPF (and it isn't,
> I tested) was exploited and resulted in a lot of spam to the list.  This
> wasn't caught by receiving servers (like Gmail's, for example) because they
> checked mail.nanog.org against the nanog.org spf record, which checked out.
> 
> You can argue that envelope header forgery is irrelevant, and that corner
> cases don't matter.  But I think this latest incident provides a good
> counterexample that it does matter.  And it's easy to fix, so why not fix
> it?
> 
> -Ian

Re: Gmail spam filtering

[Colin Johnston]

You can override the spam filter to inbox for specific domains/address's via 
googleapps gmail filter settings config

Colin


> On 22 Nov 2015, at 17:03, Jay Ashworth  wrote:
> 
> Bout a month ago, I had someone crack a POP password on my private mail 
> server,
> and got a couple days of spam out through it before I caught it on Sunday 
> afternoon.
> 
> I locked it down, and am this weekend replacing that mail server with one
> of current vintage, serving the same domain from a linode instance on a
> different IP and, obviously, transport network.
> 
> I'm finding, though, that gmail is spam-filing the emails I send out,
> presumably because they're on the same domain name in the envelope.
> 
> Anyone got a pointer to where I go to assure Google I'm on top of it now?
> 
> The mail delivers to their inbound MX ok, it just ends up in the spam folder,
> even on my business GoogleApps account.  Delivers to Yahoomail just fine.
> 
> I checked the new IP in the MXtoolbox RBL checker, and no hits, but does
> gmail know what ranges are assigned to VPS providers, like with the cable
> swamp, and bias its spamchecking accordingly?
> 
> Cheers,
> -- jra
> 
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Ransom DDoS attack - need help!

[Colin Johnston]

fingerprint shows China and Russia related as expected
Why do the abuse teams in China and Russia ignore basic abuse reports, why 
peer/setup connections to companies where abuse is ignored.

Colin

> On 8 Dec 2015, at 07:24, Joe Morgan  wrote:
> 
> We received a similar ransom e-mail yesterday followed by a UDP flood
> attack. Here is a sample of the attack traffic we received as well as a
> copy of the ransom e-mail. Thought this might be useful to others who have
> been targeted as well. I will have to talk with our upstream providers to
> get a definitive on the size of the attacks. At the point in time we
> blackholed our ip we were seeing 20+Gbps.
> 
> *Dec/07/2015 5:40:22PM *Here is a summary of the flows to our web server IP
> during the ddos event:
> 
> 
> Top 10 flows by packets per pecond for dst IP: 96.43.134.147
>  Duration Proto  Src IP Addr Src Pt Dst Pt  Packets  pps  bps
> 0.001 UDP  175.43.224.99  1900  2245620482.0 M5.8 G
> 0.002 UDP120.199.113.49  1900  5417720481.0 M2.8 G
> 0.002 UDP27.208.164.227  1900  5417720481.0 M2.7 G
> 0.002 UDP  60.209.31.218  1900  1663220481.0 M3.0 G
> 0.002 UDP  27.220.71.238  1900  2245620481.0 M3.0 G
> 0.002 UDP  120.236.121.9  1900  6200520481.0 M2.5 G
> 0.002 UDP104.137.222.90  1900  1494420481.0 M3.7 G
> 0.002 UDP  121.27.133.72  1900  4441720481.0 M3.0 G
> 0.002 UDP92.241.8.7553  557520481.0 M  12.4 G
> 0.002 UDP120.197.56.134  1900  3067220481.0 M2.7 G
> 
> Top 10 flows by flows per second for dst IP: 96.43.134.147
>  Duration Proto  Src IP Addr Src Pt Dst Pt  Packets  pps  bps
>   248.847 UDP  41.214.2.249123  472078.6 M34594  133.4 M
>   248.886 UDP91.208.136.126123  637756.7 M26813  103.4 M
>   150.893 UDP  85.118.98.253123  472075.1 M33843  130.5 M
>   151.053 UDP  80.179.166.7123  637755.0 M33292  128.4 M
>   151.230 UDP  69.31.105.142123  472074.9 M32657  125.9 M
>   150.436 UDP  182.190.0.17123  452914.8 M32128  123.9 M
>   248.832 UDP  95.128.184.10123  637754.7 M19020  73.3 M
>   150.573 UDP  188.162.13.4123  425714.6 M30514  117.7 M
>   150.261 UDP  205.128.68.5123  452914.2 M2  107.1 M
>   149.962 UDP  205.128.68.5123  425714.1 M27443  105.8 M
> 
> Top 10 flows by bits per second for dst IP: 96.43.134.147
>  Duration Proto  Src IP Addr Src Pt Dst Pt  Packets  pps  bps
> 0.002 UDP92.241.8.7553  557520481.0 M  12.4 G
> 0.003 UDP190.184.144.7453  183402048  6826668.3 G
> 0.003 UDP190.109.218.6953  634922048  6826668.3 G
> 0.004 UDP103.251.48.24553  437012048  5120006.2 G
> 0.004 UDP46.149.191.23953  584392048  5120006.2 G
> 0.001 UDP  175.43.224.99  1900  2245620482.0 M5.8 G
> 0.006 UDP37.72.70.8553  639092048  3413334.1 G
> 0.006 UDP138.204.178.16953  21622048  3413334.1 G
> 0.006 UDP  200.31.97.10753  337652048  3413334.1 G
> 0.006 UDP  110.164.58.8253  613972048  3413334.1 G
> 
> 
> 
> Copy of the e-mail headers:
> 
> Delivered-To: j...@joesdatacenter.com
> Received: by 10.79.27.84 with SMTP id b81csp1190623ivb;
>Mon, 7 Dec 2015 15:32:22 -0800 (PST)
> X-Received: by 10.25.88.208 with SMTP id m199mr28948lfb.157.1449531142088;
>Mon, 07 Dec 2015 15:32:22 -0800 (PST)
> Return-Path: 
> Received: from f369.i.mail.ru (f369.i.mail.ru. [217.69.141.11])
>by mx.google.com with ESMTPS id 7si214394lfk.103.2015.12.07.15.32.21
>for 
>(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
>Mon, 07 Dec 2015 15:32:22 -0800 (PST)
> Received-SPF: pass (google.com: domain of armada.collect...@bk.ru
> designates 217.69.141.11 as permitted sender) client-ip=217.69.141.11;
> Authentication-Results: mx.google.com;
>   spf=pass (google.com: domain of armada.collect...@bk.ru
> designates 217.69.141.11 as permitted sender)
> smtp.mailfrom=armada.collect...@bk.ru;
>   dkim=pass header.i=@bk.ru;
>   dmarc=pass (p=NONE dis=NONE) header.from=bk.ru
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=bk.ru; s=mail;
>   h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From;
> bh=1BpwCe2lM8814gJCW/09LwlVtrY6pZtMIFMB0Eprzmw=;
>   
> b=DKaMWqtH3zre6+R+qmC6+5DTa/o3zx58ubNGalhnEP8cJUtZ/Ln8DnxkQojAdL46g06xlY8rl2QhH07Rm/BHMG9ahsqKSW59F04vcrSv6m6vLnu+4GVwW0ZnRrbkYIaKJohosgdUzUMew9naxuDpF+fD1UqPKCqSs2jgu5071Dw=;
> Received: from [95.191.131.93] (ident=mail)
>   by f369.i.mai

Re: John McAfee: Massive DDoS attack on the internet was from smartphone botnet on popular app

[Colin Johnston]

saw a lot of bad traffic from china mobile more recently, hard to solve since 
abuse reports ignored.

colin
Sent from my iPhone

> On 12 Dec 2015, at 06:18, Jay Ashworth  wrote:
> 
> Is McAfee just talking to dry his teeth here? This isn't actually practical, 
> is it? Carriers would notice, right?
> 
> http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-app-1532993
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Fwd: ByteNight 2015 North West movie

[Colin Johnston]

As network/server techies  (UK and EU/USA) lets raise even more money donations 
next year for Action for Children.

Colin


> Begin forwarded message:
> 
> From: Colin Johnston 
> Subject: Fwd: ByteNight 2015 North West movie
> Date: 17 December 2015 at 16:25:12 GMT
> To: "" , 
> stephen , "ASPINALL, Karen" 
> , CWU Mersey Branch 
> Cc: Colin Johnston , Kylie Prankerd 
> , Eric Johnston , 
> colin.johnst...@bt.com
> 
> Please come and support next year, this is important to us that this event is 
> seen as the best event in the northwest for community involvement
> I raised 720 pounds as sole BT North West member, and 1 million pounds raised 
> uk wide
> 
>> https://youtu.be/aHeq9F-m4NY <https://youtu.be/aHeq9F-m4NY>
> 
> 
> Colin Johnston
> 
>> Begin forwarded message:
>> 
>> From: Colin Johnston mailto:col...@gt86car.org.uk>>
>> Subject: ByteNight 2015 North West movie
>> Date: 17 December 2015 at 16:05:18 GMT
>> To: colin.johnst...@bt.com <mailto:colin.johnst...@bt.com>
>> Cc: Colin Johnston mailto:col...@gt86car.org.uk>>
>> 
>> https://youtu.be/aHeq9F-m4NY <https://youtu.be/aHeq9F-m4NY> 
>> <https://youtu.be/aHeq9F-m4NY>

de-peering for security sake

[Colin Johnston]

see
http://map.norsecorp.com

We really need to ask if China and Russia for that matter will not take abuse 
reports seriously why allow them to network to the internet ?

Colin

Re: de-peering for security sake

[Colin Johnston]

> On 25 Dec 2015, at 00:48, valdis.kletni...@vt.edu wrote:
> 
> On Thu, 24 Dec 2015 23:44:10 +0000, Colin Johnston said:
>> We really need to ask if China and Russia for that matter will not take abuse
>> reports seriously why allow them to network to the internet ?
> 
> Well, first off, it isn't like China or Russia are just one ASN.  You'd have
> to de-peer a bunch of ASN's - and also eliminate any paid transit connections.
> 
> Note that even North Korea has managed to land at least a small presence on
> the Internet.  Are you going to ban them too?
> 
> While we're banning countries, how about the country that's known for
> widespread surveillance both foreign and domestic, has one of the strongest
> cyber warfare arsenals around, and has been caught multiple times diverting 
> and
> backdooring routers sold to foreign countries?
> 
> Oh wait, that's the US. Maybe we better rethink this?
> 
> Obviously, there's a lot of organizations that think that being able to
> communicate with China and Russia outweighs the security issues.  You are
> of course welcome to make a list of all Russian and Chinese ASNs and block
> their prefixes at your border.

So therefore we must somehow engage and enforce best practice for abuse alerts 
and action issues

Colin

Re: de-peering for security sake

[Colin Johnston]

why do the chinese network folks never reply and action abuse reports, normal 
slow speed network abuse is tolerated, but not high speed deliberate abuse 
albeit compromised machines

Sent from my iPhone

> On 25 Dec 2015, at 19:43, Baldur Norddahl  wrote:
> 
>> On 25 December 2015 at 20:06, Lee  wrote:
>> 
>> Enable IPv6 for your users.  1) it's not going to have any "history" &
>> 2) ipv6 probably isn't blocked.
>> 
> 
> I am not aware of just one single government site in this country (Denmark)
> that is IPv6 enabled. There are zero danish news sites that are IPv6
> enabled. In fact, nothing here is IPv6 enabled - with the exception of all
> major ISP sites. For some strange reason all ISPs have IPv6 on their
> websites (but they do not provide IPv6 to their customers). It is sad
> really.
> 
> 
>> 
>>> So now my users can not access government sites because the IP ranges
>> were
>>> owned by a company in a different country two years ago.
>> 
>> Find one of your users that's a citizen of said gov't & forward their
>> complaint to the gov't sites.  Non-citizen complaints are much easier
>> to ignore..
>> 
> 
> I am a citizen and yes, they do ignore us. If you can manage to find the
> right guy, he can probably fix it in a few minutes. It is just that there
> is no way to get to that guy. The front desk has no clue what you are
> talking about. To these people we should just stop sending traffic from
> Romania and it would all be fixed, no?
> 
> To make it worse it is a really boring game of whack a mole. The users are
> constantly finding new sites that are either blocking us or are showing the
> site in the wrong language. Each time we open up a new IP series, it all
> starts over again. We do not have enough cash on hand to simply buy a real
> large chunk of IPv4, so we have multiple smaller blocks.
> 
> With regards to this thread, I am finding a worrying trend for websites to
> block out of country IP-addresses at the firewall. In the past you could
> expect that some content would not play or that your credit card payment
> would be blocked. But now you never get to that stage because sites are
> dropping the packets at the firewall.
> 
> Regards,
> 
> Baldur

Re: de-peering for security sake

[Colin Johnston]

been there, done that
网络滥用 fix you ntp reflection servers :)

Sent from my iPhone

> On 25 Dec 2015, at 20:29, Baldur Norddahl  wrote:
> 
>> On 25 December 2015 at 21:10, Colin Johnston  wrote:
>> 
>> why do the chinese network folks never reply and action abuse reports,
>> normal slow speed network abuse is tolerated, but not high speed deliberate
>> abuse albeit compromised machine
> 
> They do not speak the same language as you. They barely understand your
> complaint and you would not understand their reply (in chinese!) - or do
> you expect everyone to know english?
> 
> Why does everyone expect the chinese to use Google Translate? Try it
> yourself before sending off your complaint in Mandarin...
> 
> Regards,
> 
> Baldur

Re: de-peering for security sake

[Colin Johnston]

interesting:)
but useful to make a attempt at cleaning up traffic from china and russia

colin

Sent from my iPhone

> On 27 Dec 2015, at 06:32, Hugo Slabbert  wrote:
> 
>> On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian 
>>  wrote:
>> 
>> Hmm, has anyone at all kept count of the number of times such a discussion 
>> has started up in just the last year...
> 
> Not on an ongoing basis, but I was curious as well, so a quick mailbox search 
> for 2015:
> 
> http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
> subject: Facebook outage?
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
> subject: AOL Postmaster
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
> http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
> subject: Getting hit hard by CHINANET
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
> subject: BGP offloading (fixing legacy router BGP scalability issues)
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
> subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 
> hours
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
> subject: de-peering for security sake
> author: Colin Johnston 
> 
> I tried to be pretty wide in the search and filter through a decent chunk of 
> false positives manually, though of course I could have missed some.  It does 
> skip a few of the "all of their traffic is crap and abuse reports are 
> ignored" messages that don't *explicitly* call for wholesale country-level 
> blocks or de-peering.
> 
>> ...and how many more times in the past 16 or so years?
> 
> I was curious, but not masochistic ;)
> 
> -- 
> Hugo
> 
> h...@slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
> 
> (also on textsecure & redphone)
> 
> 
>> 
>> Mind you, back in say 2004, this discussion would have run to 50 or 60 
>> emails at a bare minimum, in no time at all.
>> 
>> --srs
>> 
>> On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:
>> 
>>>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>>> Let’s just cut off the entirety of the third world instead of having
>>>> a tangible mitigation plan in place.
>>> 
>>> While you thing you are making a snarky response, it would be handy for end 
>>> users to be able to turn on and off access to other countries retail.

Fwd: port 123 reflection attacks

[Colin Johnston]

Where does it say we need to contact home cert instead on your website ?
verification of what ?
HSOFT ranges have been compromised by NTP reflection attacks and the NTP 
servers hosted by HSOFT need to have a NTP update.

This has been discussed on NANOG and I also sent information in Chinese to aid 
debug as well.

Have had no response from HSOFT…

Colin


> Begin forwarded message:
> 
> From: "cncertcc" 
> Subject: Re:Fwd: port 123 reflection attacks
> Date: 30 December 2015 at 08:15:28 GMT
> To: "Colin Johnston" 
> 
> Greetings,
> Please forward the case to the corresponding CERT you are located in first to 
> have it transferred to CNCERT after verification. Thanks for your 
> understanding.
>  
>  
> 
> 
> 
> 
> --
> 
> Thanks and Regards
> CNCERT/CC
> 
> 国家互联网应急中心
> National Computer network Emergency Response technical Team / Coordination 
> Center of China
> Tel:+8610-82991000 fax:+8610-82990375
> email: cnc...@cert.org.cn website:www.cert.org.cn
> Address: A3 Yumin Road, Chaoyang District, Beijing,100029, China 
> ----
>  
>  
>  
> -- Original --
> From:  "Colin Johnston";
> Date:  Fri, Dec 25, 2015 07:31 PM
> To:  "cncertcc";
> Cc:  "Colin Johnston";
> Subject:  Fwd: port 123 reflection attacks
>  
> 
> 
>> Begin forwarded message:
>> 
>> From: Colin Johnston mailto:col...@gt86car.org.uk>>
>> Subject: Fwd: port 123 reflection attacks
>> Date: 25 December 2015 at 11:27:02 GMT
>> To: oversea-supp...@cnnic.cn <mailto:oversea-supp...@cnnic.cn>, 
>> bdserv...@cnnic.cn <mailto:bdserv...@cnnic.cn>
>> Cc: Colin Johnston mailto:col...@gt86car.org.uk>>
>> 
>> Can you investigate with priority please
>> 
>> Colin
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Colin Johnston mailto:col...@gt86car.org.uk>>
>>> Subject: port 123 reflection attacks
>>> Date: 25 December 2015 at 11:19:26 GMT
>>> To: 16036...@qq.com <mailto:16036...@qq.com>, i...@cnnic.cn 
>>> <mailto:i...@cnnic.cn>
>>> Cc: Colin Johnston mailto:col...@gt86car.org.uk>>
>>> 
>>> please stop the port 123 reflection attacks from 115.47.24.220
>>> 
>>> Colin
>>> 
>> 
> 

Re: de-peering for security sake

[Colin Johnston]

cats are nice

colin

Sent from my iPhone

> On 19 Jan 2016, at 15:12, "Michael O'Connor"  wrote:
> 
> Why do we believe network administrators can advocate perfectly for
> customer access?
> I couldn't control my own children's access without making us all
> miserable.
> 
> Nation state access control in a free country at the network layer is bound
> to fail, way too many cats to herd.
> 
> 
> 
>> On Mon, Jan 18, 2016 at 2:31 PM,  wrote:
>> 
>> 
>> On January 18, 2016 at 00:21 valdis.kletni...@vt.edu (
>> valdis.kletni...@vt.edu) wrote:
>>> On Sun, 17 Jan 2016 19:39:52 -0500, b...@theworld.com said:
 How about if backed by an agreement with the 5 RIRs stating no new
 resource allocations or transfers etc unless a contract is signed and
 enforced? Or similar.
>>> 
>>> Then they'd just resort to hijacking address space.
>>> 
>>> Oh wait, they already do that and get away with it
>> 
>> I think we're talking about two different problems, both valid.
>> 
>> One is legitimate operators who probably mostly want to do the right
>> thing but are negligent, disagree (perhaps with many one this list) on
>> what is an actionable problem, etc.
>> 
>> The other are those actors prone to criminality.
>> 
>> I was addressing the first problem though I'd assert that progress on
>> the first problem would likely yield progress on the second, or
>> cooperation anyhow.
>> 
>>> 
>>> (And a threat of withholding IP address space from long-haul providers
>> isn't as
>>> credible - they have much less need for publicly routed IP addresses
>> than
>>> either eyeball farms or content farms, so you'll have to find some
>> other way to
>>> motivate them to not accept a hijacked route announcement...)
>>> 
>> 
>> No man is an island entire of himself -- John Donne.
>> 
>> First one has to agree to the concept of creating a network based on
>> contractual agreements.
>> 
>> I gave some examples of how to encourage actors to enter into those
>> contracts, my list wasn't intended to be exhaustive, it was intended
>> to be an existence proof, some pressure points exist and are easy to
>> understand even if not complete.
>> 
>> Besides, why make the perfect the enemy of the good? If many, perhaps
>> not all (or not at first), agreed to a common set of contractual
>> obligations that would be progress, no?
>> 
>> Is there even a document which describes what a "hijacked" net block
>> is and why it is bad? Obvious? No, it is not obvious. The best one can
>> say is there exist obvious cases.
>> 
>> --
>>-Barry Shein
>> 
>> Software Tool & Die| b...@theworld.com |
>> http://www.TheWorld.com
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
>> 
> 
> 
> 
> -- 
> Michael O'Connor
> ESnet Network Engineering
> m...@es.net
> 631 344-7410

Re: Team Cymru BGP bogon status ???

[Colin Johnston]

no idea down from bt as in uk though

colin

Sent from my iPhone

> On 31 Jan 2016, at 16:44, Matthew Huff  wrote:
> 
> Starting around 7:17 am EST, we lost our IPv4 & IPv6  BGP connections to 
> Cymru. We have two connections in both IPv4 and IPv6 on both of our two 
> routers. On each router one connection is stuck in active, the other 
> providing 0 prefixes. I can’t get to http://www.team-cymru.org from either 
> work or home. Anyone know what’s up?

Re: Yet another Quadruple DNS?

[Colin Johnston]

> On 2 Apr 2018, at 10:32, William Waites  wrote:
> 
> 
> 
>> On 2 Apr 2018, at 02:57, Aftab Siddiqui  wrote:
>> 
>> Here is the update from Geoff himself. I guess they didn't want to publish
>> it on April 1st (AEST).
>> https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreement-with-cloudflare/
> 
> The research justification for a RIR to do this seems a little thin.
> Surely we, as a community already know about what happens when a company
> operates a public resolver. How will yet another one will tell us more?
> 
The connectivity aspects could easily be done by using ripe atlas probe queries 
with dns type.

Colin

Re: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london

[Colin Johnston]

dont know if this is a problem but seeing different as paths for 1.0.0.1 and 
1.1.1.1 in UK as lands

2  185.61.135.25 (185.61.135.25)  1.964 ms  72.824 ms  72.835 ms
 3  10.254.84.3 (10.254.84.3)  2.671 ms  2.577 ms  2.601 ms
 4  31.28.72.22 (31.28.72.22)  2.798 ms  2.897 ms  3.123 ms
 5  * * *
 6  * * *
 7  ve160.er2.thn.as50056.net (178.18.119.90)  3.786 ms 178.18.122.193 
(178.18.122.193)  2.542 ms ve160.er2.thn.as50056.net (178.18.119.90)  3.736 ms
 8  * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1)  3.350 ms *



 2  185.61.135.25 (185.61.135.25)  3.172 ms  3.154 ms  3.130 ms
 3  10.254.84.3 (10.254.84.3)  3.228 ms  3.525 ms  3.502 ms
 4  31.28.72.22 (31.28.72.22)  3.781 ms  3.869 ms  3.857 ms
 5  * * *
 6  ve165.er1.the.as50056.net (94.126.43.225)  16.655 ms  9.496 ms  9.454 ms
 7  lonap.as13335.net (5.57.81.75)  91.859 ms  2.484 ms  196.896 ms
 8  1dot1dot1dot1.cloudflare-dns.com (1.0.0.1)  2.504 ms  2.804 ms  2.799 ms


Colin

Re: Unusually High traffic from Akamai/Oracle - public-yum.oracle.com

[Colin Johnston]

latest yum oracle linux applied ok today fine, 153mb
Have not seen looking content either

Colin


> On 9 May 2018, at 20:48, James Stahr  wrote:
> 
> 
> 
> Hi,
> 
> Since I'm not a customer of either organization, I'm reaching out to NANOG 
> for a contact and perhaps others may also be experiencing similar symptoms 
> over the past 3-4 weeks.  The situation appears to be that customers of ours 
> have Oracle Linux and when they attempt to download updates, their traffic 
> goes through the roof for hours on end.  While researching this phenomenon, I 
> found this discussion which coincides with the traffic I've seen, however 
> there is no mention of excessive traffic resulting from this "corruption" nor 
> have their been any additional reports:
> 
> https://community.oracle.com/thread/4138810
> 
> 
> Currently, I have two customer environments which are hitting about ~2Gb/s 
> when normally their traffic levels are nearly zero.   At first I thought it 
> was an isolated incident but then we observed the same issue with another 
> customer.  All of this traffic is coming from 23.35.204.188:80, which belongs 
> to Akamai.  Since that's somewhat of a dead end, we examined the hosts which 
> are requesting the data from Akamai and found that they are all Oracle Linux 
> boxes and it's a yum process on Oracle Linux which appears to be repeatedly 
> downloading the same content for hours on end:
> 
> 
> [root@xyzzy noc]# netstat -plutan | grep :80
> tcp0  0 172.16.122.112:1427223.35.204.188:80
> ESTABLISHED 58880/python
> [root@xyzzy noc]# ps auxww | grep python
> root 41015  0.0  0.3 401940 52044 ?SApr30   0:02 
> /usr/bin/python2 /usr/share/system-config-lvm/system-config-lvm.py
> root 58880 59.7  1.0 479680 164140 ?   R18:24  27:18 
> /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py get-updates 
> none
> 
> I can only assume that the data being downloaded is corrupt as this multiple 
> hour download does not consume any disk space and because the file(s) are 
> repeatedly downloaded, the logic behind the yum routines are also at fault 
> for 1TB of
> 
> I don't expect anyone at Akamai to reach out to me since they are simply the 
> middle man here, but I'm hoping that someone at Oracle will because the cost 
> to Oracle for Akamai to deliver this junk traffic is not zero and I have a 
> hard time seeing how this issue is isolated to our network.  I'd also be 
> interested to hear from anyone else who has been seeing traffic spikes from 
> public-yum.oracle.com.
> 
> 
> -James Stahr

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

[Colin Johnston]

also could use ripe atlas

Colin


> On 26 Sep 2018, at 09:15, Stephane Bortzmeyer  wrote:
> 
> On Wed, Sep 26, 2018 at 10:59:02AM +0300,
> Michael Bullut  wrote 
> a message of 192 lines which said:
> 
>> How would you gauge good DNS performance?
> 
> To test {XXX} performance, you use a {XXX} client, where XXX = DNS,
> HTTP, SSH, LDAP, etc.
> 

Re: Hulu / ESPN: Commercial IP Address

[Colin Johnston]

nhs public wifi seems weird for hulu and wifi calling,  uses sophos i see so 
wondered if right rules enabled...

col

Sent from my iPod

> On 15 Oct 2018, at 09:10, Christian de Larrinaga  wrote:
> 
> Brandon, That is odd. Might this be an artefact of cellular carriers being 
> fixated on revenue protection of their inter carrier rates. Are they 
> (wrongly) assuming a public IP might be a grey market termination risk onto 
> their networks?
> 
> best 
> 
> Christian
> 
> Brandon Butterworth wrote:
>> 
>>> On Sat Oct 13, 2018 at 02:39:37PM -0400, Daniel Corbe wrote:
>>> 
>>> I had a customer with a similar issue.   I statically assigned them a  
>>> different IP and it didn???t resolve it.   The problem turned out to be 
>>> tied  to their Hulu account.
>> 
>> 
>> I had a similar issue with wifi calling on O2 in the UK. it
>> worked on some wifi but not others. After pressing O2 support
>> for quite some time they admitted "you're on commercial IP space
>> which we don't support" but would say no more.
>> 
>> After a little puzzling I realised the working wifis were
>> NATed to 1918 so I added NAT to one that wasn't working and the
>> phone registered OK for wifi calling. The address it was NATed
>> to was the same range so it appears their test is for 1918 space
>> on the client.
>> 
>> I'm not saying HULU is the same, I've never has access to it,
>> but companies cook up some wierd ideas of what is accepable for
>> client access. I've still got no idea why having a public IP makes
>> it unnaceptable to make phone calls where their coverage is poor.
>> 
>> brandon

Re: DDOS solution recommendation

[Colin Johnston]

> On 12 Jan 2015, at 08:29, David Hofstee  wrote:
> 
> Hi Mike, 
> 
> About trying to hit the mail ports... It is very easy for a domain to set its 
> MX to a random host name. So before you block you might want to check the 
> To-domain in the header of the mail. Otherwise it is too easy to DoS yourself 
> (by planting email addresses in systems, such as mine, and then changing the 
> MX of that domain to your hosts).
> 


Should be overcome by good dont block range checker and header checks as above

Colin

Re: DDOS solution recommendation

[Colin Johnston]

unfortunately chinanet antispam/abuse email box is always full, after a while 
people block .
always check arin/ripe for known good provider blocks and actively exclude from 
rules



ddos protection via careful overview ips rules and active web source ip 
monitoring works well, the hard part is daily rule updates and blocks until you 
know most traffic is genuine.

colin

Sent from my iPhone

> On 11 Jan 2015, at 19:42, "Patrick W. Gilmore"  wrote:
> 
> I do love solutions which open larger attack surfaces than they are supposed 
> to close. In the US, we call that "a cure worse than the disease".
> 
> Send packet from random bot with source of Google, Comcast, Akamai, etc. to 
> Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off 
> from the world.
> 
> Voilà! Denial of service accomplished without all the hassle of sending 100s 
> of Gbps of traffic.
> 
> Best part is he was willing to explain this to 10,000+ of his not-so-closest 
> friends, in a search-engine-indexed manner.
> 
> -- 
> TTFN,
> patrick
> 
>> On Jan 11, 2015, at 14:34 , Phil Bedard  wrote:
>> 
>> Many attacks can use spoofed source IPs, so who are you really blocking?  
>> 
>> That's why BCP38 as mentioned many times already is a necessary tool in 
>> fighting the attacks overall.  
>> 
>> Phil 
>> 
>> 
>> 
>> 
>>> On 1/11/15, 4:33 PM, "Mike Hammett"  wrote:
>>> 
>>> I didn't necessarily think I was shattering minds with my ideas. 
>>> 
>>> I don't have the time to read a dozen presentations. 
>>> 
>>> Blackhole them and move on. I don't care whose feelings I hurt. This 
>>> isn't kindergarten. Maybe "you" should have tried a little harder to not 
>>> get a virus in the first place. Quit clicking on male enhancement ads or 
>>> update your OS occasionally. I'm not going to spend a bunch of time and 
>>> money to make sure someone's bubble of bliss doesn't get popped. Swift, 
>>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days 
>>> you can prove yourself to be responsible, we can try this again. Well, 
>>> that or a sufficient support request. 
>>> 
>>> Besides, if enough people did hat, the list of blackholes wouldn't be 
>>> huge as someone upstream already blocked them. 
>>> 
>>> 
>>> 
>>> 
>>> - 
>>> Mike Hammett 
>>> Intelligent Computing Solutions 
>>> http://www.ics-il.com 
>>> 
>>> 
>>> 
>>> - Original Message -
>>> 
>>> From: "Roland Dobbins"  
>>> To: nanog@nanog.org 
>>> Sent: Sunday, January 11, 2015 9:29:33 AM 
>>> Subject: Re: DDOS solution recommendation 
>>> 
>>> 
 On 11 Jan 2015, at 22:21, Mike Hammett wrote: 
 
 I'm not saying what you're doing is wrong, I'm saying whatever the 
 industry as a whole is doing obviously isn't working and perhaps a 
 different approach is required.
>>> 
>>> You haven't recommended anything new, and you really need to do some 
>>> reading in order to understand why it isn't as simple as you seem to 
>>> think it is. 
>>> 
 Security teams? My network has me, myself and I.
>>> 
>>> And a relatively small network, too. 
>>> 
 If for example ChinaNet's abuse department isn't doing anything about 
 complains, eventually their whole network gets blocked a /32 at a 
 time. *shrugs* Their loss.
>>> 
>>> Again, it isn't that simple. 
>>> 
>>> --- 
>>> Roland Dobbins 
> 

Re: Office 365 Expert - I am not. I have a customer that...

[Colin Johnston]

> On 20 Jan 2015, at 23:19, Christian Kuhtz  wrote:
> 
> I don't belong to the O365 product group, but did you look at this? 
> 
> https://technet.microsoft.com/en-us/library/hh852542.aspx
> 
> and a blog article to go along with that:
> 
> http://blogs.technet.com/b/educloud/archive/2013/08/20/do-you-have-any-bandwidth-calculators-for-office-365.aspx
> 
> There's a bunch more than comes up under "office 365 bandwidth calculator" in 
> your friendly neighborhood search engine.
> 
> The Exchange client model, for example, looks like it can give you basics for 
> a model based projection if you can characterize your base.
> 

biggest issue to deal with is migration traffic analysis,
you need to identify biggest pst users, biggest non techie users who dont 
delete emails so hence have large email sets.
you need to identify work times so that migration efforts can start overnight 
ideally.

Colin

Re: Facebook outage?

[Colin Johnston]

implement service routers for pop machines using cbac checking and acl for 
private address range spoofing.
block china ranges since never respond to abuse reports.
move on

Colin

> On 27 Jan 2015, at 07:23, Ken Chase  wrote:
> 
> cable was replugged, insta/fb back up here.
> 
> /kc
> 
> On Tue, Jan 27, 2015 at 02:04:58AM -0500, Zachary said:
>> Seems unlikely, probably taking credit for someone tripping over a cable.
> 
> -- 
> Ken Chase - m...@sizone.org Toronto

Re: scaling linux-based router hardware recommendations

[Colin Johnston]

qnx os based router works well with powerpc, could be pushed far higher load 
than intel based chips

Colin


>> That's the problem though.
>> 
>> Everyone has presentations for the most part, very few actual tools
>> that 
>> end users can just use exist.
>> 
>> On 1/28/2015 午後 08:02, Robert Bays wrote:
 On Jan 27, 2015, at 8:31 AM, Jim Shankland 
>> wrote:
 
 My expertise, such as it ever was, is a bit stale at this point, and
>> my
 figures might be a little off. But I think the general principle
 applies: think about the minimum number of x86 instructions, and the
 minimum number of main memory accesses, to inspect a packet header,
>> do a
 routing table lookup, and enqueue the packet on an outbound
>> interface. I
 can't see that ever getting reduced to the point where a generic
>> server
 can handle 40-byte packets at line rate (for that matter, "line
>> rate" is
 increasing a lot faster than "speed of generic server" these days).
>>> Using DPDK it’s possible to do everything stated and achieve 10Gbps
>> line rate at 64byte packets on multiple interfaces simultaneously.  Add
>> ACLs to the test setup and you can reach significant portions of 10Gbps
>> at 64byte packets and full line rate at 128bytes.
>>> 
>>> Check out Venky Venkatesan’s presentation at the last DPDK Summit for
>> interesting information on pps/CPU cycles and some of the things that
>> can be done to optimize forwarding in a generic processor environment.
>>> 
>>> 
>> http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan
>>> 
>>> 
>> 
>> 
>> !DSPAM:54c8de34274511264773590!
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Checkpoint IPS

[Colin Johnston]

Thought I would add

Astaro IPS works great, great functionality and does prevent ddos and exploits.

Colin

Re: Checkpoint IPS

[Colin Johnston]

Yes, update can cause problems, same as router code updates as well.
but update is price of progress.

Col

> On 6 Feb 2015, at 16:44, Darden, Patrick  wrote:
> 
> 
> Sorry, didn't mean to imply otherwise.  Had an incident back in ~2004 where 
> an IPS signature update closed ALL network traffic.  Including fix-it 
> updates.  Definitely a case where the IPS caused major difficulties for a 
> network.
> 
> --p
> 
> -----Original Message-
> From: Colin Johnston [mailto:col...@gt86car.org.uk] 
> Sent: Friday, February 06, 2015 10:32 AM
> To: Darden, Patrick
> Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org
> Subject: [EXTERNAL]Re: Checkpoint IPS
> 
> Thought I would add
> 
> Astaro IPS works great, great functionality and does prevent ddos and 
> exploits.
> 
> Colin
> 

Re: Checkpoint IPS

[Colin Johnston]

yes, using new rules via test ips good best practice as well.


> On 6 Feb 2015, at 16:47, Darden, Patrick  wrote:
> 
> 
> Auto-Update can cause problems.  I take the stance that updates should be 
> verified in a CERT or ISO first, before being operationalized.
> --p
> 
> -Original Message-
> From: Colin Johnston [mailto:col...@gt86car.org.uk] 
> Sent: Friday, February 06, 2015 10:46 AM
> To: Darden, Patrick
> Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org
> Subject: [EXTERNAL]Re: Checkpoint IPS
> 
> Yes, update can cause problems, same as router code updates as well.
> but update is price of progress.
> 
> Col
> 
>> On 6 Feb 2015, at 16:44, Darden, Patrick  wrote:
>> 
>> 
>> Sorry, didn't mean to imply otherwise.  Had an incident back in ~2004 where 
>> an IPS signature update closed ALL network traffic.  Including fix-it 
>> updates.  Definitely a case where the IPS caused major difficulties for a 
>> network.
>> 
>> --p
>> 
>> -Original Message-
>> From: Colin Johnston [mailto:col...@gt86car.org.uk] 
>> Sent: Friday, February 06, 2015 10:32 AM
>> To: Darden, Patrick
>> Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org
>> Subject: [EXTERNAL]Re: Checkpoint IPS
>> 
>> Thought I would add
>> 
>> Astaro IPS works great, great functionality and does prevent ddos and 
>> exploits.
>> 
>> Colin
>> 
> 

Re: Low cost WDM gear

[Colin Johnston]

Yes can do long distances without need to amplifier site (train tracks for 
example) but you need to make sure ground is stable and if using track bed of 
train track that the ballast is good and stable else ground tremors affect the 
signal quality.

Colin



> On 7 Feb 2015, at 22:32, Tim Durack  wrote:
> 
> You can do ~500km without inline amplifier sites using EDFA+Raman+ROPA, but
> you are going to need some serious optical engineering to make that work.
> The more standard way to do it is amplifier sites every 80-100km for EDFA.
> If you are doing 10GigE you will need to allow for DCM also.
> 
> On Sat, Feb 7, 2015 at 1:04 PM, Mike Hammett  wrote:
> 
>> One particular route I'm looking at is 185 miles, so of the options
>> presented 300 km is closest. ;-)
>> 
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> - Original Message -
>> 
>> From: "Christopher Morrow" 
>> To: "Kenneth McRae" 
>> Cc: "NANOG" 
>> Sent: Saturday, February 7, 2015 12:02:11 PM
>> Subject: Re: Low cost WDM gear
>> 
>> would be good for mike to define 'long distances' here, is it:
>> 2km
>> 30km
>> 300km
>> 3000km
>> 
>> Probably the 30-60k range is what you mean by 'long distances' but...
>> clarity might help.
>> 
>> On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae 
>> wrote:
>>> Mike,
>>> 
>>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware
>>> equipment. The FiberStore gear was a huge disappointment (excessive loss,
>>> poor technical support, refusal to issue refund without threatening legal
>>> action, etc.). I have had good results from the OSI equipment so far. I
>>> run passive muxes for CWDM (8 - 16 channels).
>>> 
>>> On Feb 07, 2015, at 09:51 AM, Manuel Marín  wrote:
>>> 
>>> Hi Mike
>>> 
>>> I can recommend a couple of vendors that provide cost effective
>> solutions.
>>> Ekinops & Packetlight.
>>> 
>>> On Saturday, February 7, 2015, Mike Hammett  wrote:
>>> 
>>> I know there are various Asian vendors for low cost (less than $500)
>> muxes
>>> to throw 16 or however many colors onto a strand. However, they don't
>> work
>>> so well when you don't control the optics used on both sides (therefore
>>> must use standard wavelengths), obviously only do a handful of channels
>> and
>>> have a distance limitation.
>>> What solutions are out there that don't cost an arm and a leg?
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>> 
>>> 
>>> --
>>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX:
>> *+52
>>> 656-257-1109*
>>> 
>>> CONFIDENTIALITY NOTICE: This communication is intended only for the use
>>> of the individual or entity to which it is addressed and may contain
>>> information that is privileged, confidential, and exempt from disclosure
>>> under applicable law. If you are not the intended recipient of this
>>> information, you are notified that any use, dissemination, distribution,
>> or
>>> copying of the communication is strictly prohibited.
>>> 
>>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la
>>> persona o entidad a la que se dirige y puede contener información
>>> privilegiada, confidencial y exenta de divulgación bajo la legislación
>>> aplicable. Si no es el destinatario de esta información, se le notifica
>> que
>>> cualquier uso, difusión, distribución o copia de la comunicación está
>>> estrictamente prohibido.
>> 
>> 
> 
> 
> -- 
> Tim:>

Re: OT - Small DNS "appliances" for remote offices.

[Colin Johnston]

use a vm dns appliance on the same machine as your vm router instance

Colin

> On 18 Feb 2015, at 14:28, Ray Van Dolson  wrote:
> 
> Hopefully not too far off topic for this list.
> 
> Am looking for options to deploy DNS caching resolvers at remote
> locations where there may only be minimal infrastructure (FW and Cisco
> equipment) and limited options for installing a noisier, more power
> hugnry  servers or appliances from a vendor.  Stuff like Infoblox is
> too expensive.
> 
> We're BIND-based and leaning to stick that way, but open to other
> options if they present themselves.
> 
> Am considering the Soekris net6501-50.  I can dump a Linux image on
> there with our DNS config, indudstrial grade design, and OK
> performance.  If the thing fails, clients will hopefully not notice due
> to anycast which will just hit another DNS server somewhere else on the
> network albeit with additional latency.  We ship out a replacement
> device rather than mucking with trying to repair.
> 
> There's also stuff like this[1] which probably gives me more horsepower
> on my CPU, but maybe not as reliable.
> 
> Maybe I'm overengineering this.  What do others do at smaller remote
> sites?  Also considering putting resolvers only at "hub" locations in
> our MPLS network based on some latency-based radius.
> 
> Ray
> 
> [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309

Re: OT - Small DNS "appliances" for remote offices.

[Colin Johnston]

older apple tv will work as well :)

Colin

> On 19 Feb 2015, at 19:47, Mel Beckman  wrote:
> 
> If your time is worth anything, you can't beat the Mac Mini, especially for a 
> branch office mission-critical application like DNS.
> 
> I just picked up a Mini from BestBuy for $480. I plugged it in, applied the 
> latest updates, purchased the MacOSX Server component from the Apples Store 
> ($19), and then via the Server control panel enabled DNS with forwarding.
> 
> Total time from unboxing to working DNS: 20 minutes.
> 
> The Server component smartly ships with all services disabled, in contrast to 
> a lot of Linux distros, so it's pretty secure out of the box. You can harden 
> it a bit more with the built-in PF firewall. The machine is also IPv6 ready 
> out of the box, so my new DNS server automatically services both IPv4 and 
> IPv6 clients.
> 
> You get Apple's warranty and full support. Any Apple store can do testing and 
> repair.
> 
> And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of 
> DNS requests.
> 
> Of course, if your time is worth little, spend a lot of time tweaking slow, 
> unsupported, incomplete solutions.
> 
> -mel
> 
> On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko 
> wrote:
> 
>> On 2015-02-19 18:26, valdis.kletni...@vt.edu wrote:
>>> On Thu, 19 Feb 2015 14:52:42 +, David Reader said:
 I'm using several to connect sensors, actuators, and such to a private
 network, which it's great for - but I'd think at least twice before 
 deploying
 one as a public-serving host in user-experience-critical role in a remote
 location.
>>> I have a Pi that's found a purpose in life as a remote smokeping sensor and
>>> related network monitoring, a task it does quite nicely.
>>> Note that they just released the Pi 2, which goes from the original 
>>> single-core
>>> ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at 
>>> the
>>> same price point.  That may change the calculus. I admit not having gotten 
>>> one
>>> in hand to play with yet.
>> Weird thing - it still has Ethernet over ugly USB 2.0
>> That kills any interest to run it for any serious networking applications.
>> 
>> ---
>> Best regards,
>> Denys
> 

Re: OT - Small DNS "appliances" for remote offices.

[Colin Johnston]

here here, apple kits rocks for low end server work, sun kit rocks for high end 
server work.

Colin

> On 19 Feb 2015, at 20:55, Mel Beckman  wrote:
> 
> Keenan,
> 
> Red. Herrings.
> 
> You can provision macs over the network. That's one of the functions of Mac 
> OSX Server OS. It's trivial to then promote them to servers themselves. All 
> remotely.
> 
> Also, the Mac is running a full BIND9 implementation, not some cutdown 
> version. Yes the GUI is minimal, but there's no need to use the GUI, and you 
> don't even have a GUI on other platforms for the most part.
> 
> BGP speaker? Come on, you're gilding the lily.
> 
> Yes, Apple is silent about its plans.  But the Mac Mini and Server OS have 
> been well supported for over a decade. I don't know why you're bringing 
> server hardware into this, the whole point of the discussion is to avoid 
> using server hardware. And how much open source "road map" has failed to 
> materialize? Lots! The future-proofing argument cuts both ways, my friend.
> 
> You may have little confidence in Apple, but the rest of the world seems to 
> have great confidence. Just look at Apple's stock performance and market cap.
> 
> As a famous scientist one said: "The absence of data is not data." :-)
> 
> -mel beckman
> 
> On Feb 19, 2015, at 12:43 PM, "Keenan Tims" 
> mailto:kt...@stargate.ca>> wrote:
> 
> If you have a lot of locations, as I believe Ray is looking for, all of
> this is a manual process you need to do for each instance. That is slow
> and inefficient. If you're doing more than a few, you probably want
> something you can PXE boot for provisioning and manage with your
> preferred DevOps tools. It also sounds like he wants to run anycast for
> this service, so probably needs a BGP speaker and other site-specific
> configuration that I assume is not covered by the cookie-cutter OSX
> tools. Of course you could still do it this way with a Mac Mini running
> some other OS, but why would you want to when there are plenty of other
> mini-PC options that are more appropriate?
> 
> Also: With Apple dropping their Pro products and leaving customers in
> the lurch, and no longer having any actual server hardware, I would have
> very little confidence in their server software product's quality org
> likely longevity. And of course they're mum on their plans, so it's
> impossible to plan around if they decide to exit the market.
> 
> Keenan
> 
> On 02/19/2015 11:47 AM, Mel Beckman wrote:
> If your time is worth anything, you can't beat the Mac Mini, especially for a 
> branch office mission-critical application like DNS.
> 
> I just picked up a Mini from BestBuy for $480. I plugged it in, applied the 
> latest updates, purchased the MacOSX Server component from the Apples Store 
> ($19), and then via the Server control panel enabled DNS with forwarding.
> 
> Total time from unboxing to working DNS: 20 minutes.
> 
> The Server component smartly ships with all services disabled, in contrast to 
> a lot of Linux distros, so it's pretty secure out of the box. You can harden 
> it a bit more with the built-in PF firewall. The machine is also IPv6 ready 
> out of the box, so my new DNS server automatically services both IPv4 and 
> IPv6 clients.
> 
> You get Apple's warranty and full support. Any Apple store can do testing and 
> repair.
> 
> And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of 
> DNS requests.
> 
> Of course, if your time is worth little, spend a lot of time tweaking slow, 
> unsupported, incomplete solutions.
> 
> -mel
> 
> On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko 
> mailto:de...@visp.net.lb>>
> wrote:
> 
> On 2015-02-19 18:26, valdis.kletni...@vt.edu 
> wrote:
> On Thu, 19 Feb 2015 14:52:42 +, David Reader said:
> I'm using several to connect sensors, actuators, and such to a private
> network, which it's great for - but I'd think at least twice before deploying
> one as a public-serving host in user-experience-critical role in a remote
> location.
> I have a Pi that's found a purpose in life as a remote smokeping sensor and
> related network monitoring, a task it does quite nicely.
> Note that they just released the Pi 2, which goes from the original 
> single-core
> ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the
> same price point.  That may change the calculus. I admit not having gotten one
> in hand to play with yet.
> Weird thing - it still has Ethernet over ugly USB 2.0
> That kills any interest to run it for any serious networking applications.
> 
> ---
> Best regards,
> Denys
> 

Re: AOL Postmaster

[Colin Johnston]

block aol like china blocks with no engagement of comms as justification

colin

Sent from my iPhone

> On 24 Feb 2015, at 12:36, Rich Kulawiec  wrote:
> 
>> On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote:
>> Having exactly the same issue. Also never received any response from
>> AOL. Quite annoying.
> 
> I've been waiting since January 26th for a response from 
> dmarc-h...@teamaol.com,
> which is their stipulated contact point for DMARC issues.
> 
> Of course I wouldn't *need* a response about that if they hadn't implemented
> DMARC so foolishly.
> 
> It seems that the days when Carl Hutzler ran the place -- and ran it well --
> are now well behind them.  I didn't always agree with their decisions,
> but it was obvious that they were working hard and trying to make AOL a
> good network neighbor, so even when I disagreed I could at least acknowledge
> their good intentions.   It seems now that AOL is determined to permit
> unlimited abuse directed at the entire rest of the Internet while
> simultaneously making life as difficult as possible for everyone who
> *doesn't* abuse...and is counting on their size to make them immune from
> the consequences of that decision.
> 
> ---rsk

Re: OT: VPS with Routed IP space

[Colin Johnston]

deploy two utm's with bgp on the two internal and external interfaces

col

Sent from my iPhone

> On 24 Feb 2015, at 20:29, Zachary Giles  wrote:
> 
> 
> How about VPS providers who will do BGP... Do they exist?
> 
> 
>> On Tue, Feb 24, 2015 at 3:11 PM, Owen DeLong  wrote:
>> 
>> Or NOT. That’s a horribly ugly thing to do in a situation where the
>> desired behavior shouldn’t be that hard to achieve.
>> 
>> Owen
>> 
 On Feb 24, 2015, at 11:07 , Baldur Norddahl 
>>> wrote:
>>> 
>>> You just need to enable proxy ARP on the box to simulate a routed subnet.
>>> Den 24/02/2015 19.25 skrev "Alex Buie" :
>>> 
 Anybody know of or have recommendations for providers of small
 VPS-line boxen (or alternative solutions) to serve as GRE endpoints?
 (for a small amount of IP addresses, /29 or /28 at most)
 
 I am finding a lot of places that will give you extra IPs on the box
 itself (oftentimes out of the provider's own larger unsubnetted
 prefix) but I am looking more for a setup with a single IP on the box
 and a prefix routed to it.
 
 TIA for your insight.
 
 Alex
 
 (if you or your company can do this, direct solicitations are okay
 too. do keep in mind it's just a personal project and I do not have
 larger commercial volume at this time)
> 
> 
> -- 
> Zach Giles
> zgi...@gmail.com

Re: Verizon Policy Statement on Net Neutrality

[Colin Johnston]

fttc in uk works great for client code push remote installs , even faster than 
some offices since the fibre nodes are less contended.
seen 18mb up work fine and sustained with voip in parallel as well
colin

Sent from my iPhone

On 3 Mar 2015, at 16:20, Tim Franklin  wrote:

>> I meant that on the Internet as a whole it is unusual for such speeds to
>> actually be realized in practice due to various issues.
>> 
>> 8-10Mb/s seems to be what one can expect without going to distributed
>> protocols.
> 
> Really?  I have 2 x VDSL (40/10) to my house, running MLPPP.  I can get a 
> sustained 60M down or 15M up on a single stream without a lot of difficulty.  
> It does typically need both ends to be aware of window scaling, or you start 
> to run up against the LFN problem, but other than that it's nothing beyond 
> regular HTTP, FTP, SCP, CIFS, ...
> 
> 15M upstream *utterly* transforms working from home where all the files I'm 
> working on are on a remote file server.  Autosave is no longer a cue for a 
> 5-10 minute tea-break.
> 
> Regards,
> Tim.

Re: How to find all of an ISP's ASNs

[colin johnston]

> On 25 Oct 2016, at 18:41, Gary Baribault  wrote:
> 
> Hi folks, how to I find all ASNs that belong to an ISP? I want to block 
> access to my IoT cameras from the world other than the two local major ISPs 
> (keeping last Friday in mind!)
> 
> Gary B
> 
> 

ripe atlas has this info

Colin

Fwd: Bonus support for Action for Children

[Colin Johnston]

excuse the subject, relevant as IT techies like this.

>  
> Bonus support for Action for Children 
> A BT senior manager is donating half of his bonus to Action for Children’s 
> Byte Night North West event and encouraging others to do the same.
> Colin Johnston is an IT technical manager who has supported Action for 
> Children for several years. This year he and hundreds of other executives 
> will be sleeping out for a night on 6 October as part of the charity’s annual 
> Byte Night event.  As well as raising money by taking part in this, Colin has 
> decided to also donate 50% of his bonus payment (£2,482.00 / 2 = 
> £1241(donation amount)) this year to Action for Children.
> Colin said, “Being involved for a while with Action for Children, I’ve got to 
> know about the amazing work they do with children and young people and 
> families. I’m happy to be in a position where I can help support their 
> services by fundraising and donating.  If people can’t take part in Byte 
> Night then they can still help out by donating what they can – if other 
> executives decided to also give half of their bonus to Action for Children, 
> it would be a simple but really effective way of helping young people to have 
> a brighter future.”
>  
> Byte Night is Action for Children's biggest annual fundraiser; a national 
> ‘sleep-out’ event. Each year, hundreds of like-minded people from the 
> technology and business arena give up their beds for one night to help change 
> the lives of vulnerable young people. It all began in 1998 when 30 
> individuals slept out in London and raised £35,000. Since then Byte Night has 
> grown to 10 UK locations and over 1,200 people slept out in 2016. Byte Night 
> is one of the UK’s top 17 mass participation charity events and is the 
> largest charity sleep-out having raised over £9.6 million since the first 
> event. Byte Night is celebrating its 20th anniversary this year and its fifth 
> year in the North West.
> Colin is a board member of the North West Byte Night event.
> BT Volunteering is a very worthwhile endeavour.
>  
> See mydonate page linked to Byte Night 
> https://mydonate.bt.com/fundraisers/colinjohnston1 
> <https://mydonate.bt.com/fundraisers/colinjohnston1>
>  
> For more information go to www.bytenight.org.uk 
> <http://www.bytenight.org.uk/>  or to donate Text Byte17 and the amount to 
> 70070. 
>  
> Colin
>  
> Colin Johnston 
> <https://myprofile.bt.com/Person.aspx?accountname=IUSER%5C600969844>
> IT Support Senior Professional, Core IT Infrastructure
> BT Technology Service & Operations  
> <https://intra.bt.com/bt/tso/Pages/index.aspx> | Tel: 01313001324  
>  | MyProfile  
> <https://myprofile.bt.com/Person.aspx?accountname=IUSER%5C600969844> | 
> colin.johnst...@bt.com  <mailto:colin.johnst...@bt.com> | 
> http://fixit.bt.com/ <http://fixit.bt.com/>
>  
> BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered 
> in England and Wales no. 4190816 This electronic message contains information 
> from BT Group plc which may be privileged or confidential.  The information 
> is intended to be for the use of the individual(s) or entity named above.  If 
> you are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information is prohibited.  If 
> you have received this electronic message in error, please delete it and 
> notify me immediately by telephone or email.

Re: Puerto Rico just lost internet?

[Colin Johnston]

one ripe atlas probe is still green though


Probe ID20057IPv4 ASNAS5786 IPv4 
Prefix136.145.0.0/16 IPv6 ASNAS65003 
IPv6 Prefix2607:2000:100:116::/64 
CountryPRConnected 
since:  2017-09-12 16:17:06 UTC


> On 21 Sep 2017, at 05:26, Mehmet Akcin  wrote:
> 
> Things are getting only worst so far - most of the island is offline - see
> the screenshot or the link here live https://stat.ripe.net/PR#tabId=routing
> 
> On Wed, Sep 20, 2017 at 8:29 PM, Javier J 
> wrote:
> 
>> Thank you for this info!
>> 
>> 
>> I think most of us kind of know there are backup power strategies in place
>> but this is very detailed and appreciated. The little communication I have
>> had with family on the island they tell me no internet, no cable tv, etc so
>> this timing is good to know for when the few cell towers that survived
>> start to go dark.
>> 
>> - J
>> 
>> 
>> 
>> On Wed, Sep 20, 2017 at 4:36 PM, Sean Donelan  wrote:
>> 
>>> On Wed, 20 Sep 2017, Javier J wrote:
>>> 
 How long usually till generators at cell sites run out of juice?
 
>>> 
>>> Rough, every provider is different, backup power hierarchy:
>>> 
>>> Neighborhood pole boxes: 1-4 hours, batteries only. May be re-charged
>> with
>>> portable generators when safe to access area. There is likely severe
>>> physical damage to neighborhood lines.
>>> 
>>> Cell towers: 8-12 hours battery. Some, not all, towers have a natural gas
>>> generator or 24 hours diesel generator
>>> 
>>> Central offices and cable headends: 8-12 hours battery, 1-3 days diesel
>>> generators. Core, tandem, and hub sites usually have more backup.
>>> 
>>> Major colocation data centers: <1 hour battery, 3-14 days diesel
>> generators
>>> 
>>> Submarine cable landing points and satellite control stations: 24 hours
>>> battery, 30 days diesel generators
>>> 
>>> 
>> 

Charity IT Pulse :) one more sleep till Bytenight Action for Children 2017

[Colin Johnston]

>>  
>> Dear all, one more sleep until ByteNight events across the UK on Friday 
>> night.
>> Please donate if you can electronically
>>  
>>  
>> See mydonate page linked to Byte Night 
>> https://mydonate.bt.com/fundraisers/colinjohnston1 
>> <https://mydonate.bt.com/fundraisers/colinjohnston1>
>>  
>> For more information go to www.bytenight.org.uk 
>> <http://www.bytenight.org.uk/>  or to donate Text Byte17 and the amount to 
>> 70070. 
>>  
>> In just 1 days time, on Friday 6 October, I am spending one night sleeping 
>> rough for Byte Night. Byte Night works to support some of the 83,000 young 
>> people who are homeless in the UK. One in four young people who are homeless 
>> have been diagnosed with mental health issues and one in five will have 
>> self-harmed due to their situation at home. £10 could provide an hour’s 
>> support with a mental health practitioner for 1 young people to help them 
>> get through their issues. Action for Children has supported many young 
>> people to a safe and happy future. Unfortunately, so many more still need 
>> our help. You can help support young people across the UK by generously 
>> donating to my page
>>  
>> 
>>  
>> Yours
>>  
>> Colin Johnston
>>  
>> Colin Johnston 
>> <https://myprofile.bt.com/Person.aspx?accountname=IUSER%5C600969844>
>> IT Support Senior Professional, Core IT Infrastructure
>> BT Technology Service & Operations  
>> <https://intra.bt.com/bt/tso/Pages/index.aspx> | Tel: 01313001324  
>>  | MyProfile  
>> <https://myprofile.bt.com/Person.aspx?accountname=IUSER%5C600969844> | 
>> colin.johnst...@bt.com  <mailto:colin.johnst...@bt.com> | 
>> http://fixit.bt.com/ <http://fixit.bt.com/>
>>  
>> BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. 
>> Registered in England and Wales no. 4190816 This electronic message contains 
>> information from BT Group plc which may be privileged or confidential.  The 
>> information is intended to be for the use of the individual(s) or entity 
>> named above.  If you are not the intended recipient be aware that any 
>> disclosure, copying, distribution or use of the contents of this information 
>> is prohibited.  If you have received this electronic message in error, 
>> please delete it and notify me immediately by telephone or email.
> 

Re: [outages] NTP Issues Today

[Colin Johnston]

On 20 Nov 2012, at 15:38, Jeremy Chadwick  wrote:

> I'm still waiting for someone who was affected by this to provide
> coherent logs from ntpd showing exactly when the time change happened.
> Getting these, at least on an *IX system, is far from difficult folks.
> 

from firewall ntp logs
Nov 19 09:58:06 [192.168.0.1.128.176] 2012:11:19-09:58:06 ntpd[21385]: ntpd 
exiting on signal 15
Nov 19 09:58:19 [192.168.0.1.128.176] 2012:11:19-09:58:19 selfmonng[3503]: W 
check Failed increment ntpd_running counter 3 - 3
Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W 
NOTIFYEVENT Name=ntpd_running Level=INFO Id=147 sent
Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W 
triggerAction: 'cmd'
Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W 
actionCmd(+):  '/var/mdw/scripts/ntp restart'
Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 ntpd[24120]: ntpd 
4.2.4p8@1.1612-o Tue Feb  2 21:46:54 UTC 2010 (1)
Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 selfmonng[3503]: W 
child returned status: exit='0' signal='0'
Nov 19 09:58:35 [192.168.0.1.128.176] 2012:11:19-09:58:35 ntpd[24121]: kernel 
time sync status change 0001

was sync'd to 84.25.175.98, stratum 2 at the time I believe

Colin

Re: [outages] NTP Issues Today

[Colin Johnston]

no idea, re sigterm cause
checked firewall system logs and could not see cause from that either
times are GMT

Colin

On 20 Nov 2012, at 17:05, Jeremy Chadwick  wrote:

> Colin,
> 
> Signal 15 = SIGTERM, so something intentionally shut ntpd down on your
> side.  The logs I'd be interested in would be prior to what you've
> provided, i.e. what lead to the SIGTERM.
> 
> Also, no timezone is mentioned anywhere in your timestamps, so please
> provide that (UTC offset would be best).
> 
> -- 
> | Jeremy Chadwick   j...@koitsu.org |
> | UNIX Systems Administratorhttp://jdc.koitsu.org/ |
> | Mountain View, CA, US|
> | Making life hard for others since 1977. PGP 4BD6C0CB |
> 
> On Tue, Nov 20, 2012 at 05:02:06PM +, Colin Johnston wrote:
>> 
>> On 20 Nov 2012, at 15:38, Jeremy Chadwick  wrote:
>> 
>>> I'm still waiting for someone who was affected by this to provide
>>> coherent logs from ntpd showing exactly when the time change happened.
>>> Getting these, at least on an *IX system, is far from difficult folks.
>>> 
>> 
>> from firewall ntp logs
>> Nov 19 09:58:06 [192.168.0.1.128.176] 2012:11:19-09:58:06 ntpd[21385]: ntpd 
>> exiting on signal 15
>> Nov 19 09:58:19 [192.168.0.1.128.176] 2012:11:19-09:58:19 selfmonng[3503]: W 
>> check Failed increment ntpd_running counter 3 - 3
>> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W 
>> NOTIFYEVENT Name=ntpd_running Level=INFO Id=147 sent
>> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W 
>> triggerAction: 'cmd'
>> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W 
>> actionCmd(+):  '/var/mdw/scripts/ntp restart'
>> Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 ntpd[24120]: ntpd 
>> 4.2.4p8@1.1612-o Tue Feb  2 21:46:54 UTC 2010 (1)
>> Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 selfmonng[3503]: W 
>> child returned status: exit='0' signal='0'
>> Nov 19 09:58:35 [192.168.0.1.128.176] 2012:11:19-09:58:35 ntpd[24121]: 
>> kernel time sync status change 0001
>> 
>> was sync'd to 84.25.175.98, stratum 2 at the time I believe
>> 
>> Colin

Re: optical gear cooling requirements

[Colin Johnston]

energis pop the cab doors would not open due to heat warping after loaded with 
two tnt max

colin

Sent from my iPhone

> On 4 Mar 2015, at 21:04, "Ricky Beam"  wrote:
> 
>> On Tue, 03 Mar 2015 20:52:44 -0500, Martin Hannigan  
>> wrote:
>> Remember the Ascend MAX TNT and the sideways left-right airflow?
> ...
> 
> Indeed I do. I see you've heard the story of PSINet melting components as 
> well.
> 
> We used USR(3Com) TotalControl hardware: vertical venting. The chimney effect 
> was impressive. (65F in, 100+ -- sometimes 120 -- out.)
> 
> (I've complained for over a decade about $DAYJOB building crap with 
> side-to-side venting.)
> 
> --Ricky

Re: Getting hit hard by CHINANET

[Colin Johnston]

use block firewall country flags, use strict packet compliance checking, dont 
bother with abuse email comms as is ignored, mentioned to trade missions but 
ignored

colin

Sent from my iPhone

> On 17 Mar 2015, at 02:06, Terrance Devor  wrote:
> 
> Hello Everyone,
> 
> I really hope this is not against group policy etc.. however our network is
> being hit
> hard by a China IP for the past 6 months. Our systems our up to date,
> passwordless
> ssh etc.. but they're DOS attempts are getting more and more aggressive.
> Tried to
> contact their phone number to no success (not valid). Emails don't get any
> response.
> The IP is 218.77.79.43. Do we have any options?
> 
> Terrance

Re: Getting hit hard by CHINANET

[Colin Johnston]

would be interested to know of providers using bgp to auto block ranges from 
china

colin

Sent from my iPhone

> On 18 Mar 2015, at 09:49, "Roland Dobbins"  wrote:
> 
> 
>> On 18 Mar 2015, at 13:32, Mark Tinka wrote:
>> 
>> That's one of two issues - if the sources are overwhelming how does one 
>> scale that up without the use of some scrubbing service? Writing data plane 
>> filters that are customer-specific works (assuming you have the hardware for 
>> it), but can get unwieldy.
> 
> Some operators have specialized DDoS mitigation capabilities.  Others rely 
> exclusively on basic network infrastructure-based mechanisms like D/RTBH, 
> S/RTBH, and/or flowspec.
> 
>> The other issues are the chance to boo-boo things when filtering a 
>> customer-facing port, and/or forgetting to remove filters after they are 
>> needed and customer (or the remote end) ends up having reachability issues.
> 
> Sure.  But this doesn't obviate the fact that cooperative DDoS mitigation 
> amongst network operators routinely takes place on the Internet today, and is 
> increasingly made available in one form or another to end-customers who 
> request same.
> 
> ---
> Roland Dobbins 

Re: Getting hit hard by CHINANET

[Colin Johnston]

why not try if chinanet folks refuse to respond to abuse,apac details

colin

Sent from my iPhone

> On 18 Mar 2015, at 10:00, "Roland Dobbins"  wrote:
> 
> 
>> On 18 Mar 2015, at 16:55, Colin Johnston wrote:
>> 
>> would be interested to know of providers using bgp to auto block ranges from 
>> china
> 
> This is not an optimal approach, and most providers are unlikely to engage in 
> such behavior due to its potential negative impact (I'm assuming you mean via 
> S/RTBH and/or flowspec).
> 
> ---
> Roland Dobbins 

Re: Getting hit hard by CHINANET

[Colin Johnston]

interesting use of ripe atlas info :)
was thinking same myself

colin

Sent from my iPhone

> On 18 Mar 2015, at 10:04, "Roland Dobbins"  wrote:
> 
> 
>> On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
>> 
>> This is not an optimal approach, and most providers are unlikely to engage 
>> in such behavior due to its potential negative impact (I'm assuming you mean 
>> via S/RTBH and/or flowspec).
> 
> Here's one counterexample:
> 
> 
> 
> ---
> Roland Dobbins 

Re: Getting hit hard by CHINANET

[Colin Johnston]

China network blocks work great, I wish did not have to use but they never 
respond to admin or abuse contacts either

Colin


> On 23 Mar 2015, at 13:06, Ray Soucy  wrote:
> 
> I did a test on my personal server of filtering every IP network assigned
> to China for a few months and over 90% of SSH attempts and other noise just
> went away.  It was pretty remarkable.
> 
> Working for a public university I can't block China outright, but there are
> times it has been tempting. :-)
> 
> The majority of DDOS attacks I see are sourced from addresses in the US,
> though (likely spoofed).  Just saw a pretty large one last week which was
> SSDP 1900 to UDP port 80, 50K+ unique host addresses involved.
> 
> 
> On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers 
> wrote:
> 
>> We are using Mikrotik for a BGP blackhole server that collects BOGONs
>> from CYMRU and we also have our servers (web, email, etc.) use fail2ban
>> to add a bad IP to the Mikrotik.  We then use BGP on all our core
>> routers to null route those IPs.
>> 
>> The ban-time is for a few days, and totally dynamic, so it isn't a
>> permanent ban.  Seems to have cut down on the attempts considerably.
>> 
>> Eric Rogers
>> PDSConnect
>> www.pdsconnect.me
>> (317) 831-3000 x200
>> 
>> 
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
>> Sent: Wednesday, March 18, 2015 6:04 AM
>> To: nanog@nanog.org
>> Subject: Re: Getting hit hard by CHINANET
>> 
>> 
>> On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
>> 
>>> This is not an optimal approach, and most providers are unlikely to
>>> engage in such behavior due to its potential negative impact (I'm
>>> assuming you mean via S/RTBH and/or flowspec).
>> 
>> Here's one counterexample:
>> 
>> > Control.pdf>
>> 
>> ---
>> Roland Dobbins 
>> 
> 
> 
> 
> -- 
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network
> www.maineren.net

Re: Usage data from Turkey

[Colin Johnston]

use ripe atlas info :)

Colin

> On 31 Mar 2015, at 18:19, Mehmet Akcin  wrote:
> 
> Hello
> 
> Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power 
> outage impacting nearly 70M people. I am writing a blog post about power 
> outage vs impact to network usage. I am looking for as much as useful network 
> usage information possible related to Turkey.
> 
> If you can share network usage information, i will be making sure to buy you 
> some drinks at next nanog ;)
> 
> Cheers
> 
> Mehmet

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

or ignore/block russia and north korea and china network blocks
takes away 5% of network ranges for memory headroom, especially the large 
number of smaller china blocks.
Some may say this is harsh but is the network contacts refuse to co-operate 
with abuse and 100% of the traffic is bad then why not

Colin


> On 2 Apr 2015, at 07:59, Mark Tinka  wrote:
> 
> 
> 
> On 1/Apr/15 19:01, Frederik Kriewitz wrote:
>> 
>> We're wondering if anyone has experience with such a setup?
> 
> Cisco have a feature called BGP-SD (BGP Selective Download).
> 
> With BGP-SD, you can hold millions of entries in RAM, but decide what
> gets downloaded into the FIB. By doing this, you can still export a full
> BGP table to customers directly connected to your 6500, and only have a
> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding
> to a bigger box.
> 
> BGP-SD started shipping in IOS XE, but I now understand that the feature
> is on anything running IOS 15.
> 
> This would be my recommendation.
> 
> Mark.

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

customers are paying for good traffic to generate eye balls and revenue, not 
bad traffic which clouds the good work done.
I know we are getting into filtering traffic wars here but if the source admins 
refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then 
why not put up walls.

I would like country trade talks to get down to the technical point that there 
are some fundamental problems being seen with bad traffic usage and it is 
significant percentage of waste bandwidth.

Colin
 
> On 2 Apr 2015, at 08:42, Mark Tinka  wrote:
> 
> 
> 
> On 2/Apr/15 09:35, Colin Johnston wrote:
>> or ignore/block russia and north korea and china network blocks
>> takes away 5% of network ranges for memory headroom, especially the large 
>> number of smaller china blocks.
>> Some may say this is harsh but is the network contacts refuse to co-operate 
>> with abuse and 100% of the traffic is bad then why not
> 
> I think that's a little extreme, especially since customers are paying
> me to deliver packets to the whole Internet.
> 
> But that's just me...
> 
> Mark.

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

> On 2 Apr 2015, at 08:40, Paul S.  wrote:
> 
> Do you have data on '100% of the traffic' being bad?
> 

as a example anything in 163data.com.cn is bad

Colin

> I happen to have a large Chinese clientbase, and this is not the case on my 
> network.
> 
> On 4/2/2015 午後 04:35, Colin Johnston wrote:
>> or ignore/block russia and north korea and china network blocks
>> takes away 5% of network ranges for memory headroom, especially the large 
>> number of smaller china blocks.
>> Some may say this is harsh but is the network contacts refuse to co-operate 
>> with abuse and 100% of the traffic is bad then why not
>> 
>> Colin
>> 
>> 
>>> On 2 Apr 2015, at 07:59, Mark Tinka  wrote:
>>> 
>>> 
>>> 
>>> On 1/Apr/15 19:01, Frederik Kriewitz wrote:
>>>> We're wondering if anyone has experience with such a setup?
>>> Cisco have a feature called BGP-SD (BGP Selective Download).
>>> 
>>> With BGP-SD, you can hold millions of entries in RAM, but decide what
>>> gets downloaded into the FIB. By doing this, you can still export a full
>>> BGP table to customers directly connected to your 6500, and only have a
>>> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding
>>> to a bigger box.
>>> 
>>> BGP-SD started shipping in IOS XE, but I now understand that the feature
>>> is on anything running IOS 15.
>>> 
>>> This would be my recommendation.
>>> 
>>> Mark.
> 

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

> On 2 Apr 2015, at 08:57, Mark Tinka  wrote:
> 
> 
> 
> On 2/Apr/15 09:52, Stefan Neufeind wrote:
>> Of course it's not something you should generalise about all people or
>> all traffic from certain countries. But it's obvious that there are some
>> countries which seem to care almost not at all about abuse or maybe even
>> are sources for planned hack-attempts. And at least some large ISPs
>> there seem to do nothing for their reputation or the reputation of their
>> country.
> 
> So when your customer calls you to complain about not being able to
> reach a random destination in "certain countries", you would tell them
> that you made a conscious decision to block access to "certain
> countries" because of reasons the customer probably will never
> understand or appreciate?
> 
Open ranges as necessary and mention will will reblock if bad traffic seen.

It is called protect what you know is good and allow bad if documented and 
check if does not cause problems

Colin

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

You would be surprised at the good effect and bandwidth incoming/outgoing 
gained.
allow blocks on exception and document and check.

drastic action done due to unresponsive contacts and 100% bad traffic

Colin


> On 2 Apr 2015, at 09:06, Paul S.  wrote:
> 
> 163data is announced as Chinanet, a China Telecom brand.
> 
> Dropping 4134 (http://bgp.he.net/AS4134) globally will get my customers up at 
> my doors with pitchforks fairly fast, I dunno about yours
> 
> Simply too big to do anything that drastic against.
> 
> On 4/2/2015 午後 05:04, Colin Johnston wrote:
>>> On 2 Apr 2015, at 08:40, Paul S.  wrote:
>>> 
>>> Do you have data on '100% of the traffic' being bad?
>>> 
>> as a example anything in 163data.com.cn is bad
>> 
>> Colin
>> 
>>> I happen to have a large Chinese clientbase, and this is not the case on my 
>>> network.
>>> 
>>> On 4/2/2015 午後 04:35, Colin Johnston wrote:
>>>> or ignore/block russia and north korea and china network blocks
>>>> takes away 5% of network ranges for memory headroom, especially the large 
>>>> number of smaller china blocks.
>>>> Some may say this is harsh but is the network contacts refuse to 
>>>> co-operate with abuse and 100% of the traffic is bad then why not
>>>> 
>>>> Colin
>>>> 
>>>> 
>>>>> On 2 Apr 2015, at 07:59, Mark Tinka  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 1/Apr/15 19:01, Frederik Kriewitz wrote:
>>>>>> We're wondering if anyone has experience with such a setup?
>>>>> Cisco have a feature called BGP-SD (BGP Selective Download).
>>>>> 
>>>>> With BGP-SD, you can hold millions of entries in RAM, but decide what
>>>>> gets downloaded into the FIB. By doing this, you can still export a full
>>>>> BGP table to customers directly connected to your 6500, and only have a
>>>>> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding
>>>>> to a bigger box.
>>>>> 
>>>>> BGP-SD started shipping in IOS XE, but I now understand that the feature
>>>>> is on anything running IOS 15.
>>>>> 
>>>>> This would be my recommendation.
>>>>> 
>>>>> Mark.
> 

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

> 
> Most of the spam I get comes from North America. Go figure. I'm not
> about to cut access to that continent off.
> 
> I'd have to consider all other options really exhausted about fixing
> this for myself before I have to go and fix it in the network in a way
> that impacts other customers who may be getting spam from non-North
> American sources, or who enjoy the North American spam…
> 
It is not spam we are talking about, it is bad invalid network packets, bad web 
traffic probing exploits, bad port traffic looking for open network ports.
All of this originates in countries not using best practice abuse process, no 
communication with route config errors, no communication when ddos seen.
In effect it is a war on bad traffic and country blocks will be in the only way 
to make people take notice of this problem.

Colin

Fwd: Holborn fire is still burning under the pavement - BBC News

[Colin Johnston]

Will take a lot of water to clear this up if gone into main tunnels :(

Colin



> 
>> http://www.bbc.co.uk/news/uk-england-london-32157618 
>> 
>> 
>> Holborn fire is still burning under the pavement
>> 
>> 
>> Local road closures are in place but Holborn Tube station is open
>> A road in central London remains closed as an electrical fire continues to 
>> burn under the pavement.
>> 
>> Some 5,000 people were evacuated from nearby buildings after smoke was seen 
>> coming out of an inspection cover on Kingsway, in Holborn, on Wednesday.
>> 
>> London Fire Brigade (LFB) said the fire has been contained but has been 
>> "technically difficult" to tackle.
>> 
>> More than 20 firefighters and officers are still at the scene and local road 
>> closures are in place.
>> 
>> LFB Assistant Commissioner Peter Cowup said: "This has been a technically 
>> difficult incident to tackle.
>> 
>> "The reason that the fire is still burning is because the service tunnel is 
>> hard to reach.
>> 
>> "Although firefighters have been applying water through access points 
>> throughout the night, the complexity of the tunnel layout means that it will 
>> be some time until the fire is fully extinguished."
>> 
>> He added LFB, the Met Police and utility companies were making steady 
>> progress to try and resolve the situation.
>> 
>> 'Not an overnight job'
>> 
>> Speaking to BBC London 94.9 , 
>> Insp Neil Johnson, from the Met Police, said: "The fire is still live in the 
>> subway. The problem at the moment is there is a gas pipe underneath and we 
>> are all in agreement that it is ok and if we can keep it contained it will 
>> be fine.
>> 
>> "All we need to do is keep people out of the area and let the fire brigade 
>> and utilities do their job."
>> 
>> 
>> The view from the London Eye on Thursday night highlighted the area affected 
>> by the power cut
>> 
>> Firefighters were called to the fire at about 12:30 BST on Wednesday
>> "I imagine this road will be closed a long time after this is finished 
>> because of damage the heat does to the road," Mr Johnson said.
>> 
>> "It will have to remain closed until a structural engineer examines it 
>> properly and either he or she says what work has to be done and that work is 
>> completed - this is not an overnight job."
>> 
>> On Thursday onlookers reported struggling to breathe and "chaos" in and 
>> around Holborn. The cause of the fire is still unknown.
>> 
>> UK Power Networks said the number of customers currently affected by the 
>> power cuts stood at about 1,000 and they had restored power to 2,000.
>> 
>> Apologising to customers Matt Rudling, from UK Power Networks, said: "The 
>> gas is still burning under there and until we can gain access to that 
>> particular area we won't understand what's caused it and what we can do."
>> 
>> 
>> Smoke was seen coming out of an inspection cover on Kingsway on Wednesday
>> 
>> "We want to try and restore [power to] all those remaining customers by the 
>> end of day today."
>> 
>> He apologised for the disruption and added that emergency generators were 
>> being used to supply power to the area.
>> 
>> UK Power Networks' engineers are also trying and connect some of the damaged 
>> cables to unaffected ones.
>> 
>> Kingsway is closed between Holborn and Aldwych, the Strand Underpass, 
>> Waterloo Bridge northbound and Southampton Row southbound between Vernon 
>> Place and High Holborn, which is causing delays.
>> 
>> Holborn station is open, however nine bus routes are being diverted 
>> .
>> 

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

yes, china ignores everything said beit by phone,email,chat

at least if you call a us provider you can at least communicate

its not a english language issue either

chinatelcom,chinanet contact info might as well not be documented

colin

Sent from my iPhone

> On 2 Apr 2015, at 19:05, goe...@anime.net wrote:
> 
>> On Thu, 2 Apr 2015, Mark Tinka wrote:
>> Most of the spam I get comes from North America. Go figure. I'm not
>> about to cut access to that continent off.
> 
> Big difference is that north america is usually responsive to abuse 
> notifications and sometimes has LEO who will listen.
> 
> china is neither.
> 
> -Dan

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

it is not censorship to check traffic follows correct standards and does not 
deliberately constantly try to exploit.
it could easily be solved if china abuse departments co-operate and acknowledge 
reports and fix
if not then country bans are in place and will remain in place until culture 
change is done

colin
Sent from my iPhone

> On 2 Apr 2015, at 19:01, Bryan Tong  wrote:
> 
> As a network consumer and network provider. The traffic seen by the
> customer should not be censored. It should be up to the consumer to protect
> their services.
> 
> I accept the risk and want uncensored internet access and provide such to
> our customers.
>> On Apr 2, 2015 11:26 AM, "Max Tulyev"  wrote:
>> 
>> Hello!
>> 
>> Very good idea is to sell that and change it to softrouter based on
>> PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than
>> $1k.
>> 
>>> On 04/01/15 20:01, Frederik Kriewitz wrote:
>>> We're wondering if anyone has experience with such a setup?
>> 
>> 

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

yes have tried chinese language communication as well.
none of it works, they dont believe bad traffic is a big issue where it has 
been proved 100% is bad
we do belive this is due to bad abuse practice not informing customers and also 
deliberately sending bad traffic to test exploits on a large scale.

ssl bad cert signing in china is just a example of this culture

shutting the door if it is shown unfriendly traffic makes sense to me

colin


Sent from my iPhone

> On 2 Apr 2015, at 20:50, Barry Shein  wrote:
> 
> 
> The essence of this discussion is IMHO a little...um...trite.
> 
> Be that as it may how many of you have attempted to contact these
> providers in Chinese?
> 
> Or do you all have good reason to believe that is never the problem?
> 
> 
>> On April 2, 2015 at 11:05 goe...@anime.net (goe...@anime.net) wrote:
>>> On Thu, 2 Apr 2015, Mark Tinka wrote:
>>> Most of the spam I get comes from North America. Go figure. I'm not
>>> about to cut access to that continent off.
>> 
>> Big difference is that north america is usually responsive to abuse 
>> notifications and sometimes has LEO who will listen.
>> 
>> china is neither.
>> 
>> -Dan
> 
> -- 
>-Barry Shein
> 
> The World  | b...@theworld.com   | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

customers are paying for good traffic to generate eye balls and revenue, not 
bad traffic which clouds the good work done.
I know we are getting into filtering traffic wars here but if the source admins 
refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then 
why not put up walls.

I would like country trade talks to get down to the technical point that there 
are some fundamental problems being seen with bad traffic usage and it is 
significant percentage of waste bandwidth.

Colin
 
> On 2 Apr 2015, at 08:42, Mark Tinka  wrote:
> 
> 
> 
>> On 2/Apr/15 09:35, Colin Johnston wrote:
>> or ignore/block russia and north korea and china network blocks
>> takes away 5% of network ranges for memory headroom, especially the large 
>> number of smaller china blocks.
>> Some may say this is harsh but is the network contacts refuse to co-operate 
>> with abuse and 100% of the traffic is bad then why not
> 
> I think that's a little extreme, especially since customers are paying
> me to deliver packets to the whole Internet.
> 
> But that's just me...
> 
> Mark.

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

portscanning on mass scale where unable to get knowledgable network/sysadmins 
to fix gets to the point of every part of large network ranges are affected. 
then country blocks make sense to protect countries from armies of exploited 
machines and protect valuable costly network resource

colin

Sent from my iPhone

> On 3 Apr 2015, at 19:22, Bacon Zombie  wrote:
> 
> Is port scanning illegal in China?
> 
> If not the there is no reason for then to do anything about it.
>> On 3 Apr 2015 19:00, "Barry Shein"  wrote:
>> 
>> 
>>> On April 2, 2015 at 14:19 goe...@anime.net (goe...@anime.net) wrote:
>>> a number of years back i did have someone contact in chinese and the
>>> response was that the customer was doing nothing wrong.
>> 
>> Ok, that's progress of a sort, what's the authoritative source of
>> right and wrong, something beyond "c'mon it's obvious!"?
>> 
>> --
>>   -Barry Shein
>> 
>> The World  | b...@theworld.com   |
>> http://www.TheWorld.com
>> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
>> Canada
>> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
>> 

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Colin Johnston]

china says not a problem since they have head in sand and ignore cooperation
phone contact with chinse folks does not help either

colin

Sent from my iPhone

> On 3 Apr 2015, at 19:51, Barry Shein  wrote:
> 
> 
>> On April 3, 2015 at 20:22 baconzom...@gmail.com (Bacon Zombie) wrote:
>> Is port scanning illegal in China?
>> 
>> If not the there is no reason for then to do anything about it.
> 
> I don't think that's a minimal standard one has to use, illegal or
> not.
> 
> Management of the internet infrastructure is primarily a cooperative,
> voluntary (in terms of cooperation and communication and agreement to
> BCPs and standards), and good-faith effort, not just bounded by what
> is or isn't illegal.
> 
> As I said before these are companies most probably with many millions
> of dollars on the table, not miscreants out to cause problems.
> 
> I suspect if one got them to the table the answers would be a bit more
> nuanced than "it's not illegal!" even if someone burdened with manning
> a support desk may have said something like that.
> 
> All we really know at this point is that flinging emails at their
> admins hasn't been as effective as one might like. That's not entirely
> surprising.
> 
> -- 
>-Barry Shein
> 
> The World  | b...@theworld.com   | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Fwd: Google Apps Status Alert

[Colin Johnston]

Sent from my iPhone

Begin forwarded message:

> From: Google Apps 
> Date: 4 April 2015 20:05:33 BST
> To: col...@mx5.org.uk
> Subject: Google Apps Status Alert
> 
> 
> 
> Status: Service disruption
> We expect to resolve the problem affecting a majority of users of Gmail at 
> April 4, 2015 1:00:00 PM PDT. Please note that this time frame is an estimate 
> and may change.
> smtp.gmail.com is displaying an invalid certificate.
> April 4, 2015 11:58:00 AM PDT
> 
> You are receiving this email as you have been subscribed to this alert. 
> Unsubscribe | Learn more 
> 
> © 2013 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043 

Re: Fixing Google geolocation screwups

[Colin Johnston]

Globalisation only works if network abuse and network contacts follow best 
practice and engage.
Else trade blocks and network country blocks are done and remain in place until 
certain countries ethically/practically do the right thing.

Colin

> On 8 Apr 2015, at 13:17, Tim Franklin  wrote:
> 
>> That all said: Restricting content based on location is complete and
>> utter nonsense in 2015. The world is global, people want to pay for
>> content and the content owners just don't allow people to pay for it.
> 
> Globalisation is for your corporate lords and masters to buy labour and raw 
> materials where they're cheap.
> 
> If mere peons try to buy goods and services in the same way, expect to be 
> crushed by the best legislation money can buy :(
> 
> Regards,
> Tim.

macomnet weird dns record

[Colin Johnston]

never saw hex in host dns records before.
host-242.strgz.87.118.199.240.0xfff0.macomnet.net

range is blocked non the less since bad traffic from Russia network ranges.

Colin

Re: macomnet weird dns record

[Colin Johnston]

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

Colin

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

Re: macomnet weird dns record

[Colin Johnston]

Get real, why make is hard for others to debug abuse issues, another reason why 
blocks in place as no technical cooperation.

Colin

> On 14 Apr 2015, at 14:48, Nikolay Shopik  wrote:
> 
> Then best practice, that naming should be helpful for owners of network
> in first place and only afterwards everyone else.
> 
> On 14/04/15 16:26, Colin Johnston wrote:
>> Because looks strange especially if the traffic is 100% bad 
>> Best practice says avoid such info in records as does not aid debug since 
>> mix of dec and hex 
>> 
>> Colin
>> 
>>> On 14 Apr 2015, at 14:09, Nikolay Shopik  wrote:
>>> 
>>> How its weird? All these chars allowed in DNS records.
>>> 
>>> On 14/04/15 15:36, Colin Johnston wrote:
>>>> never saw hex in host dns records before.
>>>> host-242.strgz.87.118.199.240.0xfff0.macomnet.net
>>>> 
>>>> range is blocked non the less since bad traffic from Russia network ranges.
>>>> 
>>>> Colin
>>>> 
>> 

Re: macomnet weird dns record

[Colin Johnston]

Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry.
At least there is communication on some level, Chinese colleagues would not 
even bother to respond to aid debug.

Be that as it may, why not use either normal decimal numbers or normal 
characters to show what a normal person would understand instead of having to 
convert the shown output ?

Colin


> On 14 Apr 2015, at 14:54, Nikolay Shopik  wrote:
> 
> Are Roman numerals allowed in DNS? Because I know some people also do them.
> 
> dig -x 217.199.208.190
> 
> 
> On 14/04/15 16:45, Chuck Church wrote:
>> Comic Book Guy would probably declare:
>> 
>> "Worst Naming Convention Ever"
>> 
>> Chuck
>> 
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colin Johnston
>> Sent: Tuesday, April 14, 2015 9:27 AM
>> To: Nikolay Shopik
>> Cc: 
>> Subject: Re: macomnet weird dns record
>> 
>> Because looks strange especially if the traffic is 100% bad Best practice
>> says avoid such info in records as does not aid debug since mix of dec and
>> hex 
>> 
>> Colin
>> 
>>> On 14 Apr 2015, at 14:09, Nikolay Shopik  wrote:
>>> 
>>> How its weird? All these chars allowed in DNS records.
>>> 
>>> On 14/04/15 15:36, Colin Johnston wrote:
>>>> never saw hex in host dns records before.
>>>> host-242.strgz.87.118.199.240.0xfff0.macomnet.net
>>>> 
>>>> range is blocked non the less since bad traffic from Russia network
>> ranges.
>>>> 
>>>> Colin
>>>> 
>> 

Re: macomnet weird dns record

[Colin Johnston]

so fix the spam hosts, don’t mask the problem and make more complicated for 
folks trying their best to solve

Colin

> On 14 Apr 2015, at 15:09, Pavel Odintsov  wrote:
> 
> Hello, Colin!
> 
> We use hexademical numbers in PTR for VPS/Servers because PTR's like
> "host-87.118.199.240.domain.ru" so often banned by weird antispam
> systems  by mask \d+\.\d+\.\d+\d+ as home ISP subnets which produce
> bunch of spam.
> 
> 
> 
> On Tue, Apr 14, 2015 at 5:00 PM, Colin Johnston  wrote:
>> Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry.
>> At least there is communication on some level, Chinese colleagues would not 
>> even bother to respond to aid debug.
>> 
>> Be that as it may, why not use either normal decimal numbers or normal 
>> characters to show what a normal person would understand instead of having 
>> to convert the shown output ?
>> 
>> Colin
>> 
>> 
>>> On 14 Apr 2015, at 14:54, Nikolay Shopik  wrote:
>>> 
>>> Are Roman numerals allowed in DNS? Because I know some people also do them.
>>> 
>>> dig -x 217.199.208.190
>>> 
>>> 
>>> On 14/04/15 16:45, Chuck Church wrote:
>>>> Comic Book Guy would probably declare:
>>>> 
>>>> "Worst Naming Convention Ever"
>>>> 
>>>> Chuck
>>>> 
>>>> -Original Message-
>>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colin Johnston
>>>> Sent: Tuesday, April 14, 2015 9:27 AM
>>>> To: Nikolay Shopik
>>>> Cc: 
>>>> Subject: Re: macomnet weird dns record
>>>> 
>>>> Because looks strange especially if the traffic is 100% bad Best practice
>>>> says avoid such info in records as does not aid debug since mix of dec and
>>>> hex
>>>> 
>>>> Colin
>>>> 
>>>>> On 14 Apr 2015, at 14:09, Nikolay Shopik  wrote:
>>>>> 
>>>>> How its weird? All these chars allowed in DNS records.
>>>>> 
>>>>> On 14/04/15 15:36, Colin Johnston wrote:
>>>>>> never saw hex in host dns records before.
>>>>>> host-242.strgz.87.118.199.240.0xfff0.macomnet.net
>>>>>> 
>>>>>> range is blocked non the less since bad traffic from Russia network
>>>> ranges.
>>>>>> 
>>>>>> Colin
>>>>>> 
>>>> 
>> 
> 
> 
> 
> -- 
> Sincerely yours, Pavel Odintsov

Re: macomnet weird dns record

[Colin Johnston]

costs more money in long term not fixing the bad traffic as have to spend more 
for transit

doing the bother and fixing the problem is best practice

Colin




> Chinese don't bother for multiply reasons, same probably apply to
> Russian part net, cheap Internet access. So when you asking them to fix
> bad traffic coming from home user they don't bother do anything with it
> as it cost money for them.
> 
> On 14/04/15 17:00, Colin Johnston wrote:
>> Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry.
>> At least there is communication on some level, Chinese colleagues would not 
>> even bother to respond to aid debug.
>> 
>> Be that as it may, why not use either normal decimal numbers or normal 
>> characters to show what a normal person would understand instead of having 
>> to convert the shown output ?
>> 
>> Colin
>> 
>> 
>>> On 14 Apr 2015, at 14:54, Nikolay Shopik  wrote:
>>> 
>>> Are Roman numerals allowed in DNS? Because I know some people also do them.
>>> 
>>> dig -x 217.199.208.190
>>> 
>>> 
>>> On 14/04/15 16:45, Chuck Church wrote:
>>>> Comic Book Guy would probably declare:
>>>> 
>>>> "Worst Naming Convention Ever"
>>>> 
>>>> Chuck
>>>> 
>>>> -Original Message-
>>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colin Johnston
>>>> Sent: Tuesday, April 14, 2015 9:27 AM
>>>> To: Nikolay Shopik
>>>> Cc: 
>>>> Subject: Re: macomnet weird dns record
>>>> 
>>>> Because looks strange especially if the traffic is 100% bad Best practice
>>>> says avoid such info in records as does not aid debug since mix of dec and
>>>> hex 
>>>> 
>>>> Colin
>>>> 
>>>>> On 14 Apr 2015, at 14:09, Nikolay Shopik  wrote:
>>>>> 
>>>>> How its weird? All these chars allowed in DNS records.
>>>>> 
>>>>> On 14/04/15 15:36, Colin Johnston wrote:
>>>>>> never saw hex in host dns records before.
>>>>>> host-242.strgz.87.118.199.240.0xfff0.macomnet.net
>>>>>> 
>>>>>> range is blocked non the less since bad traffic from Russia network
>>>> ranges.
>>>>>> 
>>>>>> Colin
>>>>>> 
>>>> 
>> 

Re: macomnet weird dns record

[Colin Johnston]

There becomes a point though that doing nothing allows larger problems which 
could have been nipped in the bud if sorted when issue was a smaller magnitude.
Profit when there is known bad traffic as a percentage and you known ignore it 
is bad profit and does not help the greater good.

most folks would welcome help if they know network would be more reliable and 
faster without the bad traffic always being present.

Colin

> On 14 Apr 2015, at 15:47, Nikolay Shopik  wrote:
> 
> Transit traffic isn't issue, as upload/download ratio usually 1:2 or more.
> 
> As I said before when you already on edge of your profits, you don't
> bother fixing these clients. Its not about best practice which I agree,
> but business you are running, which is suppose to be profitable. And
> fixing these bad machines doesn't give you any profits.
> 
> On 14/04/15 17:37, Colin Johnston wrote:
>> costs more money in long term not fixing the bad traffic as have to spend 
>> more for transit
>> 
>> doing the bother and fixing the problem is best practice
>> 
>> Colin

Re: dns on fios/frontier

[Colin Johnston]

works fine from uk folks

Col

> On 20 Apr 2015, at 07:51, Randy Bush  wrote:
> 
> anyone on fios/frontier can please run a quickie and see if you can get
> to http://psg.com/?  have a net friend who can not from multiple hosts
> on their home lan and he has rebooted router.  called support and they
> showed their sunday best "the web site is down."  sigh.
> 
> randy

Re: common checks performed when passing on an IPv4 PA allocation from one end-customer to another

[Colin Johnston]

> On 28 Apr 2015, at 10:32, Martin T  wrote:
> 
> Hi,
> 
> as far as I know, some large US Internet companies like Google,
> Facebook or Amazon restrict access to some services for certain
> regions like Crimea or countries like Iran or North Korea. Do they
> rely on services like MaxMind? Or do they use some other method to
> check the geographical location of IP address? If yes, then is there
> an API to check if an address is allowed to use Google, Facebook, etc
> services or not?
> 

you could use ripe atlas selecting nodes in countries you require and 
destination facbook/google/amazon servers and check results

Colin

Re: Low Cost 10G Router

[Colin Johnston]

If you want virtual 10gb ports go vmware with a cisco routing vm or juniper 
routing vm

Colin

> On 19 May 2015, at 18:40, Steve Noble  wrote:
> 
> You could potentially do it with a Vyatta 5600 or a 6Wind Turbo router
> running on a generic server, but I am not sure where the cost crossover
> is with physical hardware especially if you go with used hardware.
> 
>> Colton Conor 
>> May 19, 2015 at 10:22 AM
>> What options are available for a small, low cost router that has at least
>> four 10G ports, and can handle full BGP routes? All that I know of are the
>> Juniper MX80, and the Brocade CER line. What does Cisco and others have
>> that compete with these two? Any other vendors besides Juniper, Brocade,
>> and Cisco to look at?

Re: Low Cost 10G Router

[Colin Johnston]

How much of that traffic is valid legit traffic as well :(

Colin

> On 19 May 2015, at 19:32, Oleg A. Arkhangelsky  wrote:
> 
> 
> 
> 19.05.2015, 21:26, "Max Tulyev" :
>> Last config I touched: 2xIntel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 12
>> Gbit summary, <5% each core load.
> 
> And what PPS rate (in+out)?
> 
> --
> wbr, Oleg.
> 
> "Anarchy is about taking complete responsibility for yourself."
>   Alan Moore.

Re: leap second outage

[Colin Johnston]

oracle linux did this
Jul  1 02:01:29 oraclelinux ntpd[600]: 0.0.0.0 061c 0c clock_step -1.006445 s
Jul  1 02:01:29 oraclelinux ntpd[600]: 0.0.0.0 0615 05 clock_sync
Jul  1 02:01:29 oraclelinux systemd: Time has been changed
Jul  1 02:01:30 oraclelinux ntpd[600]: 0.0.0.0 c618 08 no_sys_peer
all seemed fine after this

sophus utm did this
2015:07:01-00:59:59 cloudsophosvm kernel: [653957.707421] Clock: inserting leap 
second 23:59:60 UTC
all seemed fine after this


Colin

Re: Possible Sudden Uptick in ASA DOS?

[Colin Johnston]

Hi Jared,
thanks for update

do you know provider/source ip of the source of the attack ?

Colin

> On 9 Jul 2015, at 12:27, Jared Mauch  wrote:
> 
> Really just people not patching their software after warnings more than six 
> months ago:
> 
> July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers 
> with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of 
> Service Vulnerability that was disclosed in this Security Advisory. Traffic 
> causing the disruption was isolated to a specific source IPv4 address. Cisco 
> has engaged the provider and owner of that device and determined that the 
> traffic was sent with no malicious intent. Cisco strongly recommends that 
> customers upgrade to a fixed Cisco ASA software release to remediate this 
> issue. 
> 
> Cisco has released free software updates that address these vulnerabilities. 
> Workarounds that mitigate some of these vulnerabilities are available.
> 
> Jared Mauch
> 
>> On Jul 8, 2015, at 1:15 PM, Michel Luczak  wrote:
>> 
>> 
>>> On 08 Jul 2015, at 18:58, Mark Mayfield  
>>> wrote:
>>> 
>>> Come in this morning to find one failover pair of ASA's had the primary 
>>> crash and failover, then a couple hours later, the secondary crash and 
>>> failover, back to the primary.
>> 
>> Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as 
>> well, seems related to a late leap second related issue.
>> 
>> Regards, Michel

Re: Possible Sudden Uptick in ASA DOS?

[Colin Johnston]

you would think a researcher would stop once he realised effect being caused ?

Colin

> On 9 Jul 2015, at 14:08, Jared Mauch  wrote:
> 
> My guess is a researcher. 
> 
> We saw the same issue in the past with a Cisco microcode bug and people doing 
> ping record route. When it went across a LC with a very specific set of 
> software it would crash. 
> 
> If you crashed just upgrade your code, don't hide behind blocking an IP as 
> people now know what to send/do. It won't be long. 
> 
> Jared Mauch
> 
>> On Jul 9, 2015, at 7:44 AM, Colin Johnston  wrote:
>> 
>> Hi Jared,
>> thanks for update
>> 
>> do you know provider/source ip of the source of the attack ?
>> 
>> Colin
>> 
>>> On 9 Jul 2015, at 12:27, Jared Mauch  wrote:
>>> 
>>> Really just people not patching their software after warnings more than six 
>>> months ago:
>>> 
>>> July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers 
>>> with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial 
>>> of Service Vulnerability that was disclosed in this Security Advisory. 
>>> Traffic causing the disruption was isolated to a specific source IPv4 
>>> address. Cisco has engaged the provider and owner of that device and 
>>> determined that the traffic was sent with no malicious intent. Cisco 
>>> strongly recommends that customers upgrade to a fixed Cisco ASA software 
>>> release to remediate this issue. 
>>> 
>>> Cisco has released free software updates that address these 
>>> vulnerabilities. Workarounds that mitigate some of these vulnerabilities 
>>> are available.
>>> 
>>> Jared Mauch
>>> 
>>>> On Jul 8, 2015, at 1:15 PM, Michel Luczak  wrote:
>>>> 
>>>> 
>>>>> On 08 Jul 2015, at 18:58, Mark Mayfield 
>>>>>  wrote:
>>>>> 
>>>>> Come in this morning to find one failover pair of ASA's had the primary 
>>>>> crash and failover, then a couple hours later, the secondary crash and 
>>>>> failover, back to the primary.
>>>> 
>>>> Not sure it’s related but I’ve read reports on FRNoG of ASAs crashing as 
>>>> well, seems related to a late leap second related issue.
>>>> 
>>>> Regards, Michel

Fwd: Test-drive the OS X El Capitan public beta

[Colin Johnston]

lots of 6GB downloads this morning :)

Colin


> Begin forwarded message:
> 
> From: Apple Beta Software Program 
> Subject: Test-drive the OS X El Capitan public beta
> Date: 10 July 2015 05:08:06 BST
> To: col...@mx5.org.uk
> 
> 
> 
> The El Capitan public beta is now available from the Apple Beta Software 
> Program. 
> Test-drive it and let us know what you think.
> 
> 
> 

Re: Test-drive the OS X El Capitan public beta

[Colin Johnston]

as well hopefully less upgrade traffic once installed as update install images 
less big as well

colin

Sent from my iPhone

> On 10 Jul 2015, at 14:11, John Curran  wrote:
> 
>> On Jul 10, 2015, at 2:17 AM, Colin Johnston  wrote:
>> 
>> lots of 6GB downloads this morning :)
>> 
>> Colin
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Apple Beta Software Program 
>>> Subject: Test-drive the OS X El Capitan public beta
>>> Date: 10 July 2015 05:08:06 BST
>>> To: col...@mx5.org.uk
>>> 
>>> 
>>> 
>>> The El Capitan public beta is now available from the Apple Beta Software 
>>> Program. 
>>> Test-drive it and let us know what you think.
> 
> Also note that this particular release is also likely to further increase 
> IPv6 traffic loads 
> once out in the mainstream, as it includes some significant changes to 
> Apple’s “Happy 
> Eyeballs” implementation…   (see attached)   Current growth in IPv6 traffic 
> doesn’t 
> necessarily include significant iPhone participation, but this will change 
> shortly.
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> ===
> <https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html>
>> David Schinazi  Thu, 09 July 2015 22:00 UTC
>> Hi everyone,
>> Today Apple released the first public seeds of iOS 9 and OS X El Capitan.
>> These seeds (and the third developer seeds released yesterday) include an 
>> improved version of Happy Eyeballs.
>> 
>> Based on our testing, this makes our Happy Eyeballs implementation go from 
>> roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite
>> to ~99% IPv6 in iOS 9 and El Capitan betas.
>> ...
> 
> 

Re: NTP versions in production use?

[Colin Johnston]

ntpd - NTP daemon program - Ver. 4.2.6
Colins-iMac:~ colinj$ uname -a
Darwin Colins-iMac.home 15.0.0 Darwin Kernel Version 15.0.0: Sun Jun 28 
00:25:56 PDT 2015; root:xnu-3247.1.36~7/RELEASE_X86_64 x86_64
(10.11 osx el capitan)

-bash-4.2$ uname -a
Linux oraclelinux 3.8.13-68.1.2.el7uek.x86_64 #2 SMP Mon Mar 30 11:45:57 PDT 
2015 x86_64 x86_64 x86_64 GNU/Linux
ntpd - NTP daemon program - Ver. 4.2.6p5

2015:07:11-01:05:57 cloudsophosvm ntpd[17219]: ntpd 4.2.6p5@1.2349 Tue Feb  4 
13:03:59 UTC 2014 (1)
Sophos UTM 9.313-3


Colin

Re: ISP in NYC

[Colin Johnston]

good isp's / peers are in no particular order
bt
telstra ex psinet uk/eu

colin

Sent from my iPhone

> On 17 Jul 2015, at 07:52, Jared Geiger  wrote:
> 
> HE uses Telia for Transit. So you won't gain much redundancy there. I would
> go with Cogent if you have lots of European customers and North American
> business customers. One not on your list is Level3. They would be strong in
> that blend too.
> 
> You might also try joining a peering point. You'll gain a lot by just
> peering with the route servers.
> 
>> On Thu, Jul 16, 2015 at 6:34 AM, Dovid Bender  wrote:
>> 
>> Hi,
>> 
>> We are looking to peer with another ISP in NY. My options are:
>> Telia
>> Tata
>> Cogent
>> 
>> We currently have (and will keep):
>> HE
>> NTT
>> TELX (They use NTT and HE and we are looking to replace them).
>> 
>> We need an ISP that has a good peering/connectivity in Europe and Asia
>> (Israel specific).
>> 
>> Any advice on who to go with?
>> 

Re: AW: AW: Prefix-Hijack by AS7514

[Colin Johnston]

any idea why error happened ?
what config needs fixing to mitigate mistake?
it was easy to see problem via ripe atlas :)

colin

Sent from my iPhone

> On 17 Jul 2015, at 09:32, Matsuzaki Yoshinobu  wrote:
> 
> Date: Fri, 17 Jul 2015 15:38:13 +0900
> "Paul S."  wrote
>> I let IIJ know too, hopefully they'll filter it soon.
> 
> It seems AS7514 stopped the announcements around 06:54UTC.
> 
> I am not sure how BGPmon guesses AS relationships, but it needs
> improvements as it shows IIJ as an upstream of AS7514 wrongly.
> -
> Matsuzaki Yoshinobu 
> - IIJ/AS2497  INOC-DBA: 2497*629