A feasible approach for AEAD on an ethernet link? The setup is shortly this: There are two custom switches (think of an FPGA for example), both are handling 10-100 Gb/s orders of traffic from their outside facing interfaces. This is normal traffic. Then, they have a link between each other. I want to apply AEAD to secure this link, so that an eavesdropper will not be able to analyse the traffic. The restriction is this: The traffic is streaming fast and obviously there is not much time to encrypt or authenticate. 

I own both switches, so pre-configuring certificates, symmetric-keys etc. are all allowed. After bootstrapping, I can asynchronously exchange keys in-band, but no out-of-band exchange is allowed.

I am not looking for an unbreakable system, I just want to protect the traffic as much as possible. 

What would be the best approach in this case? So far my approach is: I can install certificates to both sides (for authentication), I do not know if or how I should renew them as time goes by. For encryption, I will XOR the plaintext with symmetric keys on both sides (I guess this is the fastest way). However, I consume keys much faster than I can produce. Somehow I should stretch keys or find a way to produce key streams very fast. After this point I get lost.
Don't roll your own crypto

So far my approach is: I can install certificates to both sides (for authentication), I do not know if or how I should renew them as time goes by.

This does not provide authentication in a cryptographic sense. A MITM attacker will still be able to modify data on the wire at will if the underlying encryption is not authenticated. Alone, a certificate can only be used to sign a very small value, the size of a symmetric key. It takes more than the presence of a certificate to ensure that data cannot be tampered with on the wire. For example, you would need to sign an HMAC key which ensures integrity of the messages. If this is not obvious to you, then you should not be trying to design your own cryptosystem!

I will XOR the plaintext with symmetric keys on both sides (I guess this is the fastest way).

This is called an XOR cipher and is extremely insecure, requiring just a tiny amount of known plaintext to break (the same amount as the size of the key). When you have known plaintext the same size as the key, you can simply XOR the known plaintext with the observed ciphertext to recover the key itself. Not to mention, it is highly malleable and does not provide any authentication, even if it was secure.

However, I consume keys much faster than I can produce. Somehow I should stretch keys or find a way to produce key streams very fast.

You have just invented a stream cipher. This is a cipher that takes a single key and expands it to a virtually unlimited stream of pseudorandom data called the keystream which is then added to the plaintext or ciphertext, usually via the XOR operation. A raw stream cipher, like ChaCha20 or AES in CTR mode, is malleable and not authenticated, making it insecure for your purposes. It is so malleable, in fact, that toggling a single ciphertext bit will toggle the corresponding plaintext bit. Such tampering would not be detected or prevented without a properly-implemented authentication algorithm like HMAC, GCM, or Poly1305.
Just use MACsec!
All is not lost! There is already a solution, called MACsec (IEEE 802.1ae). This is an extension to the Ethernet protocol which allows end-to-end authenticated encryption at a low computational cost. It uses AES as a cipher, run in the GCM mode for authentication. It is supported by a number of switches, routers, and operating systems, and is considered very secure.
If you are writing the HDL for the FPGAs, you can use pre-designed IP cores for MACsec, for example this FPGA core. You can also implement MACsec yourself from the published standard if you are confident in your FPGA design skills or can hire someone who is.
An additional benefit of MACsec is that, because this is a standard, it will work out-of-the-box with other compatible switches, such as Cisco's Catalyst 4500. You will not be limited to only using in-house custom switches with your own FPGAs and will not need to go through extensive and expensive cryptanalysis of your own protocol.
Any mentions of or links to commercial products should not be construed as an endorsement of the product of company.