Hi Guys, Sorry for the off-topic post. I would appreciate it if someone that has rack space in MDXi can please ping me off list. I just have a few (two or three) random questions that I would appreciate some general feedback on. Many thanks, -- Regards, Chris Knipe
Hi James, Just want to make this clear to NANOG as well - there's no beef here. The priority was to get delisted. The beef is with AfriNIC in this case :) It's not CYMRU's fault. The datasets are incomplete. -- C On Wed, Jan 29, 2020 at 4:03 PM James Shank wrote: > Hi all, > > I am still looking into the history of this issue, but presently, the > prefix Chris shared with us is not on our IPv4 BOGON list. > > For those wanting to see the list, it is available in plain text here: > > https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt > > I welcome input on this as I look into the history a little more. > > Cheers! > > James > > On 1/29/20 7:27 AM, Chris Knipe wrote: > > Hi All, > > > > http://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-20200129 > > > > Another thing that stuck it's head out today now. No ASN, nor IP > prefixes > > allocated since 2019/05/15 is listed in the delegated text files. Our > (and > > I am sure others) prefixes is now null routed at team CYMRU (contacted > > them, waiting for response). > > > > Yesterday's file was incomplete (looks like there were errors with the > > script perhaps), and today's file is missing an enormous amount of data > (1 > > ASN, 163 IPv4 allocations, and 272 IPv6 allocations). This is comparing > the > > data file from 2020/01/29 (today) to 2020/01/27 (two days ago). > > > > We also have a ticket with AfriNIC (no response yet), and when we called > > them there was no one "available" to assist. > > > > > > On Wed, Jan 29, 2020 at 1:20 AM Ronald F. Guilmette < > r...@tristatelogic.com> > > wrote: > > > >> In message , > >> thomas brenac wrote: > >> > >>> Thank you Ronald, I also heard of governance issue in AFRINIC by some > >>> people during the last RIPE meeting so the word is spreading. Now is > >>> there any other /16 impacted to your knowledge ? Would be worth pushing > >>> to have them in as many Drop list as possible maybe :) > >> > >> As reported in Jan Vermeulen's article on the web site > mybroadband.co.za > >> published December 4, there has been, and continues to be a large number > >> of blocks, both "legacy" blocks and other blocks, that were stolen from > >> the Afrinic free pool. These blocks are of varying sizes, generally /16 > >> blocks but also some larger ones as well as a few smaller ones. > >> > >> The list of affected legacy blocks from Jan's article are as follows: > >> > >> 22.214.171.124/19 > >> 126.96.36.199/24 > >> 188.8.131.52/23 > >> 184.108.40.206/16 > >> 220.127.116.11/16 > >> 18.104.22.168/16 > >> 22.214.171.124/16 > >> 126.96.36.199/16 > >> 188.8.131.52/16 > >> 184.108.40.206/16 > >> 220.127.116.11/15 > >> 18.104.22.168/16 > >> 22.214.171.124/16 > >> 126.96.36.199/16 > >> 188.8.131.52/16 > >> > >> In addition to all of the above, I have some reason to believe that the > >> following additional legacy block WAS (past tense) stolen, but has now > >> been reclaimed by, and ressigned to its rightful modern owner: > >> > >> 184.108.40.206/16 > >> > >> It is highly probable that there are other and additional legacy blocks > >> that have also been stolen. I have been prevented from fully completing > >> my research work on this part of the problem by ongoing stonewalling by > >> Afrinic. Specifically, despite Afrinic having a defined protocol > whereby > >> legitimate researchers may request confidential access to the unredacted > >> Afrinic WHOIS data base for legitimate research purposes... a protocol > >> and a process which is fully supported and operational at all of the > other > >> four global RIRs... Afrinic has, for reasons unknown, elected to only > >> provide redacted versions of its WHOIS data base which are identical > >> to what may be obtained at any time, and without any special protocol, > >> directly from Afrinic's FTP server (via anonymous FTP). Because the > >> accurate identification of stolen Afrinic legacy blocks involves the > >> careful analysis of the *unredacted* contact person: records, access to > >> only the redacted data base is of no value whatsoever in the task of > >> identifying stolen Afrinic legacy blocks. > >> > >> Here is the page on the Afrinic web site where they needlessly torment > >> legitimate researchers into believing that they will be able to get the >
Hope Bank"/"CGHB" blocks. Those > blocks are now officially unregistered. I am informed and believe that > it is Afrinic's intent to place all of these blocks into a "quarantine" > status for a minimum of 1 year, which I think is entirely proper and > prudent, under the circumstances. > > I have no explanation for why Afrinic has not yet reclaimed any of the > "Infoplan"/"Network and Information Technology Limited" blocks, especially > the 220.127.116.11/14 block. This is for me deeply troubling, as I have some > reason to believe that these blocks were stolen by a party or parties, > who were also Afrinic insiders, but people other than the one "insider" > perpetrator of these crimes who has already been identified by myself and > Jan, and who is now the subject of a police investigation in Mauritius. > > I am not personally aware of any action that Afrinic has taken to try to > remediate the situation with regards to the stolen legacy blocks, as > listed above. These blocks all quite provably had their associated > person: contact records fiddled in the WHOIS data base in a manner so > as to redirect both emails and phone calls to either the perpetrators > or those others to whom the perpetrators had re-sold these stolen goods. > > In fact, I am not even sure that Afrinic even has the capability to undo > the damage in the case of these legacy blocks and their fiddled contact > person: records. Quite obviously, proper remediation of the affected > person: records would involve restoring those to what they were before > they had been fradulently fiddled. Completion of that task is quite > obviously dependent upon Afrinic having access to historical backups of > its own WHOIS data base from as much as ten years ago. It is not at this > moment clear to me that Afrinic is even in possession of such historical > backups, and the fact that they have, as yet, made no apparent efforts to > remediate the fradulently fiddled person: records suggests to me that they > likely do not possess such backups. > > Many of the legacy blocks and many parts of the blocks that were stolen > from the Afrinic free pool, both those that have been reclaimed and those > that haven't yet been reclaimed, continue to be routed by various parties > on behalf of the thieves and black market buyers of these blocks even as > we speak. I hope to be able to post a fully list of those routes and the > relevant ASNs that are providing the ongoing routing for various parts of > this mass of stolen booty in the very near future. > > > Regards, > rfg > -- Regards, Chris Knipe
Hi Everyone, Thank you very much for all the information, suggestions, and feedback. We have been contacted by the NCIS now, and will be discussing the matter further with them. I don't think I'm comfortable, or feel it is justified, to discuss this matter further publicly. I now find myself in the absolute last situation where I wanted to be in. Regards, Chris. On Mon, Nov 4, 2019 at 4:44 PM Joe Provo wrote: > On Mon, Nov 04, 2019 at 10:55:47AM +0200, Chris Knipe wrote: > > Hi Guys, > > > > Except for the email on ARIN's details, does anyone else have a contact > for > > the DoD? > > > > We are experiencing a situation with a 3rd party (direct peer), wanting > to > > advertise DoD address space to us, and we need to confirm whether they > are > > allowed to do so or not. > > A signed ROA would be strong attestation. Anything else is > suspect. > > > Range in question is the 18.104.22.168/8 network, which according to ARIN is > > actively assigned to the DoD (US). > > Of timely reference was this presentation from last Monday > by some USG folks who have a keen interest in address > hijacking. Unfortunatelky not recorded, but slide 11 has > some interested parties and points of contact. > > > https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf > > Cheers, > > Joe > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling > -- Regards, Chris Knipe
On Mon, Nov 4, 2019 at 3:13 PM Jason Biel wrote: > 22/8 is actively used by DoD, just not publicly. It would be in your best > interest to not accept routes for it. > > if you need something more official, contact the DoD NIC directly at the > email address specified in WHOIS. > > Precisely what I was afraid off. I have contacted the DoD NIC, am waiting for a response from them. Thank you Jason, Chris.
On Mon, Nov 4, 2019 at 11:20 AM Alarig Le Lay wrote: > > There is no route inside this /8: > bird> show route primary where net ~ [ 22.214.171.124/8+ ] > bird> > > Regards, > -- > Alarig > I know that much - but just because it's not advertised, doesn't mean you're allowed to use it? It's not a typo either - the net in question is 22/8 - https://whois.arin.net/rest/net/NET-22-0-0-0-1/pft?s=126.96.36.199%2F8 It's directly assigned space, I can't find any reference anywhere about subnets within that space that has been re-assigned, or that is in use by anyone else. -- Regards, Chris Knipe
Hi Guys, Except for the email on ARIN's details, does anyone else have a contact for the DoD? We are experiencing a situation with a 3rd party (direct peer), wanting to advertise DoD address space to us, and we need to confirm whether they are allowed to do so or not. Range in question is the 188.8.131.52/8 network, which according to ARIN is actively assigned to the DoD (US). -- Regards, Chris Knipe
On Thu, Sep 26, 2019 at 9:53 PM Christopher Morrow wrote: > Maybe asking from the get-go: > "What are you trying to do?" > > because the question asked is fraught with peril and disaster... > Why? When you have a serious problem with a specific ASN, it's not unreasonable to drop traffic to that entire ASN. When you have a serious problem predominantly originating from a certain country, why is it unreasonable to drop traffic to that entire country? Just because I own an ASN and participate in the world of BGP, doesn't mean I *must* accept everyone's traffic from all over the world. My network, my rules(1) (1) my as in the ASN whom choose to drop prefixes for an entire ASN and/or country.
Think surge protectors will protect against strikes that is far away, and the residual surge it creates. A direct strike? Don't think there's anything that will really protect against that. On Wed, Aug 14, 2019 at 7:29 PM wrote: > > Are "surge protectors" really of much use against lightning? I suspect > not, other than minor inductions tho perhaps some are specially > designed for lightning. I wouldn't assume, I'd want to see the word > "lightning" in the specs. > > I once had a lightning strike (at Harvard Chemistry), probably just an > induction on a wire some idiot had strung between building roofs (I > didn't even know it existed) and the board it was attached to's solder > was melted and burned, impressive! More impressive was the board > mostly worked, it was just doing some weird things which led me to > inspect it...oops. > > My understanding was that the only real protection is an "air gap", > which a piece of fiber will provide in essence, and even that better > be designed for lightning as it can leap small gaps. > > Check your insurance, including the deductibles, keep spares on hand. > > P.S. My grandmother would tell a story about how what sounded like the > ever-controversial "ball lightning" came into her home when she was > young. Good luck with that! > > https://en.wikipedia.org/wiki/Ball_lightning > > -- > -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* > -- Regards, Chris Knipe
On Tue, Jul 30, 2019 at 11:45 AM Scott Christopher wrote: > Dan Hollis wrote: > > > >>> RCPT To: > > <<< 550 #5.1.0 Address rejected. > > 550 5.1.1 ... User unknown > > >>> DATA > > <<< 503 #5.5.1 RCPT first > > Try j...@amazon.com > > -- > S.C. > Then update your ARIN records to reflect that. Fully agree with Dan on this one. -- Regards, Chris Knipe
On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG wrote: > The 2nd requirement seems artificial. The new hypervisors have come a long > way and the overhead is minimal. Also you can run bare metal instances in > AWS if you really need them with 100Gbps. > > Just just use the South Africa AWS region. > > ^^ You had me for a second there. AWS ain't operational yet in South Africa. Sometime 2020/2021 only.
Hi Guys, Quick question... In orgs using frequent and large amounts of IPSec, what are you guys using in terms of configuration management / documentation? Especially in terms of Phase 2 and documenting what the relevant Phase 2s are for? Is it a matter of text files / spreadsheets, or are there something out there to manage this with? -- Regards, Chris Knipe
Also no problems here with IPv6 and Windows Updates... On Sun, Nov 11, 2018 at 1:42 PM Daniel Corbe wrote: > at 4:29 AM, Mark Tinka wrote: > > > Hi all. > > > > Anyone ever figured out why Windows updates fail when the computer has > an > > IPv6 connection? > > > > Google has tickets and tickets of this to and outside of Microsoft > since > > 2013, with no real solution or answer as to what the problem actually > is. > > In essence, many of the solutions out there point toward making sure > the > > updates do not occur over IPv6, which, in effect, is the same as > > disabling it. > > > > I have a family PC at home running Windows 10 Pro, and noticed updates > > would fail in recent months. It took me a moment to realize that this > > started happening only after I enabled IPv6 in the TCP/IP stack. > > Disabling it immediately solves the issue. > > > > Quite odd that this is happening in 2018... > > > > Mark. > > I’ve had IPv6 enabled for a while and I don’t have the same issue. We > also > peer directly with Microsoft. Are you sure it’s an IPv6 issue and not a > general reachability issue? > > -Daniel > > > -- Regards, Chris Knipe
On Sun, Mar 12, 2017 at 7:53 PM, Baldur Norddahl <baldur.nordd...@gmail.com> wrote: > > > Den 12/03/2017 kl. 18.14 skrev Brielle Bruns: > >> http == TCP >> DNS == (usually) UDP >> >> Big difference here. One requires a three way handshake tearup/teardown, >> the other does not. >> >> It is not an apples to apples comparison. >> >> > You can replicate (download) the whole WHOIS if you need to. There is also > no requirement that removal from reputation lists is instant. We would be > good if it happened just within a month or even half a year. The situation > now is however that you will never have it removed and many reputation > services will ignore you if try to contact them for manual removal. > > At least in the RIPE managed space there IS a reliable way to know for > sure who owns a block. Can you know that the new owner is any better than > the old? Of course not, but that is true even for "fresh" address space. > > I am not a fan of reputation services that blacklist forever. It is just > wrong and open for abuse of power. But not much I can do about that other > than not using their service. > > Also, no reason why a UDP (or DNS based even) query can't be implemented to facilitate reputation lookups for ASNs, or even ownership. -- Regards, Chris Knipe
On Sun, Mar 12, 2017 at 6:17 PM, <valdis.kletni...@vt.edu> wrote: > On Sun, 12 Mar 2017 17:59:59 +0200, Chris Knipe said: > > > Sure, that will work. (And no, the problem isn't the number of http hits > on the registries. 35,840,000,000 hits per day is the easy part...) > And yet, there's no problems of BILLIONS of queries against RBL DNS servers? -- Regards, Chris Knipe
On Sun, Mar 12, 2017 at 5:59 PM, Baldur Norddahl
wrote: > They could watch the routing table and notice which ASN is actually using > the address space. In fact ASN reputation might work better than IP space > reputation. > +1 And not only the originating ASN, but to a lesser extend, adjacent ASNs too
On Sun, Mar 12, 2017 at 5:40 PM,
wrote: > > How does Spamhaus find out the block has been resold? > > How do other DNS-based blacklist operators find out? > > >From the REGISTRY as the ultimate custodian of the IP block. > How do all the AS's that have their own internal blacklists find out that > they should fix their old listings? (Note that this is the exact same > problem > as "We got blacklisted because of a bad customer, we axed the customer, but > we're still blacklisted", which has been a an unsolved problem for decades > now). > > >From the REGISTRY as the ultimate custodian of the IP block. "We got blacklisted because of a bad customer, we axed the customer, but we're still blacklisted" is a FAR call from what this discussion is about. "I got blacklisted because someone else that has NO relevance to me what so ever was stupid" is more accurate. You can't punish the purchaser of an IP block, because of what previous owners of the IP block did. If I receive a dynamic IP from my ISP on dialup, and the previous user using that IP hacked the FBI... Am I now to blame because the FBI got hacked? NO! The previous user of the IP is responsible! > And it's awfully easy to game the system by just reselling the block > between > a group of shell companies run by bad actors. > > Yes - just like we're playing ping pong with NetFlix (and others) and VPN providers because of geo restricted content too :-) It's a loosing battle, and a failed system. Don't blame the purchaser, it's a lack of oversight on the part of who ever does the blacklisting. And that, should form part of being RESPONSIBLE when you DO decide to blacklist / unblacklist IP blocks. There are FAR to many companies on the Internet that simply does what they want, when they want. I (or anyone else - I haven't purchased IP space from any other source other than registries, yet), can't be held liable for what others have done. Whether it's IP space, whether it's breaking an entering, whether it's fraud, it doesn't matter. I did not commit the act, and I can't be held liable. Your punishing the wrong person, for the wrong reason. The fact that there's companies out there, CAMPING on /8s which they do not use and yet refuse to return, is exactly why the internet is sitting in this predicament.
> >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > >> 188.8.131.52 > >> 184.108.40.206 > >> 220.127.116.11 > >> 18.104.22.168 > >> 22.214.171.124 > >> 126.96.36.199 > > > > -- Regards, Chris Knipe
Hi, Anyone from NetRouting NOC (AS47869) that can contact me off list please. Not getting anywhere resolving a routing issue with your support personnel. -- Regards, Chris Knipe
On Mon, Aug 15, 2016 at 5:41 PM, <valdis.kletni...@vt.edu> wrote: > On Mon, 15 Aug 2016 11:16:26 -0400, Jon Lewis said: > > Obvious first question would be, have you fallen behind paying your bill? > > And if you're in fact up-to-date, make sure you have *proof* of same. It's > not unheard of for providers to mis-credit your payments and then think > you're > behind. Usually showing them proof that funds were transferred to the > provider, and it's *their* problem to fix their accounting system, is > sufficient to make them change their tune *really* fast... > Although a company that can't manage their book keeping properly, is IMHO enough reason to not use them... :-) -- Regards, Chris Knipe
Exactly. So what precisely are the metrics they use to block? I'm not using a proxy at all, its my own ASN... On Wed, Jun 8, 2016 at 11:06 PM, Andy Ringsmuth <a...@newslink.com> wrote: > > > On Jun 8, 2016, at 3:52 PM, Chris Knipe <sav...@savage.za.org> wrote: > > > > Bwahaha > > > > Ok - that's me, never ever will I look at NexFlix again. > > > > I have my own /48, registered in my own name, my own company, my own > > peering links, and my own transit links. Signup, no problems. As soon > as > > I started watching a stream... > > > > Wham, blocked. Proxy Detected. > > > > It's clear NetFlix has something against IPv6, not tunnels. > > I disagree. > > I’ve got IPv6 at work, nothing elaborate, just a /48 given to us by our > ISP. > > I ran a test on an IPv6-only connection, no IPv4 addressing whatsoever, > and a few random Netflix shows played perfectly fine. > > > > Andy Ringsmuth > a...@newslink.com > News Link – Manager Travel, Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397(402) 304-0083 cellular > > -- Regards, Chris Knipe
; I have > > > > to change my damn network to fix Netflix? > > > > > > > > In her eyes it's "daddy fix Netflix" but the heck with that. The man > > > hours > > > > of the consumers who are affected to work around this issue is less > > > than > > > > the man hours it would take for Netflix to redirect you with a 301 > > > > to > > > an > > > > ipv4 only endpont. > > > > > > > > If Netflix needs help with this point me in the right direction. > > > > I'll > > > be > > > > happy to fix it for them and send them a bill. > > > > > > > > > > They're doing the same thing with IPv4 (banning people based on the > > > apparent IP address). Your IPv4 numbers may not be on their blacklist > > > at the moment, and disabling IPv6 might work for you, but the > > > underlying problem is the practice of GeoIP/VPN blocking, and the > > > HE.net tunnels are just one example of the collateral damage. > > > > > > I don't know why Netflix and other GeoIP users can't just ask > > > customers where they are located, instead of telling them. It is > > > possible that some user might lie, but what about "assume good faith"? > > > It shows how much they value you as a customer if they would rather > > > dump you than trust you to tell them where you are located. > > > > > > -Laszlo > > > > > > -- Regards, Chris Knipe
On Sat, Apr 16, 2016 at 12:04 AM, Josh Reynolds
wrote: > Can't do more than 1Gbps per flow. Not suitable for this application. > On Apr 15, 2016 5:03 PM, wrote: > > > Check out the Mikrotik Cloud Core routers, they make them with SFP+ > > support now. I have one of them with 10g deployed right now. > > > > -Mike > Also it falls pretty much flat on it's face the moment you do anything useful in terms of firewalling / NATing.
On Thu, Jan 28, 2016 at 7:40 PM, Mike Hammett
wrote: > There's little reason to buy a newer TV more than every 5 - 10 years, so > many TVs will be stranded until (if) they have some unifying firmware. > > Well the TV is also meaningless if the CPE, and (at the very least) service provider don't support IPv6. And yes, that is unfortunately reality. If you look beyond the US and EU, and maybe Brazil, the rest of the world, unfortunately, is FAR from IPv6 adoption, and that *is* reality. Hence my initial comments... It's going to be many more years, before IPv6 is the "fix" for any real problems currently experienced with IPv4. Sad, but unfortunately, true. -- Chris.
On Thu, Jan 28, 2016 at 11:07 AM, Owen DeLong
wrote: > > Fortunately Netflix is running IPv6 for most things already. If you’re an > ISP and you’re not > allowing them to reach Netflix via IPv6, then you’re part of the problem > rather than the solution. > > Sure. Easy to say when you have access to IPv6, and your transit providers actually PROVIDE IPv6 services. So sick and tired of this IPv6 preaching. There are HUGE obstacles in huge parts of the world preventing the use of IPv6. Simply throwing IPv6 as a solution to absolutely everything, is hardly an solution at all I'm afraid. -- Chris.
Highly unlikely... On Thu, Jan 28, 2016 at 3:46 PM, Bacon Zombie <baconzom...@gmail.com> wrote: > Do all "smart" TVs and Game consoles fully support IPv6 out of the box? > On 28 Jan 2016 10:17, "Chris Knipe" <sav...@savage.za.org> wrote: > >> On Thu, Jan 28, 2016 at 11:07 AM, Owen DeLong <o...@delong.com> wrote: >> >> > >> > Fortunately Netflix is running IPv6 for most things already. If you’re >> an >> > ISP and you’re not >> > allowing them to reach Netflix via IPv6, then you’re part of the problem >> > rather than the solution. >> > >> > >> Sure. Easy to say when you have access to IPv6, and your transit >> providers >> actually PROVIDE IPv6 services. >> >> So sick and tired of this IPv6 preaching. There are HUGE obstacles in >> huge >> parts of the world preventing the use of IPv6. >> >> Simply throwing IPv6 as a solution to absolutely everything, is hardly an >> solution at all I'm afraid. >> >> -- >> Chris. >> > -- Regards, Chris Knipe
On Mon, Oct 26, 2015 at 9:00 PM, Jim Popovitch <jim...@gmail.com> wrote: > > It is indeed much simpler and can even be done via a mobile device > from anywhere in the world. The magic sauce: Moderate the user > account being abused to post to this list. > Yep - saw ONE message on AFNOG, and that was the end of it, and I think two, or three on the Freeradius lists, and that was the end of that... Hundreds, and hundreds on NANOG however. -- Regards, Chris Knipe
Dear NANOG Moderators, Sorry but after two DAYS of this crap... Are you planning to do something about all of this spam? Thank you. On Sun, Oct 25, 2015 at 3:35 AM, Salima Ait Meziane <jde...@jdlabs.fr> wrote: > Hey! > > > > New message, please read <http://acresnacres.ca/were.php?zha> > > > > Salima Ait Meziane > > -- Regards, Chris Knipe
On Thu, Oct 22, 2015 at 4:24 PM, Clay Curtis <clay...@gmail.com> wrote: > I work for a VAR and we are starting to have customers come to us to help > with internet redundancy projects and they are unable to get address space > from ARIN. What are the viable options here? I have read about secondary > markets, transfers, auction sites, leasing, etc. Can NANOG point me in the > right direction as to the most effective way to get v4 space right now in > the US? And before we get into the whole IPv6 discussion, yes, yes, we are > discussing this with customers as well. That being said, they still need > the IPv4 space in the near-term. > Sitting in exactly the same position. IPv6 is great and all, but running my business natively on IPv6 means nothing to me if my customers can't reach me. -- Regards, Chris Knipe
Indeed! One of the nicest visualizations I've seen to date. Loving it! On Tue, Sep 8, 2015 at 4:37 PM, Max Tulyev <max...@netassist.ua> wrote: > Really nice! > > How can I do zoom in/zoom out? > > On 06.09.15 03:15, Jared Mauch wrote: > > > > OT: hit delete, or shameless plug disclaimer > > > > one of my colleagues just posted this visualiation > > of the internet from the as_path view of 2914. if you are on > > a mobile, you have to physically move your device around. > > > > http://as2914.net/ > > > > If you love it, send Job your accolades. If you hate it, > > see above disclaimer. If in a country with a holiday on monday, > > enjoy it safely. > > > > - Jared > > > > -- Regards, Chris Knipe
Running 6500's and 7200's with 3rd party memory... No issues. On Thu, May 8, 2014 at 7:02 PM, Gary Dunaway gary.duna...@teamhgs.com wrote: A few years back, we had to do memory upgrades on our ASAs in order to move to 8.3 code. All was done with 3rd party memory kits. There have been no performance issues we've noticed with them. The one issue we had was that one of the memory sticks in the kit was bad. The vendor immediately sent out a replacement for it and all was well after that. -Gary -Original Message- From: NANOG [mailto:firstname.lastname@example.org] On Behalf Of Shawn L Sent: Thursday, May 08, 2014 11:47 AM To: nanog Subject: Experience with Third-Party memory (Cisco)? With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ Please make note of our new e-mail domain name: TEAMHGS.COM. Request you to update your address book accordingly. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Hinduja Global Solutions or postmas...@teamhgs.com immediately and destroy all copies of this message and any attachments. 9284f6a0-bf16-11e3-b1b6-0800200c9a66 -- Regards, Chris Knipe
On Sat, Mar 22, 2014 at 11:30 AM, Bryan Socha br...@digitalocean.com wrote: Oh btw, how many ipv4s are you hording with zero justification to keep them? I was unpopular during apricot for not liking the idea of no liability leasing of v4. I don't like this artificial v4 situation every eyeball network created.Why is v4 a commodity and asset? Where is the audits.I can justify my 6 /14s, can you still? Oh I so agree with this one. But alas yes, IPv4's days are counted and I doubt there's any turning back. As a NA myself, I see day on day where smaller ISPs are forced to dish out large network blocks (/16s) to be able to have access to large unefficiently planned broadband networks in order to service PPPoE terminations (at least, here in ZA). These ISPs are forced to 'hand out' /16 networks for the large telco's to distribute to their respective BRAS devices Meanwhile, the ISP does not even have 20K customers - nevermind the fact that more than likely 50% of that customer base is not even 'always' connected... It's due to waisting like this, that the shortage is there and that other players with legitimate requirements (such as going provider independant) cannot obtain address space. And it is continueing to this very day. I'm definately all for proper audits, stricter audits, and more importantly the releasing of unused address space back to the respective registries. -- Regards, Chris Knipe
been getting it for a few days (weeks?) already now... On Wed, Jun 26, 2013 at 9:13 PM, Jamie Gwatkin jgwat...@magmic.com wrote: We're also seeing the same, twitter users are also reporting a lot of problem. https://twitter.com/search/realtime?q=google%20appssrc=typd On Wed, Jun 26, 2013 at 2:57 PM, Blair Trosper blair.tros...@updraftnetworks.com wrote: Our entire organization and three of my other accounts are getting this pop-up when sending a message: Oops... a server error occurred and your email was not sent. (#793) But, as usual, everything is totally fine according to the GApps status page: http://www.google.com/appsstatus#hl=env=statusts=1372272841152 -- Blair Trosper Weather Data / Updraft Networks blair.tros...@updraftnetworks.com blair.tros...@updraft.us NOC: 512-666-0536 -- Regards, Chris Knipe