Configuring BGP

Topics:

•

IPSec Configuration for BGP

•

Basic BGP Configuration

•

BGP Path Selection Process

•

AS_Path Prepending

•

Multiple Exit Discriminator (MED)

•

BGP Communities

•

Synchronization and Auto-Summary

•

Preventing an Accidental Transit AS

•

Using Multi-Homed BGP for Load Sharing

IPSec Configuration for BGP

BGP transmits packets in the clear. Therefore for strong security, Dell SonicWALL recommends configuring an IPSec tunnel to use for BGP sessions. The configurations of the IPSec tunnel and of BGP are independent of each other. The IPSec tunnel is configured completely within the VPN configuration section of the SonicOS GUI, while BGP is enabled on the Network > Routing page and then configured on the SonicOS Command Line Interface. When configuring BGP over IPSec, first configure the IPSec tunnel and verify connectivity over the tunnel before configuring BGP.

The following procedure shows a sample IPSec configuration between a SonicWALL and a remote BGP peer, where the SonicWALL is configured for 192.168.168.75/24 on the X0 network and the remote peer is configured for 192.168.168.35/24 on the X0 network.

Navigate to the VPN > Settings page and click the Add button under the VPN Policies section. The VPN Policies dialog displays.

In the Policy Type drop-down menu, make sure that Site to Site is selected.


	NOTE: A site-to-site VPN tunnel must be used for BGP over IPSec. Tunnel interfaces will not work for BGP.

Select the desired Authentication Method. In this example, we are using IKE using Preshared Secret.

Enter a Name for the VPN policy.

In the IPsec Primary Gateway Name or Address field, enter the IP address of the remote peer (for this example it is 192.168.168.35).

In the IPsec Secondary Gateway Name or Address field, enter 0.0.0.0.

Enter a Shared Secret and confirm it.

In the Local IKE ID field, enter the IP address of the SonicWALL (for this example it is 192.168.168.75)

In the Peer IKE ID field, enter the IP address of the remote peer (192.168.168.35).

Click on the Network tab.

For the local network, select X0 IP from the Choose local network from list drop-down menu.

For the remote network, select the remote peer’s IP address from the Choose destination network from list drop-down menu, which is 192.168.168.35 for this example. If the remote IP address is not listed, select Create new address object to create an address object for the IP address.

Click on the Proposals tab. You can either use the default IPSec proposals or customize them as you see fit.

Click on the Advanced tab.

Check the Enable Keep Alive checkbox.

Click OK.

The VPN policy is now configured on the firewall. Now complete the corresponding IPSec configuration on the remote peer. When that is complete, return to the VPN > Settings page and check the Enable checkbox for the VPN policy to initiate the IPSec tunnel.

Use the ping diagnostic on the SonicWall to ping the BGP peer IP address and use Wireshark to ensure that the request and response are being encapsulated in ESP packets.


	NOTE: As configured in this example, routed traffic will not go through the IPSEC tunnel used for BGP. That traffic is sent and received in the clear, which is most likely the desired behavior since the goal is to secure BGP, not all the routed network traffic.

Basic BGP Configuration

To configure BGP on a SonicWALL security appliance, perform the following tasks:

On the SonicOS GUI, navigate to the Network > Routing page.

In the Routing Mode drop-down menu, select Advanced Routing.

In the BGP drop-down menu, select Enabled (Configure with CLI).


	NOTE: After BGP has been enabled through the GUI, the specifics of the BGP configuration are performed using the SonicOS command line interface (CLI). For detailed information on how to connect to the SonicOS CLI, see the SonicOS Command-Line Interface Guide at: http://www.sonicwall.com/us/support/230_3623.html

Enter configuration mode by typing the configure command.

Enter the BGP CLI by typing the route ars-bgp command. You will now see the following prompt:

ZebOS version 7.7.0 IPIRouter 7/2009

ARS BGP>

You are now in BGP Non-Config Mode. Type ? to see a list of non-config commands.

Type show running-config to see the current BGP running configuration.

To enter BGP Configuration Mode, type the configure terminal command. Type ? to see a list of configuration commands.

When you have completed your configuration, type the write file command. If the unit is part of an High Availability pair or cluster, the configuration changes will be automatically conveyed to the other unit or units.

BGP Path Selection Process

The following attributes can be used to configure the BGP path selection process.

Table 116. BGP path selection process attributes
Attribute	Description
Weight	Prefer routes learned from neighbors with the highest weight set. Only relevant to the local router.
Local Preference	Administratively prefer routes learned from a neighbor. Shared with the whole AS.
Network or Aggregate paths	Prefer paths that were locally originated from the network and aggregate-address commands.
AS_PATH	Prefer the path with the shortest AS_PATH.
Origin	Prefer the path with the lowest origin type (as advertised in UPDATE messages): IGP < EGP < Incomplete.
Multi Exit Discriminator (MED)	Provides path preference information to neighbors for paths into originating AS.
Recency	Prefer the most recently received path.
Router ID	Prefer the path from the router with the lower router ID.

Weight

The weight command assigns a weight value, per address-family, to all routes learned from a neighbor. The route with the highest weight gets preference when the same prefix is learned from more than one peer. The weight is relevant only to the local router.

The weights assigned using the set weight command override the weights assigned using this command.

When the weight is set for a peer-group, all members of the peer-group will have the same weight. The command can also be used to assign a different weight to a particular peer-group member.

The following example shows weight configuration:

router bgp 12345

: neighbor 12.34.5.237 remote-as 12345

: neighbor 12.34.5.237 weight 60

router bgp 12345

: neighbor group1 peer-group

: neighbor 12.34.5.237 peer-group group1

: neighbor 67.78.9.237 peer-group group1

: neighbor group1 weight 60

Local Preference

The Local Preference attribute is used to indicate the degree of preference for each external route in an appliance’s routing table. The Local Preference attribute is included in all update messages sent to devices in the same AS. Local Preference is not communicated to outside AS. Figure 54 shows a sample topology illustrating how Local Preference affects routes between neighboring ASs.

Figure 54. BGP local preference topology

The following BGP configurations are entered on SNWL1 and SNWL2. The higher Local Preference on SNWL2 leads to SNWL2 being the preferred route advertised by AS 12345 (the SonicWALL AS) to outside ASs.

Table 117. SNWL1 and SNWL2 configurations
SNWL1 Configuration	SNWL2 Configuration
x0 = 12.34.5.228 x1 = 172.16.228.45 ------------------ router bgp 12345 neighbor 172.16.228.228 remote-as 7675 neighbor 12.34.5.237 remote-as 12345 bgp default local-preference 150	x0 = 12.34.5.237 x1 = 10.1.1.2 ------------------ router bgp 12345 neighbor 10.1.1.1 remote-as 8888 neighbor 12.34.5.228 remote-as 12345 bgp default local-preference 200

Local Preference used with Route Maps

Route Maps are similar to Access Control Lists. They consist of a series of Permit and/or Deny statements that determine how the appliance processes the routes. Route maps are applied to inbound traffic—not outbound traffic. Figure 55 shows a sample topology that uses a route map to configure local preference.

Figure 55. BGP local preference topology with route maps

The following BGP configurations are entered on SNWL1 and SNWL2.

Table 118. SNWL1 and SNWL2 configurations
SNWL1 Configuration	SNWL2 Configuration
x1 = 172.16.228.45 ------------------ router bgp 12345 neighbor 172.16.228.228 remote-as 7675 neighbor 12.34.5.237 remote-as 12345 bgp default local-preference 150	x0 = 12.34.5.237 x1 = 10.1.1.2 x4 = 10.4.4.1 ------------------ router bgp 12345 neighbor 10.1.1.1 remote-as 9999 neighbor 10.1.1.1 route-map rmap1 in neighbor 12.34.5.237 remote-as 12345 .... ip as-path access-list 100 permit ^8888$ ... route-map rmap1 permit 10 match as-path 100 set local-preference 200 route-map rmap1 permit 20 set local-preference 150

The Route Map configured on SNWL2 (rmap1) is configured to apply to inbound routes from neighbor 10.1.1.1. It has two permit conditions:

•

route-map rmap1 permit 10: This permit condition matches access list 100 that is configured to permit traffic from AS 8888 and set routes from AS 8888 to a Local Preference of 200.

•

route-map rmap1 permit 10: This permit condition sets all other traffic that doesn’t match access list 100 (i.e. traffic coming from ASs other than 8888) to a Local Preference of 150.

AS_Path Prepending

AS_Path Prepending is the practice of adding additional AS numbers at the beginning of a path update. This makes the path for this route longer, and thus decreases its preference.

AS_Path Prepending can be applied on either outbound or inbound paths. AS_Path Prepending may not be honored if it is over-ruled by a neighbor.

Table 119. Outbound and Inbound path configurations
Outbound Path Configuration	Inbound Path Configuration
router bgp 12345 bgp router-id 10.50.165.233 network 12.34.5.0/24 neighbor 10.50.165.228 remote-as 7675 neighbor 10.50.165.228 route-map long out ! route-map long permit 10 set as-path prepend 12345 12345	router bgp 7675 bgp router-id 10.50.165.228 network 7.6.7.0/24 neighbor 10.50.165.233 remote-as 12345 neighbor 10.50.165.233 route-map prepend in ! route-map prepend permit 10 set as-path prepend 12345 12345

This configuration leads to a route being installed to the neighbor 10.50.165.233 with the AS_Path Prepended as 12345 12345. This can be viewed by entering the show ip bgp command.

ARS BGP>show ip bgp

BGP table version is 98, local router ID is 10.50.165.228

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled

S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 12.34.5.0/24 10.50.165.233 0 0 12345 12345 12345 i

*> 7.6.7.0/24 0.0.0.0 100 32768 i

Total number of prefixes 2

Multiple Exit Discriminator (MED)

The set metric command can be used in a route map to make paths more or less preferable:

router bgp 7675

network 7.6.7.0/24

: neighbor 10.50.165.233 remote-as 12345

: neighbor 10.50.165.233 route-map highmetric out

route-map highmetric permit 10

: set metric 300

The Multi Exit Discriminator (MED) is an optional attribute that can be used to influence path preference. It is non-transitive, meaning it is configured on a single appliance and not advertised to neighbors in update messages. In this section, we will consider the uses of the bgp always-compare-med command and bgp deterministic-med command .

bgp always-compare-med command

The bgp always-compare-med command allows comparison of the MED values for paths from different ASs for path selection. A path with lower MED is preferred.

As an example, consider the following routes in the BGP table and the always-compare-med command is enabled:

Route1: as-path 7675, med 300

Route2: as-path 200, med 200

Route3: as-path 7675, med 250

Route2 would be the chosen path because it has the lowest MED.

If the always-compare-med command was disabled, MED would not be considered when comparing Route1 and Route2 because they have different AS paths. MED would be compared for only Route1 and Route3.

bgp deterministic-med command

The selected route is also affected by the bgp deterministic-med command, which compares MED when choosing among routes advertised by different peers in the same autonomous system.

When the bgp deterministic-med command is enabled, routes from the same AS are grouped together, and the best routes of each group are compared. If the BGP table showed:

Route1: as-path 200, med 300, internal

Route2: as-path 400, med 200, internal

Route3: as-path 400, med 250, external

BGP would have a group of Route1 and a second group of Route2 and Route3 (the same AS).

The best of each group is compared. Route1 is the best of its group because it is the only route from AS 200.

Route1 is compared to the Route2, the best of group AS 400 (the lower MED).

Since the two routes are not from the same AS, the MED is not considered in the comparison. The external BGP route is preferred over the internal BGP route, making Route3 the best route.