Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
cstaffbrad
Explorer

Bgp does not Established when Standby become Active

 

4400 Next Generation Firewall HA Appliance
Cluster Mode HA (Active,Standby) R80.40 Take 118
Configuration in place a per sk108958

We have implemented Dynamic routing protocol
as per sk108958 but when Cluster-1 is in the active state, the bgp traffic is processed
according to the implicit rule 0. But when Cluster-2 became active,
I see bgp traffic being drop by rule 100.

The workaround is to create a rule and allow the bgp traffic rule
in order to have the bgp status in the established state.

The question now is why is BGP traffic handled with implicit rule
when cluster-1 is Active? and does not apply to cluster-2 when
this becomes active?

Is this specific BGP rule necessary? is this official solution ?
is it by design or is it a bug?

sk39960 explained how to allow bgp traffic
How to allow dynamic routing protocols (OSPF, BGP, PIM, RIP, IGRP) traffic through Check Point Security Gateway
If this is the right solution, then why is the bgp traffic handled by an implicit rule?

0 Kudos
11 Replies
PhoneBoy
Admin
Admin

What precise traffic is being allowed by the implicit rule on the primary versus an explicit rule on the secondary when it is active?

0 Kudos
cstaffbrad
Explorer

ImpliedRule.JPG

0 Kudos
Albin
Contributor
Contributor

Looks like the traffic is sourced from the GW itself on the implied rule. Outgoing traffic is an implied rule.

Is the dropped traffic also sourced locally? That would be unexpected.

You need a BGP rule to accept the traffic for incoming BGP. 

cstaffbrad
Explorer

Yes, The Dropped traffic is also sourced locally.

0 Kudos
the_rock
Legend
Legend

@Albin gave a good explanation. Do you have an actual rule that would accept incoming BGP? Something for protocol 179?

0 Kudos
cstaffbrad
Explorer

I don't know if I understand your question correctly, but I think the description of the problem should answer your question.

"The workaround is to create a rule and allow the bgp traffic rule in order to have the bgp status in the established state. The question now is why is BGP traffic handled with implicit rule when cluster-1 is Active? and does not apply to cluster-2 when this becomes active?"

0 Kudos
the_rock
Legend
Legend

My bad, missed that part, sorry about that. Cant say I ever seen that before, does not make a whole lot of sense, since rule would apply to the cluster regardless. Im wondering, when member 2 is active, what does clish -c "show route bgp" show? Do you see all the BGP routes there like on member 1 that works?

0 Kudos
cstaffbrad
Explorer

No problem. Yes, I see BGP routes like 1 that works. 

0 Kudos
the_rock
Legend
Legend

I would probably open TAC case...I find that behavior very odd. Not sure if you tried rebooting  member 2 or not, but it might be worth a shot.

0 Kudos
Joerg_Schneider
Explorer

This was a old discussion without solution in checkmates. And I know nearly nothing about BGP.
My idea and question is:
Is a actual connection droped during failover or is it impossible to establish a new connection after failover?
The accepted outgoing connection is originating from member gateway-1 IP?
So I think a actual connection originating from member gateway IP cannot survive a cluster failover. How could state table entry change its source IP to member gateway-2 IP to work on the new active cluster member?

0 Kudos
Chris_Atkinson
Employee Employee
Employee

There isn't enough config detail here for a clear  picture. Granted there is also a VPN involved.

Is Graceful restart configured?

Is the Router_ID set the same on both members?

Were the BGP peer "local address" settings manipulated on one member compared to the other?

What do the precise rules allowing the traffic look like?

Do the remote devices correctly target the VIP as the BGP peer?

What version & JHF was the gateway etc

CCSM R77/R80/ELITE
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events