On Wednesday 25 January 2006 18:27, [EMAIL PROTECTED] wrote:
> Blaisorblade <[EMAIL PROTECTED]> writes:
First - below there's a reasonable diagnosis of what was your problem. In
short the problem wasn't the bridge, but the fact that the ping request
wasn't routed to the bridge but directly to eth0. Assigning the new IP to the
bridge happened to adjust the rules.
> > tcpdump on the host or on the guest? You must first check at
> > which point they get lost... doesn't see them routed up
> > correctly? You should check on the kernel logs if uml_net gave
> > a correct command to setup proxy ARP, and/or if you gave
> > correct commands if you did the thing yourself...
> Yeah, I'm not using proxy-arp and instead bridging the uml
> interfaces directly to the outside world. I guess having the ISP
> give me two separate blocks of IP addresses in different subnets
> is pretty irritating, but oh well. I suspect they're on
> different VLANs,
Don't know whether it's already spread out (latest Tanenbaum talks about "we
hope Gigabit Ethernet will all support 802.1q").
However your ISP can't assign VLAN IDs to IPs - VLAN travel only on the same
Ethernet and across bridges/switches, but as long as it's no more Ethernet
they shouldn't survive.
You can setup a bridge to say "subnet 1 is on VLAN 1 and subnet 2 is on VLAN
2", or other kind of filtering are possible, but this is unclean (it's layer3
dependant, and breaks with IPv6 and other possible transports); however
802.1q is intended to avoid resorting to this.
> but I don't have 802.1q support in my host
> kernel. A project for another day, I suppose.
> Yes, I assumed it would work, but something odd is going on with
> that configuration. What ended up fixing it was the following:
> 1) Configure the first IP address in the new block as an alias on
> the bridge interface. (the primary address is from the
> original subnet.)
> 2) Enable IP forwarding on the host.
> 3) Allow traffic in the FORWARD iptables chain.
I assume that since the first IP subnet worked, #2 and #3 aren't needed.
> Now, it's not the way I want it, since the traffic is not being
> bridged straight through, but it'll have to do for now. Clearly
> this is just my misunderstanding due to not really knowing a lot
> about L2 issues.
Hmm, I don't know a lot either, but indeed when you have a real L2 switch it's
not supposed to have an IP address, so a Linux (or even Windows, since it
seems to work following the same model) bridge is different. It could be
represented as bridging the N given interfaces plus another Ethernet cable
attached to the host to a virtual iface, and giving the IP to that virtual
iface.
But no, it's not a L2 issue.
> It seems as though the linux virtual bridge code was not allowing
> ports to "connect" that were from a mismatched subnet. Sniffing
> on the main interface showed the arp requests going out eth0 and
> never getting to the interface on the other end of the TAP
> device--as soon as the bridge was configured with an IP in that
> second subnet, the arps were broadcast to all connected ports.
The solution is a different question. You are pinging an address on subnet 2.
That ping request must be routed. Assuming you have eth0 and tap0 without IP
and br0 with a subnet 1 IP, there's no entry in the routing table saying
"route subnet 2 on br0". And this is a different question from making sure
that traffic passes from eth0 to tap0 and backwards! It's entirely possible
that ping from another host would have worked.
You seem to have some routing rule as "route subnet 2 onto eth0" even if eth0
isn't given an IP. This is possible, see below for examples.
Perhaps bridge-utils should adjust routing rules when setting up the bridge,
or you should. When you assign a subnet 2 address to the bridge, that rule is
replaced by "route subnet 2 on br0" (every time you give an IP to interface a
route is added for that iface).
What is strange is that the ping (or better, the ARP) was going on eth0
without replication on br0. I assume this replication is not done because
local traffic should be thrown on br0 rather than eth0.
[ As an aside: to a software bridge you indeed connect interfaces, not ports,
IMHO (for a hardware bridge you're right)... moreover, if the bridge is
connected to eth0 I assume that eth0 wasn't given an address (it should be
impossible to assign one, IIRC). So why the bridge should prefer eth0 to
tap0? The only reasonable reason is that it isn't a "broadcast" bridge but
tries to behave a bit like a switch, but it shouldn't - in fact the problem
is at routing layer, as I discovered after tossing this "it's a switch"
idea. ]
> From there, I still needed to route the traffic through the host,
> which I still don't quite understand, but at least it's working.
You refer to #2 and #3 above, right? Guess they're not needed, as said.
About routing to an iface without an address:
# ip route add 192.168.101.0/24 dev lo
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.101.0 * 255.255.255.0 U 0 0 0 lo
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.100.1 0.0.0.0 UG 0 0 0 ppp0
[...]
You can do it even on tap0, but first you must assign it at least the 0.0.0.0
address (no, bringing it up is not the same thing - guess it's some problem
with using the old ifconfig tool - you don't see the difference between the
two states; or it's a bug):
# tunctl
Set 'tap0' persistent and owned by uid 0
# ip route add 192.168.102.0/24 dev tap0
RTNETLINK answers: No such device
# ifconfig tap0 up
# ip route add 192.168.102.0/24 dev tap0
RTNETLINK answers: No such device
# ifconfig tap0 0.0.0.0
# ifconfig tap0
tap0 Link encap:Ethernet HWaddr FA:8F:E3:71:54:4D
UP BROADCAST RUNNING MULTICAST MTU:1500 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:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
# ip route add 192.168.102.0/24 dev tap0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.102.0 * 255.255.255.0 U 0 0 0 tap0
[...]
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive
http://it.messenger.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
