Large number of "MAC CTRL" packets - network port defective?

I've got a server that's displaying odd behaviour on one of it's network ports. It seems unable to process/respond to any traffic (ping etc.). Below is what is listed using 'ifconfig' (assigned static address 10.100.0.80)

eth0      Link encap:Ethernet  HWaddr 00:18:7D:0E:53:8B
          inet addr:10.100.0.80  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::218:7dff:fe0e:538b/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:802 errors:0 dropped:799 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57099 (55.7 KiB)  TX bytes:2410880 (2.2 MiB)
          Interrupt:16

There's a very large number of 'TX bytes'. If this port is directly into another machine the TX bytes continues to increase rapidly, and Wireshark picks up the following.

Wireshark capture

The only packets that aren't nonsense are the occasional ones from my laptop (like packet 28). I'm not sure what these MAC CTRL packets are or if this is a side effect of something else.

FWIW below is the capture in K12 Text format.

+---------+---------------+----------+
14:59:22,793,169   ETHER
|0   |01|80|c2|00|00|01|00|18|7d|0e|53|8b|88|08|00|01|1f|ff|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|

+---------+---------------+----------+
14:59:22,797,366   ETHER
|0   |01|80|c2|00|00|01|00|18|7d|0e|53|8b|88|08|00|01|1f|ff|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|

+---------+---------------+----------+
14:59:22,801,559   ETHER
|0   |01|80|c2|00|00|01|00|18|7d|0e|53|8b|88|08|00|01|1f|ff|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|

This seems to occur regardless if the port is setup to get a DHCP address (which it's unable to get despite being on a DHCP served network) or static address.

It's doing this both with the installed CentOS 6.6 OS (booting up as single user mode and booting normally), and when booted into a live CD/USB using CentOS 6.8, so not sure if this is a CentOS 6.X specific issue although it's not done it until now. This same server has an second Ethernet (eth1) port which appears to be operating normally.

ETA ethtool outputs as advised by grawity, eth0 is the faulty port

ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Can't see anything there that would be amiss? I'll look at the pause frames with ethtool.

"Pause" frames are sometimes used for Ethernet-level flow control.

You can see their usage being negotiated along with speed in ethtool. The odd thing here is that eth0 claims to not support pause frames, but offers their use anyway:

Settings for eth0:
        Supported pause frame use: No                       <- what eth0 supports
        Advertised pause frame use: Symmetric               <- what eth0 offers
        Link partner advertised pause frame use: Symmetric  <- what your switch offers

Of course, the NIC shouldn't be sending pause frames unless it is receiving a lot of data – and obviously if it says pause frames are unsupported, it really shouldn't be sending them at all...

Try disabling this with ethtool -A eth0 rx off tx off. (It might be a driver bug, or a hardware problem; I have no idea.) Alternatively, disable flow control on the switch for that particular port.