Generally accepted BGP acceptance criteria?
If you need to support RTBH you need to check prefix list (thus IRR) first, then the RTBH , then RPKI. Otherwise blackhole route gets dropped before executing.
Allegedly Tier 1s in Wikipedia
6762 became transit free some 15 years ago while I was still working there.
Re: Tell me about AS19111
> "Ronald" == Ronald F Guilmette writes: Ronald> Try to think of a word that is the absolute antonym of "hygiene" and Ronald> that's the global routing table. Ronald> This stuff would be funny if only it wasn't so sick and pathetic. Ronald> Even if we forget about all of the morons who are -using- these invalid Ronald> ASNs for actually routing bits to their IPs, you have to ask yourself: Ronald> Who are all of the morons who are -peering- with these invalid ASNs? Ronald> Regards, Ronald> rfg Ronald> P.S. Remember, out of all of the networking engineers in the entire world, Ronald> by definition, half of them are of below average intelligence. You would sound much more credible if you'd step down the high horse and stop insulting the very same people you're supposed to work with. plonk --
RE: 99% of HK internet traffic goes thru uni being fought over?
On 21 November 2019 23:48:33 CET, "Mahmutovic, Jas" wrote: >Excerpt from http://www.hkix.net/hkix/Presentation/forum20100129.pdf >(Page 3) > > Two Main Sites for resilience > >•HKIX1: CUHK Campus in Shatin >•HKIX2: CITIC Tower in Central > > We are confident to say that because of HKIX, more than 99% intra--HK >Internet traffic is kept within HK > > And this is a completely different thing than saying that 99% of HKG traffic passes through HKIX. Written this way it may as well be true since it only means that it neatly complements whatever transit and private peering arrangements the local operators have. Exercise for the reader: - find out who the local access providers are - find where they peer and at what capacity - find who gives them transit - try some traceroutes After this you'll concur with my original assessment about the nitrates content of the statement at subject -- Pierfrancesco Caci
Re: 99% of HK internet traffic goes thru uni being fought over?
On 19 November 2019 22:43:34 CET, b...@theworld.com wrote: > >Is this plausible? > Organic manure -- Pierfrancesco Caci
Re: AS4134/AS4847 - Appear to be hijacking some ip space.
Looks like they stopped already, I'm not seeing this on 3491 nor on
routeviews anymore.
Pf
>>>>> "Christopher" == Christopher Morrow writes:
Christopher> Howdy gentle folks:
Christopher> It looks like AS4847 - "China Networks Inter-Exchange"
Christopher> Is taking some time to announce reachability for at least:
Christopher> 136.38.33.0/24
Christopher> which they ought not, given that this /24 is part of a /11
assigned to
Christopher> AS16591 (google fiber)... Looking at routeviews data, I see the
Christopher> following as-paths for this one /24:
Christopher> $ grep -A1 Refresh /tmp/x | grep 4847
Christopher> 1239 174 4134 4847
Christopher> 3549 3356 174 4134 4847
Christopher> 701 174 4134 4847
Christopher> 4901 6079 3257 4134 4847
Christopher> 20912 174 4134 4847
Christopher> 1221 4637 4134 4847
Christopher> 1351 11164 4134 4847
Christopher> 6079 1299 4134 4847
Christopher> 6079 3257 4134 4847
Christopher> 7018 4134 4847
Christopher> 6939 1299 4134 4847
Christopher> 3561 209 4134 4847
Christopher> 3303 4134 4847
Christopher> 3277 39710 9002 4134 4847
Christopher> 2497 4134 4847
Christopher> 4826 1299 4134 4847
Christopher> 54728 20130 23352 2914 4134 4847
Christopher> 19214 3257 4134 4847
Christopher> 101 101 11164 4134 4847
Christopher> 1403 6453 4134 4847
Christopher> 852 6453 4134 4847
Christopher> 1403 6453 4134 4847
Christopher> 286 4134 4847
Christopher> 1273 4134 4847
Christopher> 57866 3491 4134 4847
Christopher> 3267 1299 4134 4847
Christopher> 49788 174 4134 4847
Christopher> 53767 3257 4134 4847
Christopher> 53364 3257 4134 4847
Christopher> 8283 57866 3491 4134 4847
Christopher> 7660 2516 4134 4847
Christopher> From that I think the following AS should have filtered this
prefix and are not:
Christopher> $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' |
awk
Christopher> '{print $NF}' | sort -n | uniq
Christopher> 174 - Cogent
Christopher> 209 - Qwest
Christopher> 286 - KPN
Christopher> 1273 - Vodafone
Christopher> 1299 - Telia
Christopher> 2497 - IIJ
Christopher> 2516 - KDDI
Christopher> 2914 - NTT
Christopher> 3257 - GTT
Christopher> 3303 - Swisscom
Christopher> 3491 - PCCW
Christopher> 4637 - Telstra
Christopher> 6453 - TATA
Christopher> 7018 - ATT
Christopher> 9002 - RETN
Christopher> 11164 - Internet2
Christopher> It'd be great if the listed folk could filter AS4134 :)
Christopher> -Chris
--
Pierfrancesco Caci, ik5pvx
Re: a quick survey about LLDP and similar
Thank you both for the feedback. I left out the "it depends" because it is more suited to a conversation or email thread like this than to a quick survey. I'm aware of a few reasons for which "it depends" and I'm learning a few more from the feedback I'm getting. Pf >>>>> "Eddie" == Eddie Parra writes: Eddie> +1 on it depends. IMO, I would prefer LLDP vs. a vendor proprietary Eddie> discovery protocol. Where you intend to run it in your network is a Eddie> major factor for risk. Eddie> Also, you forgot to add LLDP-MED to #5 (but it might not be relevant Eddie> to your services). Eddie> -Eddie >> On Feb 28, 2019, at 1:27 AM, Owen DeLong wrote: >> >> The problem with your survey is that there’s no option to answer “it depends”. >> >> Hard yes or no answers aren’t realistic to the questions you’re >> asking because the context, >> security parameters, sensitivity, and other parameters about the >> network all factor into a >> decision whether to run or not run such protocols. >> >> There are some environments where the benefit and convenience is >> moderately high >> and the risk is extremely low. There are other environments where >> the benefit is relatively >> low, but the risks are significantly higher. >> >> Owen >> >> >>> On Feb 28, 2019, at 01:00 , Pierfrancesco Caci wrote: >>> >>> >>> Hello, >>> having a bit of a debate in my team about turning on LLDP and/or CDP. >>> I would appreciate if you could spend a minute answering this >>> survey so I have some numbers to back up my reasoning, or to accept >>> defeat. >>> >>> https://www.surveymonkey.com/r/TH3WCWP >>> >>> Feel free to cross-post to other relevant lists. >>> >>> Thank you >>> >>> Pf >>> >>> -- >>> Pierfrancesco Caci, ik5pvx >> -- Pierfrancesco Caci, ik5pvx
a quick survey about LLDP and similar
Hello, having a bit of a debate in my team about turning on LLDP and/or CDP. I would appreciate if you could spend a minute answering this survey so I have some numbers to back up my reasoning, or to accept defeat. https://www.surveymonkey.com/r/TH3WCWP Feel free to cross-post to other relevant lists. Thank you Pf -- Pierfrancesco Caci, ik5pvx
Re: Long AS Path
>>>>> "Mel" == Mel Beckman <m...@beckman.org> writes: Mel> Why not ask the operator why they are pretending this path? Perhaps Mel> they have a good explanation that you haven't thought of. Blindly Mel> limiting otherwise legal path lengths is not a defensible practice, in Mel> my opinion. Mel> -mel beckman A prepend like that is usually the result of someone using the IOS syntax on a XR or Junos router. Long ago, someone accidentally prepending 255 times hit a bug (or was it a too strict bgp implementation? I don't remember) resulting in several networks across the globe dropping neighbors. One has to protect against these things somehow. As a data point, here is how many prefixes I see on my network for each as-path length, after removing prepends: aspath length count - 0: 340 1: 47522 2: 292879 3: 227822 4: 58390 5: 10217 6: 2123 7: 638 8: 48 9: 58 11: 20 12: 2 So, does your customer have a legitimate reason to prepend more than 5 times? Maybe. I still think that anyone that does should have their BGP driving licence revoked, though. Pf -- Pierfrancesco Caci, ik5pvx
Re: Amsterdam/London Underesea Cables
>>>>> "Rod" == Rod Beck <rod.b...@unitedcablecompany.com> writes: Rod> Hi, Rod> I am trying to determine which undersea cables used for Rod> London/Amsterdam traffic are the most reliable - fewest outages due to Rod> shunt faults and other problems. I'm surprised repeaters are needed at all, the Channel is not that wide after all. -- Pierfrancesco Caci, ik5pvx
Re: NetFlow - path from Routers to Collector
>>>>> "Roland" == Roland Dobbins <rdobb...@arbor.net> writes: Roland> On 2 Sep 2015, at 0:08, Steve Meuse wrote: >> Your advice is not "one size fits all". Roland> Actually, it is. Roland> Large backbone networks have DCNs/OOBs, and that's where they export Roland> their NDE. 2 out of 2 large backbone networks I've experience with use inband for flow export. -- Pierfrancesco Caci, ik5pvx
Re: Low-numbered ASes being hijacked? [Re: BGP Update Report]
Simon == Simon Leinen simon.lei...@switch.ch writes: Simon Some suspicious paths I'm seeing right now: Simon 133439 5 Simon 197945 4 my bet is on someone using the syntax prepend asnX timesY on a router that instead wants prepend asnX asnX -- Pierfrancesco Caci, ik5pvx
Re: Someone from PCCW NOC here ?
Carlos == Carlos Martinez-Cagnazzo carlosm3...@gmail.com writes: Carlos Hi all, Carlos We'd appreciate having someone from PCCW, particularly from their operation Carlos in Panama, having contact us. Private is fine. Carlos A downstream customer from them in Panama has been observed hijacking some Carlos prefixes. Carlos regards Please report to our noc (usnoc at pccwglobal.com) with details. Pf
Re: L3 announces new peering policy
Jay Ashworth j...@baylink.com wrote: In the wake of their GBLX acquisition, Level 3 has announced (already) what its new peering policy will be, in this press release posted at Telecom Ramblings: http://newswire.telecomramblings.com/2011/10/level-3-announces-new-policy-for-internet-protocol-interconnection/ Says all and nothing. -- Pierfrancesco Caci
Re: Why is your company treating IPv6 turn ups as a sales matter?
:- William == William Herrin b...@herrin.us writes: Hiya folks, Why are your respective companies treating IPv6 turn ups as a sales matter instead of a standard technical change request like IP addresses or BGP? Sprint and Qwest, I know you're guilty. How many of the rest of you are making IPv6 installation harder for your customers than it needs to be? For us, SLAs are not guaranteed for IPv6 yet, hence we want customers to acknowledge that. This is bound to change sometime in the near future of course. Pf -- --- Pierfrancesco Caci | Network System Administrator - INOC-DBA: 6762*PFC p.c...@seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/
Re: d000::/8 from AS28716
:- James == James Hess mysi...@gmail.com writes: On Tue, Jan 12, 2010 at 1:33 AM, Pierfrancesco Caci p.c...@seabone.net wrote: .. Maybe next time drop me a line when it's happening, I don't see the route from the customer now. Can still be seen on routeviews... a ghost route, perhaps? Yes. -- --- Pierfrancesco Caci | Network System Administrator - INOC-DBA: 6762*PFC p.c...@seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/
Re: d000::/8 from AS28716
:- Chuck == Chuck Anderson c...@wpi.edu writes: d000::/8 *[BGP/170] 01:08:26, MED 760, localpref 200 AS path: 30071 6762 28716 I to 2001:4830:e1:10::1 via ge-0/0/0.593 I fail to see how this could have gone through this: ipv6 prefix-list AS28716-V6-IN: 1 entries seq 5 permit 2001:1BD0::/32 unless Every IPv6 prefix list, including prefix lists that do not have any permit and deny condition statements, has an implicit deny any any statement as its last match condition is not true for this particular IOS release, or the router just went nuts. Maybe next time drop me a line when it's happening, I don't see the route from the customer now. Pf -- --- Pierfrancesco Caci | Network System Administrator - INOC-DBA: 6762*PFC p.c...@seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/
Re: Does Internet Speed Vary by Season?
:- Hank == Hank Nussbacher h...@efes.iucc.ac.il writes: http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion -Hank There are TXCOs and OXCOs inside equipment for a reason. And rubidium lamps as well, sometimes. Seasonal variations in usage from the end customers are a fact of life, instead. If your net is large enough you can even spot the different habits about vacations, holidays and whatnot across the different regions. Pf -- --- Pierfrancesco Caci | Network System Administrator - INOC-DBA: 6762*PFC p.c...@seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/
Re: Internet partitioning event regulations
:- Lamar == Lamar Owen [EMAIL PROTECTED] writes: Charles Wyble [EMAIL PROTECTED] wrote: Lamar Owen wrote: There are three ways that I know of (feel free to add to this list) to limit the events: 1.) As you mentioned, regulation (or a government run and regulated backbone); Right. But what do we want this to look like? Well, since I've already stepped out on a limb, here goes my try at a rough outline of what such a regulation might look like (with the caveat that this is likely too simple to actually make it as a regulation): [...] 2.) Allocate regulatory responsibility and enforcement authority to an entity. I would suggest the FCC would be appropriate. (This outline might then be the start of a 47 CFR 221 or similar). [...] 6.) Mandate that all transit-free Internet carriers shall maintain peering arrangements with all other transit-free Internet carriers to maintain a complete Internet (citing some law that makes a 'complete Internet' a national security matter, or somesuch, and belongs in 47 CFR 221 as a result). [...] 8.) Authorize the issuance of a 'Tier 1 Internet Provider' license (that must be renewed periodically, with documentation supporting the Tier 1 status) to participating transit-free Internet carriers (for a fee to cover the opex). 9.) Authorize the FCC's Enforcement Bureau to enforce. err... do you realize there's about 6.4 * 10^9 other people outside of the USA, don't you? -- --- Pierfrancesco Caci | Network System Administrator - INOC-DBA: 6762*PFC [EMAIL PROTECTED] | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/ Linux clarabella 2.6.15-29-server #1 SMP Mon Sep 24 17:37:57 UTC 2007 i686 GNU/Linux
Re: Peering - Benefits?
:- HRH == HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP [EMAIL PROTECTED] writes: internet exchanges are not per-se redundant depends on your concept of redundancy. they basically are a switch which actually, because of the many connected parties, most of which do not have enough PAID transit to cover any outages on it, causes more problems than they are good for. depends who you peer with, and your comment on the IX being a switch depends on which IX you connect to. (the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here) How many of the outages at AMS-IX really affected you directly? or weren't they rather limited to a bunch of your peers? And you know that you can get multiple links to separate switches in different location, don't you? Same goes for DE-CIX, LINX, the various Equinix, PAIX etc... internet exchanges usually are some sort of hobby computer club, you I think your choice of which internet exchanges to join has some flaws. cannot rely on them to actually -work-, but when they do work that's nice (always make sure you have enough paid capacity to cover for it when they do not work however!) no, always make sure you have N+1 redundancy with a particular peer in dispersed locations. or N+2 if you can afford the capex. peering on only one of them therefore does not make your network more reliable in any way (it becomes a different story when you connect to like 10 or so worldwide). as for peering agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others). those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc). you will find that most peering contracts or agreement have nice clauses to terminate the peering at some agreed notice, as well as a whole host of clauses that give the peering manager the power to say no if he feels so. -- HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. Minister of Telecommunications, Republic CyberBunker. ok, you're a troll and I bit... -- Pf
