Hello there, there are a few errors in my post which I would like to point out: In the figure at http://yfrog.com/83vlanp , PortC(LAN) shd be replaced by PortA(LAN) and PortD(WAN) by PortB(WAN) for both the real and the virtual interfaces. My linux machine is connected to LAN whereas the WAN goes on to meet the router. Thus, the ebtables rule changes to ebtables -t broute -I BROUTING -p 0x8100 -i PortA -j redirect --redirect-target DROP On Tue, 2010-05-25 at 13:22 +0530, Aijaz Baig wrote: > Hello people, > > I have a Linux machine acting as a bridge although it has been updated > to the 2.6.27 kernel and thus contains iptables, ebtables and also the > br-nf code for iptables based filtering at the Link layer (please > correct me if I have misunderstood anything). I have been trying to ping > the bridge itself from a virtual interface on my local machine (also > linux). So before we proceed heres my scenario. Please refer to the > figure describing the scenario at http://yfrog.com/83vlanp > > br0 - 192.168.5.104/20 > PortA - 0.0.0.0 (bridged port) > PortB - 0.0.0.0 (bridged port) > PortA.3 - 0.0.0.0 (bridged port) > PortB.3 - 0.0.0.0 (bridged port) > > eth0 - 192.168.4.237/20 (local) > eth0.3 - 14.11.11.11/24 (local) > > I have read the entire documentation with the title 'interaction of the > ebtables and iptables on a linux bridge'. Alongwith that I have also > read quite a few documents on using the iptables and the ebtables > utilities. > > Most of my questions concern the diagram at > (http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png) which explains > the movement of the packet flow. > > for this experiment, I have flushed all the rules in the iptables and > ebtables for all the chains. Plus the default policy for all the chains > in iptables and ebtables is set to ACCEPT. The only rule that I have on > my machine is > > ebtables -t broute -I BROUTING -p 0x8100 -i PortC -j redirect > --redirect-target DROP > > My major analysis has been the ubiquitous tcpdump alongwith some > utilities > > Now my questions: > > When I try 'arping' my brouter from eth0.3, the arp request which is > untagged arrives on PortA. Now since the above rule has got nothing to > do with untagged packets, it is not 'brouted' and according to the > diagram, it then moves forward to the ebtables PREROUTING chain in the > nat table. No rule there. Followed by prerouting chain in the nat and > mangle tables of 'iptables' (due to br-nf at link-layer i suppose?). > Finally reaches 'bridging decision'. > > 1. what exactly happens @bridging decision? The target MAC address > is a broadcast address. Now how does the bridging logic decide if it is > to be bridged or to be routed for an ARP request? Does it do it by > looking at the 'target protocol address' field for the arp packet? If > this is indeed true then since in case of 'arping' the brouter, this > field shd be = IP addr of the brouter. Thus the bridging logic instead > passes it to the routing code from where it is sent to the ARP code if I > interpret it correctly. Am I right on this one? Since I do get a reply > from the bridge for the arp request even when sent from a tagged > interface, I assume this is what might be happening. seeking > clarifications though. > > 2. Now I try to ping my brouter from eth0.3 as in 'ping -I eth0.3 > 192.168.5.104' .On running tcpdump on the brouter, I can see the > following: > > 13:17:53.822056 PortA.3, IN: In 00:25:11:8f:c6:21 ethertype IPv4 > (0x0800), length 100: 14.11.11.11 > 192.168.5.104: ICMP echo request > > 13:17:53.822415 br0, IN: In 00:25:11:8f:c6:21 ethertype IPv4 (0x0800), > length 100: 14.11.11.11 > 192.168.5.104: ICMP echo request > > 13:17:53.822740 br0, OUT: Out 00:0d:48:36:59:88 ethertype IPv4 (0x0800), > length 100: 192.168.5.104 > 14.11.11.11: ICMP echo request > > 13:17:53.822895 PortB, OUT: Out 00:0d:48:36:59:88 ethertype IPv4 > (0x0800), length 100: 192.168.5.104 > 14.11.11.11: ICMP echo reply > > After pinging from eth0.3 with this IP, I see that an ARP entry for > 14.11.11.11 has been registered at br0. > > I would be greatly obliged if you could shed some light on this. > > Regards, > Aijaz Baig. _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
