Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
There's 69,055 pure /24's allocated or assigned directly from an RIRs. At least c,d,e, and g root servers only have /24s allocated to them. Major services like Cloudflare only advertise the /24 without advertising an aggregate. Unless you're also getting a default from upstream, it sounds like you're going to end up wasting the money you saved on chasing down subtle brokenness. On Mon, Oct 10, 2022, at 9:58 AM, Edvinas Kairys wrote: > Hello, > > We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has > 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it will > be not enough - so we're thinking to deny all /24s to save the memory. What > do you think about that approach - I know it could provide some misbehavior. > But theoretically every filtered /24 could be routed via smaller prefix /23 > /22 /21 or etc. But of course it could be a situation when denied /24 will > not be covered by any smaller prefix. > > What do you think about this approach ? > > Also maybe you know - some advices for edge routers that have at least 8x100G > interfaces and "good" memory for prefix count ? Thanks
Re: Verizon no BGP route to some of AS38365 (182.61.200.0/24)
Oddly enough I *do* see this via Verizon-but-XO: 182.61.200.0/22*[BGP/170] 3d 09:25:39, MED 100, localpref 100 AS path: 2828 4134 23724 38365 I, validation-state: unverified On Wed, Jul 20, 2022, at 3:18 PM, holow29 wrote: > > To follow up on this: > I've engaged Verizon's executive office to finally try to get to a network > engineer (because I don't have a contact myself). The (proxied) response from > the engineer was that they aren't receiving any announcements for these > routes to AS701, and I would need to take it up with Baidu. I guess I would > like to understand if that seems reasonable to people since it is my > presumption that Baidu would return and say something similar (that they > advertise their routes to their peers correctly and to take it up with > Verizon). To me, it seems like there is clearly a failing in one of Verizon's > peers where they are not advertising or accepting this route correctly, but > that it would be incumbent on Verizon to do the legwork to fix it since they > are the ones who know their peering agreements and have these contacts. > Unfortunately it seems like policy that Verizon pushes any issues that aren't > internal routing issues to an external party, but surely they have a > responsibility to maintain their peering and routes to external services as > well. In other words, this type of buckpassing does not seem right to me (and > I've heard it from them on other routing issues before), especially given > that they are the ones empowered to fix it. Any thoughts? > > (As it happens, pan.baidu.com now resolves to an IP range that is routable by > Verizon, but it could always revert, and it seems like Verizon should have > these routes regardless.) > > Thanks. > > On Fri, Jun 24, 2022 at 7:41 AM Matthew Huff wrote: >> From my limited vantage point it appears that there is some issue between >> Verizon & Baidu. Baidu has 182.61.0.0/16 registered, but is only advertising >> pieces of it globally (or at least from what I can see). In our tables,we >> are receiving none from Verizon of the subnets that are advertised directly >> from Baidu (origin AS of 38365). The few within that registered range that >> have a different origin AS are coming to us from Verizon. For example:__ >> __ __ >> *> 182.61.0.0/19144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.0.0/18144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.32.0/19 144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.64.0/18 204.148.121.2210 701 6453 >> 55967 i__ >> *182.61.128.0/23 204.148.121.2210 701 4134 4134 >> 4134 4134 4134 58540 ?__ >> *> 182.61.130.0/24 144.121.203.1410 46887 6461 >> 4134 23724 38365 38365 38365 i__ >> *> 182.61.130.0/23 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.131.0/24 144.121.203.1410 46887 6461 >> 4134 23724 38365 38365 38365 i__ >> *> 182.61.132.0/23 144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.132.0/22 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.134.0/23 144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.136.0/22 144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.136.0/21 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.140.0/22 144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.144.0/21 144.121.203.1410 46887 3356 >> 4134 58466 38365 i__ >> *> 182.61.144.0/20 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.160.0/19 204.148.121.2210 701 6453 >> 55967 i__ >> *> 182.61.192.0/23 144.121.203.1410 46887 3356 >> 4134 58540 i__ >> *> 182.61.194.0/23 144.121.203.1410 46887 3356 >> 4134 58540 i__ >> *> 182.61.200.0/22 144.121.203.1410 46887 6461 >> 4134 23724 38365 i__ >> *> 182.61.200.0/21 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.216.0/21 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.223.0/24 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> *> 182.61.224.0/19 144.121.203.1410 46887 6461 >> 4134 58466 38365 38365 i__ >> __ __ >> We are getting the 182.61.200.0/21 and 182.61.200.0/22 from all of our other >> peers:__ >> __ __ >> asr-inet2#sh ip bgp 182.61.200.0/21__ >> BGP routing table entry
Re: Disney+ Issues
The fact that it even has to come to this idea is ridiculous but I wonder about the success of holding a normal customer account with repeat offending streaming services so you could report this, by proxy, /as/ a customer. On Fri, Apr 29, 2022, at 8:38 AM, Josh Luthman wrote: > >Disney+ appear to be the worst outfit at handling this kind of thing: They > >have no concept of a service provider > > Aren't all of them that way? That's been my experience. Their front line > support often tells me to call my ISP. > > On Fri, Apr 29, 2022 at 9:35 AM Paul Thornton wrote: >> On 29/04/2022 14:22, Josh Luthman wrote: >> >> > Did you try: >> > >> > Disney+: E-mail them the trouble subnet at >> > techops-distribut...@disneystreaming.com. Also, >> > techops-servi...@disneystreaming.com will probably be where that sends >> > you. Another possible email is disneyplusispsupp...@disneyplus.com. >> > >> > https://thebrotherswisp.com/index.php/geo-and-vpn/ >> > >> >> We too are having the same issue - started suddenly around 6-8 weeks ago >> having worked fine for at least a year. I have no idea what they >> changed. Based on my first hand knowledge, these E-mail addresses go >> nowhere where anyone either can - or wants to - resolve issues. >> >> Disney+ appear to be the worst outfit at handling this kind of thing: >> They have no concept of a service provider wanting them to update an >> entire block - they are fixing this for individual customers who call >> them but we are calling them weekly, and E-mailing regularly too; but go >> around in circles where someone promises to call back having sorted it. >> This never happens. >> >> They also appear to use some opaque geoloc service (who themselves don't >> have a "you have this wrong" button) and really don't care that they are >> making life difficult for their paying customers! >> >> We have to keep telling new customers variations of "Yes, this is >> Disney's fault, no we can't fix it" which doesn't go down very well >> because "It worked fine with my previous provider, it must be your >> issue". Apart from suggesting they cancel their subscription because of >> Disney's incompetence there's not much else we can do :( >> >> >> I get that you have to appease rights holders and do this idiotic >> geolocation thing, because they are still obsessed with geographical >> boundaries in the 21st century. But if you are going to do this, can >> you please damned well fix *your* screwups when you get it wrong in a >> timely manner - or don't bother doing it at all. >> >> >> Paul. >>
Re: junos config commit question
You're correct.
This the lab setup and rstp was set to the default, so I only got the commit
check to pass only when I deleted [protocols rstp].
On Fri, Feb 11, 2022, at 8:09 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> Nick Suan via NANOG writes:
>> I was actually interested to see if the EX series would let me do this, and i
>> t turns out that if STP is enabled on any of the switch interfaces, it won't:
>> tevruden@core-02# commit check
>> [edit protocols rstp]
>> 'interface'
>> XSTP : Interface ge-0/0/0.0 is not enabled for Ethernet Switching
>> error: configuration check-out failed
>
> Do you have any rstp-specific overrides in your config? E.g. we
> have things like this in some of ours:
>
> rstp {
> interface ge-0/0/45 {
> cost 1000;
> mode point-to-point;
> }
> interface ge-1/0/45 {
> cost 1000;
> mode point-to-point;
> }
> interface ae4;
> bpdu-block-on-edge;
> }
>
> With the interfaces gone I would expect the commit check to fail.
>
> --lyndon
Re: junos config commit question
I was actually interested to see if the EX series would let me do this, and it
turns out that if STP is enabled on any of the switch interfaces, it won't:
tevruden@core-02# delete interfaces
{master:0}[edit]
tevruden@core-02# commit check
[edit protocols rstp]
'interface'
XSTP : Interface ge-0/0/0.0 is not enabled for Ethernet Switching
error: configuration check-out failed
{master:0}[edit]
tevruden@core-02# rollback
load complete
{master:0}[edit]
On Fri, Feb 11, 2022, at 4:18 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> On an EX4300 switch running JunOS 14.1 let's imagine I typed
>
> config
> delete interfaces
>
> before coming to my senses. How am I supposed to back out of that
> mess? For the life of me, after a week of reading the 3000 page
> reference manual, and endless DuckDuckGoing, I cannot see a simple
> way of just abandoning the commit. I've got to be missing something
> stunningly obvious here because it's unthinkable that this functionality
> doesn't exist. Help?!?
>
> The only way out I can see is to drop into the shell, make an
> uncompressed copy of juniper.conf.gz, then pop back into the config
> editor and load that over top of the editor's config view. Surely
> there's a saner way of dealing with this.
>
> --lyndon
Re: [EXTERNAL] Re: Flow collection and analysis
While I agree that, yes everything SHOULD support TLS, there's a perfectly good reason for terminating TLS in something like (nginx/caddy/apache/etc): X number of things supporting TLS on their web interface means X number of ways of configuring TLS. If I terminate it on nginx, there's only a single way: the nginx config, which is then farily easily leveraged into having a single set allowed protocols and ciphers. On Wed, Jan 26, 2022, at 9:33 AM, Mel Beckman wrote: > People who advocate TLS lash-ups like nginx front ends remind me of Mr. Beans > DIY automobile security, which started with a screwed-on metal hasp and > padlock, and then continued to a range of additional “layers”. Not > “defense-in-depth”, merely unwarranted “complexity-in-depth”: > > https://youtu.be/CCl_KxGLgOA > > > TLS is a standardized, fully open-source package that can be integrated into > even tiny IoT devices (witness this $10 WiFi module > https://www.adafruit.com/product/4201). The argument that people who want > intrinsically secure products can just bolt-on their own security are missing > the point entirely. Every web-enabled product should be required to implement > TLS and then let custiners decide when they want to enable it. Vendors who > are so weak that they can’t should have their products go straight into > /dev/null. > > -mel via cell > >> On Jan 26, 2022, at 6:51 AM, heasley wrote: >> >> Wed, Jan 26, 2022 at 07:21:19AM -0600, Mike Hammett: >> >>> Why is it [TLS] even necessary for such a function? >> >> confidentiality and integrity, even if you do not care about authentication. >> I am surprised that question is asked. >> >> The fewer things that are left unprotected, the better for everyone. those >> with concern about erosion of their privacy and human rights benefit from >> everything being protected, everywhere for everyone.
Re: Scanning activity from 2620:96:a000::/48
I've noticed something similar on two networks, however it appears to be trying to scan port 80: 13:30:26.387183 IP6 2620:96:a000::5. > 2620:135:5005:71::b0c.80: Flags [S], seq 2063829402, win 65535, length 0 13:30:26.393445 IP6 2620:96:a000::5. > 2620:135:5006:7::703.80: Flags [S], seq 2158423190, win 65535, length 0 13:30:26.430259 IP6 2620:96:a000::5. > 2620:135:500e:3d::804.80: Flags [S], seq 3284825109, win 65535, length 0 13:30:26.432115 IP6 2620:96:a000::5. > 2620:135:5007:2d7::a.80: Flags [S], seq 109350720, win 65535, length 0 13:30:26.460045 IP6 2620:96:a000::5. > 2620:135:5009:998::a.80: Flags [S], seq 3938745191, win 65535, length 0 13:30:26.515579 IP6 2620:96:a000::5. > 2620:135:500b:c92::6.80: Flags [S], seq 430848867, win 65535, length 0 13:30:26.516136 IP6 2620:96:a000::5. > 2620:135:5006:14::b0c.80: Flags [S], seq 515087951, win 65535, length 0 13:30:26.542392 IP6 2620:96:a000::5. > 2620:135:500a:67::30a.80: Flags [S], seq 2626838356, win 65535, length 0 13:30:26.547341 IP6 2620:96:a000::5. > 2620:135:500f:b30::f.80: Flags [S], seq 939521116, win 65535, length 0 13:30:26.549701 IP6 2620:96:a000::5. > 2620:135:500c:b::95.80: Flags [S], seq 1015131109, win 65535, length 0 13:30:26.557200 IP6 2620:96:a000::5. > 2620:135:5009:50::f5.80: Flags [S], seq 217447395, win 65535, length 0 On Tue, Jul 6, 2021, at 4:53 AM, Tore Anderson wrote: > A couple of hours after midnight UTC, the control plane policers for > unresolved traffic on a couple of our CE routers started being clogged with > ping-scanning activity from 2620:96:a000::/48, which belongs to «Internet > Measurement Research (SIXMA)» according to ARIN. > > Excerpt of this traffic (anonymised on our end): > > 11:21:05.016914 IP6 2620:96:a000::10 > 2001:db8:1234::f5:7a69: ICMP6, > echo request, seq 0, length 16 > 11:21:05.016929 IP6 2620:96:a000::10 > 2001:db8:1234::12:ba74: ICMP6, > echo request, seq 0, length 16 > 11:21:05.060045 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, > destination unreachable, unreachable address 2001:db8:1234::e7:f473, > length 64 > 11:21:05.060060 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, > destination unreachable, unreachable address 2001:db8:1234::d4:c4a3, > length 64 > 11:21:05.060419 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, > destination unreachable, unreachable address 2001:db8:1234::42:198a, > length 64 > 11:21:05.064464 IP6 2620:96:a000::10 > 2001:db8:1234::4a:d4cd: ICMP6, > echo request, seq 0, length 16 > 11:21:05.079645 IP6 2620:96:a000::10 > 2001:db8:1234::63:b58d: ICMP6, > echo request, seq 0, length 16 > 11:21:05.097337 IP6 2620:96:a000::10 > 2001:db8:1234::24:1038: ICMP6, > echo request, seq 0, length 16 > 11:21:05.111091 IP6 2620:96:a000::7 > 2001:db8:1234::8f:a126: ICMP6, > echo request, seq 0, length 16 > 11:21:05.124112 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, > destination unreachable, unreachable address 2001:db8:1234::e6:70fc, > length 64 > 11:21:05.124417 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, > destination unreachable, unreachable address 2001:db8:1234::bf:ca18, > length 64 > 11:21:05.137509 IP6 2620:96:a000::10 > 2001:db8:1234::12:f0df: ICMP6, > echo request, seq 0, length 16 > 11:21:05.142614 IP6 2620:96:a000::7 > 2001:db8:1234::8f:9ec6: ICMP6, > echo request, seq 0, length 16 > > While the CP policer did its job and prevented any significant operational > impact, the traffic did possibly prevent/delay legitimate address resolution > attempts as well as trigger loads of pointless address resolution attempts > (ICMPv6 Neighbour Solicitations) towards the customer LAN. > > We just blocked the prefix at our AS border to get rid of that noise. Those > ACLs are currently dropping packets at a rate of around 600 pps. > > I was just curious to hear if anyone else is seeing the same thing, and also > whether or not people feel that this is an okay thing for this «Internet > Measurement Research (SIXMA)» to do (assuming they are white-hats)? > > Tore > > > >
Re: Google IP Geolocation
The portal account isn't even the be all and end all of fixing this, we're telling google where our endpoints are explicitly with a geofeed, The portal says the clients are in the right location and for some reason it's still decided some of our IPs are on the other side of the world. On Sat, Apr 10, 2021, at 6:09 PM, Jared Mauch wrote: > I've had a similar issue in the past trying to get ready to peer with > them. I wanted portal access to look at things. I may yet post a > geofeed file just because. > > (I was also rejected a portal account, didn't escalate to friends at > google because I know my traffic is under a gig for now). > > - Jared > > Ps: Akamai can take geofeed if you have issues > > Sent from my TI-99/4a > > > On Apr 10, 2021, at 4:57 AM, Laura Smith via NANOG wrote: > > > > Yup. I've had this problem with Google for two years now. > > > > "We're Google. We know better than you. We're not interested in discussion. > > And no, you can't have access to the ISP portal you silly little person" > > .. is the summary of my experience. > > > > And all this is despite my network peering with Google over a major IXP. > > They *STILL* can't get the right geolocation despite having a direct > > peering session with us over the exchange ! > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐ Original Message ‐‐‐ > >> On Monday, 29 March 2021 21:12, Troy Kelly via NANOG > >> wrote: > >> > >> We've also been denied access to the ISP portal. > >> > >> When we replied as to why, we were told to not open another ticket. They > >> aren't interested in conversation. > >> > >> Sent from ProtonMail mobile > >> > >> Original Message > >>> On 30 Mar 2021, 6:53 am, Mike Hammett < na...@ics-il.net> wrote: > >>> > >>> I've had others at Google specifically say that portal should be used for > >>> that purpose, so maybe they need to make sure right and left hands know > >>> what the other is doing. > >>> > >>> - > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> > >>> Midwest-IX > >>> http://www.midwest-ix.com > >>> > >>> From: "Josh Luthman" > >>> To: "Christopher Morrow" > >>> Cc: nanog@nanog.org > >>> Sent: Monday, March 29, 2021 1:52:48 PM > >>> Subject: Re: Google IP Geolocation > >>> > >>> https://isp.google.com > >>> > >>> I signed up for an account there and they said: > >>> > >>> "Currently, the Google ISP portal is designed for our partners of GGC, > >>> PNI or IX programs. > >>> > >>> The access to portal is granted on request only to our partners." > >>> > >>> Josh Luthman > >>> 24/7 Help Desk: 937-552-2340 > >>> Direct: 937-552-2343 > >>> 1100 Wayne St > >>> Suite 1337 > >>> Troy, OH 45373 > >>> > On Mon, Mar 29, 2021 at 2:08 PM Christopher Morrow > wrote: > >>> > On Mon, Mar 29, 2021 at 1:59 PM Josh Luthman > wrote: > > > Google ISP specifically told me they didn't want to do deal with > > geolocation on the ISP portal. > > unsure who 'google isp' is here, but ... I think if you point at a > properly formed geo-location data file it'll get eaten and produce > proper results for you. > you do have to add that in your isp portal: > tri-pipe-thingy -> configuration -> IP geolocation > and /register feed/ button on that page. > > > > Josh Luthman > > 24/7 Help Desk: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Sat, Mar 27, 2021 at 3:28 PM Christopher Morrow > > wrote: > > > >> As a note, on the ISP portal there's a place to put a link to your > >> RFC8805 format geolocation feed... > >> these are scraped out 'regularly' and help keep things oriented better > >> for folks. > >> > >> the ietf noc folk use this method to tell google (and other folk who > >> scrape out our data) where meetings are before the meetings get there: > >> https://noc.ietf.org/geo/google.csv > >> > >> -chris > >> volunteer noc persona > >> > >> On Fri, Mar 26, 2021 at 6:43 PM Michael K. Spears > >> wrote: > >> > >>> Awesome, I think I’ve figured out the Google ISP portal signup, but > >>> it definitely seems semi-complicated in a way, notably finding the > >>> link… > >>> > >>> > >>> > >>> Thank you, > >>> > >>> Michael K. Spears > >>> > >>> 727.656.3347 > >>> > >>> > >>> > >>> From: Mike Hammett > >>> Sent: Friday, March 26, 2021 6:30 PM > >>> To: Michael K. Spears > >>> Cc: nanog@nanog.org > >>> Subject: Re: Google IP Geolocation > >>> > >>> > >>> > >>> We're working on a video to show people how to sign up for the ISP > >>> portal and get to that part of the portal once signed up. We'll drop > >>> a link to it near the Google
Re: telia - texas - 10:30 a.m. central time - issues ?
Not sure about Telia specifically, but there is apparently a fiber cut between Dallas and Waxahachie, that took out our wave service to Austin. Nick On Wed, May 27, 2020, at 12:41 PM, Aaron Gould wrote: > In the Texas area, particularly, south central, Austin area….. anyone know of > any issues with Telia Internet today around 10:32 a.m. central time ? > > I had good bgp session and good route 0/0 from them, but little to no > internet packets were flowing. > > -Aaron
Re: PCH.net down?
From everywhere I've tried, it connects but loads slowly. On Jul 21, 2010, at 8:44 AM, Jason Lewis wrote: This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net Anyone else?
