amd64/146358: wrong destination MAC address

Ben Smith bsmith at boltnet.com
Thu May 6 16:00:12 UTC 2010


>Number:         146358
>Category:       amd64
>Synopsis:       wrong destination MAC address
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 06 16:00:11 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     bsmith at boltnet.com
>Release:        FreeBSD 8.0-RELEASE amd64
>Organization:
Boltnet, Inc.
>Environment:
System: FreeBSD gw2.edge2 8.0-RELEASE FreeBSD 8.0-RELEASE #1: Tue May 4 13:36:59 UTC 2010 root at gw2.edge2:/usr/obj/usr/src/sys/BOLTNET amd64

        Manufacturer: Supermicro
        Product Name: X8DTU
igb0: Intel(R) PRO/1000 Network Connection version - 1.7.3> port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaec0000-0xfaedffff,0xfae9c000-0xfae9ffff irq 28 at device 0.0 on pci1
igb0: Using MSIX interrupts with 3 vectors
igb1: Intel(R) PRO/1000 Network Connection version - 1.7.3> port 0xd880-0xd89f mem 0xfae60000-0xfae7ffff,0xfae40000-0xfae5ffff,0xfae98000-0xfae9bfff irq 40 at device 0.1 on pci1

*and*

gw1# uname -a
FreeBSD gw1.edge2 8.0-RELEASE FreeBSD 8.0-RELEASE #2: Wed May  5 16:07:01 UTC 2010     root at gw1.edge2:/usr/obj/usr/src/sys/BOLTNET  amd64
igb0: Intel(R) PRO/1000 Network Connection version - 1.7.3> port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaec0000-0xfaedffff,0xfae9c000-0xfae9ffff irq 28 at device 0.0 on pci1
igb1: Intel(R) PRO/1000 Network Connection version - 1.7.3> port 0xd880-0xd89f mem 0xfae60000-0xfae7ffff,0xfae40000-0xfae5ffff,0xfae98000-0xfae9bfff irq 40 at device 0.1 on pci1
(same motherboard)


openbgpd-4.5.20090709 Free implementation of the Border Gateway Protocol, Version

        
>Description:

        Sometimes when using openbgpd the kernel table becomes decoupled/corrupt.  Packets destined for remote hosts are sent out the correct interface but with the wrong destination(next hop gateway) mac address.


gw1# bgpctl show ip bgp ben'sIP

flags destination         gateway          lpref   med aspath origin
*>    198.144.192.0/19    206.51.36.18       100     0 26769 22212 14743 22781 7961 i
*     198.144.192.0/19    206.51.37.5        100     0 14361 22212 14743 22781 7961 i
I*    198.144.192.0/19    10.3.4.2           100     0 3491 22212 14743 22781 7961 i
I*    198.144.192.0/19    10.3.5.2           100     0 3491 22212 14743 22781 7961 i

gw1# netstat -nr | grep ^198.144.192
198.144.192.0/19   206.51.36.18       UG1         8     1245  vlan2

gw1# tcpdump -nei vlan2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan2, link-type EN10MB (Ethernet), capture size 96 bytes
13:46:41.265114 00:02:fc:08:d9:82 > 00:30:48:9f:56:16, ethertype IPv4 (0x0800), length 98: ben > gw1: ICMP echo request, id 60539, seq 76, length 64
13:46:41.265122 00:30:48:9f:56:16 > 00:30:48:9f:56:3a, ethertype IPv4 (0x0800), length 98: gw1 > ben: ICMP echo reply, id 60539, seq 76, length 64

gw1# arp -an | grep 206.51.36.18
? (206.51.36.18) at 00:19:2f:7a:0c:00 on vlan2 [vlan]
gw1# arp -an | grep 56:3a
? (10.3.4.2) at 00:30:48:9f:56:3a on vlan4 [vlan]



another example:

gw2# tcpdump -nei vlan4 host inoc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan4, link-type EN10MB (Ethernet), capture size 96 bytes
06:05:29.371654 00:30:48:9f:56:16 > 00:30:48:9f:56:3b, ethertype IPv4 (0x0800), length 74: gw1.60029 > inoc.179: Flags [S], seq 50533919, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 95326947 ecr 0], length 0
06:05:30.342159 00:30:48:9f:56:16 > 00:30:48:9f:56:3b, ethertype IPv4 (0x0800), length 62: gw1.64469 > inoc.179: Flags [S], seq 2800506931, win 65535, options [mss 1460,sackOK,eol], length 0
^C
2 packets captured
37 packets received by filter
0 packets dropped by kernel
gw2# ifconfig vlan4
vlan4: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:30:48:9f:56:3a
        inet 10.3.4.2 netmask 0xffffff00 broadcast 10.3.4.255
        media: Ethernet autoselect (1000baseT full-duplex>)
        status: active
        vlan: 4 parent interface: igb0
gw2# ifconfig vlan5
vlan5: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:30:48:9f:56:3b
        inet 10.3.5.2 netmask 0xffffff00 broadcast 10.3.5.255
        media: Ethernet autoselect (1000baseT full-duplex>)
        status: active
        vlan: 5 parent interface: igb1

gw1# bgpctl show ip bgp inoc'sIP
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination         gateway          lpref   med aspath origin
I*>   208.70.82.0/23      10.3.4.2           100     0 3356 4150 15176 i
I*    208.70.82.0/23      10.3.5.2           100     0 3356 4150 15176 i
      208.70.82.0/23      206.51.36.13       100  2654 3549 1239 4150 15176 i
      208.70.82.0/23      206.51.37.5        100     0 14361 3356 4150 15176 i
gw1# !netst
netstat -nr | grep default
default            206.51.36.4        UGS         1    64713  vlan2
gw1# netstat -nr|grep ^208.70.82
208.70.82.0/24     10.3.4.2           UG1         0        0  vlan4 =>
208.70.82.0/23     10.3.4.2           UG1         6     2706  vlan4

gw1# !teln
telnet inoc 179
Trying inoc...

gw1# tcpdump -nei vlan4 host inoc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan4, link-type EN10MB (Ethernet), capture size 96 bytes
06:04:52.603694 00:30:48:9f:56:16 > 00:30:48:9f:56:3b, ethertype IPv4 (0x0800), length 74: gw1.54513 > inoc.179: Flags [S], seq 2254251043, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 95545315 ecr 0], length 0
gw1# arp -an|grep 56:3b
? (10.3.5.2) at 00:30:48:9f:56:3b on vlan5 [vlan]


gw1# sysctl -a | grep redir
net.inet.ip.redirect: 0
net.inet.icmp.log_redirect: 1
net.inet.icmp.drop_redirect: 1

after stopping openbgpd:
gw1# netstat -nr | grep ^208.70.82
208.70.82.0/24     10.3.4.2           UG1         0        0  vlan4 =>
208.70.82.0/23     10.3.4.2           UG1         6     2753  vlan4

These machines have a lot of routes:
gw1# bgpctl show
Neighbor                   AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
app1_vlan160            65030       2739       2741     0 22:04:02      5
app1_vlan120            65030       2746       2739     0 22:04:01      8
inoc                    65534       3483     379202     0 1d05h10m      0
gw2_vlan5               33616     166248     244942     0 1d05h17m 224198
gw2_vlan4               33616     166246     244935     0 1d05h17m 224198
EquinixB                25658     302028       3517     0 1d05h15m 318387
EquinixA                25658     299936       3517     0 1d05h15m 318386

which may be a factor.  This doesn't seem to happen all of the time.  A reboot will fix it, if it breaks it seems to break within a few minutes of it coming online.  It also doesn't break for all traffic.  Some traffic with the same next hop will work.

Even after /usr/local/etc/rc.d/openbgpd stop, the routes stay:

gw1# netstat -nr | grep ^208.70.82
208.70.82.0/24     10.3.4.2           UG1         0        0  vlan4 =>
208.70.82.0/23     10.3.4.2           UG1         6     2753  vlan4




        
>How-To-Repeat:

Run openbgpd with several peers, reboot test the machine a couple times.  Sometimes when it comes up it can no longer get to certain eBGP multihope peers because of this.
        
>Fix:

Rebooting (and probably also route flush?) will clear the bad routes and hopefully the problem doesn't happen again.


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-amd64 mailing list