BGP-speaking routers communicate with each other by establishing peer relationships using four types of BGP messages: OPEN, KEEPALIVE, UPDATE, and NOTIFICATION. These BGP messages are communicated in Transmission Control Protocol (TCP) segments, using source and destination port 179.

BGP offers a rich set of attributes that are helpful in granularly defining routing policies. RFC 4271 defines BGP attributes in four categories:

There are three well-known, mandatory attributes that all BGP implementations should support and that are crucial in BGP path selection:

Additionally, in the context of IBGP, the LOCAL_PREF attribute is required in UPDATE messages:

Finally, here is a list of some additional BGP attributes:

Note that RFC 4360 defines an EXTENDED_COMMUNITY attribute that has similar characteristics to the COMMUNITY attribute, with two enhancements: a wider range of community values and a Type field that you can use to categorize the extended communities (e.g., route target and route origin communities).

ScreenOS firewalls run BGP within the context of a Virtual Router (VR). As discussed in Chapter 4, ScreenOS assigns a route preference to the different types of routes in a VR. Route preference becomes relevant in the context of installing the best route in the routing table when there are multiple route entries for the same destination, learned from different routing protocols. Lower route preference routes are preferred over those with higher preference. ScreenOS assigns a default route preference of 40 to EBGP routes, making them more preferred over OSPF, (default ScreenOS route preference 60) and RIP (default ScreenOS route preference 100). However, EBGP routes are less preferred than Static (default ScreenOS route preference 20) and connected (default ScreenOS route preference 0) routes. IBGP routes are assigned a default route preference of 250, making them less preferred to most other routing protocols. In the event that multiple instances of the same destination route are received from different peers, the BGP-speaking device employs a well-defined set of tie-breaking criteria to install the “best” route in its routing table. RFC 4271 specifies the sequence of steps for breaking ties.

You want to configure BGP between a ScreenOS firewall and a peer device in a different AS.

As depicted in Figure 17-1, the ScreenOS firewall is in AS 64515 and the EBGP peer is in AS 65500. The e0/0 interface of the firewall is in the Untrust zone, which is hosted in the trust-vr (the default VR for all route-mode zones).

Figure 17-1. EBGP configuration

Configure the following on the ScreenOS firewall.

First, make sure you have correctly assigned the interface zone, IP address, and mode on the BGP-speaking interface:

External_fw-> set interface ethernet0/0 zone Untrust
	External_fw-> set interface ethernet0/0 ip 10.0.0.1/24
	External_fw->set interface ethernet0/0 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, define the EBGP neighbor, and enable BGP at the interface level:

	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253
	remote-as 65500
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 enable
	External_fw (trust-vr)-> exit

	External_fw->set interface ethernet0/0 protocol bgp

This configuration starts BGP on the firewall, and permits it to receive all route advertisements from the 10.0.0.253 EBGP peer.

	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 ebgp-multihop 15

You can deploy ScreenOS firewalls directly at the external perimeter of an organization, communicating directly to a service provider or business partner’s router via EBGP. An example of such a deployment is a hosting data center where an enterprise may get a gigabit Ethernet handoff from the hosting provider’s router, and connect it directly into the ScreenOS firewall’s Untrust zone, receiving Internet routes via BGP.

Enterprises that are multihomed or have unique routing policies typically need to run BGP to ensure fully redundant reachability from the Internet. In Figure 17-1, the ScreenOS firewall resides at the perimeter of the organization’s network. The enterprise’s ASN is 64515 and the ISP’s ASN is 65500. BGP configuration parameters such as ASN and neighbor information are defined in ScreenOS in the context of the VR. In this example, we are using a single VR, the default trust-vr, for all of the zones on the firewall.

The BGP OPEN message includes the router ID of the firewall in its initial communication with a peer. Within the VR context, the BGP router ID for the firewall is configured using the set router-id <ip> command. It is not mandatory to explicitly configure a router ID in ScreenOS. When a router ID is not configured, ScreenOS uses the highest interface IP address as its router ID.

BGP KEEPALIVE messages are a “Hello” mechanism BGP uses to ensure that a peer is up and responsive. The default interval for BGP KEEPALIVE messages in ScreenOS is 60 seconds. A peer is declared “down” following the loss of three KEEPALIVE messages, that is, 180 seconds at default parameters.

You can view the BGP-specific configuration on a ScreenOS gateway using the get vrouter <vr-name> protocol bgp config command:

External_fw-> get vrouter trust-vr protocol bgp config
	set protocol bgp 64515
	set enable
	set neighbor 10.0.0.253 remote-as 65500
	set neighbor 10.0.0.253 enable
	exit
	set interface ethernet0/0 protocol bgp
	External_fw->

Notice that the configuration output does not show the router ID configuration on the gateway because the router ID is applicable to all of the routing protocols that are configured in the VR, and is not limited to the BGP configuration.

You can view the status of the configured BGP instance for a given VR using the get vrouter <vr-name> protocol bgp ScreenOS command:

	External_fw-> get vrouter trust-vr protocol bgp
	Admin State:           enable
	Local Router ID:       10.1.1.1
	Local AS number:       64515
	Hold time:             180
	Keepalive interval:    60 = 1/3 hold time, default
	Retry time:            120
	Local MED is:          0
	Always compare MED:    disable
	Local preference:      100
	Route Flap Damping:    disable
	IGP synchronization:   enable 
	Route reflector:       disable
	Cluster ID:            not set (ID = 0)
	Confederation based on RFC 1965
	Confederation:         disable (confederation ID = 0)
	Member AS:             none
	Origin default route:  disable
	Ignore default route:  disable
	External_fw->

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

	External_fw-> get vrouter trust-vr protocol bgp neighbor
	Peer AS Remote IP   Local IP  Wt  Status   State     ConnID Up/Down
	---------------------------------------------------------------------------
	  65500 10.0.0.253  10.0.0.1  100 Enabled  ESTABLISH     13 00:00:32

	total 1 BGP peers shown
	External_fw->

The ESTABLISH state shows that the BGP session is fully established with the peer. The Up/Down counter shows how long the connection has been up.

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

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.0.0.253
	peer: 10.0.0.253, remote AS: 65500, admin status: enable
	type: EBGP, multihop: 0(disable), MED: node default(0)
	connection state: ESTABLISH, connection id: 30 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: 10.0.0.1/179,
	 remote IP address/port: 10.0.0.253/1028
	router ID of peer: 10.1.1.253, remote AS: 65500
	negotiated hold time: 180s, negotiated keepalive interval: 60s
	route map in name: , route map out name:
	weight: 100 (default)
	self as next hop: disable
	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
	  Address family IPv4 Unicast: advertised
	force reconnect is disable
	total messages to peer: 15, from peer: 11
	update messages to peer: 0, from peer: 0
	route-refresh messages to peer: 0, from peer: 0
	last reset 00:03:55 ago, due to BGP send Notification
	(Cease: Admin stopped)(code 6 : subcode 0)
	number of total successful connections: 3
	connected: 3 minutes 45 seconds
	External_fw->

The detailed neighbor status includes information such as the reason for the last connection reset (identified in bold in the preceding code snippet).

A given BGP neighbor can be temporarily disabled, while keeping its configuration intact, as follows:

	External_fw-> set vrouter trust-vr
	External_fw-> set protocol bgp
	External_fw(trust-vr/bgp)-> unset neighbor 10.0.0.253 enable
	External_fw(trust-vr/bgp)->exit

Disabling a neighbor using this method and then enabling it with the set neighbor <ip> enable command in this manner performs a hard reset of the BGP neighbor connection.

Another method of performing a hard reset to a BGP connection where the peer connection is torn down and rebuilt is via the exec vrouter <rvr-name> protocol bgp neighbor <ip> command:

	extfw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	disconnect
	start to close the connection

	extfw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253 connect
	started peer 10.0.0.253's state machine

Furthermore, you can delete a BGP neighbor as follows:

	External_fw-> set vrouter trust-vr
	External_fw-> set protocol bgp
	External_fw(trust-vr/bgp)-> unset neighbor 10.0.0.253 remote-as 65500
	External_fw(trust-vr/bgp)-> exit
	External_fw(trust-vr)-> exit
	External_fw->

Finally, you can delete the entire BGP configuration for a particular VR by using the unset protocol bgp <ASN> command in a VR context:

	External_fw-> set vrouter trust-vr
	extfw(trust-vr)-> unset protocol bgp 64515
	deleting BGP instance, are you sure? y/[n] y
	External_fw(trust-vr)->

Although it is acceptable to directly define individual neighbors if you have one or a few peers, the preferred method to configure several BGP neighbors with similar parameters is to use peer groups, which are discussed in Recipe 17.3.

Recipe 17.2; Recipe 17.3; Recipe 17.4

You want to configure BGP with a peer in the same AS.

As depicted in Figure 17-2, both the External_fw and Internal_fw gateways are in AS 64515.

Figure 17-2. IBGP configuration

IBGP is configured on the External_fw gateway as follows:

First, make sure 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

As illustrated in Figure 17-2, IBGP peers can have several intermediate hops of non-BGP-enabled routers between them. Thus, IBGP peers rely on an IGP, such as OSPF, or on static routes to reach their BGP neighbor.

A BGP-speaking gateway that receives a routing update from an IBGP peer does not propagate this update any further to any other IBGP peers. This is done to prevent routing loops. Hence, to have consistent exterior routing information across all the BGP peers in the AS while 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. Hence, in most instances, route announcements via IBGP are stamped with a modified BGP next_hop attribute that 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:

	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 that it has learned from an EBGP peer, which it advertises to its IBGP peer, the Internal_fw gateway. You can view the IBGP routes in the Adj-RIB-In on the Internal_fw gateway 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 into the routing table of the Internal_fw gateway 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 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 reconverge over an alternative path in most instances before the BGP hold time expires. Hence, 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 using loopback interfaces. Thus, 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 learned by the Internal_fw gateway from the External_fw gateway over this loopback-to-loopback IBGP peering session 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 with 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
	Internal_fw->

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, the next IGP next hop to reach the BGP 10.1.1.1 next_hop.

Recipe 17.3; Recipe 17.6

You want to use peer groups to configure BGP peers with similar parameters.

As illustrated in Figure 17-3, the External_fw gateway has three IBGP peers in this topology. We will use a BGP peer group, ipeers, to configure the common parameters for the three IBGP peers defined on the External_fw gateway.

Figure 17-3. IBGP peer group configuration

Configure the following on the External_fw ScreenOS gateway:

	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 peer-group ipeers
	External_fw(trust-vr)-> set protocol bgp neighbor peer-group ipeers
	 nhself-enable
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.7
	 peer-group ipeers
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.7
	 remote-as 64515 src-interface loopback.1
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.7 enable
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.8
	 peer-group ipeers
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.8
	 remote-as 64515 src-interface loopback.1
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.8 enable
	External_fw (trust-vr)-> set protocol bgp neighbor 10.1.1.9
	 peer-group ipeers
	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 enable
	External_fw(trust-vr)-> exit
	Extennal_fw->set interface loopback.1 protocol bgp

Note that if you are using the default physical interface as the source interface for your BGP peering session, you can simply define the remote-as as a peer-group parameter, and you do not have to redefine the remote-as at the individual neighbor level and specify the source interface. Reachability to the three peering loopback addresses from the External_fw gateway is assumed through an IGP or static routes.

BGP peer groups are convenient for grouping together common configuration parameters across several peers.

You can use the following command to verify the various BGP peers:

	External_fw-> get vrouter trust-vr protocol bgp neighbor
	Peer AS Remote IP   Local IP   Wt  Status    State     ConnID Up/Down
	----------------------------------------------------------------------
	  65500 10.0.0.253  10.0.0.1  100  Enabled   ESTABLISH      3 00:07:34
	  64515 10.1.1.7    10.1.1.1  100  Enabled   ESTABLISH      15 00:05:25
	  64515 10.1.1.8    10.1.1.1  100  Enabled   ESTABLISH      16 00:03:54
	  64515 10.1.1.9    10.1.1.1  100  Enabled   ESTABLISH      11 00:06:52
	total 4 BGP peers shown
	External_fw->

ScreenOS supports the configuration of several other BGP parameters, such as route maps, timers, communities, and authentication, using peer groups.

You can verify that a given peer belongs to a peer group using the get vrouter <vr-name> protocol bgp neighbor <ip> | include group command:

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.1.1.7 |
	 include group
	peer group belongs to: ipeers
	External_fw->

You want to authenticate your BGP neighbor before exchanging routes with it.

This solution assumes that you have already configured the various commands to define a BGP neighbor, as specified in other recipes in this chapter. As depicted in Figure 17-4, the ScreenOS firewall is in AS 64515 and an EBGP peer is in AS 65500. The e0/0 interface of the firewall is in the Untrust zone, which is hosted in the trust-vr (the default VR for all route-mode zones).

Figure 17-4. EBGP neighbor authentication

To add Message Digest 5 (MD5) authentication of BGP peers to an existing BGP neighbor configuration, use the set protocol bgp neighbor <ip> md5-authentication <password> command on the ScreenOS firewall:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 md5-authentication aabbcc
	External_fw(trust-vr)->exit

ScreenOS encrypts the plain text password entered in the configuration to ensure a secure configuration file. Thus, the password aabbcc is converted into an encrypted string:

	External_fw-> get config | include md5
	set neighbor 10.0.0.253 md5-authentication
	 "E51tDTutNXrKP+sgHhClsQmV4hnShtAB0A=="
	External_fw->

To remove MD5 authentication on a BGP peer, use the unset protocol bgp neighbor <ip> md5-authentication command within a VR context:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> unset protocol bgp neighbor 10.0.0.253
	 md5-authentication
	External_fw(trust-vr)->exit

MD5 is a hash algorithm defined in RFC 1321. MD5 generates a 128-bit “message digest”, or hash, on a given set of text characters of any length. MD5 hashes are non-reversible, that is, the original text cannot be retrieved for a given hash. While certain vulnerabilities have been found in MD5 in recent years, MD5 authentication prevails as the most common method for authenticating BGP neighbors.

RFC 2385 (Protection of BGP Sessions via the TCP MD5 Signature Option) defines the mechanism for protecting BGP sessions against spoofing attacks. The implementation of MD5 signatures on the TCP segments of an authenticated BGP session flow comprises computing a 128-bit MD5 digest using the TCP pseudoheader (src/dest IP address, zero-padded protocol number, and segment length), the TCP header, the TCP segment data (if any), and the BGP neighbor password.

The BGP neighbor password is a shared secret that needs to be the same on both peers for the BGP session to come up. When the peer receives a signed TCP segment, it computes an MD5 hash on the segment using the shared secret and the various TCP segment elements described above to ensure that the computed MD5 hash matches the received MD5 hash. This confirms that the received segment is not spoofed.

The following command displays the state of the BGP neighbor and verifies that MD5 neighbor authentication is enabled:

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.0.0.253
	peer: 10.0.0.253, remote AS: 65500, admin status: enable
	type: EBGP, multihop: 0(disable), MED: node default(0)
	connection state: ESTABLISH, connection id: 3 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: 10.0.0.1/1065,
	 remote IP address/port: 10.0.0.253/179
	router ID of peer: 10.1.1.253, remote AS: 65500
	negotiated hold time: 180s, negotiated keepalive interval: 60s
	MD5 authentication: enable
	route map in name: inbound-from-isp,
	 route map out name: outbound-to-isp
	weight: 100 (default)
	self as next hop: disable
	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
	  Address family IPv4 Unicast:  advertised
	force reconnect is disable
	total messages to peer: 31, from peer: 30
	update messages to peer: 2, from peer: 1
	route-refresh messages to peer: 0, from peer: 0
	last reset 00:27:52 ago, due to peer create
	number of total successful connections: 1
	connected: 27 minutes 43 seconds
	Elapsed time since last update: 27 minutes 38 seconds
	External_fw->

Recipe 17.1

You want to define custom BGP keepalive and hold timers for your BGP peer.

Building on the BGP configuration in Recipe 17.1, you can modify the BGP keepalive and hold timers for the peering session using the set protocol bgp neighbor <ip> keepalive <seconds> and set protocol bgp neighbor <ip> hold-time <seconds> commands in a VR context:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 keepalive 15
	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 hold-time 45
	External_fw(trust-vr)-> exit
	External_fw->

If you already have a BGP peer defined, and you have BGP enabled on the respective interfaces, the only commands required for changing the keepalive and hold timers are the keepalive and hold-time command-line statements shown in the preceding code snippet, followed by a reset of the BGP neighbor connection.

As discussed in Recipe 17.1, the default BGP keepalive and hold timer values are 60 seconds and 180 seconds, respectively. You can configure BGP keepalive and hold timers on a per-peer basis or for an entire peer group. If they are configured for a peer both at the peer group and at the individual peer configuration level, the per-peer parameters override the peer-group parameters.

You can verify the keepalive and hold timer configuration for a peer using the get vrouter trust-vr protocol bgp neighbor <ip> | include keepalive command:

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.0.0.253 |
	 include keepalive
	configured hold time: 45s, configured keepalive: 15s(1/3 hold time)
	negotiated hold time: 45s, negotiated keepalive interval: 15s
	External_fw->

As shown in the preceding output, both the configured and the negotiated keepalive and hold timer values for the BGP peer are displayed.

Using the peer-group topology from Recipe 17.3 as a reference, you can configure the BGP keepalive and hold timers for a peer group using the set protocol bgp neighbor peer-group <peer-group-name> keepalive <sec> and set protocol bgp neighbor peer-group <peer-group-name> hold-time <sec> commands:

	External_fw(trust-vr)-> set protocol bgp neighbor peer-group ipeers
	 keepalive 5
	External_fw(trust-vr)->set protocol bgp neighbor peer-group ipeers
	 hold-time 15

You want to statically define the prefixes that you will announce from a ScreenOS firewall to an EBGP peer.

Building on the EBGP configuration from Recipe 17.1, as shown in Figure 17-5, this solution advertises the 172.21.1.0/24 network to the ISP router.

First, make sure you have correctly assigned the interface zone, IP address, and mode on the ScreenOS firewall’s BGP-speaking interface:

	External_fw-> set interface ethernet0/0 zone Untrust
	External_fw-> set interface ethernet0/0 ip 10.0.0.1/24
	External_fw->set interface ethernet0/0 route

Figure 17-5. Advertising routes to EBGP neighbors

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, define the BGP neighbor and the prefix(es) that you would like to advertise:

	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 remote-as
	 65500
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 enable
	External_fw (trust-vr)-> set protocol bgp network 172.21.1.0/24
	External_fw (trust-vr)-> exit

	External_fw->set interface ethernet0/0 protocol bgp

You can verify the networks defined to be advertised by a BGP instance in a VR via the get vrouter trust-vr protocol bgp network ScreenOS command:

	External_fw-> get vrouter trust-vr protocol bgp network
	network            weight check reachable-prefix   rib-in route-map
	---------------------------------------------------------------------------
	172.21.1.0/24      32768  yes   172.21.1.0/24      yes    null
	External_fw->

As shown in the preceding output, the check setting indicates that the reachability of this route should be checked before it is advertised. The reachable prefix is the same as the network to be advertised, unless explicitly specified to be different. Thus, for this recipe’s solution, the 172.21.1.0/24 IP prefix could be defined as a static route reachable via the bgroup0 interface:

	External_fw-> set vrouter trust-vr route 172.21.1.0/24 interface
	bgroup0

This 172.21.1.0/24 route could also be reachable through any other method, such as an IGP like OSPF. However, if the ScreenOS gateway does not have a route to the reachable prefix, the associated network is not advertised to the EBGP peer.

In current releases of ScreenOS, you can turn off this reachability check, which is enabled by default, with the no-check qualifier on the set protocol bgp network <prefix> statement, which forces advertisement of the route to the peer even if it is not reachable on the ScreenOS gateway:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set protocol bgp network 172.24.1.0/24 no-check
	External_fw(trust-vr)->exit

As illustrated in Figure 17-5, the ISP router advertises the 10.9.8.0/24 prefix to the External_fw ScreenOS gateway. You can view the RIB-In (Routing Information Base containing prefixes learned from BGP neighbors) on the External_fw gateway to check whether this route is being received using the get vrouter trust-vr protocol bgp rib-in ScreenOS command:

	External_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: 1 (0 in flap-damping history)
	---------------------------------------------------------------------------
	>e*    10.9.8.0/24    10.0.0.253   100   100     0   INC    65500
	Total no. of entries shown: 1
	External_fw->

The preceding output shows the correct prefix, 10.9.8.0/24, received by the ScreenOS gateway from the peer with a BGP next_hop of 10.0.0.253, the ISP router. Also, the prefix has a BGP weight of 100 (default), a BGP LOCAL_PREF value of 100 (default), a BGP MED of 0, and an INCOMPLETE origin. Finally, the BGP AS_PATH for this prefix indicates that it originates in AS 65500, which is directly connected to the External_fw gateway’s AS 64515. The * indicates that this is a valid route, and the > indicates that this is the best path to this prefix, which leads to its installation in the ScreenOS gateway’s trust-vr routing table:

	External_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
	N: NHRP
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2 trailing B: backup route

	Total 6/max entries

	  ID   IP-Prefix    Interface   Gateway     P  Pref   Mtr  Vsys
	---------------------------------------------------------------
	* 12   10.9.8.0/24   eth0/0    10.0.0.253   eB   40    0   Root

	Total number of bgp routes: 1
	External_fw->

The preceding output verifies that the 10.9.8.0/24 prefix is installed in the trust-vr routing table on the External_fw gateway. As indicated in the Introduction to this chapter, the route preference for this route is 40, the default route preference for EBGP routes.

Recipe 17.7; Recipe 17.8

You want to filter the prefix announcements to a BGP peer by using a route map.

This solution builds on the EBGP configuration from Recipe 17.6, and applies a route map in ScreenOS to filter the prefixes announced to an EBGP peer, as shown in Figure 17-6.

Figure 17-6. Filtering outbound BGP route announcements

First, make sure you have correctly assigned the interface zone, IP address, and mode on the ScreenOS firewall’s BGP-speaking interface:

	External_fw-> set interface ethernet0/0 zone Untrust
	External_fw-> set interface ethernet0/0 ip 10.0.0.1/24
	External_fw->set interface ethernet0/0 route

Next, define the router ID, enable BGP with the correct local AS number, and define the set of networks that this BGP instance can advertise to its peers:

	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 network 172.21.1.0/24
	External_fw(trust-vr/bgp)-> set network 172.24.1.0/24
	External_fw(trust-vr/bgp)-> set network 172.27.1.0/24
	External_fw(trust-vr/bgp)-> set enable
	External_fw(trust-vr/bgp)->exit

Next, define the access list that specifies the prefix that will be permitted to the ISP router peer and a route map that references the access list:

	External_fw(trust-vr)-> set access-list 1 permit ip 172.27.1.0/24 1
	External_fw(trust-vr)-> set route-map name outbound-to-isp permit 10
	External_fw(trust-vr/outbound-to-isp-10)-> set match ip 1
	External_fw(trust-vr/outbound-to-isp-10)->exit

Finally, define the BGP neighbor settings for the ISP router and apply the route map in the outbound direction to the neighbor:

	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253 remote-as
	 65500
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 route-map outbound-to-isp out
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 enable
	External_fw (trust-vr)-> exit
	External_fw->set interface ethernet0/0 protocol bgp

The route map in the solution to this recipe acts as a route filter by blocking out all IP prefixes, except 172.21.1.0/24, from being announced to the ISP router EBPG neighbor, 10.0.0.253.

The outbound-to-isp route map is applied in the out direction in the preceding configuration and, thus, only filters outbound announcements to the ISP router.

As discussed in Recipe 17.6, a candidate IP prefix needs to be reachable by the ScreenOS gateway before it gets announced to a BGP peer, prior to going through the route-map processing. You can waive this reachability requirement using the no-check qualifier on the set protocol bgp network <prefix> statement.

You can verify the BGP neighbor’s status, including information on any relevant inbound or outbound route maps, using the get vrouter <vr-name> protocol bgp neighbor <ip> command:

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.0.0.253
	peer: 10.0.0.253, remote AS: 65500, admin status: enable
	type: EBGP, multihop: 0(disable), MED: node default(0)
	connection state: ESTABLISH, connection id: 49 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: 10.0.0.1/1068,
	 remote IP address/port: 10.0.0.253/179
	router ID of peer: 10.1.1.253, remote AS: 65500
	negotiated hold time: 180s, negotiated keepalive interval: 60s
	route map in name: , route map out name: outbound-to-isp
	weight: 100 (default)
	self as next hop: disable
	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
	  Address family IPv4 Unicast: advertised
	force reconnect is disable
	total messages to peer: 27, from peer: 26
	update messages to peer: 2, from peer: 1
	route-refresh messages to peer: 0, from peer: 0
	last reset 07:42:22 ago, due to peer create
	number of total successful connections: 1
	connected: 23 minutes 20 seconds
	Elapsed time since last update: 23 minutes 16 seconds
	External_fw->

The preceding output shows the outbound-to-isp route map applied in the outbound direction for the ISP router BGP peer, 10.0.0.253.

Although a given route-map sequence number is defined for the first time using the set route-map name <route-map-name> <action> <sequence-number> command, subsequent modifications to this route-map sequence do not need to use the name or action keyword. Thus, for instance, you can set the MED on all routes that match sequence number 10 of the outbound-to-isp route map to 300 as follows:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set route-map outbound-to-isp 10
	External_fw(trust-vr)-> set metric 300
	External_fw(trust-vr)->exit

You can remove an entire route map, including all its sequences, from the ScreenOS configuration using the unset route-map <route-map-name> command:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> unset route-map outbound-to-isp
	External_fw(trust-vr)->exit

At a more granular level, you can remove individual route-map sequences using the unset route-map <route-map-name> <sequence-number> command:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> unset route-map outbound-to-isp 20
	External_fw(trust-vr)->exit

You can run the following debug command on the External_fw gateway to verify that the outbound-to-isp route map is performing outbound route filtering correctly:

	External_fw-> debug bgp rtmap
	External_fw-> debug bgp update
	External_fw-> clear dbuf
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 disconnect
	start to close the connection
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 connect
	started peer 10.0.0.253's state machine
	External_fw-> undebug all
	External_fw-> get dbuf stream
	<Additional_Output_Truncated
	## <Date/Time>: [bgp/rtmap]: o/g filter route 172.24.1.0/24 from peer
	 10.0.0.253 with rtmap outbound-to-isp
	##<Date/Time>: [bgp/rtmap]: Filter with route-map entry 10
	##<Date/Time>: [bgp/rtmap]: MATCH IP-addr: acc-list-id 1 return deny
	##<Date/Time>: [bgp/rtmap]: input-policy exit: no match in route-map
	##<Date/Time>: [bgp/update]: Txq Add Rt return: qparms->filter: 1
	##<Date/Time>: [bgp/update]: done: initial send eBGP 172.24.1.0/24 OK
	##<Date/Time>: [bgp/update]: start: initial send eBGP update
	 172.27.1.0/24
	##<Date/Time>: [bgp/update]: nhop: 0.0.0.0, bgprt->i_nhop: 0.0.0.0
	##<Date/Time>: [bgp/rtmap]: o/g filter route 172.27.1.0/24 from peer
	 10.0.0.253 with rtmap outbound-to-isp
	##<Date/Time>: [bgp/rtmap]: Filter with route-map entry 10
	##<Date/Time>: [bgp/rtmap]: MATCH IP-addr: acc-list-id 1 return permit
	##<Date/Time>: [bgp/update]: peer opun is 1: set qparm local pref: 100
	##<Date/Time>: [bgp/update]: Build Tx PA: med: 0, local pref: 100,
	 nhop: 10.0.0.1
	##<Date/Time>: [bgp/update]: add feasible prefix 172.27.1.0/24 to
	peer 10.0.0.253 Tx-q
	##<Date/Time>: [bgp/update]: done: initial send eBGP 172.27.1.0/24 OK

Thus, as shown in the preceding debug output, the outbound-to-isp route map returns a deny match for all outbound prefixes except 172.27.1.0/24.

Recipe 17.6; Recipe 17.8; Recipe 17.9

You want to aggregate route announcements to your EBGP peer to reduce the total number of advertised prefixes.

As shown in Figure 17-7, this solution configures BGP route aggregation of announcements from the External_fw ScreenOS gateway to the ISP router.

First, make sure you have correctly assigned the interface zone, IP address, and mode on the BGP-speaking interface:

	External_fw-> set interface ethernet0/0 zone Untrust
	External_fw-> set interface ethernet0/0 ip 10.0.0.1/24
	External_fw->set interface ethernet0/0 route

Figure 17-7. Aggregating route announcements to a BGP peer

Next, define the router ID, configure BGP with the correct local AS number, enable route aggregation, define the aggregate route to be advertised, and then enable BGP in the VR. Make sure you configure the set aggregate command to enable aggregation prior to enabling BGP in the VR with the set enable command:

	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 aggregate
	External_fw(trust-vr/bgp)-> set aggregate 172.27.0.0/16 summary-only
	External_fw(trust-vr/bgp)-> set enable
	External_fw(trust-vr/bgp)->exit

Finally, define the BGP neighbor, and specify the component prefixes that comprise the aggregate that gets advertised:

	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 remote-as
	 65500
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 enable
	External_fw (trust-vr)-> set protocol bgp network 172.27.1.0/24
	External_fw (trust-vr)-> set protocol bgp network 172.27.3.0/24
	External_fw (trust-vr)-> set protocol bgp network 172.27.120.0/24
	External_fw (trust-vr)-> exit
	External_fw->set interface ethernet0/0 protocol bgp

Most ISPs have inbound routing policies for EBGP peers whereby inbound prefixes longer than /24 are immediately discarded. Furthermore, to help contain the size of the Internet routing table, it is recommended that all BGP participants aggregate their routes before announcing them.

You can verify the BGP neighbor state using the get vrouter <vr-name> protocol bgp neighbor command:

	External_fw-> get vrouter trust-vr protocol bgp neighbor
	Peer AS Remote IP   Local IP   Wt  Status   State     ConnID Up/Down
	---------------------------------------------------------------------
	  65500 10.0.0.253  10.0.0.1  100  Enabled  ESTABLISH     19 00:03:25
	total 1 BGP peers shown
	External_fw->

Next, you can verify the components of the aggregate route to be present in the BGP instance in the VR with the get vrouter <vr-name> protocol bgp network command:

	External_fw-> get vrouter trust-vr protocol bgp network
	network            weight check reachable-prefix   rib-in route-map
	---------------------------------------------------------------------------
	172.27.1.0/24       32768  yes   172.27.1.0/24      yes    null
	172.27.3.0/24       32768  yes   172.27.3.0/24      yes    null
	172.27.120.0/24     32768  yes   172.27.120.0/24    yes    null
	External_fw->

Finally, you can verify the BGP aggregate route announcements from the External_fw gateway with the get vrouter <vr-name> protocol bgp aggregate command:

	External_fw-> get vrouter trust-vr protocol bgp aggregate
	The aggregate state: Enable
	-------------------------------------------------------------------
	aggregate-route as-set summary-only  suppr/advt/attribute-route-map
	-------------------------------------------------------------------
	172.27.0.0/16   no     yes           null/null/null
	External_fw->

You can check the output from a debug bgp update to verify that the aggregate summary route is being advertised while its component routes are being suppressed:

	External_fw-> debug bgp update
	External_fw-> clear dbuf
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 disconnect
	start to close the connection
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 connect
	started peer 10.0.0.253's state machine
	External_fw->
	External_fw-> undebug all
	External_fw-> get dbuf stream
	<Additional_Output_Truncated>
	##<Date/Time>: [bgp/update]: start: initial send eBGP update
	172.27.0.0/16
	##<Date/Time>: [bgp/update]: nhop: 0.0.0.0, bgprt->i_nhop: 0.0.0.0
	##<Date/Time>: [bgp/update]: peer opun is 1: set qparm local pref: 100
	##<Date/Time>: [bgp/update]: Build Tx PA: med: 0, local pref: 100,
	 nhop: 10.0.0.1
	##<Date/Time>: [bgp/update]: add feasible prefix 172.27.0.0/16 to
	 peer 10.0.0.253 Tx-q
	##<Date/Time>: [bgp/update]: done: initial send eBGP 172.27.0.0/16 OK
	<Additional_Update_Truncated>
	External_fw->

Recipe 17.6; Recipe 17.7; Recipe 17.9

You want to filter the route announcements from a BGP peer.

This solution builds on the EBGP configuration from Recipe 17.6 and applies a route map in ScreenOS to filter the prefixes received from an EBGP peer, as shown in Figure 17-8.

Figure 17-8. Filtering inbound BGP route announcements

First, make sure you have correctly assigned the interface zone, IP address, and mode on the ScreenOS firewall’s BGP-speaking interface:

	External_fw-> set interface ethernet0/0 zone Untrust
	External_fw-> set interface ethernet0/0 ip 10.0.0.1/24
	External_fw->set interface ethernet0/0 route

Next, define the router ID, enable BGP with the correct local AS number, and define the set of networks that this BGP instance can advertise to its peers:

	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

Then, define the access list that specifies the prefixes that will be accepted from the ISP router peer and a route map that references the access list:

	External_fw(trust-vr)-> set access-list 3 permit ip 10.9.8.0/24 1
	External_fw(trust-vr)-> set access-list 3 permit default-route 2
	External_fw(trust-vr)-> set route-map name inbound-from-isp permit 10
	External_fw(trust-vr/inbound-from-isp-10)-> set match ip 3
	External_fw(trust-vr/inbound-from-isp-10)->exit

Finally, define the BGP neighbor settings for the ISP router and apply the route map in the inbound direction from the neighbor:

	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253 remote-as
	 65500
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 route-map inbound-from-isp in
	External_fw (trust-vr)-> set protocol bgp neighbor 10.0.0.253 enable
	External_fw (trust-vr)-> exit
	External_fw->set interface ethernet0/0 protocol bgp

Although the low-end ScreenOS firewall appliances support a full suite of BGP features, they do not have sufficient hardware resources to accept and process a full BGP Internet routing table (in excess of 220,000 prefixes in 2007). Hence, if your ScreenOS firewall is directly connected to an ISP router that is sending a full or partial Internet routing table, it is a good idea to filter the incoming routes.

You can verify the BGP neighbor’s status, including information on any relevant inbound or outbound route maps, using the get vrouter <vr-name> protocol bgp neighbor <ip> command:

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.0.0.253
	peer: 10.0.0.253, remote AS: 65500, admin status: enable
	type: EBGP, multihop: 0(disable), MED: node default(0)
	connection state: ESTABLISH, connection id: 32 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: 10.0.0.1/179,
	 remote IP address/port: 10.0.0.253/1055
	router ID of peer: 10.1.1.253, remote AS: 65500
	negotiated hold time: 180s, negotiated keepalive interval: 60s
	route map in name: inbound-from-isp,
	 route map out name: outbound-to-isp
	weight: 100 (default)
	self as next hop: disable
	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
	  Address family IPv4 Unicast: advertised
	force reconnect is disable
	total messages to peer: 212, from peer: 199
	update messages to peer: 18, from peer: 11
	route-refresh messages to peer: 0, from peer: 0
	last reset 00:24:46 ago, due to BGP send Notification
	(Cease: Admin stopped)(code 6 : subcode 0)
	number of total successful connections: 6
	connected: 23 minutes 12 seconds
	Elapsed time since last update: 11 minutes 22 seconds
	External_fw->

The preceding output shows the inbound-from-isp route map applied in the inbound direction for the ISP router BGP peer, 10.0.0.253.

To verify that route filtering is successful, you can view the RIB-In on the ScreenOS firewall to ensure that, per access list 3 in this recipe’s solution, the ISP router receives only the 10.9.8.0/24 prefix and the default route:

	External_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)
	---------------------------------------------------------------------------
	>e*      0.0.0.0/0      10.0.0.253   100   100     0  INC   65500
	>e*    10.9.8.0/24      10.0.0.253   100   100     0  INC   65500
	Total no. of entries shown: 2
	External_fw->

As the preceding output confirms, the External_fw ScreenOS gateway is only installing the 10.9.8.0/16 route and the default route in its RIB-In from the ISP router BGP peer, 10.0.0.253.

Also, you can view the BGP routes in the routing table on the External_fw ScreenOS gateway to verify that the routes from the ISP router that were verified in the RIB-In have been installed in the routing table:

	External_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
	N: NHRP
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2 trailing B: backup route

	Total 9/max entries

	    ID   IP-Prefix   Interface   Gateway      P  Pref  Mtr    Vsys
	-----------------------------------------------------------------
	*   41   0.0.0.0/0    eth0/0   10.0.0.253     eB  40    0      Root
	*   42  10.9.8.0/24   eth0/0   10.0.0.253     eB  40    0      Root

	Total number of bgp routes: 2
	External_fw->

You can run the following debug command on the External_fw gateway to verify that the outbound-to-isp route map is performing outbound route filtering correctly:

	External_fw-> debug bgp rtmap
	External_fw-> debug bgp update
	External_fw-> clear dbuf
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 disconnect
	start to close the connection
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 connect
	started peer 10.0.0.253's state machine
	External_fw-> undebug all
	External_fw-> get dbuf stream
	##<Date/Time>: [bgp/update]: created new PA, peer 10.0.0.253
	##<Date/Time>: [bgp/update]: validate/canonical UPDATE pass
	##<Date/Time>: [bgp/update]: start: proc updt msg, peer:10.0.0.253
	##<Date/Time>: [bgp/rtmap]: start: apply policy route 10.9.8.0/24,
	 peer 10.0.0.253, rtmap inbound-from-isp
	##<Date/Time>: [bgp/rtmap]: IP addr match: acc-list-id 3 return
	permit
	##<Date/Time>: [bgp/rtmap]: done : apply policy pref 100,
	 metric 0, weight 100
	##<Date/Time>: [bgp/update]: local rib add prefix 10.9.8.0 / pref
	 100, metric 0, next-hop 10.0.0.253
	<Additional_Output_Truncated>
	##<Date/Time>: [bgp/rtmap]: start: apply policy route 10.9.5.0/24,
	 peer 10.0.0.253, rtmap inbound-from-isp
	##<Date/Time>: [bgp/rtmap]: IP addr match: acc-list-id 3 return deny
	##<Date/Time>: [bgp/rtmap]: done : apply policy, no match in route-map
	<Additional_Output_Truncated>
	##<Date/Time>: [bgp/rtmap]: start: apply policy route 0.0.0.0/0,
	 peer 10.0.0.253, rtmap inbound-from-isp
	##<Date/Time>: [bgp/rtmap]: IP addr match: acc-list-id 3 return permit
	##<Date/Time>: [bgp/rtmap]: done : apply policy pref 100, metric 0,
	 weight 100
	##<Date/Time>: [bgp/update]: local rib add prefix 0.0.0.0 / pref 100,
	 metric 0, next-hop 10.0.0.253
	##<Date/Time>: [bgp/update]: add 0.0.0.0/0 to intchg
	External_fw->

Thus, as shown in the preceding debug output, the inbound-from-isp route map denies all other IP prefixes from the 10.0.0.253 except 10.9.8.0/24 and the default route (0.0.0.0/0).

Recipe 17.7

You want to clear and update the routes received from a BGP peer without tearing down and reestablishing the BGP neighbor connection.

This solution builds on the IBGP topology used in Recipe 17.2, represented here in Figure 17-9.

Figure 17-9. Performing a soft reset with a BGP peer

You can use the clear vrouter <vr-name> protocol bgp neighbor <ip> soft-in command on the Internal_fw ScreenOS gateway to perform a soft reset and build a new Adj-RIB-In for the External_fw peer:

	Internal_fw-> clear vrouter trust-vr protocol bgp neighbor 10.1.1.1
	 soft-in

Route refresh capability, defined in RFC 2918, is a mechanism that enables a BGP speaker to request a fresh advertisement of the Adj-RIB-Out from a peer without resetting the neighbor connection. Thus, the BGP-speaking device that requests the route refresh effectively refreshes its Adj-RIB-In for that peer without resetting the peer connection.

To use route refresh to soft-reset a BGP neighbor connection, the peers need to negotiate route-refresh capability during connection establishment. You can confirm route-refresh support with a peer using the get vrouter <vr-name> protocol bgp neighbor <ip> | include refresh ScreenOS command:

	Internal_fw-> get vrouter trust-vr protocol bgp neighbor 10.1.1.1 | 
	 include refresh 
	  Route refresh: advertised and received
	route-refresh messages to peer: 1, from peer: 0
	Internal_fw->

As shown in the preceding output, ScreenOS keeps track of the number of route-refresh requests generated by the local gateway as well as the requests received by the peer.

You can verify the sequence of processing steps carried out by a ScreenOS gateway when it generates a BGP soft-in reset, thereby generating a route-refresh request, through a set of debug commands:

	Internal_fw-> debug bgp peer
	Internal_fw-> debug bgp stack
	Internal_fw-> debug bgp update
	Internal_fw-> clear dbuf
	Internal_fw-> clear vrouter trust-vr protocol bgp neighbor 10.1.1.1
	 soft-in
	<Wait_30_Seconds>
	Internal_fw-> undebug all
	Internal_fw-> get dbuf stream
	<Date/Time>: [bgp/peer]: Route-refresh req. for afi/safi: 1/1 to peer
	 is found: 10.1.1.1
	<Date/Time>: [bgp/peer]: Route-refresh req. for afi/safi: 1/1 sent
	 to peer: 10.1.1.1
	<Date/Time>: [bgp/stack]: Rx 10.1.1.1: UPDATE msg, conn-id 52
	<Date/Time>: [bgp/update]: validate/canonical UPDATE pass
	<Date/Time>: [bgp/update]: start: proc updt msg, peer:10.1.1.1
	<Date/Time>: [bgp/update]:    start: proc nlri 10.9.8.255/24
	<Date/Time>: [bgp/update]:    10.1.1.1: rcvd nlri 10.9.8.255/24
	 -duplicate ignored
	<Date/Time>: [bgp/update]:    done : proc updt msg, peer:10.1.1.1
	Internal_fw->

As shown in the preceding debug output, the ScreenOS gateway generates a full route-refresh request and then processes the received IP prefixes while the BGP session remains up.

A BGP-speaking device can also autonomously publish its set of Adj-RIB-Out prefixes to a peer without a hard reset. However, because this represents an autonomous generation of BGP UPDATE messages, this transaction does not require route-refresh capabilities to be negotiated. Hence, the External_fw gateway can send out its Adj-RIB-Out to the Internal_fw gateway through the clear vrouter <vr-name> protocol bgp neighbor <ip> soft-out command:

	External_fw-> clear vrouter trust-vr protocol bgp neighbor 10.1.1.9 
	 soft-out

You want to prefer a specific BGP path from within an AS to a destination by using the Local_Pref BGP attribute.

This solution builds on the configurations in Recipe 17.1 and Recipe 17.3, with a topology where the External_fw gateway peers with two different ISP routers and propagates the routes learned to a mesh of IBGP peers, as illustrated in Figure 17-10.

Figure 17-10. Using BGP Local_Pref for BGP path selection

With the External_fw gateway configured to peer with the two ISP routers and the three internal IBGP peers, define the access list that identifies the routes that will get assigned a specific LOCAL_PREF value and a route map that matches the access list and specifies the value:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set access-list 9 permit ip 10.9.8.0/24 1
	External_fw(trust-vr)-> set route-map name Prefer_ISP1 permit 10
	External_fw(trust-vr/Prefer_ISP1-10)-> set match ip 9
	External_fw(trust-vr/Prefer_ISP1-10)-> set local-pref 300
	External_fw(trust-vr/Prefer_ISP1-10)-> exit
	External_fw(trust-vr)->

Next, apply the route map to the external BGP peers whose routes need to be assigned a higher preference:

	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253 
	 route-map Prefer_ISP1 in
	External_fw(trust-vr)->exit

Finally, after applying the route map, restart both EBGP peering connections:

	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253 
	 disconnect
	start to close the connection
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.1.253 
	 disconnect
	start to close the connection
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253 
	 connect
	started peer 10.0.0.253's state machine
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.1.253 
	 connect
	started peer 10.0.1.253's state machine
	External_fw->

The BGP LOCAL_PREF attribute is useful in scenarios where you have a BGP gateway that is receiving the same prefix from multiple BGP peers and you want to prefer the path from a specific peer. The default LOCAL_PREF value assigned to a route in ScreenOS is 100, with higher values having greater preference than lower values.

BGP has an exhaustive path selection criteria list, where the BGP LOCAL_PREF immediately follows the BGP weight of a route (default value 100) as the attribute that gets compared with different paths to choose the best path. Because the BGP LOCAL_PREF value has precedence over most other BGP path selection attributes, such as AS_PATH Length, it prevails as the path selection criterion for the two possible paths in this recipe’s solution, whereby the route announcement from AS 65500 gets preferred.

You can check the BGP RIB-In on the External_fw gateway to verify that the route map correctly assigned the BGP LOCAL_Pref value to the route announcement from AS 65500:

	External_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)
	-------------------------------------------------------------------------
	>e*    10.9.8.0/24   10.0.0.253  100   300    0    INC   65500
	 e    10.9.8.0/24   10.0.1.253  100   100    0    IGP   65501
	Total no. of entries shown: 2
	External_fw->

As shown in the preceding output, the path from AS 65500 is chosen as the best route and is installed in the routing table:

	External_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
	N: NHRP
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2 trailing B: backup route

	Total 17/max entries

	    ID    IP-Prefix   Interface   Gateway    P  Pref Mtr Vsys
	-----------------------------------------------------------------
	*   30    10.9.8.0/24 eth0/0      10.0.0.253 eB  40   0  Root

	Total number of bgp routes: 1
	External_fw->

Furthermore, because BGP LOCAL_PREF is an attribute that gets propagated within an AS, you can verify its propagation to the Internal_fw IBGP gateway 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: 1 (0 in flap-damping history)
	-------------------------------------------------------------
	>i*  10.9.8.0/24   10.1.1.1   100   300     0   INC    65500
	Total no. of entries shown: 1
	Internal_fw->

The Introduction to this chapter; Recipe 17.2; Recipe 17.3

You want to dampen route flaps by enforcing flap dampening on the ScreenOS gateway.

This solution builds on the EBGP topology used in Recipe 17.1, represented here in Figure 17-11.

Figure 17-11. BGP route dampening configuration

You configure BGP route-flap dampening in ScreenOS using the set vrouter <vr-name> protocol bgp flap-damping command:

	External_fw-> set vrouter trust-vr protocol bgp flap-damping

The flap-damping command in ScreenOS ensures that flapping routes from BGP peers are not advertised until they become stable.

You can verify the BGP flap-damping settings and statistics in ScreenOS with the get vrouter <vr-name> protocol bgp flap-damping command:

	External_fw-> get vrouter trust-vr protocol bgp flap-damping
	Route Flap Damping             :    enabled
	Reuse                          :    1024
	Suppress Limit                 :    2048
	Max Penalty                    :    4096
	Reachable Half Life            :    5 minutes 0 seconds
	Unreachable Half Life          :    15 minutes 0 seconds
	Maximum Reachable  Hold Time   :    15 minutes 0 seconds
	Maximum Unreachable Hold Time  :    30 minutes 0 seconds
	Decay factor                   :    4

	-----------------------------------------------------------------
	total: 1 flapping, 1 suppressed(*).
	histAge/lastEvnt/TTL: seconds
	-----------------------------------------------------------------
	event prefix     peer         penalty flap histAge lastEvnt TTL
	-----------------------------------------------------------------
	*Up   10.9.8.0   10.0.0.253       3342   4     226      7   893
	External_fw->

As the preceding output illustrates, the 10.9.8.0 IP prefix from the ISP router peer has been dampened by the External_fw ScreenOS gateway as it has flapped four times in the tracking period. Furthermore, this route is now suppressed, because its penalty value of 3342 is higher than the suppress limit of 2048. Thus, this sup-pressed route is not installed in the routing table.

You can verify the RIB-In on the External_fw gateway to check the status of this flapping route:

	External_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: 3 (1 in flap-damping history)
	---------------------------------------------------------------------------
	>e*      0.0.0.0/0       10.0.0.253 100   100     0   INC   65500
	>e*     10.9.3.0/24      10.0.0.253 100   100     0   INC   65500
	 ed        10.9.8.0/24      10.0.0.253 100   100     0   INC   65500
	Total no. of entries shown: 3
	External_fw->
	External_fw->

As shown in the preceding output, the 10.9.8.0/24 IP prefix is verified to be in a dampened state, and is currently not shown by ScreenOS to be a valid route. Once the flapping stops and the penalty associated with this route drops below the suppress limit, it is reintroduced into the ScreenOS routing table.

Recipe 17.1; Recipe 17.9

You want to tag your BGP route announcements with a community string.

As illustrated in Figure 17-12, this solution builds on Recipe 17.1 by configuring a route map that defines a community string for a list of routes on the External_fw gateway. This route map is then applied to the ISP router peer configuration on the External_fw gateway to tag the routes with the community string.

Figure 17-12. Configuring BGP communities

First, define an access list with the routes to be tagged:

	External_fw-> set vrouter trust-vr access-list 8 permit ip
	 172.21.1.0/24 1
	External_fw-> set vrouter trust-vr access-list 8 permit ip
	 172.24.1.0/24 2
	External_fw->set vrouter trust-vr access-list 8 permit ip
	 172.27.1.0/24 3

Then, define the community list with the specific community string with which the routes will be tagged:

	External_fw(trust-vr)-> set protocol bgp community-list 10 permit 
	as 64515 90

Next, define a route map that references the access list and the BGP community list:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set route-map name set_community permit 10
	External_fw(trust-vr/ set_community-10)-> set match ip 8
	External_fw(trust-vr/ set_community-10)-> set community 10
	External_fw(trust-vr/ set_community-10)->exit

Finally, apply the route map on the specific BGP neighbor and specify the send-community qualifier on the neighbor:

	External_fw(trust-vr)-> set protocol bgp neighbor 10.0.0.253
	 route-map set_community out
	External_fw(trust-vr)->set protocol bgp neighbor 10.0.0.253
	 send-community

As described in the Introduction to this chapter, BGP communities are defined in RFC 1997. BGP community strings are typically used to signify a common property across the prefixes that are advertised with a common tag. Some well-known BGP communities include the NO_EXPORT and NO_ADVERTISE community tags.

In this recipe’s solution, the BGP advertisements of the IP prefixes defined in access list 8 are tagged with the 64515:90 community string.

You can use the get vrouter <vr-name> protocol bgp community-list command to view the community lists configured on a ScreenOS gateway:

	External_fw-> get vrouter trust-vr protocol bgp community-list

	community list id: 10
	community value:   64515:90->Permit
	External_fw->

You can execute a set of debug commands on the External_fw gateway to verify that the community string is being applied to the route updates to the ISP router peer:

	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 disconnect
	start to close the connection
	External_fw-> debug bgp update
	External_fw-> debug bgp rtmap
	External_fw-> debug bgp peer
	External_fw-> clear dbuf
	External_fw-> exec vrouter trust-vr protocol bgp neighbor 10.0.0.253
	 connect
	started peer 10.0.0.253's state machine
	External_fw->
	##<Date/Time>: [bgp/rtmap]: o/g filter route 172.27.1.0/24 from peer
	 10.0.0.253 with rtmap set_community
	##<Date/Time>: [bgp/rtmap]: Filter with route-map entry 10
	##<Date/Time>: [bgp/rtmap]: MATCH IP-addr: acc-list-id 8 return permit
	##<Date/Time>: [bgp/rtmap]: SET Community-List-id 10 as-list-id 10
	##<Date/Time>: [bgp/update]: peer opun is 1: set qparm local pref: 100
	##<Date/Time>: [bgp/update]: Build Tx PA: med: 0, local pref: 100,
	 nhop: 10.0.0.1
	##<Date/Time>: [bgp/update]: add feasible prefix 172.27.1.0/24 to peer
	 10.0.0.253 Tx-q
	##<Date/Time>: [bgp/update]: done: initial send eBGP 172.27.1.0/24 OK
	##<Date/Time>: [bgp/update]: start: initial send eBGP update
	 172.24.1.0/24
	External_fw->

Finally, you can verify the propagation of the community tags to the ISP router directly on the ISP router. Using a sample ScreenOS gateway as the ISP router, you can use the get vrouter <vr-name> protocol bgp comm-rib-in command to display the Adj-RIB-In with community tags:

	ISP_Router-> get vrouter trust-vr protocol bgp comm-rib-in
	Prefix: 172.24.1.0/24
	Nexthop: 10.0.0.1, Weight:100, Local Pref:0, MED:0, Flag:80, Orig:IGP
	Community: 64515:90
	AS segment type: AS_SEQUENCE, AS path:64515

	Prefix: 172.27.1.0/24
	Nexthop: 10.0.0.1, Weight:100, Local Pref:0, MED:0, Flag:88, Orig:IGP
	Community: 64515:90
	AS segment type: AS_SEQUENCE, AS path:64515

	Prefix: 172.21.1.0/24
	Nexthop: 10.0.0.1, Weight:100, Local Pref:0, MED:0, Flag:80, Orig:IGP
	Community: 64515:90
	AS segment type: AS_SEQUENCE, AS path:64515

	ISP_Router->

Recipe 17.1; Recipe 17.6; Recipe 17.7

You want to configure your ScreenOS gateways to participate in a BGP route reflector topology.

As illustrated in Figure 17-13, this solution uses a topology and a base configuration that builds on Recipe 17.3 and Recipe 17.11.

Figure 17-13. BGP route reflector configuration

The External_fw gateway is configured as a route reflector, and is assigned a cluster ID:

	External_fw-> set vrouter trust-vr
	External_fw(trust-vr)-> set protocol bgp reflector
	External_fw(trust-vr)->set protocol bgp reflector cluster-id 90

Next, all the IBGP peers in the ipeers peer group (from Recipe 17.3) are configured on the External_fw gateway as route-reflector clients:

	External_fw(trust-vr)-> set protocol bgp neighbor peer-group ipeers
	 reflector-client

The route-reflector clients in the ipeers peer group do not need to be configured with any specific parameters, and can retain their configuration from Recipe 17.3.

Route reflectors alleviate the IBGP full-mesh scaling problem by eliminating the need for all IBGP-enabled gateways in an AS to peer with each other; instead, each route-reflector-client IBGP gateway simply needs to peer with the route reflector. The route reflector and its route-reflector clients comprise a cluster, and are assigned a cluster ID. You can prevent routing loops in a route-reflector topology by using a cluster list in a routing update, whereby a BGP gateway drops an update if it sees its own cluster ID listed in it.

The get vrouter <vr-name> protocol bgp command on the External_fw gateway verifies its configuration as a route reflector:

	External_fw-> get vrouter trust-vr protocol bgp
	Admin State:           enable
	Local Router ID:       10.1.1.1
	Local AS number:       64515
	Hold time:             180
	Keepalive interval:    60 = 1/3 hold time, default
	Retry time:            120
	Local MED is:          0
	Always compare MED:    disable
	Local preference:      100
	Route Flap Damping:    enable
	IGP synchronization:   disable
	Route reflector:       enable
	Cluster ID:       90
	Confederation based on RFC 1965
	Confederation:         disable (confederation ID = 0)
	Member AS:             none
	Origin default route:  disable
	Ignore default route:  disable
	External_fw->

Furthermore, you can use the get vrouter <vr-name> protocol bgp neighbor <ip> | include reflector command on the External_fw gateway to verify that a neighbor is configured as a route-reflector client:

	External_fw-> get vrouter trust-vr protocol bgp neighbor 10.1.1.9 |
	 include reflector
	reflector client: yes
	External_fw->

Finally, the get vrouter <vr-name> protocol bgp rib-in command on one of the route-reflector clients, the Internal_fw gateway, shows the IP prefixes learned from the route reflector:

	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: 1 (0 in flap-damping history)
	--------------------------------------------------------------
	>i*    10.9.8.0/24   10.1.1.1   100  300     0   INC     65500
	Total no. of entries shown: 1
	Internal_fw->

The Introduction to this chapter; Recipe 17.3; Recipe 17.11

You want to troubleshoot BGP on a ScreenOS firewall.

To enable BGP debugging in ScreenOS to navigate through basic BGP message generation and processing, such as KEEPALIVE generation, use the debug bgp basic command:

	External_fw-> clear dbuf
	External_fw-> debug bgp basic
	<Wait for 60 seconds>
	External_fw-> undebug bgp all
	External_fw->get dbuf stream

As indicated in the preceding output, it is recommended that you clear the debug buffer before executing a new set of debug commands, and run an undebug all before viewing the debug output with the get dbuf stream command.

To troubleshoot a scenario where a BGP peer is not coming up, use a combination of the debug bgp peer, debug bgp event, and debug bgp socket commands:

	External_fw-> debug bgp peer
	External_fw-> debug bgp event
	External_fw->debug bgp socket

To troubleshoot a scenario with route maps where certain routes are not being received or sent to a peer, use a combination of the debug bgp stack and debug bgp rtmap commands:

	External_fw-> debug bgp stack
	External_fw->debug bgp rtmap

Finally, if you would like to see a verbose output with all of the ScreenOS BGP-related debug outputs, you can run the debug bgp all command:

	External_fw-> debug bgp all

ScreenOS offers a rich set of debug commands for BGP. In addition to the outputs specified in this recipe’s solution, we have discussed several instances of running BGP-specific debug commands in other recipes in this chapter.

If a BGP session is not getting established with a peer, make sure you have enabled the BGP instance in ScreenOS as well as on the specific BGP-speaking interface. You can run a get socket | include 179 command on your ScreenOS gateway to make sure you are listening on TCP port 179 as well as to see some of the other established BGP connections:

	External_fw-> get socket | include 179
	      8  tcp     listen     0.0.0.0       0   0.0.0.0       179
	      9  tcp     open       10.1.1.9    1084  10.1.1.1      179
	     11  tcp     open       10.1.1.8    1088  10.1.1.1      179
	     14  tcp     open       10.0.0.253   179  10.0.0.1     1085
	     16  tcp     open       10.0.1.253  1049  10.0.1.1      179
	     51  tcp     open       10.1.1.7     179  10.1.1.1     1087
	External_fw->

Also, you can use the debug bgp stack command, which captures the processing and generation of BGP messages, as an effective standalone BGP monitoring/diagnostic debug command. We used it here to exhibit the generation of the BGP NOTIFICATION message by the External_fw gateway:

	External_fw-> debug bgp stack
	<Wait_60_Seconds>
	External_fw-> get dbuf stream
	<Additional_Output_Truncated>
	##<Date/Time>: [bgp/stack]: send NOTIFICATION msg code (Hold-Error)
	subcode(Hold Timer Expired) to peer 10.1.1.7 via socket 52
	External_fw->

The Introduction to this chapter; Recipe 17.7; Recipe 17.8; Recipe 17.9; Recipe 17.10