alex_saroyan

BTW, this was a brownfield use case for bringing VPC networking into an existing physical network without requiring major changes.

We have solution for Equinix Metal, where we consume Equinix API, and underlying pluming happens automatically. + we have a greenfield solution when we operate underlying leaf-spine fabric end-to-end.

Happy to dive/discuss further. Love networking!

Ha, good question. 1) Integration with Rancher, as well as with Vmware are on the roadmap.

2) underlying vlans: you don't plumb every time, you create a range of vlans (vlan 600-700 for example) and allow that range on the ports that are looking towards Netris and towards hypervisors (switchport trunk allowed vlan 600-700). It's a one-time and basic configuration, which network admins would typically do in any case to enable some vlans for server virtualization platform. Then you let Netris know what are the allowed vlans and that's it. Your switch will move packets based on mac address and vlan id, switches are good on that. While Netris will pick next available vlan (from allowed range) for every V-NET.

Hi, our team at Netris been working on this solution for a while to help DevOps folks skip networking challenges in on-prem, colo, bare metal cloud, and edge.

Kelsey and I recorded this webinar recently. I thought i would be interesting for the group here.

Happy to take questions and hear all/any feedback!

Right. We instruct Kernel to reserve 8 CPU cores exclusively for our user space application that is responsible for traffic forwarding.

Here's performance results. Max latency is 0.31 msec.

####################################################

min_latency_ns: 708

avg_latency_ns: 63723

max_latency_ns: 310795

jitter_ns: 30940

####################################################

Regarding L3 PFC support. In my understanding it's a ROCE requirement. I view RoCE as east-west traffic, since its not leaving the boundaries of the switch fabric, I think non-blocking leaf/spine fabric should be sufficient there. Please correct me if'm missing something.

SoftGate, the Linux router where we use DPDK, is designed for North/South traffic, sitting on the border of the data center, so we don't expect RoCE traffic there, but again, please let me know if you see it differently.

Thanks.

Our customers are operating private cloud deployments, running Linux on network switches, and on their SoftGate nodes.

Linux made its place to the data center networking. We need to spread this knowledge further to make Linux Networking mainstream.

eBPF is awesome. Container networking inside the server is the best place for eBPF networking.

For data center border networking (border router, full routing table, Layer-4 load balancing, NAT, VPN) DPDK enables us to push the boundaries of Linux Networking, squeezing 100Gbps / 30Mpps out of one server. It's performance comparable with Cisco ASR and Juniper MX specialized hardware.

The Linux router + Linux switches, wrapped into Netris automatic NetOps software enables users to operate their on-prem network with cloud-like experience. Plugging in their favorite tools like Kubernetes, Terraform, etc.

You can hook a DPI into Netris operated network, yes.

We leverage DPDK & SmartNIC to accelerate Layer-3 routing to 100Gbps / 30Mpps with 1M routes in the routing table.

This approach allows for border router, NAT, L4LB functionality with performance comparable to Cisco ASR / Juniper MX routers.

100Gbps / 30Mpps - border router, on $5000 Linux server and decent SmartNIC. (Alternative to $20-200K Cisco ASR/Juniper MX routers)

Native integration with Kubernetes and Terraform, designed for modern cloud practitioners, DevOps, and NetOps folks.

Cloud-like, self-operating, functionality.

We commonly see, online entertainment providers, online ad providers, AI/ML companies, Edge & private cloud builders.

Every company that builds a private cloud or edge can easily adopt this technology. It's designed for cloud practitioner, DevOps, and NetOps engineers in mind.

thanks, i'm glad it's helpful.

>> Expose default type of services (ClusterIP) external > What's the use case of this? ClusterIP, by API definition, is used within the cluster. If I need to expose something to external, I use a LoadBalancer service.

Exactly! You use service of the type LoadBalancer to expose something to the public Internet. You need something that will respond to your LoadBalancer request.

While Metallb is a nice tool for small clusters. Netris offers a way of leveraging open source ecosystem but provide a production grade cloud-like LoadBalancer service together with bunch of other essential things you will need when you are building a private cloud.

What is your use-case?

Thanks for bringing this up.

Metallb is a good product for small use cases. When you consider production, something scalable to 10s 100s or 1000s of nodes then:

auto-add: Every time you add/remove k8s node, you need to tweak your BGP configs to add/remove BGP neighbor (both on Metallb and your router/switch)

ip-address-sharing: MetalLB can share Ip address only when backends are the same, it isn't pure IP address sharing

What do you think?