Configuring Internal BGP in Gaia Clish

Use these commands to configure internal BGP sessions (between routers within the same autonomous system).

Syntax

set bgp internal

      {off | on}

      description "Your Text"

      graceful-restart-helper {off | on}

      graceful-restart-helper-stalepath-time seconds

      interface {all | <Name of Interface>} {off | on}

      local-address <IP Address> {off | on}

      med {<0-4294967295> | default }

      nexthop-self {off | on}

      outdelay {<0-65535> | off}

      protocol {all | bgp_internal_protocol} {off | on}

      route-refresh {off | on}

set bgp internal peer <IP Address>

      holdtime {<6-65535> | default}

      ignore-first-ashop {off | on}

      ip-reachability-detection {check-control-plane-failure | multihop | off | on}

      keepalive {<2-21845> | default}

      no-aggregator id {off | on}

      peer_type {none | no-client-reflector | reflector-client} {off | on}

      send-keepalives <off | on>

      send-route-refresh {request | route-update} {all | ipv4 | ipv6} unicast

      weight {<0-65535> | off}

Parameters

Parameter

Description

{off | on}

Enable or disable an internal BGP group.

description "Your Text"

Optional: A brief text description of the group.

med {<0-4294967295> | default}

Defines the Multi-Exit Discriminator (MED) metric used when advertising routes to all peers in this group.

If no value is specified, then no metric is propagated.

Any metric configured in redistribution policy for this peer group will override the value configured here.

Default: No MED is advertised

outdelay {<0-65535> | off}

Configures or disables the amount of time in seconds that a route must be present in the routing database before it is redistributed to BGP.

The configured value applies to all peers configured in this group.

This feature dampens route fluctuation.

Default: 0 (means that this feature is disabled)

nexthop-self {off | on}

This router sends one of its own IP addresses as the BGP next hop.

Default: off

local-address <IP Address> {off | on}

The address used on the local end of the TCP connection with the peer.

For external peers that do not have multihop enabled, the local address must be on an interface that is shared with the peer or with the peer's gateway when the gateway parameter is used.

A session with an external peer is opened only when an interface with a local address through which the peer or gateway address is directly reachable operates.

For other types of peers, a peer session is maintained when any interface with the specified local address operates.

In both cases, incoming connections are recognized as matching a configured peer only if they are addressed to the configured local address.

Default: off

Note - If you run BGP in a clusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., you must not configure the local address.

interface {all | <Name of Interface>} {off | on}

Enable or disable the specified internal peer group on all interfaces or a specific interface.

protocol {all | <BGP Internal Protocol>} {off | on}

Enable or disable all internal routing protocols on the specified internal peer group or specific internal protocols.

You can enter the following specific internal protocols: direct, rip, static, ospf, and ospfase.

peer <IP Address> peer_type {none | reflector-client | no-client-reflector} {off | on}

Specifies if this is a Route Reflector client.

  • no-client-reflector

    Peer is a 'non-client' Route Reflector.

    Enter this option to specify that a reflection client's routes are reflected only to internal BGP peers in other groups.

    Clients in the group are assumed to be direct iBGP peers of each other.

  • none

    Peer is not a Route Reflector.

    Enter this option, if you do not want to specify route reflection.

  • reflector-client

    Peer is a Route Reflector. Enter this option to specify that the local router acts as a route reflector for the group of peers named.

    That is, the local router is the route reflection server, and the named peers are route reflection clients.

    Normally, the routing daemon readvertises, or reflects, routes it receives from one of its clients to all other iBGP peers, including the other peers in that client's group.

peer <IP Address> weight <0-65535>

The weight associated with the specified peer.

BGP implicitly stores any rejected routes by not mentioning them in a route filter.

BGP explicitly mentions them within the routing table by using a restrict keyword with a negative weight.

A negative weight prevents a route from becoming active, which prevents it from being installed in the forwarding table or exported to other protocols.

This eliminates the need to break and reestablish a session upon reconfiguration if import route policy is changed.

peer <IP Address> weight off

Disables the weight associated with the specified peer.

peer <IP Address> aggregator id {off | on}

The router's aggregate attribute as zero (rather than the router ID value).

This option prevents different routers in an AS from creating aggregate routes with different AS paths.

Default: off

peer <IP Address> holdtime <6-65535>

The BGP holdtime interval, in seconds, when negotiating a connection with the specified peer.

If the BGP speaker does not receive a keepalive update or notification message from its peer within the period specified in the holdtime field of the BGP open message, the BGP connection is closed.

peer <IP Address> holdtime default

A holdtime of 180 seconds.

peer <IP Address> keepalive <2-21845>

The keepalive option is an alternative way to specify a holdtime value in seconds when negotiating a connection with the specified peer.

You can use the keepalive interval instead of the holdtime interval.

You can also use both interval, but the holdtime value must be 3 times the keepalive interval value.

peer <IP Address> keepalive default

A keepalive interval of 60 seconds.

peer <IP Address> ignore-first-ashop {off | on}

Ignore the first autonomous system number in the autonomous system path for routes learned from the corresponding peer.

Note - Set this option only if you are peering with a route server in transparent mode, that is, when the route server is configured to redistribute routes from multiple other autonomous systems without prepending its own autonomous system number.

peer <IP Address> send-keepalives {off | on}

This router always sends keepalive messages even when an update message is sufficient.

This option allows interoperability with routers that do not strictly adhere to protocol specifications regarding update.

send-route-refresh [request | route-update {all | ipv4 | ipv6} [unicast]

The router dynamically request BGP route updates from peers or respond to requests for BGP route updates.

peer <IP Address> accept-routes all

An inbound BGP policy route if one is not already configured.

Enter "all" to specify accepting routes and installing them with an invalid preference.

Depending on the local inbound route policy, these routes are then made active or inactive.

peer <IP Address> accept-routes none

An inbound BGP policy route if one is not already configured.

Enter "none" to specify deleting routes learned from a peer.

This option saves memory overhead when many routes are rejected because no inbound policy exists.

peer <IP Address> passive-tcp {off | on}

The router waits for the specified peer to issue an open message.

No TCP connections are initiated by the router.

Default: off

peer <IP Address> authtype none

Do not use an authentication scheme between peers.

Using an authentication scheme guarantees that routing information is accepted only from trusted peers.

peer <IP Address> authtype md5 secret <Secret>

Use MD5 authentication between peers.

In general, peers must agree on the authentication configuration to and from peer adjacencies.

Using an authentication scheme guarantees that routing information is accepted only from trusted peers.

peer <IP Address> throttle-count <0-65535>

The number of BGP updates to send at one time. The throttle count option limits the number of BGP updates when there are many BGP peers.

peer <IP Address> throttle count off

Disables the throttle count option.

peer <IP Address> log-state-transitions {off | on}

The router generates a log message whenever a peer enters or leave the established state.

peer <IP Address> log-warnings {off | on}

The router generates a log message whenever a warning scenario is encountered in the codepath.

peer <IP Address> trace bgp_traceoption {off | on}

Tracing options for the BGP implementation.

Log messages are saved in the /var/log/routed.log.* files.

See Trace Options.

graceful-restart-helper {off | on}

Whether the Check Point system should maintain the forwarding state advertised by peer routers even when they restart to minimize the negative effects caused by peer routers restarting.

graceful-restart-helper -stalepath-time seconds

The maximal amount of time that routes previously received from a restarting router are kept so that they can be validated again. The timer is started after the peer sends an indication that it has recovered.

route-refresh {off | on}

Re-learns routes previously sent by the BGP peer or refreshes the routing table of the peer.

The peer responds to the message with the current routing table.

Similarly, if a peer sends a route refresh request the current routing table is re-sent.

A user can also trigger a route update without having to wait for a route refresh request from the peer.

ip-reachability-detection {off | on | multihop | check-control-plane-failure}

Configure Bidirectional Forwarding Detection (BFD) on each Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. and cluster memberClosed Security Gateway that is part of a cluster. that sends or receives BFD packets.

  • "off" - The default state. Stale routes are purged when the peer goes down.

  • "on"- Sets the peer to singlehop BFD. Singlehop BFD is for a peer that is one hop away. The peer must be on a directly connected network. Make sure the Firewall policy allows UDP port 3784 in both directions.

  • "multihop" - For a peer is one or more hops away. Make sure the Firewall policy allows UDP port 4784 in both directions. The configuration on both BFD peers must be the same (both configured as multihop or singlehop).

  • "check-control-plane-failure" interprets the control plane independent flag (the C bit) received from the remote BFD peer.

    When these two conditions are met at the same time, the gateway keeps stale routes and does not purge them, for graceful restart purposes:

    1. The C-bit received from the peer is zero.

    2. BGP graceful restart is enabled.

Make sure the SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on. topology is correct (issues with incorrect Firewall topology can cause anti-spoofing to interfere with BFD traffic.