Knowledge Search


×
 

[ScreenOS] How to configure IBGP

  [KB22991] Show Article Properties


Summary:
This article provides information on how to configure BGP with a peer in the same AS.
Symptoms:
How to configure BGP with a peer in the same AS?

Solution:
IBGP is configured on the External_fw gateway, as follows:

First, ensure that you have correctly assigned the interface zone, IP address, and mode on the BGP-speaking interface:
External_fw-> set interface bgroup0 zone Trust
External_fw-> set interface bgroup0 ip 192.168.4.1/24
External_fw-> set interface bgroup0 route

Next, define the router ID and enable BGP with the correct local AS number:
 
External_fw-> set vrouter trust-vr
External_fw(trust-vr)-> set router-id 10.1.1.1
External_fw(trust-vr)-> set protocol bgp 64515
External_fw(trust-vr/bgp)-> set enable
External_fw(trust-vr/bgp)-> exit

Finally, disable IGP synchronization, define the IBGP neighbor, enable BGP on the specified interface, and make sure an IGP or static route exists to the BGP peer:
External_fw(trust-vr)-> unset protocol bgp synchronization
External_fw(trust-vr)-> set protocol bgp neighbor 192.168.6.1
remote-as 64515
External_fw (trust-vr)-> set protocol bgp neighbor 192.168.6.1
nhself-enable
External_fw(trust-vr)-> set protocol bgp neighbor 192.168.6.1 enable
External_fw(trust-vr)-> exit
Extennal_fw-> set interface bgroup0 protocol bgp
External_fw-> set vrouter trust-vr route 192.168.6.0/24 gateway
192.168.4.3

BGP peers can have several intermediate hops of non-BGP-enabled routers between them. So, IBGP peers rely on an IGP, such as OSPF, or static routes to reach their BGP neighbor.

A BGP-speaking gateway, which receives a routing update from an IBGP peer, does not propagate this update any further to any of the other IBGP peers. This is done to prevent routing loops. So, to have consistent exterior routing information across all the BGP peers in the AS, when preventing routing loops, all the BGP-speaking devices within an AS need to peer with each other; often known as the IBGP full mesh requirement. You can use route reflectors or confederations as an alternative to an IBGP full mesh.

BGP implementations do not install a received IP prefix into the routing table, unless the BGP next_hop for the route is reachable. The BGP next_hop for a route learned from an EBGP peer is typically the EBGP peer's interface IP address. However, this address is typically not reachable from within an IGP. So, in most instances, route announcements via IBGP are stamped with a modified BGP next_hop attribute, which changes the BGP next_hop from the original advertising router to the IBGP router. This is achieved through the nhself-enable configuration attribute.

You can view the status of a specific BGP peer in ScreenOS with the get vrouter <vr-name> protocol bgp neighbor <ip> command:

Code View:
 
External_fw-> get vrouter trust-vr protocol bgp neighbor 192.168.6.1
peer: 192.168.6.1, remote AS: 64515, admin status: enable
type: IBGP
connection state: ESTABLISH, connection id: 7 retry interval: 120s,
cur retry time 15s
configured hold time: node default(180s),
configured keepalive: node default(60s)
designated local IP: n/a
local IP address/port: 192.168.4.1/1047,
remote IP address/port: 192.168.6.1/179
router ID of peer: 10.1.1.9, remote AS: 64515
negotiated hold time: 180s, negotiated keepalive interval: 60s
route map in name: , route map out name:
weight: 100 (default)
self as next hop: enable
send default route to peer: disable
ignore default route from peer: disable
send community path attribute: no
reflector client: no
Neighbor Capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
force reconnect is disable
total messages to peer: 43, from peer: 39
update messages to peer: 8, from peer: 3
route-refresh messages to peer: 0, from peer: 2
last reset 00:09:51 ago, due to BGP send Notification
(Cease: Admin stopped)(code 6 : subcode 0)
number of total successful connections: 2
connected: 5 minutes 12 seconds
Elapsed time since last update: 5 minutes 11 seconds
External_fw->


The Internal_fw gateway BGP peer is configured in a manner similar to the External_fw gateway's IBGP configuration.

For the preceding configuration, the External_fw gateway has two routes, which it has learned from an EBGP peer, and it advertises them to its IBGP peer; the Internal_fw gateway. You can view the IBGP routes in the Adj-RIB-In on the Internal_fw gateway, by using the get vrouter <vr-name> protocol bgp rib-in command:
 
Internal_fw-> get vrouter trust-vr protocol bgp rib-in
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
-----------------------------------------------------------------
Total routes in rib-in: 2 (0 in flap-damping history)
-----------------------------------------------------------------
>i* 0.0.0.0/0 192.168.4.1 100 100 0 INC 65500
>i* 10.9.8.0/24 192.168.4.1 100 100 0 INC 65500
Total no. of entries shown: 2
Internal_fw->

As shown in the preceding output, the BGP next_hop for these prefixes is 192.168.4.1, which is the IP address of the IBGP peer (External_fw).

Also, you can verify the installation of these IBGP routes in the routing table of the Internal_fw gateway, by using the get vrouter <vr-name> route protocol bgp command:
 
Internal_fw-> get vrouter trust-vr route protocol bgp
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2

Total 8/max entries

ID IP-Prefix Interface Gateway P Pref Mtr Vsys
-----------------------------------------------------------------
* 10 0.0.0.0/0 eth0/0 192.168.6.3 iB 250 0 Root
* 11 10.9.8.0/24 eth0/0 192.168.6.3 iB 250 0 Root

Internal_fw->


As shown in the preceding output, ScreenOS assigns these IBGP routes a route preference of 250. In many instances, IBGP peering connections are established by using loopback addresses as endpoints for the TCP BGP connection. One of the key benefits of doing this is that if the physical path to a loopback interface experiences an outage, the IGP will re-converge over an alternative path, in most instances, before the BGP hold time expires. So, the IBGP session does not have to get torn down and rebuilt in the event of a transient path failure.

ScreenOS gateways support BGP peering by using loopback interfaces. So, using loopback interfaces, whose addresses are the same as the respective router IDs of the devices, the Internal_fw and External_fw gateways can build an IBGP peering session:
 
External_fw-> set interface loopback.1 zone Trust
External_fw-> set interface loopback.1 ip 10.1.1.1/32
External_fw-> set interface loopback.1 route
External_fw-> set vrouter trust-vr
External_fw(trust-vr)-> set router-id 10.1.1.1
External_fw(trust-vr)-> set protocol bgp 64515
External_fw(trust-vr/bgp)-> set enable
External_fw(trust-vr/bgp)-> exit
External_fw(trust-vr)-> unset protocol bgp synchronization
External_fw(trust-vr)-> set protocol bgp neighbor 10.1.1.9
remote-as 64515 src-interface loopback.1
External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.9
nhself-enable
External_fw(trust-vr)-> set protocol bgp neighbor 10.1.1.9 enable
External_fw(trust-vr)-> exit
Extennal_fw-> set interface loopback.1 protocol bgp
External_fw-> set vrouter trust-vr route 10.1.1.9/32
gateway 192.168.4.3


You can view the IBGP prefixes, which are learned by the Internal_fw gateway from the External_fw gateway, over this loopback-to-loopback IBGP peering session by using the get vrouter <vr-name> protocol bgp rib-in command:

Internal_fw-> get vrouter trust-vr protocol bgp rib-in
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
------------------------------------------------------------
Total routes in rib-in: 2 (0 in flap-damping history)
------------------------------------------------------------
>i* 0.0.0.0/0 10.1.1.1 100 100 0 INC 65500
>i* 10.9.8.0/24 10.1.1.1 100 100 0 INC 65500
Total no. of entries shown: 2
Internal_fw->



As shown in the preceding output, the BGP next_hop for these prefixes is now the loopback.1 interface address of the External_fw gateway.

Finally, you can verify the installation of these IBGP-learned prefixes in the routing table, by using the get vrouter <vr-name> route protocol bgp command:
 
Internal_fw-> get vrouter trust-vr route protocol bgp
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2

Total 9/max entries
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
-----------------------------------------------------------------
* 10 0.0.0.0/0 eth0/0 192.168.6.3 iB 250 0 Root
* 11 10.9.8.0/24 eth0/0 192.168.6.3 iB 250 0 Root

As shown in the preceding code snippet, these IBGP routes are installed in the routing table with an IGP gateway of 192.168.6.3, which is the next IGP next hop to reach the BGP 10.1.1.1 next_hop.

 
Modification History:
2017-12-07: Article reviewed for accuracy. No changes made. Article is correct and complete.
Related Links: