BGP_Advanced_Routing
Appendix B: BGP Advanced Routing
This appendix provides an overview of SonicWALL’s implmenetation of Border Gateway protocol (BGP), how BGP operates, and how to configure BGP for your network.
This document contains the following sections:
BGP Overview
The following sections provide an overview of BGP:
What is BGP?
BGP is a large-scale routing protocol used to communicate routing information between Autonomous Systems (ASs), which are well-defined, separately administered network domains. BGP support allows for SonicWALL security appliances to replace a traditional BGP router on the edge of a network's AS. The current SonicWALL implementation of BGP is most appropriate for "single-provider / single-homed" environments, where the network uses one ISP as their Internet provider and has a single connection to that provider. SonicWALL BGP is also capable of supporting "single-provider / multi-homed" environments, where the network uses a single ISP but has a small number of separate routes to the provider. BGP is enabled on the Network > Routing page of the SonicOS GUI and then it is fully configured through the SonicOS Command Line Interface (CLI).
Background Information
Routing protocols are not just packets transmitted over a network, but comprise all the mechanisms by which individual routers, and groups of routers, discover, organize, and communicate network topologies. Routing protocols use distributed algorithms that depend on each participant following the protocol as it is specified, and are most useful when routes within a network domain dynamically change as links between network nodes change state.
Routing protocols typically interact with two databases:
The best routes chosen from the RIB are used to populate the FIB. Both the RIB and FIB change dynamically as routing updates are received by each routing protocol, or connectivity on the device changes.
There are two basic classes of routing protocols:
SonicOS supports OSPFv2 and RIPv1/v2 protocols, the two most common routing Interior Gateway Protocols, allowing our customers to use our products in their IGP networks and avoid the additional cost of a separate traditional router.
Each Autonomous System has a 16-bit number assigned. Like IP addresses, an AS number may be public or private. Public AS numbers are a limited resource and are provisioned based on a number of factors. ISP customers with large networks multi-homed to two or more ISPs usually have a public AS, whereas smaller customers will be given a private AS administered by their ISP provider.
As our products evolve in support of enterprise-level requirements, some customers may want to place our products on the edge of their AS in place of a traditional BGP router. To support these topologies, BGP has been added beginning in SonicOS 5.6.5.
Autonomous Systems
Each Autonomous System has a 16-bit number assigned. Like IP addresses, an AS number may be public or private. Public AS numbers are a limited resource and are provisioned based on a number of factors. ISP customers with large networks multi-homed to two or more ISPs usually have a public AS, whereas smaller customers will be given a private AS administered by their ISP provider.
Types of BGP Topologies
BGP is a very flexible and complex routing protocol. As such, BGP routers may be placed in a large variety of topology settings, such as Internet core routers, intermediary ISP routers, ISP Customer Premises Equipment (CPE), or routers in small private BGP networks. The number of BGP routes required for different topologies varies from greater than 300,000 for core routers, to 0 for ISP customers that use a single ISP and use default routing for all destinations outside of their AS. ISP customers are often required to run BGP from their edge router (the CPE) to the ISP regardless of the number of routes they receive from the ISP. This allows ISP customers to control which networks to advertise to the outside world. There's always the fear that a customer will advertise a network, or network aggregate, not owned by the customer, black-holing Internet traffic to those networks. In reality, ISP providers are careful to filter invalid advertisements from their customers (one of BGP's strengths), so this rarely happens.
There are three basic scales of BGP networks:
Why Use BGP?
How Does BGP Work?
BGP uses TCP port 179 for communication. BGP is considered a path-vector protocol, containing end-to-end path descriptions for destinations. BGP neighbors can either be internal (iBGP) or external (eBGP):
Paths are advertised in UPDATE messages that are tagged with various path attributes. AS_PATH and NEXT_HOP are the two most important attributes that describe the path of a route in a BGP update message.
BGP Finite State Machine
RFC 1771, which defines BGP, describes the operation of BGP in terms of the following state machine. The table following the diagram provides additional information on the various states.
Figure A:78: BGP Finite State Machine
|
BGP Messages
BGP communication includes the following types of messages
|
BGP Attributes
BGP update messages can include the following attributes:
|
For more information on BGP attributes, see: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml
Caveats
Currently, our implementation is most appropriate for the single-provider / single-homed customers. Single-provider / multi-homed installations may also be appropriate when either the default route is being received from the ISP, or a very small number of ISP-specific routes are received by the customer. The latter allows inside routers to take the optimal path to destinations outside of the AS, but still within the ISP's network domain (this is called partial-routes).
Configuring BGP
The following sections describe how to configure BGP Advanced Routing for SonicOS:
IPSec Configuration for BGP
BGP transmits packets in the clear. Therefore for strong security, 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.
Note: A site-to-site VPN tunnel must be used for BGP over IPSec. Tunnel interfaces will not work for BGP.
The VPN policy is now configured on the SonicWALL appliance. 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.
For more detailed information on configuring IPSec, see the VPN chapters in the SonicOS Enhanced Administrator’s Guide.
Basic BGP Configuration
To configure BGP on a SonicWALL security appliance, perform the following tasks:
Note: After BGP has been enabled thorugh the GUI, the speicifcs 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
ZebOS version 7.7.0 IPIRouter 7/2009
ARS BGP>
BGP Path Selection Process
The following attributes can be used to configure the BGP path selection process.
|
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. The following figure shows a sample topology illustrating how Local Preference affects routes between neighboring ASs.
Figure A:79: 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.
|
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. The following diagram shows a sample topology that uses a route map to configure local preference.
Figure A:80: BGP Local Preference topology with Route Maps
The following BGP configurations are entered on SNWL1 and SNWL2.
|
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:
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.
|
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 and bgp deterministic-med commands.
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.
BGP Communities
A community is a group of prefixes that share some common property and can be configured with the transitive BGP community attribute. A prefix can have more than one community attribute. Routers can act on one, some or all the attributes. BGP communities can be thought of as a form of tagging. The following is an example of a BGP communities configuration.
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
network 23.45.6.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 10.50.165.228 send-community
neighbor 10.50.165.228 route-map comm out
!
access-list 105 permit 12.34.5.0/24
access-list 110 permit 23.45.6.0/24
!
route-map comm permit 10
match ip address 105
set community 7675:300
!
route-map comm permit 20
match ip address 110
set community 7675:500
!
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 shape in
!
ip community-list 1 permit 7675:300
ip community-list 2 permit 7675:500
!
route-map shape permit 10
match community 1
set local preference 120
route-map shape permit 20
match community 2
set local preference 130
Synchronization and Auto-Summary
The synchronization setting controls whether the router advertises routes learned from an iBGP neighbor based on the presence of those routes in its IGP. When synchronization is enabled, BGP will only advertise routes that are reachable through OSPF or RIP (the Exterior Gateway Protocols as opposed to BGP, the Exterior Gateway Protocol). Synchronization is a common cause of BGP route advertisement problems.
The auto-summary setting controls whether or not routes are advertised classfully. Auto-summary is another common cause of BGP configuration problems
By default, auto-summary and synchronization are disabled on Zebos.
Preventing an Accidental Transit AS
As we discussed earlier, an AS peer can either be a transit peer (allowing traffic from an outside AS to another outside AS) or a non-transit peer (requiring all traffic to either originate or terminate on its AS). Transit peers will have dramatically larger routing tables. Typically, you will not want to configure a SonicWALL security appliance as a transit peer.
Figure A:81: Transit Peers vs. Non-Transit Peers
To prevent your appliance from inadvertently becoming a transit peer, you will want to configure inbound and outbound filters, such as the following:
Outbound Filters
Permit only routes originated from the local AS out:
ip as-path access-list 1 permit ^$
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 filter-list 1 out
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 filter list 1 out
Permit only owned prefixes out:
ip prefix-list myPrefixes seq 5 permit 12.34.5.0/24
ip prefix-list myPrefixes seq 10 permit 23.45.6.0/24
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
network 23.45.6.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 prefix-list myPrefixes out
neighbor 172.1.1.2 prefix-list myPrefixes out
Inbound Filters
Drop all owned and private inbound prefixes
ip prefix-list unwantedPrefixes seq 5 deny 12.34.5.0/24 le 32
ip prefix-list unwantedPrefixes seq 10 deny 23.45.6.0/24 le 32
ip prefix-list unwantedPrefixes seq 20 deny 10.0.0.0/8 le 32
ip prefix-list unwantedPrefixes seq 21 deny 172.16.0.0/12 le 32
ip prefix-list unwantedPrefixes seq 22 deny 192.168.0.0/16 le 32
ip prefix-list unwantedPrefixes seq 30 permit 0.0.0.0/0 le 32
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
network 23.45.6.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 prefix-list unwantedPrefixes in
neighbor 172.1.1.2 prefix-list unwantedPrefixes in
Using Multi-Homed BGP for Load Sharing
The following topology shows an example where a SonicWALL security appliance uses a multi-homed BGP network to load share between two ISPs.
Figure A:82:
Multi-Homed BGP for Load Sharing Topology
The SonicWALL security appliance is configured as follows:
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 ISP1 out
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 route-map ISP2 out
!
route-map ISP1 permit 10
match ip address 1
set weight 100
route-map ISP1 permit 20
match ip address 2
route-map ISP2 permit 10
match ip address 1
route-map ISP2 permit 20
match ip address 2
set weight 100
access-list 1 permit 12.34.5.0/25
access-list 2 deny 12.34.5.0/25
access-list 2 permit any
Verifying BGP Configuration
The following sections describe methods to verify a BGP configuration:
Viewing BGP Routes
Figure A:83 shows a basic BGP topology where a SonicWALL security appliance is configured for BGP to connect to two routers on two different ASs.
Figure A:83: BGP Topology
The routes in the FIB for this network can be viewed either in the SonicOS GUI or by using the CLI.
Viewing FIB routes in the GUI
A summary of the BGP configuration can be viewed on the SonicOS GUI through the Network > Routing page by clicking the BGP Status button, located at the top of the page next to the Routing Mode pulldown menu. The BGP Status window displays the output of the show ip bgp summary and show ip bgp neighbor commands.
The BGP routes in the FIB can also be viewed on the SonicOS GUI in the Routing Policies table on the Network > Routing page.
Viewing FIB Routes in the CLI
To view the FIB routes in the CLI, perform the following commands:
SonicWALL> configure
(config[SonicWALL])> route ars-nsm
ZebOS version 7.7.0 IPIRouter 7/2009
ARS NSM>show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
B 7.6.7.0/24 [20/0] via 10.50.165.228, X1, 05:08:31
B 199.199.0/16 [20/0] via 10.50.165.237, X1, 05:08:31
C 10.50.165.192/26 is directly connected, X1
C 127.0.0.0/8 is directly connected, lo0
C 12.34.5.0/24 is directly connected, X0
Viewing RIB Routes in the CLI
To view the RIB routes in the CLI, enter the show ip bgp command:
ARS BGP>show ip bgp
BGP table version is 98, local router ID is 10.50.165.233
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
*> 7.6.7.0/24 10.50.165.228 0 0 7675 i
*> 12.34.5.0/24 0.0.0.0 100 32768 i
*> 199.199.0.0/16 10.50.165.228 0 0 7675 9999 i
Total number of prefixes 3
Note: The last route is the path to AS9999 that was learned through AS7675.
Configuring BGP Logging
SonicWALL BGP offers a comprehensive selection of debug commands to display log events related to BGP traffic. BGP logging can be configured on the CLI by using the debug bgp command followed by of the following keywords:
|
To disable BGP debugging, enter the “no” form of the command. For example, to disable event debugging, type the no debug events command.
BGP log messages can also be viewed on the SonicOS GUI on the Log > View page. BGP messages are displayed as part of the Advanced Routing category of log messages.
The above message indicates that an update to the outgoing RIB was denied because the router from which the update was received was not directly connected to the appliance.
To allow for BGP peers that are not directly connected, use the ebgp-multihop keyword with the neighbor command. For example:
neighbor 10.50.165.228 ebgp-multihop
BGP Terms
ARD – Autonomous Routing Domain – A collection of networks/routers that have a common administrative routing policy.
AS - Autonomous System – An ARD that has been assigned an identifying number, typically running BGP4 at its border router(s).
BGP4: - Border Gateway Protocol 4: The most prevalent EGP.
CIDR – Classless inter-domain routing, enables efficient route advertisement through route aggregation.
CPE – Customer Premise Equipment - The equipment at the edge of a customer's network used to interface with the ISP.
EGP - Exterior Gateway Protocol – Any protocol (in practice, BGP4) used to communicate routing information between Autonomous Systems.
Full-Routes - The entire global BGP route table.
FIB - Forwarding Information Base – Our existing route table, used to find the egress interface and next hop when forwarding packets.
Looking Glass* - A Looking Glass (LG) server is a read-only view of routers of organizations running the LG servers. Typically, publicly accessible looking glass servers are run by ISPs or NOCs.
Multi-Homed - An ISP customer that has multiple connections to one or more ISPs.
Multi-Provider - An ISP customer that uses multiple ISPs to connect to the Internet.
NSM – Network Services Module - The ZebOS component that centralizes the interface to the FIB and RIB. The separate routing protocol daemons interface with the NSM for all RIB updates. NSM alone updates the FIB with best-route information from the RIB.
Partial Routes - A subset of the full BGP route table, usually specific to destinations that are part of an ISP's domain.
RIB - Route Information Base – A run-time database owned by the NSM, and used to store all route information gathered and used by the routing protocols.