Fórumok
Hi,
Adott egy x64 ubuntu server (vwgubu01 - 192.168.113.25) virtuális gép, amelyen futtatok hercules emulátorban egy z/Debian (vwgzlnx01 - 192.168.113.70) mainframe linux-ot.
A jelenlegi hálózati beállítások mellett a zDebian csak a host gépet éri el, a hálózat többi részét nem. A host gép a teljes hálózatot látja és bárhonnan elérhető.
! x64 LINUX
root@vwgubu01:/# ifconfig
br0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0e
inet addr:192.168.113.25 Bcast:192.168.113.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:feac:e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37814 errors:0 dropped:0 overruns:0 frame:0
TX packets:18087 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15889931 (15.8 MB) TX bytes:16318678 (16.3 MB)
eth0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0e
inet6 addr: fe80::250:56ff:feac:e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39988 errors:0 dropped:0 overruns:0 frame:0
TX packets:26276 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16605201 (16.6 MB) TX bytes:16756614 (16.7 MB)
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)
tap0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0f
inet6 addr: fe80::250:56ff:feac:f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:115 errors:0 dropped:0 overruns:0 frame:0
TX packets:1876 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:12521 (12.5 KB) TX bytes:131750 (131.7 KB)
root@vwgubu01:/# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.005056ac000e no eth0
tap0
root@vwgubu01:/# ping -c 4 192.168.113.70
PING 192.168.113.70 (192.168.113.70) 56(84) bytes of data.
64 bytes from 192.168.113.70: icmp_req=1 ttl=64 time=0.805 ms
64 bytes from 192.168.113.70: icmp_req=2 ttl=64 time=1.00 ms
64 bytes from 192.168.113.70: icmp_req=3 ttl=64 time=0.967 ms
64 bytes from 192.168.113.70: icmp_req=4 ttl=64 time=0.901 ms
--- 192.168.113.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.805/0.919/1.006/0.084 ms
root@vwgubu01:/# ping -c 4 192.168.113.1
PING 192.168.113.1 (192.168.113.1) 56(84) bytes of data.
64 bytes from 192.168.113.1: icmp_req=1 ttl=255 time=0.563 ms
64 bytes from 192.168.113.1: icmp_req=2 ttl=255 time=0.524 ms
64 bytes from 192.168.113.1: icmp_req=3 ttl=255 time=0.566 ms
64 bytes from 192.168.113.1: icmp_req=4 ttl=255 time=0.612 ms
--- 192.168.113.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.524/0.566/0.612/0.035 ms
root@vwgubu01:/#
! zLINUX
root@vwgzlnx01:~# ifconfig
eth0 Link encap:Ethernet HWaddr 02:00:00:f8:54:ec
inet addr:192.168.113.70 Bcast:192.168.113.255 Mask:255.255.255.0
inet6 addr: fe80::ff:fef8:54ec/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:1086 errors:0 dropped:0 overruns:0 frame:0
TX packets:103 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:60400 (58.9 KiB) TX bytes:10305 (10.0 KiB)
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:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:491 (491.0 B) TX bytes:491 (491.0 B)
root@vwgzlnx01:~# ping -c 4 192.168.113.25
PING 192.168.113.25 (192.168.113.25) 56(84) bytes of data.
64 bytes from 192.168.113.25: icmp_req=1 ttl=64 time=0.645 ms
64 bytes from 192.168.113.25: icmp_req=2 ttl=64 time=0.564 ms
64 bytes from 192.168.113.25: icmp_req=3 ttl=64 time=0.355 ms
64 bytes from 192.168.113.25: icmp_req=4 ttl=64 time=1.35 ms
root@vwgzlnx01:~# ping -c 4 192.168.113.1
PING 192.168.113.1 (192.168.113.1) 56(84) bytes of data.
From 192.168.113.70 icmp_seq=1 Destination Host Unreachable
From 192.168.113.70 icmp_seq=2 Destination Host Unreachable
From 192.168.113.70 icmp_seq=3 Destination Host Unreachable
From 192.168.113.70 icmp_seq=4 Destination Host Unreachable
--- 192.168.113.1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3006ms
pipe 3
Merre induljak, hogy kiderítsem hol akadnak el a csomagok?
A dolog érdekessége, hogy a tap0 interface az emuátor indulása után, a guest linux boot folyamata alatt jön létre és egy automatizált scripttel adom hozzá a bridge-hez. Okozhatja ez a hibát?
Udv,
Gabor
Update:
Mint azt ahogy többen sejtették, a probléma a switch környékén volt, a hálózati adminisztrátor engedélyezte a promisc módot a vSwitch pool számára. A ping megy szélrózsa minden irányába...
root@vwgzlnx01:~# ping index.hu
PING index.hu (217.20.130.97) 56(84) bytes of data.
64 bytes from sportgeza.hu (217.20.130.97): icmp_req=1 ttl=54 time=23.4 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_req=2 ttl=54 time=21.9 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_req=3 ttl=54 time=23.9 ms
^C
--- index.hu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.996/23.115/23.903/0.812 ms
Köszi mindenkinek a segítséget!
- 8945 megtekintés
Hozzászólások
ip_forward 1?
- A hozzászóláshoz be kell jelentkezni
permanensen be van állítva.
root@vwgubu01:/# more /proc/sys/net/ipv4/ip_forward
1
- A hozzászóláshoz be kell jelentkezni
Látod az icmp csomagokat oda-vissza?
#tcpdump -ni br0 host 192.168.113.70
- A hozzászóláshoz be kell jelentkezni
Ha kiadom a guest gepen a ping 192.168.113.1 parancsot, akkor ez a kimenete a host gepen a tcpdump-nak:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:33:35.731847 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [P.], seq 3728560836:3728560884, ack 355390862, win 661, options [nop,nop,TS val 2713659 ecr 1253022], length 48
13:33:35.744259 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 1:49, ack 48, win 779, options [nop,nop,TS val 1256222 ecr 2713659], length 48
13:33:35.744281 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 49, win 661, options [nop,nop,TS val 2713663 ecr 1256222], length 0
13:33:35.760188 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 49:145, ack 48, win 779, options [nop,nop,TS val 1256227 ecr 2713663], length 96
13:33:35.760232 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 145, win 661, options [nop,nop,TS val 2713667 ecr 1256227], length 0
13:33:35.760356 ARP, Request who-has 192.168.113.1 tell 192.168.113.70, length 28
13:33:36.759608 ARP, Request who-has 192.168.113.1 tell 192.168.113.70, length 28
13:33:37.760133 ARP, Request who-has 192.168.113.1 tell 192.168.113.70, length 28
13:33:38.761774 ARP, Request who-has 192.168.113.1 tell 192.168.113.70, length 28
13:33:38.763647 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 145:369, ack 48, win 779, options [nop,nop,TS val 1256978 ecr 2713667], length 224
13:33:38.763676 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 369, win 661, options [nop,nop,TS val 2714417 ecr 1256978], length 0
13:33:39.759109 ARP, Request who-has 192.168.113.1 tell 192.168.113.70, length 28
13:33:40.759159 ARP, Request who-has 192.168.113.1 tell 192.168.113.70, length 28
13:33:41.722554 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [P.], seq 48:96, ack 369, win 661, options [nop,nop,TS val 2715157 ecr 1256978], length 48
13:33:41.725900 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 369:417, ack 96, win 779, options [nop,nop,TS val 1257718 ecr 2715157], length 48
13:33:41.725931 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 417, win 661, options [nop,nop,TS val 2715158 ecr 1257718], length 0
13:33:41.728778 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 417:497, ack 96, win 779, options [nop,nop,TS val 1257719 ecr 2715158], length 80
13:33:41.728795 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 497, win 661, options [nop,nop,TS val 2715159 ecr 1257719], length 0
13:33:41.729814 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 497:625, ack 96, win 779, options [nop,nop,TS val 1257719 ecr 2715158], length 128
13:33:41.729836 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 625, win 661, options [nop,nop,TS val 2715159 ecr 1257719], length 0
13:33:41.732618 IP 192.168.113.70.22 > 192.168.113.25.33458: Flags [P.], seq 625:689, ack 96, win 779, options [nop,nop,TS val 1257720 ecr 2715159], length 64
13:33:41.732637 IP 192.168.113.25.33458 > 192.168.113.70.22: Flags [.], ack 689, win 661, options [nop,nop,TS val 2715160 ecr 1257720], length 0
^C
22 packets captured
23 packets received by filter
0 packets dropped by kernel
- A hozzászóláshoz be kell jelentkezni
Próbáld meg kikapcsolni a TX checksumming-ot a tap interfészen vagy az egész br0-án.
#/usr/sbin/ethtool -K tap0 tx off
esetleg
#/usr/sbin/ethtool -K br0 tx off
BTW mitől 1492 a virtual gép eth0 MTU-ja?
- A hozzászóláshoz be kell jelentkezni
Sajnos egyik dolog se segített, beállítottam az MTU 1500-ra fixen az interfaces fileban.
Nem lehet, hogy a MAC címek környékén van a probléma? Esetleg a tap0 host interface és az eth0 guest interface azonosnak kellene lennie?
- A hozzászóláshoz be kell jelentkezni
biztosan nem! ilyenkor a br0 MAC-jével megy a forgalom
- A hozzászóláshoz be kell jelentkezni
Esetleg valami összeakadhatott, pl. switch arp tabla törlés, gép újraindítás, switch reset. Vagy host gépen valami tűzfal szabály?
- A hozzászóláshoz be kell jelentkezni
Egyedül a host/guest gépeket tudom újraindítani, a switch-hez nem férek hozzá (ausztriában van) és a 2 hálózatos kolléga így péntek délután érthető módon nem reagál a kéréseimre. :)
Azt tudom még megpróbálni, hogy másik IP-t állítok be guest-nek, vagy amit még javasoltok.
- A hozzászóláshoz be kell jelentkezni
Egy újraindítást/más IP címet megpróbálnék. De ha a gépeken minden rendben, akkot már csak a switch-el lehet valami gond. Be van állítva, hogy ezen a porton, csak egy IP mehet át vagy valami hasonló, esetleg VLAN?
- A hozzászóláshoz be kell jelentkezni
vlan-nál a host ifconfig nem így nézne ki
- A hozzászóláshoz be kell jelentkezni
tap0 MAC biztos jó? (nálam ez van: fe:ff:ff:ff:ff:ff)
már csak azért is gyanús, mert az eth0 MAC-nál csak 1-gyel nagyobb
- A hozzászóláshoz be kell jelentkezni
Kipróbáltam minden lehetséges variációt a MAC címekkel, mindegyik azonos, ķülönböző, stb, de nem segített. :-(
- A hozzászóláshoz be kell jelentkezni
tűzfalra szavazok :)
- A hozzászóláshoz be kell jelentkezni
"Okozhatja ez a hibát?"
Elvileg nem. Én tap-nál és tun-nál is azt tapasztaltam hogy a routolás nem megy ha a Herculesen futó OS-ek ugyanabból az IP tartományból kapnak címet, mint amiben a host OS is van. Nem jöttem rá hogy miért (annyira nem is törtem magam), de én végül azt csináltam hogy tun-t használva, egy másik IP tartományból kapnak IP címeket /32-es maskkal, és a host OS route-ol kifelé/befelé/egymás között.
____________________
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
Korábban én is ezt használtam, ctc (channel to channel adapter) interface. A hercules 4-es verzióban már implementálták a qeth device-t és szeretném végre működésre bírni. A ctc-vel az a gond, hogy minden gépen, kellett adjam a routolási szabályt a guest felé és ha külön subnet-ről próbáltam elérni, akkor már gondban voltam.
Ezért lenne fontos és végleges megoldás a bridge.
- A hozzászóláshoz be kell jelentkezni
Én csak egy helyen adtam meg hogy merre kell menni a guestek felé, a gateway-en, így automatikusan tudta mindenki hogy hol vannak. Bár ha nincs gw akkor ez nem járható út.
Megpróbálom én is belőni a tap-ot valamikor, mostmár érdekel.
____________________
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
Amikor tcpdump-pal nézed a forgalmat, tegyél már a kapcsolók közé egy "-e"-t is!
Nekem is a MAC a gyanús, de ha kiderülne, hogy mégsem, akkor feleslegesen nem részletezném.
- A hozzászóláshoz be kell jelentkezni
root@vwgubu01:/home/gabor# tcpdump -e -ni br0 host 192.168.113.70
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
!!! itt a guest geprol inditottam ping-et a host felé, ez megy
15:30:32.589158 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 1, length 64
15:30:32.589190 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 1, length 64
15:30:33.590777 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 2, length 64
15:30:33.590793 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 2, length 64
15:30:34.593486 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 3, length 64
15:30:34.593507 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 3, length 64
15:30:35.596033 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 4, length 64
15:30:35.596072 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 4, length 64
15:30:36.597820 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 5, length 64
15:30:36.597846 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 5, length 64
15:30:37.591547 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.70 tell 192.168.113.25, length 28
15:30:37.592213 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype ARP (0x0806), length 42: Reply 192.168.113.70 is-at 02:00:00:cf:bd:e4, length 28
15:30:37.599187 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 6, length 64
15:30:37.599203 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 6, length 64
15:30:38.601835 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 7, length 64
15:30:38.601862 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 7, length 64
15:30:39.605295 02:00:00:cf:bd:e4 > 00:50:56:ac:00:0e, ethertype IPv4 (0x0800), length 98: 192.168.113.70 > 192.168.113.25: ICMP echo request, id 2247, seq 8, length 64
15:30:39.605316 00:50:56:ac:00:0e > 02:00:00:cf:bd:e4, ethertype IPv4 (0x0800), length 98: 192.168.113.25 > 192.168.113.70: ICMP echo reply, id 2247, seq 8, length 64
!!! itt a guest geprol inditottam ping-et a switch felé (192.168.113.1), ez nem megy
15:30:45.915434 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:46.912813 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:47.912956 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:48.931372 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:49.929775 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:50.928998 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:51.940325 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:52.937523 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
15:30:53.936749 02:00:00:cf:bd:e4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.113.1 tell 192.168.113.70, length 28
^C
27 packets captured
27 packets received by filter
0 packets dropped by kernel
Időközben próbálkoztam többféle MAC címmel, jelenleg ez a konfig van érvényben. A host géppel tudok kommunikálni, de semmi más géppel az adott vagy más subnet-ből nem.
root@vwgubu01:/home/gabor# ifconfig
br0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0e
inet addr:192.168.113.25 Bcast:192.168.113.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:feac:e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:113164 errors:0 dropped:0 overruns:0 frame:0
TX packets:145986 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5490913 (5.4 MB) TX bytes:29182978 (29.1 MB)
eth0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0e
inet6 addr: fe80::250:56ff:feac:e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:112388 errors:0 dropped:0 overruns:0 frame:0
TX packets:147927 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7371260 (7.3 MB) TX bytes:29257737 (29.2 MB)
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:41 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5232 (5.2 KB) TX bytes:5232 (5.2 KB)
tap0 Link encap:Ethernet HWaddr 46:a9:08:e6:9a:e5
inet6 addr: fe80::44a9:8ff:fee6:9ae5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:788 errors:0 dropped:0 overruns:0 frame:0
TX packets:36111 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:130829 (130.8 KB) TX bytes:2507113 (2.5 MB)
Páran a tűzfalra gyanakszanak, ezért ott is csináltam pár módosítást az eredeti beállításhoz képest, most ez van érvényben a host-on. Nem igazán tudom, hogy jó-e.
root@vwgubu01:/home/gabor# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Udv,
Gabor
- A hozzászóláshoz be kell jelentkezni
Részemről akkor passzolom a kérdést.
Abban bíztam, hogy valami hasonlóan "triviális" dolog, mint amit a Virtualbox-ba telepített router csinált, mikor a wifi kártyán át kommunikált a külvilággal. De ott annyi történt, hogy a válasz csomagok a host kártyájának MAC address-ére voltak címezve a guest-é helyett.
Itt meg úgy tűnik, ki sem jutnak a csomagok.
- A hozzászóláshoz be kell jelentkezni
ma volt időm foglalkozni a problémával és beszléltem a hálózati adminisztrátorokkal is. kiderült, hogy a host gép amivel tesztelek a produkciós subnet-ben volt és inkább áttettük az egész környezetet a 192.168.115.0 hálózatba. Itt van egy másik általam adminisztrált linux tesztgép, így tudom nem csak az átmenő, hanem a beérkező forgalmat is figyelni.
a jelenlegi felállás a következő:
host linux: 192.168.115.182 (00:50:56:ac:00:0e)
zLinux: 192.168.115.183 (00:50:56:ac:00:fe)
tesztgép: 192.168.115.73 (00:50:56:ac:00:27)
host és guest továbbra is látja egymást a bridge-en keresztül.
amennyiben a zLinux-ból pingelem a tesztgépet, akkor így alakul a forgalom:
forgalom a host gépen:
gabor@vwgubu01:~$ sudo tcpdump -e -ni eth0 ether host 00:50:56:ac:00:fe
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:57:17.681380 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:18.678087 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:19.678889 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:20.681398 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:21.678560 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:22.677930 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:23.698135 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:24.699028 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
18:57:25.697969 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.73 tell 192.168.115.183, length 28
^C
9 packets captured
11 packets received by filter
0 packets dropped by kernel
forgalom a tesztgép (192.168.115.73 - mac: 00:50:56:ac:00:27)
gah@vwgarnfs01:~$ sudo tcpdump -e -ni eth0 ether host 00:50:56:ac:00:fe
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:42:57.146032 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
09:42:57.146046 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype ARP (0x0806), length 42: Reply 192.168.115.73 is-at 00:50:56:ac:00:27, length 28
09:42:58.144584 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
09:42:58.144598 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype ARP (0x0806), length 42: Reply 192.168.115.73 is-at 00:50:56:ac:00:27, length 28
09:42:59.143970 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
09:42:59.143983 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype ARP (0x0806), length 42: Reply 192.168.115.73 is-at 00:50:56:ac:00:27, length 28
09:43:00.162018 00:50:56:ac:00:fe > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
09:43:00.162028 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype ARP (0x0806), length 42: Reply 192.168.115.73 is-at 00:50:56:ac:00:27, length 28
^C
48 packets captured
50 packets received by filter
0 packets dropped by kernel
4294967294 packets dropped by interface
egy másik példa, ahol a ping-elt tesztgép lekérdezi a 192.168.115.183 mac címét brodcast üzenettel, megjön a válasz, de az ICMP echo reply már nem érkezik meg.
gah@vwgarnfs01:~$ sudo tcpdump -e -ni eth0 | grep 192.168.115.183
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:52:20.169848 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 1, length 64
09:52:20.171161 00:50:56:ac:00:27 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.115.183 tell 192.168.115.73, length 28
09:52:20.171903 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype ARP (0x0806), length 60: Reply 192.168.115.183 is-at 00:50:56:ac:00:fe, length 46
09:52:20.171909 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 1, length 64
09:52:21.178445 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 2, length 64
09:52:21.178459 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 2, length 64
09:52:22.186526 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 3, length 64
09:52:22.186541 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 3, length 64
09:52:23.194483 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 4, length 64
09:52:23.194506 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 4, length 64
09:52:24.202515 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 5, length 64
09:52:24.202535 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 5, length 64
09:52:25.210034 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 6, length 64
09:52:25.210059 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 6, length 64
09:52:26.191823 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
09:52:26.218354 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 7, length 64
09:52:26.218366 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 7, length 64
09:52:27.191633 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
09:52:27.226600 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype IPv4 (0x0800), length 98: 192.168.115.183 > 192.168.115.73: ICMP echo request, id 2288, seq 8, length 64
09:52:27.226615 00:50:56:ac:00:27 > 00:50:56:ac:00:fe, ethertype IPv4 (0x0800), length 98: 192.168.115.73 > 192.168.115.183: ICMP echo reply, id 2288, seq 8, length 64
09:52:28.191629 00:50:56:ac:00:fe > 00:50:56:ac:00:27, ethertype ARP (0x0806), length 60: Request who-has 192.168.115.73 tell 192.168.115.183, length 46
^C238 packets captured
240 packets received by filter
0 packets dropped by kernel
olyan, mintha a bridge csak a saját vagy ff:ff:ff:ff:ff:ff című csomagokat engedné be, a 00:50:56:ac:00:fe címre érkezőeket eldobná.
Lehet, hogy valami mac szintű firewall fogja meg a csomagokat? vagy a bridge-ben lévő eth0 interface dobja azokat?
- A hozzászóláshoz be kell jelentkezni
A hercules-t futtató gépen próbálj egy olyat, hogy
ebtables -t brouting -A BROUTE --ip-dst z/Debian-címtartománya/mask -j redirect
Megpróbálom megkeresni, hogy pontosabban hogy néz ki.
A másik tippem, hogy a guest virtuális hálókártyáján nincs-e letiltva a promiscuous mód?
Virtualboxban alapból le van, ezzel is lehet nagyokat szopni. :)
update:
ebtables -t broute -A BROUTING -p IPv4 --ip-dst /mask -j redirect
Lehet, hogy ez vagy a promisc. mód segít.
- A hozzászóláshoz be kell jelentkezni
elvileg minden interface-en be van allitva a promisc mode:
gabor@vwgubu01:~$ ifconfig
br0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0e
inet addr:192.168.115.182 Bcast:192.168.115.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:feac:e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:103813 errors:0 dropped:12 overruns:0 frame:0
TX packets:106626 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6302680 (6.3 MB) TX bytes:20535844 (20.5 MB)
eth0 Link encap:Ethernet HWaddr 00:50:56:ac:00:0e
inet6 addr: fe80::250:56ff:feac:e/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:103597 errors:0 dropped:0 overruns:0 frame:0
TX packets:106791 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7751350 (7.7 MB) TX bytes:20539405 (20.5 MB)
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:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1184 (1.1 KB) TX bytes:1184 (1.1 KB)
tap0 Link encap:Ethernet HWaddr 8e:57:c1:05:4f:dc
inet6 addr: fe80::8c57:c1ff:fe05:4fdc/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:222 errors:0 dropped:0 overruns:0 frame:0
TX packets:38191 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:19016 (19.0 KB) TX bytes:3539137 (3.5 MB)
beállítottam ahogy kérted, de sajnos nem segített:
gabor@vwgubu01:~$ sudo ebtables -t broute -A BROUTING -p IPv4 --ip-dst 192.168.115.0/24 -j redirect
gabor@vwgubu01:~$ sudo ebtables -Ln
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
- A hozzászóláshoz be kell jelentkezni
Promisc mode nem az interface-en, hanem a virtualizációs szoftverben lenne érdekes.
De én csak a virtualbox-ot ismerem ilyen szinten, nem tudom, máshol van-e ilyen állítási lehetőség.
VB-ban, ha kívül letiltom, az a guest felől úgy tudom, nem látszik.
- A hozzászóláshoz be kell jelentkezni
nem tudom megmondani, hogy hogyan van beállítva jelenleg a vmware-ben, holnap rákérdeztek. azt tudom, hogy a br0 interfacen érkeznek csomagok nem 00:50:56:ac:00:0e/ff:ff:ff:ff:ff:ff címekről.
gabor@vwgubu01:~$ sudo tcpdump -e -ni br0 '(not ether host 00:50:56:ac:00:0e) and (not ether host ff:ff:ff:ff:ff:ff)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:59:17.638638 00:00:0c:07:ac:07 > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 62: 192.168.115.2.1985 > 224.0.0.2.1985: HSRPv0-hello 20: state=active group=7 addr=192.168.115.1
20:59:17.935283 44:d3:ca:7e:8d:3f > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 62: 192.168.115.3.1985 > 224.0.0.2.1985: HSRPv0-hello 20: state=standby group=7 addr=192.168.115.1
20:59:18.006170 40:55:39:da:cd:77 > 01:00:0c:cc:cc:cd, 802.3, length 64: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Cisco (0x00000c), pid PVST (0x010b): STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 2007.44:d3:ca:7e:8d:00.8282, length 42
20:59:18.814391 00:50:56:ac:76:e6 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 171: fe80::2d5e:a1d3:37c1:22d9.546 > ff02::1:2.547: dhcp6 solicit
20:59:18.892248 78:e7:d1:b1:9a:27 > 01:14:c2:44:1e:cc, 802.3, length 80: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Unknown (0x0014c2), pid Unknown (0x0001): Unnumbered, ui, Flags [Command], length 66
20:59:19.871797 10:1f:74:78:b5:1d > 01:14:c2:44:1e:cc, 802.3, length 80: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Unknown (0x0014c2), pid Unknown (0x0001): Unnumbered, ui, Flags [Command], length 66
20:59:19.892156 78:e7:d1:b1:9a:27 > 01:14:c2:44:1e:cc, 802.3, length 80: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Unknown (0x0014c2), pid Unknown (0x0001): Unnumbered, ui, Flags [Command], length 66
20:59:20.007796 40:55:39:da:cd:77 > 01:00:0c:cc:cc:cd, 802.3, length 64: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Cisco (0x00000c), pid PVST (0x010b): STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 2007.44:d3:ca:7e:8d:00.8282, length 42
20:59:20.083490 00:00:0c:07:ac:07 > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 62: 192.168.115.2.1985 > 224.0.0.2.1985: HSRPv0-hello 20: state=active group=7 addr=192.168.115.1
20:59:20.455264 44:d3:ca:7e:8d:3f > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 62: 192.168.115.3.1985 > 224.0.0.2.1985: HSRPv0-hello 20: state=standby group=7 addr=192.168.115.1
20:59:20.931174 78:e7:d1:b1:9a:23 > 01:14:c2:44:1e:cc, 802.3, length 80: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Unknown (0x0014c2), pid Unknown (0x0001): Unnumbered, ui, Flags [Command], length 66
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
- A hozzászóláshoz be kell jelentkezni
Megoldva, leírás fent.
- A hozzászóláshoz be kell jelentkezni
Vehetem úgy, hogy némileg hozzájárultam a sikerhez? ;)
(csak mert már régóta gyűjtögetem, hányszor sikerül valakinek olyan tippet adnom, ami ha nem is teljes megoldás, de legalább segítség :) )
- A hozzászóláshoz be kell jelentkezni
mindenkepp. koszi mindenkinek megegyszer!
- A hozzászóláshoz be kell jelentkezni
Akkor ezt is felvésem a sikerélmények közé :)
(viszont ebben az esetben már nem merülök el a hercules szépségeiben. Van VAX emulátorom, rajta OpenVMS-sel, ha nosztalgiázni akarok ;) )
- A hozzászóláshoz be kell jelentkezni