ovs-vsctl add-port hostInterface hostveth tag=9. This command adds hostveth to bridge and also the packets coming out of hostveth are tagged with vlan id 9. I'm looking for similar commands for linux bridge
My setup is
hostInterface(bridge) -> hostvethpair -> ns1vethpair(another namespace)
hostinterface and hostvethpair are is same default namespace but ns1vethpair in different namespace.
I want packets coming out of hostvethpair to be tagged with vlan id and these tagged packets should be sent to bridge. Im able to achieve this with ovs bridge using above command. Is there any command that can do the same in Linux bridge. If so, can you share an example?
Thanks in advance
I think I got the solution for what i'm looking for. It can be done via bridge vlan filtering rules. (bridge vlan add).
Related
I have one network connection on my Macbook Pro. It is configured by my ADSL modem by DHCP. That modem is on 192.168.1.1 . I also have a cable modem connected to the network. I switched its DHCP server off. It is on 192.168.1.254 .
How can I connect to a URL using the cable modem?
I think I have to set up a vlan which I then can use by setting the localAddress option of http.request. Am I right?
Ok, I found out that it is not possible with one ethernet interface. So I bought another usb to ethernet adapter. Now one is configured by DHCP. The other is configured by hand. In node I use the localAddress to set which interface to use.
I'm trying to implement vlans on a target programmatically.
But first I wanted to set up vlans manually to help get a better understanding of vlan setup. So I setup a vlan manually on my development system (ubuntu) using the vconfig/ifconfig command combination, but using the same command combination on the intended target doesn't work.
Both systems use the same 8021q driver so the method of informing the lower level Ethernet driver of the vlan info should be the same (I would think). After looking at the vlan driver source it appears that it collects the vlan info and adds the info the sk_buff structure which is eventually passed to the ethernet driver, but it's not obvious where the vlan magic is suppose to happen (ethernet driver or 8021q driver).
I looked at the source for the target system’s ethernet driver and it supports an ioctl method of setting up a vlan. But this does not seem like the conventional way that Linux sets up a vlan in the ethernet driver.
By what mechanism does the vlan driver (8021q.ko) tell the Ethernet hardware about a vlan?
Is it a special api call to the ethernet driver to set up a vlan in hardware, or should the vlan driver be adding the vlan tags to the packet?
Any info on vlan implementation would also be helpful too.
Can someone explain in detail what are the differences of veth pairs and tap interfaces and how these devices connect to linux bridge or openvswitch.
I found this:
"Veth is a special net devices which were created in pair, I consider it as a method to change the traffic's direction, that is, when the out direction traffic is sent to veth device from Linux protocol stack, it was sent to another its mirror veth device, so the mirror one treats it as a in direction traffic and put it back to Linux protocol stack for further usage.
Tap device is logical net device but have different with any other one: it allows user space program directly injecting traffic into Linux protocol stack, as well as it can retrieve traffic from the stack. It opens a tunnel to Linux protocol stack at level 2(or tun device at level 3) in user space, the stack will consider data from user space as in direction traffic"
but it didn't gave me the whole picture.
thanks in advance!
Linux tap interfaces created with ip tuntap cannot be used to attach network namespaces to linuxbridges or the openvswitch so we need to depend upon veth pair.
Virtual Ethernet interfaces come in pairs, and they are connected like a tube—whatever comes in one veth interface will come out the other peer veth interface.
As a result, you can use veth interfaces to connect a network namespace to the outside world via the “default” or “global” namespace where physical
interfaces exist.
A TAP device, such as vnet0 is how hypervisors such as KVM and Xen implement a virtual network interface card (typically called a VIF or vNIC).
An Ethernet frame sent to a TAP device is received by the guest operating system.
The purpose of these virtual networking artifacts are similar. But there are subtle differences and hence they are used in different circumstances:
TAP: The user-space application/VM can read or write an ethernet frame to the tap interface and it would reach the host kernel, where it would be handled like any other ethernet frame that reached the kernel via physical (e.g. eth0) ports. You can potentially add it to a software-bridge (e.g. linux-bridge)
VETH: Typically used when you are trying to connect two entities which would want to "get hold of" (for lack of better phrase) an interface to forward/receive frames. These entities could be containers/bridges/ovs-switch etc. Say you want to connect a docker/lxc container to OVS. You can create a veth pair and push the first interface to the docker/lxc (say, as a phys interface) and push the other interface to OVS. You cannot do this with TAP.
Please note that we should not misconstrue that we need to use VETH and not tap when using the OVS. We can always create the internal ports in OVS which behave exactly like the tap interface. But this is not always possible, for instance when you want to connect to an entity that cannot synthesise a tap-like interface. I.e.:
$ ovs-vsctl add-port ovs-switch-name tap0
Now you can use tap0 like we use the tap interfaces.
I am working on an embedded Linux project. It has a cell modem that comes up as ppp0 and a single Ethernet interface eth0 that may or may not be connected. The cable could be unplugged at any time from eth0 or may never be plugged in.
Is it possible to setup multicasting so that it could intelligently send the outgoing traffic over eth0 if it's up, otherwise over ppp0? If so I would be very interested on how to do this.
Thanks,
Fred
I have the following problem. My PC is very old and it has a built in ethernet port that doesn't work, not due to a misconfiguration, I think it's physically damaged. It didn't work in either Ubuntu or even on Windows. I have an ethernet PCI card which is the one I use. The problem is, for some odd reason, the card that does works sometimes changes from eth0 to eth1 and I have to run dhcpd as I don't always get an IP via DHCP. Now, the actual question is, is there some way to disable the card that doesn't work using its MAC address or something? I can't disable either eth0 or eth1 as I'm sure it's not always "pointing" to the same card.
Are they the same kind of chipset or different ones?
If they are differnt then probably the simplest solution would be to just blacklist the modules for that Ethernet chipset.
You will first need to find the module name (this is for eth0):
dmesg | grep eth0
See if you have something like the following:
[ 2.209295] r8169 0000:05:00.0: eth0: RTL8168d/8111d at 0xffffc90000c6e000, 00:24:1d:11:b6:64, XID 081000c0 IRQ 44
In my case 'r8169' is the module name. You can also see a list of currently loaded modules with 'lsmod' so check that it appears in there.
Next you need to black list the module. There is an entry on the Arch wiki for that.
Fellow archer here; I have a method I use to disable my nVidia graphic card's HDMI port audio chip based on its hardware pci id; perhaps you could apply the same approach to your nic:
Find the ethernet's pci id:
$ lspci | grep Eth
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
Find the corresponding directory:
$ find /sys/devices -name *00:19.0
/sys/devices/pci0000:00/0000:00:19.0
There should be a file named "remove" in that directory.
You can disable the device at startup by editing /etc/rc.local
echo 1 > /sys/devices/pci0000:00/0000:00:19.0/remove
On second thought; this may not work in your case if modules get loaded prior to /etc/rc.local finishing... it would do you little good to have /dev/eth0 and /dev/eth1 assigned in the "wrong" order and then have /etc/rc.conf disable one of them... you could still end up with your prefered nic as eth1. This used to be a problem with alsa on multiple sound cards so methods were devised to assign the numbering of the cards via module parameters. Perhaps the module itself allows this?
I'm gathering from your description this in an onboard NIC. The best solution would be to disable it in the motherboard BIOS rather than the OS. The method for this varies by manufacturer but I'm sure you could find a manual for your model online somewhere.
I'm confused it didn't show up: In case you don't need the low level solution proposed by cjpembo, you can just use
ip link set dev <interface name> down
You get them via ip link show.