On 22 April 2017 at 04:22, Edgar Pettijohn <ed...@pettijohn-web.com> wrote: > On 04/21/17 20:49, Anders Andersson wrote: >> >> Now to my problem: I have no connection between vether0<->vether1. >> >> # traceroute -nvq1 10.0.0.3 >> traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40 byte... >> 1 * >> 2 * >> ^C >> >> If I listen with tcpdump on the bridge, I see lots of unanswered arp >> who-has: >> >> # tcpdump -nti bridge0 >> tcpdump: listening on bridge0, link-type EN10MB >> arp who-has 10.0.0.3 tell 10.0.0.2 >> arp who-has 10.0.0.3 tell 10.0.0.2 >> ^C > > > Never done this, but maybe you need an arp proxy. Not sure which $iface to > put it on, but something like: > # arp -s 10.0.0.2 00:00:00:00:00:02 pub > > may or may not help depending on if my understanding of what I read in the > manual actually does what I think it will.
Thank you for the reply! I tried this, and it *does* help with the ARP problem. However, it only moves the problem to the next stage. # ping 10.0.0.3 PING 10.0.0.3 (10.0.0.3): 56 data bytes ^C # tcpdump -nti vether1 tcpdump: listening on vether1, link-type EN10MB 10.0.0.2 > 10.0.0.3: icmp: echo request 10.0.0.2 > 10.0.0.3: icmp: echo request 10.0.0.2 > 10.0.0.3: icmp: echo request ^C Now the pings are transmitted, and according to tcpdump, they are received on the virtual interface, it's just that there's no reply. Pinging the same interface from outside the box works great, the packets are transported through the physical interface, through the bridge, and ending up at the virtual interface which replies. Running httpd on the interface in routing domain 1 also works from the outside. I probably have to trim this down to an even smaller example in order to get any help, I realize that the initial mail was a bit much to digest. I don't really *have* to connect between the interfaces, but I expect that I will find a lot of problems with this setup in the future unless I understand all the issues involved. // Anders
