February 2020 - Test - lists.nanog.org

Re: NANOG Digest, Vol 145, Issue 5
by Chris Orsman 05 Feb '20

05 Feb '20

Hi, First submission so be nice :-) Ex. CenturyLink'er here so happy to share my knowledge of their network based solution if anyone is interested. Cheers Chris On Wed, 5 Feb 2020, 12:00 , <nanog-request(a)nanog.org> wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Recommended DDoS mitigation appliance? (Colton Conor) > 2. RE: Recommended DDoS mitigation appliance? (Phil Lavin) > 3. RE: Recommended DDoS mitigation appliance? (Kushal R.) > 4. Re: Recommended DDoS mitigation appliance? (J. Hellenthal) > 5. Re: Recommended DDoS mitigation appliance? (Colton Conor) > 6. RE: Recommended DDoS mitigation appliance? (Phil Lavin) > 7. Re: Jenkins amplification (Daryl) > 8. Re: Jenkins amplification (Mike Meredith) > 9. Re: EVPN multicast route (multi home case ) implementation / > deployment information (Andrey Kostin) > 10. WTR: 1-2RU @ Equinix Ashburn (Jason Lixfeld) > 11. Help with survey on enterprise network challenges? > (Joseph Severini) > 12. Re: Jenkins amplification (Christopher Morrow) > 13. Re: Has Anyone managed to get Delegated RPKI working with > ARIN (Cynthia Revström) > 14. Re: Has Anyone managed to get Delegated RPKI working with > ARIN (Randy Bush) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 4 Feb 2020 07:40:18 -0600 > From: Colton Conor <colton.conor(a)gmail.com> > To: Javier Juan <javier.juan(a)gmail.com> > Cc: Rabbi Rob Thomas <robt(a)cymru.com>, NANOG <nanog(a)nanog.org> > Subject: Re: Recommended DDoS mitigation appliance? > Message-ID: > < > CAMDdSzN0vhwK70Gd0EnNPRvP9QAfqoXZ_GUZiaVtgzcWgwN_GQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Javier, > > So is Imperva similar to how Kentik operates? What was it priced liked? I > like the Kentik solution, but their per router per month pricing is too > expensive even for a small network. > > On Mon, Feb 3, 2020 at 11:01 AM Javier Juan <javier.juan(a)gmail.com> wrote: > > > Hi ! > > > > I was looking around (a couple years ago) for mitigation appliances > > (Riorey, Arbor, F5 and so on).... but the best and almost affordable > > solution I found was Incapsula/Imperva. > > > > > https://docs.imperva.com/bundle/cloud-application-security/page/introducing… > > > > > > Basically, You send your flows to Imperva on cloud for analysis. As soon > > as they find DDoS attack , they activate mitigation. It´s some kind of > > elegant-hybrid solution without on-premise appliances . Just check it > out :) > > > > Regards, > > > > JJ > > > > > > > > On Sun, Nov 17, 2019 at 11:20 PM Rabbi Rob Thomas <robt(a)cymru.com> > wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> > >> Hello, NANOG! > >> > >> I'm in the midst of rebuilding/upgrading our backbone and peering - > >> sessions cheerfully accepted :) - and am curious what folks recommend > >> in the DDoS mitigation appliance realm? Ideally it would be capable > >> of 10Gbps and circa 14Mpps rate of mitigation. If you have a > >> recommendation, I'd love to hear it and the reasons for it. If you > >> have an alternative to an appliance that has worked well for you > >> (we're a mix of Cisco and Juniper), I'm all ears. > >> > >> Private responses are fine, and I'm happy to summarize back to the > >> list if there is interest. > >> > >> Thank you! > >> Rob. > >> - -- > >> Rabbi Rob Thomas Team Cymru > >> "It is easy to believe in freedom of speech for those with whom we > >> agree." - Leo McKern > >> -----BEGIN PGP SIGNATURE----- > >> > >> iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF > >> 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF > >> xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV > >> 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv > >> oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ > >> N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y > >> 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti > >> 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ > >> hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka > >> VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC > >> g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP > >> d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo= > >> =uuel > >> -----END PGP SIGNATURE----- > >> > > >

1 0

Looking for an AT&T Wireless contact
by Michael Brown 04 Feb '20

04 Feb '20

I'm looking for an AT&T Wireless contact to reach out to me off-list. We (discourse.org) have reports from multiple customers that their users are unable to negotiate SSL with our sites when using their AT&T Wireless data connection. The problem is be affecting users around Chicago and Pennsylvania. Evidence points to some sort of SSL interference/tampering. Cheers, Michael Brown

1 0

Jenkins amplification
by Töma Gavrichenkov 04 Feb '20

04 Feb '20

FYI https://nvd.nist.gov/vuln/detail/CVE-2020-2100 A nice description: https://mobile.twitter.com/Foone/status/1223063275996213248 May you live in interesting times. Do not postpone a software update if Jenkins is deployed somewhere in your network. -- Töma

13 19

Help with survey on enterprise network challenges?
by Joseph Severini 04 Feb '20

04 Feb '20

Hi, My name is Joseph Severini, and I am a PhD student in the Computer Science Department at Carnegie Mellon University. I’m working on a research project to identify common operational challenges in modern enterprise computer networks. I’ve put together a survey to identify these challenges by analyzing some operational problems found in the Network Engineering Stack Exchange open-source dataset. You’ll be given a problem from the dataset and asked some questions about it. I would appreciate it if you would consider taking this survey, which can be found at the link below: http://cmu.ca1.qualtrics.com/jfe/form/SV_dm6i9znuPWlLDN3 The survey should take ~15 minutes. Participation is voluntary, with no compensation, and all responses are anonymous. You must be at least 18 years old to complete the survey. Thanks, Joseph Severini PhD Student CMU Computer Science Department

1 0

WTR: 1-2RU @ Equinix Ashburn
by Jason Lixfeld 04 Feb '20

04 Feb '20

Hi, I’m wondering if anyone is looking to subsidize their Equinix Ashburn colo costs by way of carving out 1-2 RU to a friendly for a low density networking application. If so, I’d love to hear from you! Thanks in advance!

1 0

EVPN multicast route (multi home case ) implementation / deployment information
by Mankamana Mishra (mankamis) 04 Feb '20

04 Feb '20

Folks Wondering if there is any known implementation of EVPN multihome multicast routes which are defined in https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04 there is some change planned in NLRI , we want to make sure to have solution which does work well with existing implementation. Note: Discussion involves Nokia, Juniper, Cisco, Arista already. So looking for any other vendor who have implementation. Mankamana

2 1

Recommended DDoS mitigation appliance?
by Rabbi Rob Thomas 04 Feb '20

04 Feb '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, NANOG! I'm in the midst of rebuilding/upgrading our backbone and peering - sessions cheerfully accepted :) - and am curious what folks recommend in the DDoS mitigation appliance realm? Ideally it would be capable of 10Gbps and circa 14Mpps rate of mitigation. If you have a recommendation, I'd love to hear it and the reasons for it. If you have an alternative to an appliance that has worked well for you (we're a mix of Cisco and Juniper), I'm all ears. Private responses are fine, and I'm happy to summarize back to the list if there is interest. Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo= =uuel -----END PGP SIGNATURE-----

18 30

The curious case of 159.174.0.0/16
by Ronald F. Guilmette 03 Feb '20

03 Feb '20

[[ Fair warning to newcomers: I write and post longish pieces here regarding my various investigations of funny business I find going on within the IPv4 address space and the allocations and uses thereof. If you're looking for a quick 2 minute read then you are advised to skip this message now. ]] I confess that I have been meaning to write about the 159.174.0.0/16 legacy IPv4 block for quite some time now. What can I say? I was busy. The Present State of 159.174.0.0/16 ----------------------------------- I discovered quite some long time ago that this block was getting routing from a rather unusual place, and that the ASN in question was also announcing a few other nice juicy /16 legacy blocks, which by itself was more than a little suspicious. But that's not imporant now. Please allow me to just talk about who is routing this block at present, and who the alleged legitimate registrants are, going by ARIN's relevant current WHOIS record for this block: https://pastebin.com/raw/FBWMN9p3 As you can see, this block is registered to an entity located in Wilton, Connecticut. The block appears to have been originally assigned on 1992-05-11, well before the formation of ARIN. It is thus an unusually valuable "legacy" block. The first indication that something might be a bit off about this block is the contact phone number, +1-407-476-9854. In this modern era of number portability the area code portion of that may or may not have any real-world geographical implications at all, but it turns out to be notable, in this case, that area code 407 corresponds, historically, to the greater Orlando, Florida area and surrounding Florida counties. A quick bit of research reveals that there is in fact an entity calling itself Dunsnet, LLC and that it is located in Winter Park, Florida, a northern suburb of Orlando: http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inqui… Further research on the Florida Secretary of State's web site confirms that this entity does exist, that it is "active", and that it has one and only one manager, that being another corporate entity called Ahosting, Inc.: http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inqui… As you can see via the above link, Ahosting, Inc. has only two corporate directors, i.e. a Mr. Erkan Ozdogan and a Mr. Adnan Canturk, both apparently residents of Istanbul, Turkey. At the present time, 100% of the 159.174.0.0/16 legacy block is being routed by AS54163, aka Ahosting, Inc.: https://bgp.he.net/AS54163#_prefixes The question is: Is this proper? A Brief History of 159.174.0.0/16 --------------------------------- When the 159.174.0.0/16 block was first allocated and registered, way back on 1992-05-11 it was assigned at that time to a unit of the famous Dun & Bradstreet financial information company for use in connection with one of the company's early forays into the world of the Internet: Fortune Magazine, August 19, 1985: https://archive.fortune.com/magazines/fortune/fortune_archive/1985/08/19/66… "Dun & Bradstreet also operates DunsNet, a $20- million private telecommunications network completed in March, which connects customers in 155 cities directly to the company's mainframes." On June 8th, 1994, Dun & Bradstreet's "Dunsnet" operation announced that it had elected to partner with a European company named Eunetcom SA, which was itself a partnership between Deutsche Bundespost Telekom and France Telecom: https://www.cbronline.com/news/eunetcom_wins_dunsnet_pact/ In August, 1994, Eunetcom apparently elected to buy out its customer, Dunsnet: "The Information Superhighway" (Randall L. Carlson - 1996) https://bit.ly/2O7kV48 "Eunetcom is actively pursuing customers and entry into the North American market. Its first customer was worth $200 million over five years and was {subequently} acquired by purchasing the networking services of Dun & Bradstreet's DunsNet. DunsNet provides data communications services for the Dun & Bradstreet companies, a role that Eunetcom now assumes." https://www.postjobfree.com/resume/pumacu/unix-administrator-technical-anal… "In August 1994, DunsNet was acquired by eunetcom, a joint venture between Deutsche Telekom and France Telecom." As we all know, unlike the situation today, IPv4 blocks in the 1990s had essentially no monetary value. And thus the 159.174.0.0/16 block became forgotten and abandoned by its rightful owners, which is to say Deutsche Telekom and France Telecom. Fast forward some 16 years to June 29, 2011, on which date it appears that two clever fellows in Istanbul, Turkey began what would seem to be a quite deliberate, premeditated, and determined effort to take control of the (now quite valuable) 159.174.0.0/16 legacy block via the same sort of simple-minded ruse that had already, by that time, worked so well for others who likewise coveted various ARIN-administered large and valuable legacy IPv4 blocks. They simply pretended to be "Dunsnet" and began the process of requesting from ARIN complete control over "their" legacy block. ARIN apparently obliged and permitted these two Turkish geentleman to make various changes to the relevant ARIN WHOIS records. The official ARIN "WhoWas" historical records relating to the 159.174.0.0/16 block show quite clearly various changes being made to the relevant organization record on 06-29-2011, 09-24-2011, and again on 11-06-2017: https://pastebin.com/raw/WTgvjXg2 Also and similarly, changes were made to the NET-159-174-0-0-1 record for the block itself on 06-29-2011 and again on 11-06-2017: https://pastebin.com/raw/b3F1eTua These latter day changes to the relevant ARIN WHOIS records might have been and remained mostly unsuspicious had it not been for the creation, by the aforementioned two Turkish gentlemen, on 08/06/2012, of the new Florida LLC named "Dunsnet, LLC". (See link above.) In this context, it seems more than plausible that the name of this newly minted Florida LLC was chosen specifically and deliberately with the intent of hiding the facts regarding the illicit usurpation of the valuable 159.174.0.0/16 block. This pattern of apparent corporate-level identity theft is one that I have already seen on multiple previous occasions in association with fraud, perpetrated against some Regional Internet Registry (and ARIN in particular) with the goal being the theft of some sizable IPv4 legacy block. In fact, the only thing that is actually striking and somewhat remarkable in this case is the exact timing of the relevant events. As noted above, the relevant ARIN WHOIS records were, it appears, improperly fiddled on various dates in 2011. It is not immediately clear why ARIN would have allowed such manipulations in that year, given that the fradulent Florida shell company, Dunsnet, LLC was not actually incorporated until 08/06/2012 according to Florida state records. (See link above.) As noted above, official Florida state records for Dunsnet, LLC say that it has one and only one manager, that being Ahosting, Inc. As also noted above, two specific persons appear to be in control of Ahosting, Inc., Mr. Erkan Ozdogan and Mr. Adnan Canturk, both residents of Istanbul, Turkey. Despite the strikingly inconvenient commute that these two gentlemen must apparently have to deal with, these gentlemen quite obviously are the principals of at least the two Florida corporate entities named above. A look at some relevant web sites provides us with some further clues. Whereas ahosting.com formerly was associated with a fuilly functioning web site, that appears to not be the case at the present time. There is some downloadable content that can be reached via a URL which, in normal circumstances, would be expected to take you to the home page of this company, but the content in question is just some small bit of HTML that my various web browsers refuse to render for some reason. The same problem seems to also and likewise afflicts what should be the home page for dunsnet.com. And the same again also for the web site associated with tthe domain name mentioned in the WHOIS record for AS54163, ahostinginc.com. (Remember that this ASN is currently routing all of the 159.174.0.0/16 block.) In this last case however the content provides some clues as to an apparently related business known as aseohosting.com, where the "SEO" part apparently stands for "Search Engine Optimization". https://pastebin.com/raw/PnpgnA2A A simple Google search for Mr. Erkan Ozdogan turns up little of interest, however a similar search in the case of Mr. Adnan Canturk turns up multiple bits of his social media footprint: https://www.linkedin.com/in/adnan-canturk-24a66633 https://twitter.com/adnan_canturk The latter page provides us with a link to Mr. Canturk's personal web site, adnancanturk.com, but this also appears to have a dysfunctional home page. Nontheless, the text content that can be fetched from that URL further confirms Mr. Canturk's apparent connection to a business named "Aseohosting": https://pastebin.com/raw/NTW9nH6G Despite all of these dysfunctional web sites and home pages, the web site and the home page of aseohosting.com appears to be very much alive and well at present: https://www.aseohosting.com/ It is my hope that I will not have to go into too much detail in order to explain to the audience here why the use of large numbers of unique IPv4 addresses might be viewed by some as an integral part of any one of the net's myriad and almost entirely useless "SEO" schemes whose intent is the fundamental hoodwinking of search engines, such as Google, and their algorithms. The ultimate goal of these schemes, of course, is to snooker the search engines into displaying certain results above others. The bottom line is that it would appear that in this case, in the year 2011, Mr. Ozdogan and Mr. Canturk found themlseves a convenient and zero cost way of acquiring a sizable supply of IPv4 addreses, and that at the present time these valuable legacy IPv4 addrdesses are being employed (wasted?) on one big and undoubtedly fruitless search engine optimization scheme. To say that this is not the highest, best or most efficient use of the increasingly scarce supply of IPv4 addresses would, I'm sure, be a serious understatement. (To paraphrase my mother's early admonitions to me at dinner time "There are children starving in Asia would would like to have those IP addresses!") I must note that before posting this message I have made what I believe to be reasonable efforts to contact both Mr. Ozdogan and Mr. Canturk via every email address I could find for them, offering them the opportunity to respond to the preceeding facts and my interpretation of them, while promising those gentlemen that I would post their responses, whatever they might be. No response was received to this offer by press time. I also emailed John Curran, CEO of ARIN, prior to posting this message, and also offered him an opportunity to provide me with a response. This is his response: "ARIN does not comment on specific registry changes (as number resource change requests are made in confidence), but we do take matters of potential number resource fraud quite seriously. As you have chosen not to report this case of potential fraud, ARIN will not be investigating at this time, but we would welcome a fraud report if you believe that there is a need for investigation." -- John Curran, CEO, ARIN In closing I would just like to offer my personal observation that over time it appears to me that ARIN has been repeatedly victimized by this exact form of rather transparent fraud based on corporate identity theft. Instances of this date back to 2008, and now appear to have occurred as recently as last year. (More about that later.) I find this fact more than a little troubling, not least because of the apparent correlation between the specific IPv4 blocks that have been purloined in this manner and the congregation of Internet bad actors... spammers, hackers, and all manner of other Internet hooligans and miscreants... in and around the relevant stolen blocks. I understand that ARIN has neither the mandate to perform exhaustive investigations of all requests it receives, nor the kind of unlimited resources that might be required in order to do exhaustive investigations on a routine basis. That having been said however, in this and other such instances, the fradulent nature of the requests has been really rather obvious and transparent, requiring only the most modest amount of effort to note one or more of the glaring red flags and thus the need for further inquiry. I feel compelled to also note that ARIN's responses to cases such as this (e.g. the case of the 143.95.0.0/16 block) or, more accurately, the general lack of such responses may ultimately prove to be problematic, not just for ARIN but for the United States Department of Justice, e.g. in its current prosecution of federal criminal case 3:18-CR-04683-GPC: https://krebsonsecurity.com/2019/09/feds-allege-adconion-employees-hijacked… I am not immediately persuaded that a case could not be made, by the defense in that case, for selective prosecution. To an outsider such as myself, it seems that it might be difficult to defend and justify a decision to criminally prosecute one case in which ARIN was allegedly defrauded, apparently by persons of less-than-impressive means, while electing to -not- prosecute a half-billion dollar corporation, such as EIGI, against which the weight of the evidence may perhaps be equally compelling. This is the kind of slippery slope that one begins to traverse when one is guided by convenience or pragmatics, rather than by even-handed principal. Regards, rfg P.S. I have previously been in contact with a representative of Orange S.A., formerly France Telecom, and have requested that he arrange for his company to take back control of what would appear to be their partial ownership of the 159.174.0.0/16 block. To the best of my knowledge, no action has been taken by the company in this direction. To date I have to date been utterly unable to make contact with any representative of Deutsche Telekom in order to likewise encourage that company to reassert its apparently rightful claims to the 159.174.0.0/16 block. I would thus appreciate any referrals to any actual natural persons in that company with whom I might be able to discuss this matter. (I have a standing policy of never attempting to converse with unaccountable anonymized role accounts. Based on past experience, this is without exception an utter waste of my time.)

6 6

Re: Starting to Drop Invalids for Customers
by Jakob Heitz (jheitz) 03 Feb '20

03 Feb '20

Mark, Thanks for bringing this up again. I remember this from nearly 3 years ago when Randy brought it up. A bug was filed, but it disappeared in the woodwork. I have now given it the high priority tag that it should have had initially. Sorry about the mess up. In the meantime, you may be able to signal the validation state in iBGP once it is validated at the network edge. For an iBGP neighbor, use a configuration like this: neighbor 192.0.2.1 announce rpki state Regards, Jakob. Date: Sat, 11 Jan 2020 23:12:27 +0200 From: Mark Tinka <mark.tinka(a)seacom.mu> On 10/Jan/20 16:15, Lukas Tribus wrote: > Thanks for sharing all this. Regarding those 2 platforms specifically, > what release are you using here that does not blow up? On the ASR920, we are on 16(11)01a. On the ME3600X, we are on 15.6(2)SP6. > IIRC you had > some RPKI related crash bugs at some point in time? Yes, that was the first time we were deploying RPKI in 2014 and the code back then crashed the ME3600X. No such problem this time around. > - there is no ROA, so prefixes are supposed to be UNKNOWN on all nodes > - but IOS-XE prefers VALID over UNKNOWN (changing best path selection) > - iBGP is *always* VALID (even if it's really UNKNOWN), eBGP is > showing UNKNOWN, so iBGP is preferred over eBGP which breaks a lot of > assumptions and "hot potato" concepts (possible temporary routing > loops, other than of course different egress behavior) So your timing on this is ominous. In the last day or so, we had an issue with a customer on one of our ASR1006 edge routers that fell victim to this IOS XE stupidity. An alternate path toward them learned from a peer was sent back to the edge router they are connected to, which chose it over the local one because, well, it was an iBGP route. We didn't notice this issue with this customer since enabling ROV on this box weeks ago, which means the alternate route became available in the last 2 - 3 days, e.g., perhaps they turned up an alternative provider, or changed their routing toward them for us to see another path. Since this IOS XE stupidity is not configurable, what we've decided to do is disable ROV on all ASR1006 boxes for now. This is not a big issue for us. We've only got 2 customers using them as these boxes only carry non-Ethernet customers. While this should be an issue for our ASR920 and ME3600X routers also, it isn't because we run BGP-SD on those, i.e., even if the RIB will have all iBGP routes marked as Valid, they won't be installed in FIB, whereas the eBGP routes learned locally from the customer will. Having to create a ROA to solve this, while feasible, is inappropriate for a solution, especially when Juniper do it correctly. Randy and I complained to Cisco about this years back, and AFAIK, it was only fixed in IOS XR. That this is still going on in 2020 is silly, especially when it's clear that they are in violation of the RFC. > Apparently there is an IOS feature "Announce RPKI Validation State to > Neighbors" to transmit the *real* RPKI state in iBGP (so as opposed to > defaulting to VALID for all iBGP neighbors), I'm not sure if that > fixes this problem or not. It doesn't really address the root cause > (which is: unwanted and not configurable interference with the best > path selection algorithm) - but at it can at least hide it's symptoms. I've not tried communicating RPKI state between routers via BGP communities. One of the reasons I like RPKI is because it is a feature that works on each router independent of another. Each router has a discrete RTR session to a validator, and can make its own RPKI decisions without any regard for the rest of the network. And yet all routers in the network can do this and equally have a converged RPKI state, without ever speaking to one another. So the idea of having routers co-ordinate RPKI information through communities is one I am not so keen on, if I'm honest. Not only do you need to worry about inter-op issues between vendors, there is potential for problems when code changes over time. I'd rather not deal with that, especially since what Cisco are doing with IOS XE is simply a broken implementation. That said, if there is anyone out there who has done this and sees it as a solution to the problem, I'm sure this list would like to hear about it. > RPKI implementations should not touch best path selection. Dropping > RPKI invalids is the real use-case here, and if someones wants to > loc-pref based on RPKI status we should allow it (even if it doesn't > make a lot of sense), but having the RPKI implementation intervene in > the best path selection without the possibility to disable it is ... > frustrating. Agreed. At least, if IOS XE had a knob that could "set rpki [valid|notfound|invalid]" this would somewhat help. But alas, they don't :-(. You can only match on existing RPKI state. You cannot manually set RPKI state in IOS XE routing policy. I mean, how dumb is that? It's pretty presumptuous of Cisco to automatically apply policy for you re: RPKI in IOS XE, but then show they can do it right in IOS XR. Unreal! > > How much do you rely on "hot potato" routing for peers/transit and > customers? How does that work for you with RPKI unkowns? As above, we've disabled RPKI on all ASR1006 edge routers. It affects only 2 of our customers, so not an issue. I'll go through a few bottles of wine and some music this weekend as I summon up the energy to write to Cisco again to fix this. If I don't, I'll just keep sending money Juniper's way. Simple, and simpler! Mark.

3 3

AS16509 contacts in peering?
by Siyuan Miao 01 Feb '20

01 Feb '20

Hello, Anyone has peering contacts in AS16509 other than peering#amazon(dot)com? We'd like to establish peering with additional locations to balance the AnyCast traffic but unfortunately got no response in the last 6 months. Also, they forgot to update PeeringDB records on PTT Metro SP. Thanks,

1 0