BGP Filter and Advertising

[melcu]

Hi mates,

Again, missed me ? 😞

I have a requirement that kinds of blows me away.

SO .. 3 routers.  A,  B (Check Point) and C

B receives from C   and advertise to A  but with a "catch".

Routes from C are marked with a community of  1:1 (It's a Cisco).

On Check Point we need the following:

if routes are received from C with community 1:1 then redistribute them to A  with a MED of 50

if routes have a different community (or no community) inject them in CKP routing table

If routes are received with community 1:2  then redistribute them to A with a MED of 200

This is where I'm stuck: Check Point doesn't do community in that format therefore I've asked the customer to create route-maps on Cisco and set for 1:1  100 and for 1:2 200

But know I have no idea how to do redistribution with different MEDs based on what's inbound.  

In Cisco World will be simple but here it blows my mind and I have horse vision right now (I've struggled with it whole weekend)

Any advice is as usual really appreciated!!

[melcu]

Yeah so I had a SR with TAC India and they said that everything works as expected. Am I stupid or what ?!
Sent me to the sk103047:For your reference, kindly review the BGP Communities section in the following SK article and follow this configuration:
https://support.checkpoint.com/results/sk/sk103047

I'm slowly burning my brain out!  Replicated this **bleep** on Cisco and it works out of the box.   match community , then to med 200,  otherwise live it untouched. 

[the_rock]

I think it would be good if you do remote with TAC, just to make sure config matches the sk, so there is no confusion.

[Lari_Luoma]

Yes, TAC case is recommended. I briefly exchanges messages with our R&D and the route map looked ok to them. They also suggested to open a case.

[melcu]

Case opened.  TAC engineer was very responsive until I showed him the issue 🙂 After that .. haha
I'm still waiting as my customer is pushing this every day. 

[the_rock]

LOL...well, lets be realistic, its NOT an issue issue, but its a true challenge.

I hope its resolved somehow.

Im still trying to many things in the lab for you.

[melcu]

For me it's not but for the customer actually it is a big deal.  Based on this "community match filter decision" traffic is moved between two datacenters.
Long story short is:

if something happens inside (after Check Point) then a router (which is capable of IP SLA 🙂 ) will mark a  route/set of routes  and advertise them to Check Point with a specific community. When this happens then Check Point should advertise those routes to the upstream router with a different MED/METRIC  and everything will be moved to the other datacenter.

Since our <if condition   then action> is not working they are blaming CP. Since it's working on Cisco , Fortigate and even Palo Alto with 'monitor'.  But it's irrelevant as their firewall is Quantum.

So yeah, not a big deal, but important.

[the_rock]

Of course its IMPORTANT! If thats what customer wants and its totally legit, sk says it should work, so there is no reason why it would not.

[Duane_Toler]

Match community works.  Your Cisco router is showing it with the metric of 200, which is what your routemap action statement says.  Add another routemap entry with "restrict" to block the other routes.

set routemap bgp-out id 20 on
set routemap bgp-out id 20 restrict

For another customer, for example, I do matching based on communities and setting actions:

set routemap TO_GWs id 30 on
set routemap TO_GWs id 30 allow
set routemap TO_GWs id 30 match community 12 as 65001 on
set routemap TO_GWs id 30 action aspath-prepend-count 2

I, and everyone else, is assuming that all of this is eBGP and not iBGP.  For iBGP, things are very different.

[the_rock]

I totally see the logic there brother. My colleague and I had to do similar for harmony sase...only thing is not sure if restrict works with same ID, but here is how we did it:

set inbound-route-filter bgp-policy 1000 based-on-as as 65001 on

set inbound-route-filter bgp-policy 1000 restrict-all-ipv4

set inbound-route-filter bgp-policy 1000 route 10.255.0.0/16 normal on

[the_rock]

Example from the sk:

set bgp communities on 
set routemap FromPeer-R3 id 10 on
set routemap FromPeer-R3 id 10 allow
set routemap FromPeer-R3 id 10 match community 300 as 30 on
set routemap FromPeer-R3 id 10 action localpref 10
set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
save config
Did you try localpref option?

[the_rock]

Wondering of any of below options would apply..

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_Advanced_Routing_AdminGuide/T...

[melcu]

It doesn't say anything.

Use community attributes to configure your BGP speaker to set, append, or modify the community of a route that controls which routing information is accepted, preferred, or distributed to other neighbors. The following table displays some special community attributes that a BGP speaker can apply.

so basically those are "special" communities

r82gwf> set routemap bgp-out id 10 match community

<Community-ID> exact no-advertise no-export no-export-subconfed none

But this exactly the opposite. I want to export if it's marked with 1:1 :))

[the_rock]

whats exact community name? 1 as 1?

[melcu]

Yes.
Advertised from CIsco side with 1:1

route-map Peer-CKP permit 10
match ip address 110
set community 1:1


Received by checkpoint marked with 1:1

Prefix Nexthop Communities

10.144.12.0/23 10.144.82.1 1:1

Routemap that maches community 1:1

set routemap bgp-out id 10 allow
set routemap bgp-out id 10 match community 1 as 1 on
set routemap bgp-out id 10 match community exact on
set routemap bgp-out id 10 action metric value 200

Them routemap exported

set bgp external remote-as 6900 export-routemap bgp-out preference 1 family inet on

What's received on the other side ? 🙂

B>* 10.144.12.0/23 [20/200] via 10.144.82.150, eth0, weight 1, 00:17:58
B>* 10.144.20.0/24 [20/200] via 10.144.82.150, eth0, weight 1, 00:17:58
B>* 10.144.70.0/24 [20/200] via 10.144.82.150, eth0, weight 1, 00:17:58
B>* 10.144.72.0/24 [20/200] via 10.144.82.150, eth0, weight 1, 00:17:58
B>* 10.144.76.0/22 [20/200] via 10.144.82.150, eth0, weight 1, 00:17:58
B>* 100.113.10.0/24 [20/200] via 10.144.82.150, eth0, weight 1, 00:17:58

Everything but with MED 200.

match filter doesn't work.

[the_rock]

This is really bugging me too...

Hasve you tried with below line?

set routemap bgp-out id 10 action community 1 as 1 on

[melcu]

I tried but "action" basically marks everything with 1:1  and sends it over to the peer.

Not something that I'm looking for. 

How the upstream receives everything with comm 1:1

GP routing table entry for 10.144.76.0/22, version 164
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.144.82.150
67000 64520
10.144.82.150 from 10.144.82.150 (10.144.70.10)
Origin incomplete, metric 200, valid, external, best (First path received)
Community: 1:1
Last update: Thu Oct 30 19:55:53 2025
BGP routing table entry for 100.113.10.0/24, version 166
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.144.82.150
67000 69000
10.144.82.150 from 10.144.82.150 (10.144.70.10)
Origin incomplete, metric 200, valid, external, best (First path received)
Community: 1:1
Last update: Thu Oct 30 19:55:53 2025

[Duane_Toler]

Keep in mind that communities are transitive attributes.  They will be passed on to the next peer.  Are you expecting to strip, or rewrite, the community as well as set the metric?

The MED is used by the next-hop peer to influence its decision on how to exit its AS when it has multiple exits to the same external AS.  If the next-hop only has 1 exit to the external AS, the MED generally will be useless.  If you want to make the current exit less-preferred, then you need to be using AS path pre-pend instead.

Here's a refresher on the BGP path attributes, if you need it:

https://www.packetswitch.co.uk/bgp-path-attributes/

[melcu]

That will only mark exported routes with comminity 1:1 but this is not something that I;m looking for. 

[the_rock]

I got nothing else, sorry mate : - (. As Lari said, please open TAC case.

[the_rock]

Make sure ebgp multihop is enabled, thats main Cisco feature.

[Lari_Luoma]

I'm asking around internally at Check Point to find a solution. Stand by!

[melcu]

So .. 4 weeks have passed  and my "trial' license expired.

Today I've reinstalled everything and reconfigured  everything (that's why IPs are different)

set routemap to-bgp id 10 on
set routemap to-bgp id 10 allow
set routemap to-bgp id 10 match community 1 as 1 on
set routemap to-bgp id 10 action metric value 200
set routemap to-bgp id 20 on
set routemap to-bgp id 20 allow
## The following items are listed under their respective command sets
## (e.g. "set bgp") and are displayed here for informational purposes:
# set bgp external remote-as 50 export-routemap to-bgp preference 1 on

My jaw dropped whey I saw this:

Default BGP configuration:

vyos@upstream:~$ sh ip route bgp
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

B>* 10.100.42.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 10.100.60.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 10.100.61.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 10.144.82.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 100.112.10.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:00:40
B>* 100.113.10.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:00:40
B>* 100.114.10.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:00:40
B>* 100.120.0.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 100.122.0.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 100.143.0.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 172.19.154.0/30 [20/0] via 192.168.86.1, eth1, weight 1, 00:22:14
B>* 172.20.0.0/30 [20/200] via 192.168.86.1, eth1, weight 1, 00:22:52
vyos@upstream:~$ ^C

Everything is advertised with "default" values. So far so good.

But then I add community 1:1 from the originating router that sends 100.112.10.0, 100.113.10.0 and 100.114.10.10

gw01> show route bgp detailed destination 100.113.10.0
Route: 100.113.10.0/24
Next Hop: 172.20.0.2, via eth4
MED: None
Local Preference: 100
Age: 21
Rank: 170
Weight: N/A
AS Path: (1000),100,Incomplete.(Id-23),comm-1.1
Local AS: 1000
Peer AS: 100
Origin: Incomplete
Originator ID: 172.20.0.2
BGP Next Hop Attribute: 172.20.0.2
Communities: 1:1

vyos@upstream:~$ sh ip route bgp
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

B>* 10.100.42.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 10.100.60.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 10.100.61.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 10.144.82.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 100.112.10.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:00:47
B>* 100.113.10.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:00:47
B>* 100.114.10.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:00:47
B>* 100.120.0.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 100.122.0.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 100.143.0.0/24 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 172.19.154.0/30 [20/0] via 192.168.86.1, eth1, weight 1, 00:24:47
B>* 172.20.0.0/30 [20/200] via 192.168.86.1, eth1, weight 1, 00:25:25

The routemap works as expected, even with 1:1  not with the actual aa:nn  community format (that was above, as 999 and comm 2000).

So now I'm so pissed off and have no idea what to do next. The only thing that changed was the fact that my initial test was on R82 with Take 39  and now gateway runs  R81.20 with Take 119.

I'm slowly dying inside! What in the name of 0 and 1  happened ?!

[the_rock]

Omg...what in the world 😂

[Duane_Toler]

This smells like the issue in PMTR-114835, but it was included in R82 JHF 36 and you said you were on JHF 39.  This same hotfix is included in R81.20 JHF 111 (thus 119, too):

If you have the spare cycles, make no changes on your configuration (be sure to do 'save config'!), then do Blink upgrade to R82 with the latest JHF.  This will let you do a quick A/B test to see if you've found another BGP issue in R82; you just might have!

If the error returns, then there's your answer.  Update the TAC case and send over the R82 CPINFO.  You can do Gaia snapshot revert to get back to the R81.20 version.

I know these things are painful to work through, and you've been as persistent as I would have been (...or is it "stubborn" 😂)!  Good work!

[the_rock]

Looks right.

[melcu]

Ha ha!  R82 Take44  and yup.  "match community" is  fully ignored and everything is sent to the upstream router with metric 200

vyos@upstream:~$ sh ip route bgp
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

B>* 10.100.42.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:28
B>* 10.100.60.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:28
B>* 10.100.61.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:28
B 10.144.70.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:32
B>* 10.144.82.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:36
B>* 100.112.10.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:32
B>* 100.113.10.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:32
B>* 100.114.10.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:32
B>* 100.120.0.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:36
B>* 100.122.0.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:36
B>* 100.143.0.0/24 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:36
B>* 172.19.154.0/30 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:28
B>* 172.20.0.0/30 [20/200] via 192.168.86.1, eth1, weight 1, 00:03:32

Geez and I've lost almost 5 weeks on this issue....  How not to love R82 😞

[the_rock]

So all good now?

[melcu]

No. Exactly the opposite! 
The "match community 1:1" is ignored and everything is redistributed with med 200, not only those that are received with 1:1.

So I just have to tell my customer: don't upgrade to R82 and you'll be fine  🙂

[the_rock]

geesh lol

[Duane_Toler]

Good that you were able to verify it quickly! Be sure to follow-up the TAC SR you have to get it escalated.  This was super frustrating, but good work on the confirmation and testing!