Arp on the Linux Bridge Port

Linux Bridge Port arp problem Linux brctladdif command can add an interface to the existing bridge, then this interface becomes a brport, belonging to a subordinate interface, however, you can still see it and add an IP address for it. then, the route command will display... linux Bridge Port arp problem Linux brctl addif command can add an interface to the existing bridge, then this interface becomes a brport, belonging to a subordinate interface, however, you can still see it and add an IP address for it. then, the route command will show that the link layer route of the newly added IP address has taken effect, all the indications are that this brport still maintains the IP semantics. However, if you use this IP address (the Linux kernel will select the source address) to access other addresses in the same network segment, you will find that, otherwise, access from the address of the same network segment cannot be obtained. why? Let me break it down. If the network on www.2cto.com is disconnected, the first step is to capture packets and find that arp is a problem at arp. arp is the life source of IPv4. if there is a problem with arp, do nothing! People who know how to implement Linux networks have long known why something went wrong, because as the subordinate brport, everything is taken over by the bridge interface, including arp, that is to say, the interface information that arp expects is about the bridge interface rather than the brport-based interface. In general, this is the case. The IP address is configured on the brport of the physical interface. Therefore, the egress device displayed on the link layer route is the brport. when sending data, the arp logic records the target IP-Mac ing under the brport, however, when arp came back, the bridge interface received it, and the kernel found that there was no arp request to be resolved under the bridge interface door, so it was discarded, therefore, it is impossible to access and configure any IP address in the same network segment on the brport from the local machine. In turn, arp requests come from other machines and are received by the bridge interface. However, when arp_process is about to reply, the reverse route query fails because of the dev parameter, the dev parameter is a bridge, but the query result is a brport, so failed. To analyze this point, you need to be very proficient in network protocols or Linux kernel protocol stacks. So how can we solve this problem? Easy, easy. use the following command: ebtables-t broute-a brouting-p ARP -- arp-ip-dst 12.12.12-j redirect -- redirect-target DROP indicates that the physical interface is used, that is, brport takes over arp instead of using the bridge interface. In order not to affect the normal process of the bridge, the target IP address is the address added to the brport.