Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, 29 Sept 2023 at 08:24, William Herrin wrote: > Maybe. That's where my comment about CPU cache starvation comes into > play. I haven't delved into the Juniper line cards recently so I could > easily be wrong, but if the number of routes being actively used > pushes past the CPU data

Re: maximum ipv4 bgp prefix length of /24 ?

On Thu, Sep 28, 2023 at 9:54 PM Owen DeLong wrote: > > In principle, a company could make a business out of announcing a > > large block from a bunch of peering points and then tunneling (vpn) > > parts of it back to customers with sub-/24 assignments. With a broad > > enough selection of peering

Re: maximum ipv4 bgp prefix length of /24 ?

> > In principle, a company could make a business out of announcing a > large block from a bunch of peering points and then tunneling (vpn) > parts of it back to customers with sub-/24 assignments. With a broad > enough selection of peering points, the routing would not be too > inefficient. And

Re: maximum ipv4 bgp prefix length of /24 ?

On Thu, Sep 28, 2023 at 9:50 PM VOLKAN SALİH wrote: > multi-homed networks could also do default routing just packet-mark incoming > interface and then route packets out via same interface.. Take that to its logical conclusion and you'll invent MPLS. Regards, Bill Herrin -- William Herrin

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 28, 2023, at 21:14, VOLKAN SALİH wrote: > > IMO, No. ipv4 is not dead yet. we need to raise it, a bit. > Agree to disagree… We need to put the final stake through its heart and move on. > EINAT solutions are OK > I presume you mean CGNAT? Otherwise, not sure what EINAT is and

Re: maximum ipv4 bgp prefix length of /24 ?

On Thu, Sep 28, 2023 at 2:25 PM VOLKAN SALİH wrote: > I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 > instead of limiting maximum length to /24.. > > It is because BGP research and experiment networks can not get /24 due to > high IPv4 prices, but they have to get

Re: maximum ipv4 bgp prefix length of /24 ?

CIDR and aggregation in the early 1990s was developed in response to AGS+ routers falling over under the strain of the global size back then. Since then, IPv4 has been a progressive loosing proposition and only gets worse every year. This proposal could certainly accelerate the rate at which it

Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need? Owen > On Sep 28, 2023, at 14:25, VOLKAN SALİH wrote: > > hello, > > I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 > instead of limiting maximum length to /24.. > > I also believe that RIRs and LIRs should

Seattle-area centurylink (residential fiber) on the list?

Howdy, Is anyone from Centurylink in the Seattle area on the list? Would you mind contacting me offlist? My residential fiber has been bouncing for a few hours. I figured it was something physical and scheduled a technician, but on closer examination I'm seeing something weird with the PPPoE. It

Re: maximum ipv4 bgp prefix length of /24 ?

Wasn't it about 1997 or so when we ran into deployed Cisco gear (5500s back then) running out of memory for BGP routes? Been there, done that. -Joe On Thu, Sep 28, 2023 at 7:41 PM Jon Lewis wrote: > On Fri, 29 Sep 2023, VOLKAN SALİH wrote: > > > I believe, ISPs should also allow ipv4 prefixes

Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, 29 Sep 2023, VOLKAN SALİH wrote: I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32

maximum ipv4 bgp prefix length of /24 ?

hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of

Legal system as a weapon (was Re: AFRINIC placed in receivership)

Somewhat related (at least one of the principals is the same) and perhaps of interest to some here. While I have strong opinions on the topic, provided without comment: https://www.gofundme.com/f/supporting-and-protecting-internet-governance Regards, -drc > On Sep 13, 2023, at 6:27 PM, Bryan

Fwd: RADb will migrate to IRRdv4 on October 30, 2023

Dear all, Please see the below announcement, I think this is really good news! RPKI-based filtering at large databases and mirror services like RADB really helps take the sting out of potentially harmful RPKI-invalid IRR route objects. This will positively impact operators who use bgpq3, irrpt,

Re: Test Lab Best Practices

I love the built-in Wireshark capability in EVE-NG. BTW, EVE-NG Community is free. You just have to get images for anything you want to emulate. Virtual images for various vendor products are sometimes freely available, with trail licenses. For instance Junipers vMX was freely available for

Re: Test Lab Best Practices

On Thu, Sep 28, 2023 at 10:14:24AM -0400, Kenneth Vedder wrote: Hello NANOG, We have been struggling with firmware bugs from a specific router vendor. I am looking to set up a test lab of our core network and a few remote site routers. Protocols would include SR-MPLS, ISIS, EVPN MPLS and L3VPN

Re: Test Lab Best Practices

++ all that was said thus far. Physical equipment with console access is the best way to test software/firmware issues. As for virtualization, it's great for expanding your topology quickly. Use a virtual bridge in GNS3 or EVE-NG and you can make your smaller footprint physical lab into a

Re: Test Lab Best Practices

I agree with others here... Physical lab - gotta have console server for the most control - perle console server is good, and also good ole fashion cisco terminal server (2509/2511 or 2600 with asynch module) Virtual labs are great for testing features and functionality - Juniper vLabs -

Re: Test Lab Best Practices

Appliance virtualization is perfectly acceptable for a lot of things. But there are large sets of problems that you will never catch that way. To the OP : With respect to 'strategies' : 1. Test something to make sure it works. 2. Then test it to see where and how it breaks. Lots of people do

Re: Test Lab Best Practices

If you're able to virtualize some of these appliances, almost any virtualization platform can be setup to connect nodes together. However I really enjoy using Eve-ng . It's a network virtualization web app that can be deployed on bare metal or in a VM. It lets you diagram,

Re: Test Lab Best Practices

In any lab,I find concurrent access to serial ports is still an essential diagnostic tool. In a pinch you can get a used Cisco 2811 for $100, but there are multiport devices from lots of vendors. These let you SSH into the server and then connect to any serial port, giving you separate serial

Test Lab Best Practices

Hello NANOG, We have been struggling with firmware bugs from a specific router vendor. I am looking to set up a test lab of our core network and a few remote site routers. Protocols would include SR-MPLS, ISIS, EVPN MPLS and L3VPN with a little OSPF sprinkled in. I'd be grateful for any tips or

Re: Contact for Hulu

Digital Element helped promptly last time, it was mainly with Hulu Live. ipad...@hulu.com has helped before, but they didn't last time when Digital Element did. https://www.digitalelement.com/contact-us/ Hope this helps! On 9/27/23 11:46 AM, Brad Bendy wrote: Can anyone at Hulu contact me

Re: Contact for Hulu

I would also be thankful for a contact at Hulu, we've been having similar issues to what Brad described. Ken V Amplex Internet On Thu, Sep 28, 2023 at 8:00 AM wrote: > Send NANOG mailing list submissions to > nanog@nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit