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.
