-
Notifications
You must be signed in to change notification settings - Fork 489
feat(vpcnatgw): send gratuitous arp for nexthops at natgw initialization #5607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: SkalaNetworks <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @SkalaNetworks, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request enhances the robustness of the VPC NAT gateway by ensuring that its MAC address is promptly updated on connected BGP routers upon initialization or restart. By sending gratuitous ARP for all IPv4 addresses on the external network interface, it prevents traffic blackholing that could occur when a NAT gateway is rescheduled to a different node, thereby improving network stability and availability, especially in BGP mode.
Highlights
- VPC NAT Gateway Initialization: Implemented a mechanism to send gratuitous ARP for all IPv4 addresses on the external network interface (
net1
) during the NAT gateway's initialization process. - BGP Mode Stability: Addresses an issue in BGP mode where a NAT gateway restarting on a new node would lead to outdated MAC address caches on BGP routers, causing traffic blackholing. This change ensures immediate cache updates.
- Network Reliability: Improves the overall reliability and availability of the NAT gateway service by preventing traffic disruptions caused by stale ARP caches on upstream BGP routers.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request adds a command to send gratuitous ARP packets at NAT gateway initialization, which is a crucial fix to prevent traffic blackholing in BGP mode. The implementation is a good start, but the shell command pipeline can fail silently, potentially reintroducing the very issue it aims to solve. I've provided a suggestion to make the command more robust by adding error handling and also simplifying the pipeline.
…ion (#5607) Signed-off-by: SkalaNetworks <[email protected]> (cherry picked from commit 267fb02)
Pull Request
What type of this PR
Examples of user facing changes:
This PR adds a one-liner to the script launched at the initialization of a VPC NAT gateway. The one-liner picks up every IPv4 on the external interface (the one that connects to the physical network) and sends gratuitous ARP for each of the interface.
When the NAT gateway is in pure ARP mode (which is the default mode), it doesn't serve any specific purpose.
But when the NAT gateway is in BGP mode, the external BGP router will see a nexthop address mounted on this interface (whereas in ARP mode, the nexthop is the EIP directly, which already has a gratuitous ARP feature).
The BGP router will forward traffic to this nexthop by resolving the MAC address through ARP and will cache it. If the NAT gateway restarts and is scheduled on another node, the MAC address changes, but no announcement of that change is propagated to the BGP router.
The BGP router will keep forwarding traffic to the wrong node until its cache expire. In the meantime, all the traffic is blackholed.
This fix will ensure the cache for the nexthop is updated on any neighbour of the NAT gateway when it boots up.
Which issue(s) this PR fixes
Fixes #(issue-number)