google / seesaw

Seesaw v2 is a Linux Virtual Server (LVS) based load balancing platform.
Apache License 2.0
5.65k stars 511 forks source link

Question: no neighbor statement issued to quagga? #27

Closed lasse-aagren closed 8 years ago

lasse-aagren commented 8 years ago

Hi,

Trying (and failing) to get seesaw to advertise through quagga I don't seem to find any neighbor statement being sent to quagga.

What I see by parsing the code is something like this being sent:

router bgp 64512
address-family ipv4 unicast
network a.b.c.d/32

Manually toying with quagga with our network guys, I can't only get it to work by adding a neighbor like:

router bgp 65500
address-family ipv4 unicast
network a.b.c.d/32
neighbor e.f.g.h remote-as 65500

I have the following in my cluster.pb:

bgp_remote_asn: 65500
bgp_local_asn: 65500
bgp_peer: <
  fqdn: "name.of.my.router."
  ipv4: "e.f.g.h/28"
>

but as I see it, this peer is not used in any of the vty.Command calls? Am I missing something?

Best regards, Lasse

4a6f656c commented 8 years ago

IIRC you currently need an /etc/quagga/bgpd.conf that contains a basic BGP configuration, in particular the neighbor statements - seesaw will then add the "network" and "no network" statements in order to advertise and withdraw anycast routes. It would be preferable that seesaw did all of the necessary BGP configuration, however I don't believe that is currently the case (that said, I'd have to go and read the code to double check).

lasse-aagren commented 8 years ago

That's what I thought as well, so I created a small bgpd.conf:

router bgp 65500
  neighbor e.f.g.h remote-as 65500

and restarted quagga. Now seesaw_engine FATALs with:

failed to advertise VIP a.b.c.d: VTY status 1: BGP is already running; AS is 65500

so it doesn't seem to like the router bgp definition to exist in advance?

4a6f656c commented 8 years ago

That looks like quagga is complaining that BGP is already running with a different ASN - my guess would be that the local ASN that you've got in your configuration is mismatched with the local ASN configured for seesaw (in other words, the 'router bgp' statement that seesaw is issuing does not match the 'router bgp' statement in the existing configuration). If they both match then I'll have to dig further...

lasse-aagren commented 8 years ago

I have a suspicion that regardless of what I write as bgp_local_asn in the config, is ignored with some hardcoded value (probably 64512). Will test.

lasse-aagren commented 8 years ago

Yup. logging the value just before router bgp ... gets send to quagga, tells me that asn used is 64512, even though I have:

bgp_remote_asn: 65500
bgp_local_asn: 65500
bgp_peer: <
  fqdn: "my.router.example.com."
  ipv4: "e.f.g.h/28"
 >

in cluster.pb.

lasse-aagren commented 8 years ago

culprit ncc/bgp.go:

// TODO(jsing): Make this configurable.
const seesawASN = uint32(64512)

https://github.com/google/seesaw/blob/master/ncc/bgp.go#L32

lasse-aagren commented 8 years ago

Could you point me in the direction of fixing this the correct way? The value is in the config. How do I access it from ncc/bgp.go?