I have the network configuration as follows
I have tried to ping 192.168.1.100 to 192.168.1.101 and it succeeds.
I have tried to ping 192.168.50.100 to 192.168.50.101 which is on vlan 50 and it fails.
The simulation diagram showed arp is not being forwarded from switch1 to switch2.
I have configured both the sides of switch to trunk.
I am just learning on vlans and trunking.
Can anybody please explains what is the configuration I am missing?
If i remove switch1 and connect switch0 to switch2 everything works fine.
EDIT
Switch0 vlan configuration.
Switch1 vlan configuration.
Switch2 vlan configuration
You have to add at switch0 and switch2 in the assigned ports, in my case:
Switch0(config-if)#int fastEthernet0/2
Switch0(config-if)#switchport access vlan 50
Switch0(config-if)#switchport mode access
Switch2(config-if)#int fastEthernet0/3
Switch2(config-if)#switchport access vlan 50
Switch2(config-if)#switchport mode access
You can also add vlan 50 to switch1 (I don't know how you have it).
Switch1(config)#vlan 50
Switch1(config-vlan)#name VLAN0050
Switch1(config-vlan)#exit
Switch1(config)#
where the Ethernet cable connects from the PC to the switch.
As you can see PC0 goes to PC2 successfully and PC1 goes to PC3 successfully.
Write This Command on Switch 0 & 2 :
Switch#configure terminal
Switch(config)#vlan 50
Switch(config-vlan)#name test
Switch(config-vlan)#exit
Switch(config)#interface fastEthernet 0/2
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 50
Switch(config-if)#exit
Switch(config)#interface fastEthernet 0/3
Switch(config-if)#switchport mode trunk
Switch(config-if)#exit
Switch(config)#exit
Switch#write memory
Switch 1 :
in Switch 1 You Must Define Vlan's or You Can Delete This Switch and Connect Switch 0 & 2 Direct With Trunk or You Have Anoter Option Like VTP mode .
Whatever This Command Write On Switch 1 :
Switch(config)#interface fastEthernet 0/1
Switch(config-if)#switchport mode trunk
Switch(config-if)#exit
Switch(config)#interface fastEthernet 0/2
Switch(config-if)#switchport mode trunk
Switch(config-if)#exit
Switch(config)#vlan 50
Switch(config-vlan)#name test
Switch(config-vlan)#exit
Switch(config)#exit
Switch#write memory
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
Improve this question
System: Host: rpi32 Kernel: 5.15.56-v7+ armv7l bits: 32 Console: tty 0 Distro: Raspbian GNU/Linux 11 (bullseye)
Machine: Type: ARM Device System: Raspberry Pi 3 Model B Rev 1.2 details: BCM2835 rev: a22082 serial: 000000009a5073f1
I had a working machine before the upgrade, ntp, dhcp (is actually isc-dhcpserver), dns all working.
Then upgraded the OS (to Bullseye) and could no longer connect to the rPi.
dmesg revealed that eth0 could not be connected to.
The interface was identified as enxb827eb5073f1. en = Ethernet plus MAC address.
Some research revealed that what I am seeing is called "Predictable Network Interface Names".
It said this is the new standard/approach, due to multi-interface machines not necessarily assigning the interface name at kernel boot; e.g., it could be eth0 on one boot, and eth1 during another; not good for firewalls, etc.
So I changed the following config files to get dhcp working:
/etc/default/isc-dhcp-server
/etc/network/interfaces
/etc/dhcp/dhcpd.conf
... and changed eth0 to enxb827eb5073f1.
No luck.
sudo service dhcpcd status
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/dhcpcd.service.d
└─wait.conf
Active: failed (Result: exit-code) since Fri 2022-08-19 15:04:18 AEST; 28min ago
Process: 859 ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w (code=exited, status=6)
CPU: 11ms
Aug 19 15:04:18 rpi32 systemd[1]: Starting dhcpcd on all interfaces...
Aug 19 15:04:18 rpi32 dhcpcd[859]: Not running dhcpcd because /etc/network/interfaces
Aug 19 15:04:18 rpi32 dhcpcd[859]: defines some interfaces that will use a
Aug 19 15:04:18 rpi32 dhcpcd[859]: DHCP client or static address
Aug 19 15:04:18 rpi32 systemd[1]: dhcpcd.service: Control process exited, code=exited, status=6/NOTCONFIGURED
Aug 19 15:04:18 rpi32 systemd[1]: dhcpcd.service: Failed with result 'exit-code'.
Aug 19 15:04:18 rpi32 systemd[1]: Failed to start dhcpcd on all interfaces.
and
dhcpd -t /etc/dhcp/dhcpd.conf
/etc/dhcp/dhcpd.conf: interface name too long (is 20)
Researching this topic pointed to incorrect dhcpd config, pointing to udev rules, and I do not understand, and from what I could see, did not contain interface reference.
I read here: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ that this naming scheme can be reverted by adding this: net.ifnames=0 to the kernel command line (/boot/cmdline.txt).
This is what I did. I reverted all changes in the three config files listed above, plus in the cmdline.txt.
(I rebooted as required after these changes.)
and dhcpd -t /etc/dhcp/dhcpd.conf still returns:
/etc/dhcp/dhcpd.conf: interface name too long (is 20)
All services work, except dhcp (ntp is back up as well, as no changes where made here WRT eth0 changes).
Now I wonder what else I need to do to get dhcp working again.
Config files:
ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.8 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:50:73:f1 txqueuelen 1000 (Ethernet)
RX packets 14682 bytes 1148952 (1.0 MiB)
RX errors 0 dropped 3460 overruns 0 frame 0
TX packets 7079 bytes 1063400 (1.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 105 bytes 10173 (9.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 105 bytes 10173 (9.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
cat /etc/default/isc-dhcp-server
# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
#DHCPDv6_CONF=/etc/dhcp/dhcpd6.conf
# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
DHCPDv4_PID=/var/run/dhcpd.pid
#DHCPDv6_PID=/var/run/dhcpd6.pid
#OPTIONS=""
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
#INTERFACESv4="enxb827eb5073f1"
INTERFACESv4="eth0"
#INTERFACESv6=""
cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
cat /etc/dhcp/dhcpd.conf
# 190803-1530 installed DHCP server on rPi32
#
# 170611-1933 MaxG: changed from none to interim
#ddns-update-style none;
ddns-update-style interim;
# 170612-2300 MaxG: added based on
# https://blog.bigdinosaur.org/running-bind9-and-isc-dhcp/
ddns-updates on;
update-static-leases on;
ddns-domainname "argylecourt.lan";
ddns-rev-domainname "in-addr.arpa.";
authoritative;
# 190804-1424 MaxG: added key and 2 zones
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
# Important: Replace this key with your generated key.
# Also note that the key should be surrounded by quotes.
secret "someKeyBlah";
};
zone argylecourt.lan. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 1.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
# 150301 MaxG - added to shut up Windows PC from clogging
# syslog with DHCPACK and DHCPINFORM msgs (WPAD)
option wpad-url code 252 = text;
# my subnet specifications
subnet 192.168.1.0 netmask 255.255.255.0 {
#interface enxb827eb5073f1;
# pool range; can have multiple ranges in this file
range 192.168.1.50 192.168.1.199;
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
ddns-domainname "argylecourt.lan";
ddns-rev-domainname "in-addr.arpa";
option broadcast-address 192.168.1.255;
option domain-name "argylecourt.lan";
option domain-name-servers 192.168.1.8;
option ntp-servers 192.168.1.8; # Default NTP server to be used by DHCP clients
default-lease-time 86400; # 1 day
max-lease-time 604800; # 7 days
option wpad-url "\n";
}
# reservations; must NOT be in pool
# sorted by assinged IP address
host maxg-x570 {
# MaxG's PC -- x570
# added 20220409-2106
hardware ethernet 04:42:1a:95:2b:37;
fixed-address 192.168.1.13;
}
host brother-mfc {
# Brother Network Printer -- BRN_368926
hardware ethernet 00:80:77:36:89:26;
fixed-address 192.168.1.33;
ddns-hostname "brothermfc8820d";
}
I ran into the same situation and was not able to tell where the mistake was.
try $ dhcpd /etc/dhcp/
this will search the whole file and will point directly where the mistake is
Well, well... how embarrassing!
The solution is simple:
sudo service isc-dhcp-server start
Start the correct service. It is not dhcp, it is isc-dhcp-server!
What I do not understand is why this service was no longer auto-starting.
Anyway, problem, or rather stupidity solved.
I am trying to detect packets with a VLAN tag. I have some PCAP files to containing VLAN tagged packets to test. A Wireshark screenshot of a sample packet:
After reading some tutorials, I wrote the following code:
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/in.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>
#define bpf_printk(fmt, ...) \
({ \
char ____fmt[] = fmt; \
bpf_trace_printk(____fmt, sizeof(____fmt), \
##__VA_ARGS__); \
})
SEC("xdpvlan")
int myxdpprogram(struct xdp_md *ctx) {
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;
struct ethhdr *eth = data;
if ((void*)eth + sizeof(*eth) <= data_end) {
bpf_printk("h_proto is: 0x%x, ETH_P_8021Q is: 0x%x\n", bpf_ntohs(eth->h_proto), ETH_P_8021Q);
}
return XDP_PASS;
}
char _license[] SEC("license") = "GPL";
The output in /sys/kernel/debug/tracing/trace is like this:
bpf_trace_printk: h_proto is: 0x800, ETH_P_8021Q is: 0x8100
I expected:
bpf_trace_printk: h_proto is: 0x8100, ETH_P_8021Q is: 0x8100
I am using Fedora 34 to test, kernel version: 5.11.12-300.fc34.x86_64.
Why the h_proto is not equal to 0x8100?
Update
I have two VMs, and I am using tcpreplay to send packets (PCAP file) from one VM to the other VM that has the eBPF program. VMs are connected through a host-only interface. I load the program using:
ip link set dev ens37 xdpgeneric obj xdp_vlan_kern.o sec xdpvlan
[EDIT] Not sure this answer is correct, have a look at the comments for details.
Generic XDP, or SKB-mode XDP, is an XDP mode that was primarily added for experimenting with XDP (and to provide a model for future driver-based implementations). Given that it requires no support from the NIC driver, it is easier to use, but has lower performance than the other modes (driver/native XDP or XDP hardware offload).
One consequence of not having driver support is that the hook for generic XDP is necessarily higher in the networking stack when compared with native XDP. Generic XDP runs after the socket buffer (SKB) has been allocated. This means that some processing may already have occurred on your packets. In your case, the networking stack has already decapsulated the packets from their VXLAN headers, so you just observe regular IP packets.
Switching to driver-level XDP, providing your hardware (or virtual interface) uses a driver that supports it, should allow you to process your packets before they are sent to the kernel stack and before the VXLAN are removed.
I faced the same problem when running xdp in xdpdrv mode.
In this tutorial I found notes about VLAN offloads on NIC interface:
Since XDP needs to see the VLAN headers as part of the packet headers, it is important to turn off VLAN hardware offload (which most hardware NICs support), since that will remove the VLAN tag from the packet header and instead communicate it out of band to the kernel via the packet hardware descriptor. The testenv script already disables VLAN offload when setting up the environment, but for reference, here is how to turn it off for other devices, using ethtool:
# Check current setting:
ethtool -k DEV | grep vlan-offload
# Disable for both RX and TX
ethtool --offload DEV rxvlan off txvlan off
# Same as:
# ethtool -K DEV rxvlan off txvlan off
I tried to use driver-mode as #Qeole, suggested. I created a pair of virtual interfaces because my NIC's driver didn't support driver specific hook.
ip link add dev veth1 type veth peer name veth2
The I loaded the program:
ip link set dev veth1 xdpdrv obj xdp_vlan_kern.o sec xdpvlan
And the replayed the PCAP file (on the same VM):
tcpreplay -i veth2 vlan.pcap
The output was as I expected:
bpf_trace_printk: h_proto is: 0x8100, ETH_P_8021Q is: 0x8100
Roman Sokolov's answer is correct.
Disabling txvlan on the sending side fixed the error.
ip link add veth0 type veth peer name veth1
ip link add link veth0 name veth0.100 type vlan id 100
ip link set veth0 up
ip link set veth1 up
ip link set veth0.100 up
ip addr add 10.100.0.4/24 dev veth0.100
ethtool -K veth0 txvlan off
Attaching ebpf program on veth1 using SKB mode, injecting packets into veth0.100 (simply run arping would be enough), then I can get packets with vlan tags in my ebpf program.
However it didn't solve the problem when I only disable rxvlan on veth1.
I didn't test this on a physical device yet, I'll try it later and modify this answer.
I want to connect an 5" HDMI display (26 header pins) to a Raspberry Pi 3. I also want to use UART0 (Tx=GPIO14, Rx=GPIO15).
So I remapped UART 0 to Tx=GPIO36 and RX=GPIO37 by using the command in config.txt file:
dtoverlay=uart0 ,txd0_pin36,rxdo_pin=37,pin_func=7 # alt 3
I also included the following commands in rc.local:
raspi-gpio set 14 ip
raspi-gpio set 15 ip
On entering raspi-gpio get command, I am getting TXD0 and RXD0 enabled at GPIO14, GPIO15 and GPIO36, GPIO37 respectively, but still serial communication is not working. Though it was working on GPIO14, GPIO15.
Now how to enable serial communication on GPIO36, GPIO37?
I want to install neutron server on different Nodes. In my environment there will be 3 provider networks name provider1, provider2 and provider3 with respectively. All of them will be flat network. In my system, I want each neutron server manages different provider networks (neutron1 only controls provider1, neutron2 controls provider2 and neutron3 controls provider3). VMs will have internal networks (overlay network) and use Virtual Routers to access provider networks. The interface mapping on neutron servers are as given below:
Neutron 1
Bond 0 : Management + overlay
Bond 1 : use for provider1
Neutron 2
Bond 0 : Management + overlay
Bond 1 : use for provider2
Neutron 3
Bond 0 : Management + overlay
Bond 1 : use for provider3
Virtual router(VR) is randomly scheduled across multiple OpenStack Networking nodes. My question is how I can deploy VR on specific neutron node (like VR which has GW address from provider1 will deploy on neutron1) ? or I will create high available VR, in this case VR will deploy all neutron servers. How can I select the active virtual router in this case?
I thought the DVR(Distributed Virtual Router) is helpful for your case.
I describe some differences between DVR and non-DVR based on VM access routes.
The DVR is generated Virtual Router at each compute node that has VMs to decrease overloads of Network node and SPOF.
Differences based on how to route.
VMs running node | subnet | using router at DVR | non-DVR
---------------------------------------------------------------------------------------------------------------------------------
all on the same node | different | Routing from each VM running compute node | Specified Network node (running L3agent node)
all across multiple nodes | different | Routing from each VM running compute node | Specified Network node (running L3agent node)
Difference when using Floating IPs. (but accessing from external to internal (SNAT) is not HA, just one node can routing it as of Ocata.)
DVR | non-DVR
-------------------------------------------------------
each DVR has each Floating IP | Just Network node only
As following configuration steps were based just a simple pattern, you need to refer the official tutorials for adopting your system.
Prerequisite: all compute nodes have installed l3, dhcp, metadata, openvswitch agents.
Enable the DVR at all compute nodes.
# vim /etc/neutron/neutron.conf
[DEFAULT]
...snip...
router_distributed = True
...snip...
Adding the l2population driver at controller node.
# /vim/etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
...snip...
mechanism_drivers = openvswitch,l2population
...snip...
Configure the SNAT router on the specified compute node.
# vim /etc/neutron/l3_agent.ini
[DEFAULT]
...snip...
agent_mode = dvr_snat
...snip...
Configure the agent mode to DVR on the remaining compute nodes.
# vim /etc/neutron/l3_agent.ini
[DEFAULT]
...snip...
agent_mode = dvr
...snip..
Edit openvswitch config on all compute nodes.
# vim /etc/neutron/plugins/ml2/openvswitch_agent.ini
[agent]
...snip...
l2_population = True
enable_distributed_routing = True
...snip...
Restart for chages to take effect.
On controller node.
# systemctl restart neutron-server
On all compute nodes.
# systemctl restart neutron-l3-agent neutron-openvswitch-agent
I hope this will help you.
i have a major issue that i can't find nor heads nor tails of. I have googled this error, but i have not found any relevant solutions.
The problem:
I have about 8 servers, all running freebsd 8.3 p3 / p4. This fileserver is pushing around 300-400 mb/s.
This is the second time it happens. The network card just seems to die. I have 2 network cards in it, and i can reach the server via private network, and it all works okay, only that the public network is completely down. I have tried restarting the network interfaces: /etc/rc.d/netif restart && service routing restart | ifconfig em1 down && ifconfig em1 up, but with no success.
I can only bring the connectivity back if i reboot the server.
Below is the output from dmesg.boot that shows the network card drivers info.
em0: <Intel(R) PRO/1000 Network Connection 7.3.2> port 0xf020-0xf03f mem 0xf7b00000-0xf7b1ffff,0xf7b25000-0xf7b25fff irq 20 at device 25.0 on pci0
em0: Using an MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:25:90:7a:8e:9f
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xf7b24000-0xf7b243ff irq 16 at device 26.0 on pci0
em1: <Intel(R) PRO/1000 Network Connection 7.3.2> port 0xd000-0xd01f mem 0xf7900000-0xf791ffff,0xf7920000-0xf7923fff irq 16 at device 0.0 on pci3
em1: Using MSIX interrupts with 3 vectors
em1: [ITHREAD]
em1: [ITHREAD]
em1: [ITHREAD]
em1: Ethernet address: 00:25:90:7a:8e:9e
----------------------------
pciconf -lv
em1#pci0:3:0:0: class=0x020000 card=0x000015d9 chip=0x10d38086 rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class = network
subclass = ethernet
em0#pci0:0:25:0: class=0x020000 card=0x150215d9 chip=0x15028086 rev=0x05 hdr=0x00
vendor = 'Intel Corporation'
class = network
subclass = ethernet
I would really love some help to debug and fix this, because it usually happens while i am sleeping, at random days, and it's driving me crazy. I love my sleep.
This is a supermicro server, right?
cat /var/run/dmesg.boot | grep MSI
em0: Using an MSI interrupt
em1: Using MSIX interrupts with 3 vectors
Your answer is probably here: http://forums.freebsd.org/showthread.php?t=27736