雅典卫城开放式vswitch

• 喜欢
• 引用

\n

\nFor most use cases, keep in mind that in Nutanix, each node has full network access, such that (for example) a 3 node cluster would have (at minimum) 60 Gbits of bandwidth going into it (assuming 2x 10Gbits per node). That math, of course, goes up linearly with node count or with an increase in NIC speed (like 25\/40\/100g interfaces).

\n

\nFor folks like Service Providers, this makes more sense, so that they can shape the traffic of specific tenants or applications within a tenant, which is where we've been exploring this use internally.

\n

\nOn a related note, we're releasing service chaining with OVS in the very next release as part of the microsegmentation feature, which is quite interesting.","quoteUsername":"Jon","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用

\n

\nIn general, its not a problem due to the reasons I mentioned, given you've got copius amounts of bandwidth and live migration events are relatively rare in Nutanix. Stacked together with data locality, where reads are mostly kept off the network, those network adapters will be sitting at lower-ish utilization that you'd expect.

\n

\nWe're huge fans of the kiss principle here at nutanix, as most things \"just work\", which is quite nice.

\n

\nThat said, its good to know whats what and know the reasoning behind what we do, so I'd recommend checking out the AHV networking guide here: https:\/\/portal.nutanix.com\/#\/page\/solutions\/details?targetId=BP-2071-AHV-Networking:BP-2071-AHV-Networking<\/a>

\n

\nThat should give you some good background. After you read that, you'll find that you'll likely want to use either balance-slb or balance-tcp for load balancing policy on the OVS side, which does give you better load distribution than the default (active\/backup), which is the default simply because its the most compatible for almost anyones network setup, so its very easy to get going.

\n

\nEven if you kept the default though, you'll still have copius amounts of bandwidth that scales linearly per node.","quoteUsername":"Jon","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用

\n

\nhappy to help

\n- jon","quoteUsername":"Jon","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用

\nhttp:\/\/docs.openvswitch.org\/en\/latest\/faq\/configuration\/<\/a>

\n

\nTLDR - no, OVS doesn't support ERSPAN but does have some other tunneling technologies. Either way, we dont have that particular tunneling technology plumbed into our side, so we can't set up that tunnel automatically, etc","quoteUsername":"Jon","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用

\n

\nDoing an unsupported change like that would very likely break every time you do any sort of operation on a given VM, like power on\/power off, migration, high availability restarts, cloning, etc. This is because it would be a change that our control plane didn't program in, so it would just override it as it went about its business. Thats best case. Worst case, we haven't tested it, so we dont know any unintended side effects.

\n

\n

\nThat said - Could you expand on what you're hoping to accomplish here? I know what tech you're talking about, but I'm wondering what your specific use case is, so I can take it back to the team here.","quoteUsername":"Jon","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用

\nhttps:\/\/portal.nutanix.com\/#\/page\/docs\/details?targetId=AHV-Admin-Guide-v55:ahv-ahv-integrate-with-network-functions-intro-c.html<\/a>

\n

\nI'm working on a blog post to cover this use case. Here is an image to show how it would work. You can do an inline port or a tap port.

\n

<\/a><\/p>","quoteUsername":"bbbburns","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用

\nThe NFV I referred to is a special VM that runs on every single AHV host in the cluster. You provision this VM and mark it as an agent VM. Then you add it to a network function chain. This VM can run any OS that's supported on AHV, and you can decide whether to hook up a single interface as a tap, or multiple interfaces as inline.

\nThis NFV VM can receive, inspect, and capture in tap mode. In inline mode it can do these function AND decide to reject or transmit the traffic. In the example diagram above, imagine that VM as a Palo Alto Networks VM-Series firewall. I've also used the Snort IDS in my own lab.

\nWith this type of NFV configured in a network function chain, you can only capture traffic sent or received by VMs running on AHV. You cannot capture traffic sent by physical hosts, or send in ERSPAN type traffic to the NFV VM.

\n

\nIf you setup a regular VM on AHV, you can use this to receive ERSPAN traffic from outside sources, since all that's required is the IP address of the VM. It's up to you to decide what software you want to install inside this VM. You could use something as simple as tcpdump if you wanted, or you could install a VM with software from a 3rd party vendor for analyzing traffic.","quoteUsername":"bbbburns","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

• 喜欢
• 引用