Proper isolation of a Linux bridge
TL;DR: when configuring a Linux bridge, use the following commands to enforce isolation:
# bridge vlan del dev br0 vid 1 self # echo 1 > /sys/class/net/br0/bridge/vlan_filtering
A network bridge (also commonly called a “switch”) brings several Ethernet segments together. It is a common element in most infrastructures. Linux provides its own implementation.
A typical use of a Linux bridge is shown below. The hypervisor is
running three virtual hosts. Each virtual host is attached to the
br0 bridge (represented by the horizontal segment). The hypervisor
has two physical network interfaces:
eth0is attached to a public network providing various services for the virtual hosts (DHCP, DNS, NTP, routers to Internet, …). It is also part of thebr0bridge.eth1is attached to an infrastructure network providing various services to the hypervisor (DNS, NTP, configuration management, routers to Internet, …). It is not part of thebr0bridge.
The main expectation of such a setup is that while the virtual hosts should be able to use resources from the public network, they should not be able to access resources from the infrastructure network (including resources hosted on the hypervisor itself, like a Continue reading
Hello world!
Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
Kubernetes networking 101 – Services
In our last post we talked about how Kubernetes handles pod networking. Pods are an important networking construct in Kubernetes but by themselves they have certain limitations. Consider for instance how pods are allocated. The cluster takes care of running the pods on nodes – but how do we know which nodes it chose? Put another way – if I want to consume a service in a pod, how do I know how to get to it? We saw at the very end of the last post that the pods themselves could be reached directly by their allocated pod IP address (an anti-pattern for sure but it still works) but what happens when you have 3 or 4 replicas? Services aim to solve these problems for us by providing a means to talk to one or more pods grouped by labels. Let’s dive right in…
To start with, let’s look at our lab where we left at the end of our last post…
If you’ve been following along with me there are some pods currently running. Let’s clear the slate and delete the two existing test deployments we had out there…
user@ubuntu-1:~$ kubectl delete deployment pod-test-1 deployment "pod-test-1" Continue reading
How to decide between cloud, on-premise and As-a-Service
Although vendor-written, this contributed piece does not advocate a position that is particular to the author’s employer and has been edited and approved by Network World editors.
Deciding whether and how to use cloud computing is a complex, and made all the more complicated by the overwhelming number of vendors and products. What’s more, hybrid and multicloud approaches blur the lines between the cloud and on-premise deployment options.
With an operations team that counsels organizations on which type of architecture is best for them – on premise, cloud, hybrid or multicloud – and then evaluates what went well and didn’t in all four kinds of deployments, here’s our view of what situations tip the scale toward one approach or another. While the context is data storage, this analysis applies to most enterprise IT scenarios.
To read this article in full or to leave a comment, please click here
Worth Reading: Microsoft’s Open Approach to Networking
The post Worth Reading: Microsoft’s Open Approach to Networking appeared first on 'net work.