[Steffen asked:] How is the (dynamic?) traffic allowance planned to be realized on vnphost?
I'm not quite sure what your question means. I think the answer is that we're using promiscuous interface(s) to listen for all traffic. Allowed traffic is forwarded. All other traffic is allowed to drop. [Steffen asked:] Why does the vlan base device eth1 have configured IP address(es)? (The local TCP/IP stack and the vlan devices might undesirably compete for incoming frames.) These IP addresses were present as we tried some things. They've been removed with no change in result. [Steffen asked:] Is vnphost a bridge (ebtables? vlan devices don't have configured IP addresses) or a router (routing tables? iptables?) for the other guests? Vnphost runs our own kernel module bridging between VLANs. Allowed traffic is dynamically configured to the module. Regards, Neal -----Original Message----- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Steffen Maier Sent: Saturday, July 14, 2012 4:40 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: VLAN Packet reverb. The MAC address of br0 seems to indicate that at least one of eth1* is connected to the bridge br0. What's the virtual network topology inside Linux guest vnphost? "brctl show", "brctl showmacs br0" (and maybe also "brctl showstp br0"), "tail -100 /proc/net/vlan/*". How is the (dynamic?) traffic allowance planned to be realized on vnphost? Why does the vlan base device eth1 have configured IP address(es)? (The local TCP/IP stack and the vlan devices might undesirably compete for incoming frames.) Is vnphost a bridge (ebtables? vlan devices don't have configured IP addresses) or a router (routing tables? iptables?) for the other guests? Tcpdump (or any sniffer using packet sockets, e.g. being based on libpcap) is tricky in such environments with virtual vlan network devices and even more so with bridges due to stripping/prepending of vlan tag headers (e.g. REORDER_HDR vconfig flag, network device vlan hardware assist), the Linux internal delivery of frames to packet sockets (net/core/dev.c:dev_queue_xmit_nit() called from dev_hard_start_xmit() for egress traffic and ptype_all loop in __netif_receive_skb() for ingress traffic), and the order of frame processing hooks for packet sockets, vlan, bridge, local protocol stack (e.g. in dev_hard_start_xmit() and esp. in __netif_receive_skb()). Unfortunately, not all possible configurations work or work as expected with Linux since not all features are implemented orthogonally. On 07/13/2012 08:49 PM, Taylor, Neal E wrote: > Correction. State of eth1.x makes no difference. > Corrected version below. > > From: Taylor, Neal E > Sent: Friday, July 13, 2012 11:08 AM > To: 'linux-390@vm.marist.edu' > Cc: Anand, Swapna A; Pavelka, Tomas; Quach, Minh T > Subject: VLAN Packet reverb. > > Gentlefolk, > > As a new person to the list I have checked the archive and didn't locate an > answer. > > We're Using VLANs to isolate traffic to VMs with a > router/firewall-like process to switch VLAN IDs to complete allowed > communication. Only the router/firewall instance of zLinux is grated > trunked, promiscuous access to the vswitch. On the router/firewall we > start see 18 (usually) copies of packets. > > Other nodes on the vswitch see normal traffic. > > Any suggestions on what we've mis-configured or what data to gather next? > > Neal Taylor > Principal Software Engineer > CA Technologies, Inc. > > [root@vnphost ~]# vmcp q lan vnptest acc > VSWITCH SYSTEM VNPTEST Type: QDIO Connected: 3 Maxconn: INFINITE > PERSISTENT RESTRICTED ETHERNET Accounting: OFF > USERBASED > VLAN Aware Default VLAN: 0001 Default Porttype: Access GVRP: Disabled > Native VLAN: 0001 VLAN Counters: OFF > MAC address: 02-00-C2-00-00-14 MAC Protection: Unspecified > State: Defined > IPTimeout: 5 QueueStorage: 8 > Isolation Status: OFF > Authorized userids: > VNPAPP1 Porttype: Access VLAN: 0002 > VNPAPP2 Porttype: Access VLAN: 0003 > VNPHOST Porttype: Trunk VLAN: 0002-0003 > > [root@vnphost tmp]# ifconfig -a > br0 Link encap:Ethernet HWaddr 02:00:C2:00:00:1B > inet6 addr: fe80::c2ff:fe00:1b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:468 (468.0 b) > > eth0 Link encap:Ethernet HWaddr 02:00:C2:00:00:1C > inet addr:141.202.162.61 Bcast:141.202.162.255 Mask:255.255.255.0 > inet6 addr: fe80::200:c200:1800:1c/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:12518 errors:0 dropped:0 overruns:0 frame:0 > TX packets:10681 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:4093811 (3.9 MiB) TX bytes:1588807 (1.5 MiB) > > eth1 Link encap:Ethernet HWaddr 02:00:C2:00:00:1B > inet addr:10.55.255.3 Bcast:10.55.255.255 Mask:255.255.255.0 > inet6 addr: fe80::c2ff:fe00:1b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:5166 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4644 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:419062 (409.2 KiB) TX bytes:379468 (370.5 KiB) > > eth1.2 Link encap:Ethernet HWaddr 02:00:C2:00:00:1B > inet6 addr: fe80::c2ff:fe00:1b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:984 (984.0 b) > > eth1.3 Link encap:Ethernet HWaddr 02:00:C2:00:00:1B > inet6 addr: fe80::c2ff:fe00:1b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:984 (984.0 b) > > eth1.4 Link encap:Ethernet HWaddr 02:00:C2:00:00:1B > inet6 addr: fe80::c2ff:fe00:1b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:492 (492.0 b) > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > From a "tcpdum -i eth1". This shows traffic between two other nodes, but 18 > copies of it: > 12:19:12.089413 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089444 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089449 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089455 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089460 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089465 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089470 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089475 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089480 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089485 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089490 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089495 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089500 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089505 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089510 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089515 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089520 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 > 12:19:12.089525 IP 10.55.255.1> 10.55.255.2: ICMP echo request, id 3334, seq > 1, length 64 -- Mit freundlichen Grüßen / Kind regards Steffen Maier Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
