[moved back to tech-net. tech-kern is for kernel stuff that doesn't have a sub-list.] BERTRAND Joël <joel.bertrand%systella.fr@localhost> writes: > Greg Troxel a écrit : >> >> BERTRAND Joël <joel.bertrand%systella.fr@localhost> writes: >> >>> There is no way to configure agr interfaces without attaching physical >>> interfaces. >>> >>> Is tap considered as physical interface or not ? tap has MAC >>> address thus I think that is not a limitation. And agr created with >>> tap0 and tap1 uses tap0 MAC address. >> >> They are not actually physical of course, but I don't see any reason it >> should not work. However, if no one has tried and fixed any bugs that >> stop it from working, it might well not. So I suspect digging in with >> gdb or printf might help. >> >> Also, I would suggest setting up agr with two normal ethernet interfaces >> to be really sure you are doing everything else right. > > On the same server, I use agr1 with both wm0 and wm1 without > any trouble. Thus, I'm pretty sure that this issue comes from kernel > itself. This morning, I have had a look in agr directory, but I don't > know what I'm looking for. tap0 and tap1 are registered in agr0, but > no packets are sent over enslaved interfaces... > > I'll try to fix this issue but any help will be welcome. My usual advice is to run tcpdump on every interface that's possibly relevant with -w to save the packets to a file, and then look over them later. Specifically I mean this and not live tcpdump and not wireshark. And then generating test traffic in each direction on each path. Perhaps you already did this. My second standard advice is to run "netstat -s" and save the output to a file before and after each test, and diff them, to find changes in counters that you do not expect, as well as to look for the expected changes. I would in this case also advise reading the code. I am really not familiar with agr, but I wouldn't be surprised if there have to be some agr hooks in a driver, and I further wouldn't be surprised if those hooks are present in real ethernet interfaces used for agr by others, but not present in tap. bpf works this way, but usually the person who makes the driver work the first time at all cares about bpf. You are probably the first person to care about agr/tap.
Attachment:
signature.asc
Description: PGP signature