[Users] Broadcast traffic on veth interfaces
Jason Voorhees
jvoorhees1 at gmail.com
Fri Feb 13 15:03:31 EST 2009
On Fri, Feb 13, 2009 at 2:34 PM, Vitaliy Gusev <vgusev at openvz.org> wrote:
> On 13 February 2009 22:43:31 you wrote:
>> On Fri, Feb 13, 2009 at 2:10 PM, Vitaliy Gusev <vgusev at openvz.org> wrote:
>> > On 13 February 2009 21:35:16 you wrote:
>> >> On Fri, Feb 13, 2009 at 12:22 PM, Vitaliy Gusev <vgusev at openvz.org> wrote:
>> > ...
>> >> > 1) what ip address does veth101.0 have?
>> >>
>> >> veth101.0 doesn't have any IPv4 address. According to the wiki I did
>> >> "ifconfig veth101.0 0".
>> >> eth0 in HN has 192.168.99.208. Should I assign a 192.168.99.X address
>> >> to veth101.0? I think that having 2 network interfaces with IP
>> >> addresses of the same range creates routing problems. Right?
>> >>
>> >> > 2) You did "route add -host". System will add IP to route with mask 255.255.255.255.
>> >> > What is broadcast traffic for IP with this mask?
>> >> Sorry, I don't get you. Maybe my English isn't very good to interpret
>> >> correctly this question :(
>> >
>> > It was really a joke. Broadcast traffic assume that you have
>> > mask not 255.255.255.255 . broadcast address calculated as
>> > (0xffffffff & mask) | ip_address,
>> >
>> > ip_address: 192.168.99.23
>> > netmask: 255.255.255.0
>> > broadcast: 192.168.99.255 << set not masked bits to 1
>> >
>> >>
>> >> > 3) What command do you use for check?
>> >> > If "ping 192.168.99.255", so related to 2) you can check route by:
>> >> >
>> >> > ip route get 192.168.99.255
>> >> >
>> >> > Please, show output of upper command and "ip r l"
>> >> >
>> >> > You can use "ping 192.168.99.255 -I veth102.0". Broadcast
>> >> > traffic will send directly through veth102.0 interface.
>> >> >
>> >> Ok, I was probing PING from my PC (192.168.99.23), not from the HN
>> >> (192.168.99.208). But anyway, these are the result of my tests:
>> >>
>> >> 1. At HN, ping broadcast address:
>> >>
>> >> # ping -b 192.168.99.255
>> >>
>> >> .. meanwhile at VE I'm listening on eth0 with tcpdump:
>> >>
>> >> # tcpdump -ni eth0 -e host 192.168.99.255
>> >> ... (returns nothing)
>> >>
>> >>
>> >> 2. At HN, ping broadcast address choosing what interface address to use:
>> >>
>> >> # ping -b 192.168.99.255 -I veth101.0
>> >>
>> >> ... meanwhile still running tcpdump at VE:
>> >>
>> >> # tcpdump -ni eth0 -e host 192.168.99.255
>> >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> >> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
>> >> 13:24:20.476026 00:18:51:80:c1:23 > Broadcast, ethertype IPv4
>> >> (0x0800), length 98: 192.168.99.208 > 192.168.99.255: ICMP echo
>> >> request, id 50002, seq 5, length 64
>> >> 13:24:21.475878 00:18:51:80:c1:23 > Broadcast, ethertype IPv4
>> >> (0x0800), length 98: 192.168.99.208 > 192.168.99.255: ICMP echo
>> >> request, id 50002, seq 6, length 64
>> >> 13:24:22.475709 00:18:51:80:c1:23 > Broadcast, ethertype IPv4
>> >> (0x0800), length 98: 192.168.99.208 > 192.168.99.255: ICMP echo
>> >> request, id 50002, seq 7, length 64
>> >>
>> >> Broadcast traffic delivers fine to VE, so NetBIOS queries should too.
>> >> I can see now that there's a routing problem... apparently, but I'm
>> >> not able to identify it, yet.
>> >> Why unicast traffic works OK trough veth101.0 but broadcast doesn't?
>> >> Why do I need to be specific about the network interface when I try to
>> >> send broadcast packets?
>> >>
>> >> This is the information requested about my HN routes:
>> >>
>> >> # ip route get 192.168.99.255
>> >> broadcast 192.168.99.255 dev eth0 src 192.168.99.208
>> >> cache <local,brd> mtu 1500 advmss 1460 hoplimit 64
>> >>
>> >> # ip route list
>> >> 192.168.99.206 dev venet0 scope link
>> >> 192.168.99.212 dev venet0 scope link
>> >> 192.168.99.209 dev veth10199202.0 scope link
>> >
>> > ^^^^^^^^^^
>> > Here is a very strange number of veth. What do you think?
>>
>> Ok, my real veth interface is veth10199202.0 but for simplicity I just
>> say that is veth101.0
>>
>> >> 192.168.99.0/24 dev eth0 proto kernel scope link src 192.168.99.208
>> >> 169.254.0.0/16 dev eth0 scope link
>> >> default via 192.168.99.1 dev eth0
>> >>
>> >> Do I need to route traffic to 192.168.99.255 trough veth101.0 only?
>> >> What happens when I need to create more veth interfaces for additional
>> >> VEs?
>> >
>> > It seems like bridge doesn't pass broadcast traffic. Can you setup
>> > network with bridge again and run tcpdump on veth101.0 interface?
>> >
>> Remember that bridge doesn't exist anymore since you suggested me to
>
> I remember it. I tried to find why broadcast traffic wasn't passed
> from the outset.
>
>> do that. I was routing directly to veth101.0 instead of routing to
>> vzbr0 (inexistent)
>>
>> Ok, these are the outputs requested after setting up the networking with bridge:
>>
>> # ifconfig
>> eth0 Link encap:Ethernet HWaddr 00:13:20:D5:93:8A
>> inet addr:192.168.99.208 Bcast:192.168.99.255 Mask:255.255.255.0
>> inet6 addr: fe80::213:20ff:fed5:938a/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:183752 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:97318 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:100
>> RX bytes:28046335 (26.7 MiB) TX bytes:24221984 (23.0 MiB)
>> Base address:0x1100 Memory:88020000-88040000
>>
>> 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:3 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:336 (336.0 b) TX bytes:336 (336.0 b)
>>
>> venet0 Link encap:UNSPEC HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>> UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
>> RX packets:9435 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:10168 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:755501 (737.7 KiB) TX bytes:2433889 (2.3 MiB)
>>
>> veth101.0 Link encap:Ethernet HWaddr 00:18:51:80:C1:23
>> inet6 addr: fe80::218:51ff:fe80:c123/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:29086 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:19240 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:7538099 (7.1 MiB) TX bytes:13040719 (12.4 MiB)
>>
>> vzbr0 Link encap:Ethernet HWaddr 00:18:51:80:C1:23
>> inet6 addr: fe80::218:51ff:fe80:c123/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:141 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:244 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:16229 (15.8 KiB) TX bytes:23253 (22.7 KiB)
>>
>> # ip r l
>> 192.168.99.206 dev venet0 scope link
>> 192.168.99.212 dev venet0 scope link
>> 192.168.99.209 dev vzbr0 scope link
>> 192.168.99.0/24 dev eth0 proto kernel scope link src 192.168.99.208
>> 169.254.0.0/16 dev eth0 scope link
>> default via 192.168.99.1 dev eth0
>>
>> # brctl show
>> bridge name bridge id STP enabled interfaces
>> vzbr0 8000.00185180c123 no veth101.0
>>
>> After this veth101.0 doesn't receive any broadcast packet according to
>> the null tcpdump output (tcpdump -ni veth101.0 -e host
>> 192.168.99.255).
>
> Try do next:
>
> 1. add eth0 to the bridge
> 2. reset ip address on eth0 to 0.0.0.0
> 3. set ip address 192.168.99.208 to the bridge
>
> Check tcpdump again, and if broadcast traffic will not be appeared, then
> show again
>
> ip a l
> ip l l
> ip r l
> brctl show
>
OMG, it finally worked. Now my VE can reply to broadcast queries and
also make broadcast queries receiving the corresponding replies.
I think about inserting eth0 to the bridge in a moment but I forgot to do it.
To finish this thread I believe this "extra" step should be included
in the Wiki too, it doesn't matter is only a networking issue but it
will be useful to anyone who has the same problem as me.
Thanks for your help, it was the key to solve this problem. Bye!
>>
>>
>> > Can you run next command in VE0 after setup net with bridge:
>> >
>> > ifconfig
>> > ip r l
>> > brctl show
>> >
>> >
>>
>
> --
> Thank,
> Vitaliy Gusev
>
More information about the Users
mailing list