Re: Longest prepend( 255 times) as path found
On Thu, Aug 25, 2022 at 10:58 AM Tom Beecher wrote: > If I was running an edge device with a limited FIB, perhaps >I might drop it to save memory. If I had beefier devices, perhaps >I would just depref it. Hi Tom, Neither of these answers make much sense to me. If you're using a default route to overcome a limited FIB, you want a more reliably chosen set of routes to filter than the stray error route that shouldn't have reached you. Nearly all paths on the Internet are still under 64 hops wide (packet TTL of 64) so finding a non-customer route with more than double that number of elements in the AS path suggests someone tried to do something fancy in a local environment and it leaked. Not only is it reasonably safe to discard such routes, long AS paths have been responsible for triggering bugs in multiple BGP implementations. Failing to filter it may actually be harmful to folks downstream from you. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Re: Longest prepend( 255 times) as path found
> > If I was running an edge device with a limited FIB, perhaps I might drop > it to save memory. If I had beefier devices, perhaps I would just depref > it. > Note that if said prefix either existed elsewhere with fewer prepends that meant it 'won' bgp best-path selection, then it would not result in any difference in the FIB. The FIB is where the 'winning' prefixes go as fully-resolved things from the RIB, but the RIB too would not have it, as an alternative won in BGP. And even if you depref'd it in BGP, it would still be there in the control-plane, consuming the same amount of RAM. Reject it for excess prepends is likely the best choice.
Anyone with the FAA around, VOR-DME circuit related.
Greetings, Anyone with the FAA around by chance, needing to speak to someone regarding a circuit we provide to a specific VOR-DME. We normally deal with L3Harris though that avenue has gone unanswered. Appreciate any help anyone can provide. Luke
Re: U.S. Court PACER system overloaded by public interest
You can reproduce the document by taking a blank sheet of paper and a fat sharpie and coloring it black. :). -richey. On Fri, Aug 26, 2022 at 2:34 PM Anne Mitchell wrote: > For anyone wanting the document and unable to get it through Pacer, we > have it locally and I'm happy to make it available, just let me know. > > > On Aug 26, 2022, at 12:07 PM, Sean Donelan wrote: > > > > > > > > Having some experience with documents of extreme public interest, and > web sites getting overloaded (Starr Report on President Clinton, 1998)... > > > > its nice to see government web sites still get overloaded several > decades later. > > > > "PACER Service Under Fire After Trump Affidavit Crash Reports" > > > > PACER is the electronic document system used by the U.S. Court System. > >
Re: U.S. Court PACER system overloaded by public interest
PACER Gave me something to do, while waiting on hold for Disney Reservations making family vacation plans for next year, listening to Disney music on a loop :-) On Fri, 26 Aug 2022, Anne Mitchell wrote: For anyone wanting the document and unable to get it through Pacer, we have it locally and I'm happy to make it available, just let me know. On Aug 26, 2022, at 12:07 PM, Sean Donelan wrote: Having some experience with documents of extreme public interest, and web sites getting overloaded (Starr Report on President Clinton, 1998)... its nice to see government web sites still get overloaded several decades later. "PACER Service Under Fire After Trump Affidavit Crash Reports" PACER is the electronic document system used by the U.S. Court System.
Re: U.S. Court PACER system overloaded by public interest
* amitch...@isipp.com (Anne Mitchell) [Fri 26 Aug 2022, 20:36 CEST]: For anyone wanting the document and unable to get it through Pacer, we have it locally and I'm happy to make it available, just let me know. By now it's so widely available that even DuckDuckGo can find it for you. Not readers of The Guardian, though; the newspaper posted a brief update on their website that read "The affidavit is now out. It is here." and linked to https://file///Users/Shared/Internet%20Downloads/gov.uscourts.flsd.617854.102.1_1.pdf . (It's still there as I write this.) -- Niels.
Re: U.S. Court PACER system overloaded by public interest
For anyone wanting the document and unable to get it through Pacer, we have it locally and I'm happy to make it available, just let me know. > On Aug 26, 2022, at 12:07 PM, Sean Donelan wrote: > > > > Having some experience with documents of extreme public interest, and web > sites getting overloaded (Starr Report on President Clinton, 1998)... > > its nice to see government web sites still get overloaded several decades > later. > > "PACER Service Under Fire After Trump Affidavit Crash Reports" > > PACER is the electronic document system used by the U.S. Court System.
U.S. Court PACER system overloaded by public interest
Having some experience with documents of extreme public interest, and web sites getting overloaded (Starr Report on President Clinton, 1998)... its nice to see government web sites still get overloaded several decades later. "PACER Service Under Fire After Trump Affidavit Crash Reports" PACER is the electronic document system used by the U.S. Court System.
Weekly Global IPv4 Routing Table Report
This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net. For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith . IPv4 Routing Table Report 04:00 +10GMT Sat 27 Aug, 2022 BGP Table (Global) as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 907997 Prefixes after maximum aggregation (per Origin AS): 342169 Deaggregation factor: 2.65 Unique aggregates announced (without unneeded subnets): 438559 Total ASes present in the Internet Routing Table: 73597 Prefixes per ASN: 12.34 Origin-only ASes present in the Internet Routing Table: 63163 Origin ASes announcing only one prefix: 25995 Transit ASes present in the Internet Routing Table: 10434 Transit-only ASes present in the Internet Routing Table:397 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 55 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 955 Number of instances of unregistered ASNs: 955 Number of 32-bit ASNs allocated by the RIRs: 40061 Number of 32-bit ASNs visible in the Routing Table: 33252 Prefixes from 32-bit ASNs in the Routing Table: 159101 Number of bogon 32-bit ASNs visible in the Routing Table:12 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:507 Number of addresses announced to Internet: 3068908416 Equivalent to 182 /8s, 235 /16s and 211 /24s Percentage of available address space announced: 82.9 Percentage of allocated address space announced: 82.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.6 Total number of prefixes smaller than registry allocations: 308313 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 236904 Total APNIC prefixes after maximum aggregation: 67404 APNIC Deaggregation factor:3.51 Prefixes being announced from the APNIC address blocks: 232031 Unique aggregates announced from the APNIC address blocks:96215 APNIC Region origin ASes present in the Internet Routing Table: 12900 APNIC Prefixes per ASN: 17.99 APNIC Region origin ASes announcing only one prefix: 3733 APNIC Region transit ASes present in the Internet Routing Table: 1760 Average APNIC Region AS path length visible:4.7 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 8141 Number of APNIC addresses announced to Internet: 773150720 Equivalent to 46 /8s, 21 /16s and 88 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-151865 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:264812 Total ARIN prefixes after maximum aggregation: 120921 ARIN Deaggregation factor: 2.19 Prefixes being announced from the ARIN address blocks: 265108 Unique aggregates announced from the ARIN address blocks:127764 ARIN Region origin ASes present in the Internet Routing Table:19052 ARIN Prefixes per ASN:
Re: AS701 anycasts any IP?
On Fri, Aug 26, 2022 at 5:49 AM Bjoern Franke via NANOG wrote: > > Hi, > while investigating an issue I was wondering a german IP was only 1-2 > hops away from some RIPE Atlas Probes connected via AS701. > > It seems at least probe #50235 and #54508 see any IP directly as next > hop, as an example here with the IP of mailop.org: > the 2 probes are in boston, mass vs new york, new york. The endpoint appears to be closer to the boston probe (54508). >From virginia/wdc the endpoint is ~100ms away and in ~germany. (the last hop I see says anx84, which might be norway... 'not boston' though) Is it possible that 701's seeing a local copy of the /24? looking at their lookingglass for ping/bgp data from billerica, ma (boston adjacent): 91.132.144.0/22 (2 entries, 1 announced) *BGPPreference: 170/-96 Age: 2w2d 6:44:09 Metric: 10 Metric2: 500502 Announcement bits (4): 0-KRT 3-RT 10-BGP_RT_Background 11-Resolve tree 5 AS path: 1299 47147 197540 I (Originator) PING 91.132.147.157 (91.132.147.157): 56 data bytes 64 bytes from 91.132.147.157: icmp_seq=0 ttl=55 time=102.899 ms curious results though :) > https://atlas.ripe.net/measurements/44133927/ > > Regards > Bjoern > > >
AS701 anycasts any IP?
Hi, while investigating an issue I was wondering a german IP was only 1-2 hops away from some RIPE Atlas Probes connected via AS701. It seems at least probe #50235 and #54508 see any IP directly as next hop, as an example here with the IP of mailop.org: https://atlas.ripe.net/measurements/44133927/ Regards Bjoern
