I was recently involved in a project upgrading the core firewall pair from Checkpoint R71.40 SPLAT to R77.20 GAiA. While very different, a lot of the configuration is pretty straight forward, and well documented in various articles on the Checkpoint website.
This setup runs BGP on the firewalls, to learn routes from our internal VRF's and also the WAN VRF where our MPLS is connected. The main routing configuration is quite well documented in the GAiA Advanced Routing R77 Administration Guide
We did this gateway replacement with no changes to the core switches...we matched the BGP config on the gateways to the existing setup to minimise changes - and hopefully the number of things that could go wrong!
The only thing that really stood out as being particularly different, and took a little figuring out, was the route origination. It is fairly simple to redistribute routes in, but we didn't want that. We wanted the equivalent of a network statement - giving us granularity over which routes are originated and also maintaining the BGP origin code of "i".
We ended up with a config like this:
```set routemap connected-to-bgp id 10 on set routemap connected-to-bgp id 10 allow set routemap connected-to-bgp id 10 match network 10.1.0.0/24 exact set routemap connected-to-bgp id 10 match network 10.2.0.0/24 exact set routemap connected-to-bgp id 10 match protocol direct set routemap connected-to-bgp id 15 on set routemap connected-to-bgp id 15 allow set routemap connected-to-bgp id 15 match network 0.0.0.0/0 exact set routemap connected-to-bgp id 15 match protocol static set routemap connected-to-bgp id 20 on set routemap connected-to-bgp id 20 allow set routemap connected-to-bgp id 20 match protocol bgp
This works much like a standard Cisco route-map, albeit with different syntax. A number of rules, with a sequence number, processed top to bottom, with an implicit deny at the end. Rule 10 matches selected connected (direct) routes and originates them into BGP. Rule 15 matches selected static routes - in this case just the default to the internet - and originates them into BGP. Rule 20 allows BGP learned routes to be passed to neighbors. This route-map was then applied as an export-routemap to the AS:
set bgp external remote-as 65000 export-routemap "connected-to-bgp" preference 1 family inet on
We then also had an import route-map, to allow learned routes to be imported into the routing table: ```set routemap import-bgp id 10 on set routemap import-bgp id 10 allow set bgp external remote-as 65000 import-routemap "import-bgp" preference 1 on
I think the only other thing that puzzled us briefly was how the local AS and router ID were set by CLI. We ended up setting these by the web GUI and finding the relevant config:
set as 65001
set router-id 10.0.0.1
Some things in GAiA are better done in the web interface. Configuring upwards of 60 BGP peers...definitely better on CLI. Create one complete neighbor configuration, get a list of neighbors and run the whole lot through a mail merge and your config is done.