Re: Friday Thanks
Sorry, NTT, I didn't mean to leave you out, you were great too - Thanks. From: NANOG on behalf of Graham Johnston via NANOG Sent: Friday, August 11, 2023 10:53 AM To: nanog@nanog.org Subject: Friday Thanks I've been busy over the last few days trying to clean up IRR information for our subnets and issue ROAs for our address space. Invariably I came across stale entries in various IRR databases. They aren't really hurting me, but I feel like there shouldn't be competing incorrect information out there that I'm not in control of. The database maintainers have been mixed in their response so far. This email isn't about name and shame though, I'm not at that point. Instead, I want to provide thanks to two organizations that have been very responsive and easy to deal with in getting records cleaned up. RADb - Thank you. Level3/CenturyLink/Lumen - Thank you. Separately, I know there is some work to do with ARIN's recent RPKI/IRR changes, but as someone from a regional ISP, rather than a national or multi-national ISP, I can say that the tools are moving in the right direction. The experience right now is better than it was several years ago. Thank you ARIN for the improvements and the dedication to work with us on making further improvements. Have a good weekend, Graham
Friday Thanks
I've been busy over the last few days trying to clean up IRR information for our subnets and issue ROAs for our address space. Invariably I came across stale entries in various IRR databases. They aren't really hurting me, but I feel like there shouldn't be competing incorrect information out there that I'm not in control of. The database maintainers have been mixed in their response so far. This email isn't about name and shame though, I'm not at that point. Instead, I want to provide thanks to two organizations that have been very responsive and easy to deal with in getting records cleaned up. RADb - Thank you. Level3/CenturyLink/Lumen - Thank you. Separately, I know there is some work to do with ARIN's recent RPKI/IRR changes, but as someone from a regional ISP, rather than a national or multi-national ISP, I can say that the tools are moving in the right direction. The experience right now is better than it was several years ago. Thank you ARIN for the improvements and the dedication to work with us on making further improvements. Have a good weekend, Graham
RE: Akvorado Resource Requirements
Thanks, Vincent, I appreciate the feedback. Regards, Graham -Original Message- From: Vincent Bernat Sent: Friday, March 24, 2023 2:35 PM To: Graham Johnston ; nanog@nanog.org Subject: Re: Akvorado Resource Requirements On 2023-03-24 15:01, Graham Johnston via NANOG wrote: > For anyone running Akvorado, can you please comment on resource requirements. > I'm most concerned with CPU and memory, with the assumption that resources > are somewhat linear to flow rate, but also curious about disk usage > secondarily. A VM with 64 GB, 24 vCPU can sustain about 100k flows/s. 1 TB seems enough to keep data for about 5 years at 30k flows/s with the default setup. This is however highly dependent on how well your flows can be compressed. The main table with the default retention can use around 600 GB by itself. The data compresses well outside of the main table. You should test on your setup and let it run for a few days. You can check how much space each table uses and extrapolate depending on the TTL set on each table.
Akvorado Resource Requirements
For anyone running Akvorado, can you please comment on resource requirements. I'm most concerned with CPU and memory, with the assumption that resources are somewhat linear to flow rate, but also curious about disk usage secondarily. Thanks, Graham
EVPN-VXLAN Service Types
Good day, NANOG. I'm at the front end of an expected implementation of EVPN-VXLAN as the primary method to shift a network that is largely based on traditional Ethernet switching and spanning-tree to one that attempts to route traffic as often as possible, and where we want to separate the physical topology from the logical services. We are selecting EVPN-VXLAN as it seems to inherently provide for the Network Virtualization Overlay function, as well as routing since the entire underlay will be routed. As part of all the reading we are doing, and lab testing that is just about to commence, I'm trying to weigh the options around VLAN-based services and VLAN-aware bundle services. I know that the options aren't mutually exclusive, and that I can mix and match, at least I expect that this to be an option. In case it matters, our implementation will initially involve VTEPs based on a mix of Juniper QFX5100, QFX5110, QFX5120, and EX4650 switches, as well as MX. Yes, I do recognize the RIOT capabilities that aren't present in the QFX5100. From a basic FIB standpoint, we do believe that we are well below the quote limits in terms of hosts, routes, etc. I do believe that we've effectively weighed the use of VXLAN over MPLS. We currently believe that our use cases don't require some of the more advanced features and control knobs available in MPLS. We are also pragmatic and are trying to use the equipment that we have. We believe that the Trident ASICs in our devices are likely better suited for VXLAN than MPLS, despite the glossy datasheets quoting support for various MPLS features. Feel free to comment on this. For internal use, I can see the VLAN-aware bundles as advantageous to group all our own services together in a single MAC-VRF, treat ourselves as a tenant. I'm not clear yet if I should be concerned or not about each switch that is involved in this EVI having to populate all entries into FIB. Our own use cases are likely of a small enough scale that it wouldn't matter in comparison to the positive outcomes. As for customer use cases, I can't yet see an advantage to VLAN-aware bundles as our customers don't interact with multiple VLANs where those individual VLANs are terminating on individual VTEP ports. The customer use cases feel more like a traditional Q-in-Q type activity that has us treating them as single outer VLAN, and thus the VLAN-based service seems more appropriate. I'm flat out ignoring the middle ground option of VLAN-bundle service as I can't see anything that seems compelling compared to the other two. I know there is bunch that I don't know here. Am I focusing on the right two choices of the three service types? Do organizations regularly use both two that I am focusing on? How do you decide between the two models when provisioning an EVI? What gotchas await me with the Juniper equipment, or the Trident ASICs, that just aren't spelled out in the documentation? Answers to these questions and anything else you have to offer is appreciated. Thanks in advance, Graham
