-
Notifications
You must be signed in to change notification settings - Fork 696
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
Allow testing multiple GoBGP instances on localhost. #2709
Conversation
Currently GoBGP does not accept UPDATE messages with nexthops pointing to a loopback address. This disallows multiple GoBGP instances from running at the same time on 127.0.0.0/8. This PR proposes removing this constraint when the RouterID of the current GoBGP instance itself resides within the testing subnet of 127.0.0.0/8.
routerId? |
The code just checks loopback for now: gobgp/pkg/packet/bgp/validate.go Line 172 in 8bfcc66
Are you suggesting simply to change the check for Or do you mean I have a bug here that I need to check whether next-hop == RouterID as well, even in this test environment? |
pkg/server/fsm.go
Outdated
ok, err := bgp.ValidateUpdateMsg(body, rfMap, isEBGP, isConfed) | ||
|
||
// Allow updates from loopback addresses if the GoBGP instance | ||
// itself is assigned to 127.0.0.0/8, since this can happen when |
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.
What assigned
mean?
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.
"assigned" means that the GoBGP server is expected set the next-hop attribute to one of these addresses, which generally should not happen.
The use case I have is I'm starting multiple GoBGP servers on the same host on different loopback addresses for lightweight testing. In order for this to work, I need the UPDATE messages to not be dropped when the next-hop is set to 127.0.0.0/8. I set this up by configuring Neighbor.Transport.Config.LocalAddress to the specific IP address within 127.0.0.0/8 for each test GoBGP instance.
In order to distinguish this test scenario from production scenarios, I thought the right way would be to check whether the RouterID falls within 127/8.
I wasn't able to figure out how GoBGP exactly sets the nexthop attribute, which should never be 127/8 in production use cases. Do you think there is a better way to check for this to make GoBGP more testable?
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.
You can set RouterID to anything so I don't think that it's the right way to check if nexthops points to a loopback address or not.
Why not using fsm.peerInfo.Address
or fsm.peerInfo.LocalAddress
?
The following code updates the next hop attribute:
gobgp/internal/pkg/table/path.go
Line 197 in 146b2b8
func UpdatePathAttrs(logger log.Logger, global *oc.Global, peer *oc.Neighbor, info *PeerInfo, original *Path) *Path { |
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.
Done. Check both Address
and LocalAddress
.
I think that Checking Address or LocalAddress is enough but I pushed anyway. Thanks! |
Currently GoBGP does not accept UPDATE messages with nexthops pointing to a loopback address. This disallows multiple GoBGP instances from running at the same time on 127.0.0.0/8.
This PR proposes removing this constraint when the RouterID of the current GoBGP instance itself resides within the testing subnet of 127.0.0.0/8.