Re: Low to Mid Range DWDM Platforms
Finally, the name came to me :-): https://www.xkl.com/ Looks like they are still in business. Mark. On 10/6/23 16:02, Mark Tinka wrote: On 10/6/23 15:52, Dave Bell wrote: Smartoptics? https://smartoptics.com/ Not them. I want to say they had an "X" in their name, but memory is fuzzy. Mark.
Re: Low to Mid Range DWDM Platforms
On 06/10/2023 16:07, Mike Hammett wrote: I have found that for low end DWDM solutions, https://www.packetlight.com/ has always been the cheapest available. Regards, Hank I've been using various forms of passive WDM for years. I have a couple different projects on my plate that require me to look at the next level of platform. In some projects, I'll be looking for needing to have someone long distances of glass without any electronics. Some spans could be over 60 miles. In some projects, I'll need to transport multiple 100-gig waves. What is the landscape like between basic passive and something like a 30 terabit Ciena? I know of multiple vendors in that space, but I like to learn more about what features I need and what features I don't need from somewhere other than the vendor's mouth. Obviously, the most reliability at the least cost as well. Thanks. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com
Re: maximum ipv4 bgp prefix length of /24 ?
On Sat, Oct 7, 2023 at 9:27 AM Willy Manga wrote: > Hi. > > On 06/10/2023 16:00, nanog-requ...@nanog.org wrote: > > From: Matthew Petach > [...] > > > > There's significantly less pressure to deaggregate IPv6 space right now, > > because we don't see many attacks on IPv6 number resources. > > Once we start to see v6 prefix hijackings, /48s being announced over /32 > > prefixes to pull traffic, then I think we'll see IPv6 deaggregation > > completely swamp IPv4 deaggregation. > > How about we educate each other to not assume you must deaggregate your > prefix especially with IPv6? > If you're the victim of a prefix hijacking, you don't really have a choice. Right now, that's the only way to try to counteract a prefix hijacking; to advertise something at least as specific as the prefix being hijacked, or smaller if possible. I see 'some' (it's highly relative) networks on IPv4, they 'believe' > they have to advertise every single /24 they have. And when they start > with IPv6, they replicate the same mindset with a tons of /48 . You can > imagine what will happen of course. > > A better alternative IMHO is to take advantage to the large prefix range > and advertise a sub-aggregate when necessary. But absolutely not each > end-node or customer prefix. > Absolutely. Right up the moment someone hijacks part of your IP space. And then you announce a bunch of more specifics to try to counteract the hijacking. If you're a good, responsible network, you remove the more specific prefixes once the hijacking is done. If you're most networks, you're overworked, understaffed, and cleanup is at the bottom of the priority list, so you just leave them being announced, just in case someone tries to hijack your space again. Most cases of deaggregation I've seen are the result of an event that took place that triggered it, not just because people don't know better. Now, RPKI can help a little bit, at least with protecting you from accidental route leaks and unintended hijacks; but it only validates the ASN originating the prefix, it doesn't validate the full pathway. So, being a determined hijacker, I'm going to set my router up to pretend to be the correct origin ASN, and announce more specifics, adjusting the AS-PATH to match what my neighbors and upstreams expect to see, and utter silent thanks that most networks use a relatively liberal "max length" for the prefixes in their ROAs (just in case *they* need to announce more specifics to counteract my hijacking effort). As we crack the BGP path validation nut, and put some means in place to validate BGP adjacencies, this attack vector will fade away, and the need to be able to announce more specifics willy-nilly will slowly go by the wayside. But for the moment, it's just as necessary in IPv6 as it is in IPv4, though the resulting impact is less, because wise networks allocate their IPv6 prefixes in a sparse manner, meaning that during a hijack event, you only need to announce the matching /48s for the blocks carrying relevant traffic, which should be a small fraction of your overall v6 assignment. I completely agree that we should educate network engineers to only advertise the largest prefix possible that covers your space. But I also realize that in the world of non-secured BGP adjacencies and non-validatable BGP AS-PATHs, we cannot fault people for having to deaggregate during prefix hijacking events. Thanks! Matt
FastNetMon Usage in the wild
Hi, I wanted to drop a quick question as I would like to evaluate the FastNetMon solution to do DDoS protection and wanted to see what other companies are using it out there so I can have a base of how much should I recommend this. Thanks in advance for your responses Kind regards, Javier Gutierrez,
Re: maximum ipv4 bgp prefix length of /24 ?
On 10/7/23 14:32, Willy Manga wrote: How about we educate each other to not assume you must deaggregate your prefix especially with IPv6? I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course. A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix. There are a number of operational reasons folk de-aggregate. I do agree that there is some behaviour around de-aggregating by default in IPv4 that transferred to IPv6. But the main issue is that most people only consider the state of their own FIB situation. They hardly consider the FIB state of other network operators around the world. As an operator, you have to consciously decide that you will not de-aggregate any of your allocations. Of course, there is a cost to that as well, so that cannot be ignored. We, for example, do not de-aggregate any of our allocations (AS37100), but we can afford to do so because we always ensure all peering and transit exit/entry points have the same bandwidth (TE being the main reason networks de-aggregate). Not all shops can afford that. Network operations workshops abound where we teach about de-aggregation, when it can be necessary, and why it should generally be avoided unless in the most extreme of circumstances. However, in real life, even engineers that have been through the workshop ringer tend to prefer to de-aggregate without caution to the FIB state of other autonomous systems. That said, I do agree that, perhaps, network operations workshops could emphasize the reluctance to unnecessarily de-aggregate in light of the increasing cost of having to maintain FIB's. Mark.
Re: maximum ipv4 bgp prefix length of /24 ?
Hi. On 06/10/2023 16:00, nanog-requ...@nanog.org wrote: From: Matthew Petach [...] The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in an essentially unmanaged system. Were you expecting it to be lower than IPv4? Mark. I've dug through the mailman mirror on nanog.org, and there's currently no post by Geoff Huston saying that: https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest I read (and send) NANOG emails through the digest emails sent once a day. I noticed the same thing . I assumed it was sent directly to Mark (or the mail will enter my next digest...) But I'll play along. There's significantly less pressure to deaggregate IPv6 space right now, because we don't see many attacks on IPv6 number resources. Once we start to see v6 prefix hijackings, /48s being announced over /32 prefixes to pull traffic, then I think we'll see IPv6 deaggregation completely swamp IPv4 deaggregation. How about we educate each other to not assume you must deaggregate your prefix especially with IPv6? I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course. A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
