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).
BGP licensing requirements are shown in the table below.
Routing protocols typically interact with two databases:
|
•
|
Routing Information Base (RIB) - Used to store all the route information required by the routing protocols themselves.
|
|
•
|
Forward Information Base (FIB) - Used for actual packet forwarding.
|
There are two basic classes of routing protocols:
|
•
|
Interior Gateway Protocols (IGPs) - Interior Gateway Protocols are routing protocols designed to communicate routes within the networks that exist inside of an AS. There are two generations of IGPs. The first generation consists of distance-vector protocols. The second generation consists of link-state protocols. The distance-vector protocols are relatively simple, but have issues when scaled to a large number of routers. The link-state protocols are more complex, but have better scaling capability. The existing distance-vector protocols are Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), and RIPv2, an enhanced version of RIP. IGRP and EIGRP are proprietary Cisco protocols. The link-state protocols currently in use are Open Shortest Path First (OSPF) and the little-used Intermediate System to Intermediate System (IS-IS) protocol.
|
|
•
|
Exterior Gateway Protocols (EGPs) - The standard, ubiquitous Exterior Gateway Protocol is BGP (BGP4, to be exact). BGP is large-scale routing protocol that communicates routing information and policy between well-defined network domains called Autonomous Systems (ASs). An Autonomous System is a separately administered network domain, independent of other Autonomous Systems. BGP is used to convey routes and route policy between Autonomous Systems. ISPs commonly use BGP to convey routes and route policy with their customers as well as with other ISPs.
|
There are three basic scales of BGP networks:
|
•
|
Single-Provider/Single-Homed - The network receives a single route (single-homed) from a single ISP (single-provider). The number of routes an ISP customer receives from its ISP depends on the nature of its AS. An ISP customer that uses only one ISP as their Internet provider, and has a single connection to that provider (single-provider / single-homed) has no need to receive any routes - all traffic destined outside of the AS will go to their ISP. These customers may still advertise some or all of their inside network to the ISP.
|
|
•
|
Single-Provider/Multi-Homed - The network receives multiple routes (multi-homed) from a single ISP (single-provider). ISP customers that use a single ISP, but have multiple connections to their ISP may only receive the default route (0.0.0.0/0) at each ISP gateway. If an ISP connection goes down, the advertised default route sent from the connected CPE router to internal routers would be withdrawn, and Internet traffic would then flow to a CPE router that has connectivity to the ISP. The customer's inside network would also be advertised to the ISP at each CPE router gateway, allowing the ISP to use alternate paths should a particular connection to a customer go down.
|
|
•
|
Multi-Provider/Multi-Homed - ISP customers that use more than one ISP (multi-provider / multi-homed) have one or more separate gateway routers for each ISP. In this case, the customer's AS must be a public AS, and may either be a transit or non-transit AS. A transit AS will receive and forward traffic from one ISP destined for a network reachable through another ISP (the traffic destination is not in the customer's AS). A non-transit AS should only receive traffic destined for its AS - all other traffic would be dropped. BGP routers in a transit AS would often receive a large portion (in many cases, all) of the full BGP route table from each ISP.
|
|
•
|
Single-provider/Single-homed – Not typically a strong candidate for BGP, but may still use it to advertise networks to the ISP. single-homed networks are not eligible for a public AS from RIRs.
|
|
•
|
Single-provider/Multi-homed – Common to follow RFC2270 suggestion to use a single private AS (64512 to 65535) to get the benefit of BGP while preserving public ASN.
|
|
•
|
Multi-provider/Multi-homed – Highly redundant, typically with dedicated routers to each ISP. Requires public ASN. Large memory footprint
|
|
•
|
iBGP – Neighbor is in the same AS.
|
|
•
|
eBGP – Neighbor is in a different AS.
|
|
•
|
AS_PATH: Indicates the ASs that the route is traveling from and two. In the example below, the AS_PATH is from AS 7675 to AS 12345. For internal BGP, the AS_PATH specifies the same AS for both the source and destination.
|
|
•
|
NEXT_HOP: Indicates the IP address of the next router the path travels to. Paths advertised across AS boundaries inherit the NEXT_HOP address of the boundary router. BGP relies on interior routing protocols to reach NEXT_HOP addresses.
|
Figure 70. BGP finite state machine
BGP communication includes the following types of messages:
|
•
|
Open – The first message between BGP peers after TCP session establishment. Contains the necessary information to establish a peering session, e.g. ASN, hold time, and capabilities such as multi-product extensions and route-refresh.
|
|
•
|
Update – These messages contain path information, such as route announcements or withdrawals.
|
|
•
|
Keepalive – Periodic messages to keep TCP layer up, and to advertise liveliness.
|
|
•
|
Notification – A request to terminate the BGP session. Non-fatal notifications contain the error code “cease”. Subcodes provide further detail:
|
|
•
|
Route-refresh – A request for the peer to resend its routes.
|
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
