Parts and terminology of BGP

In a BGP network, there are some terms that need to be explained before going ahead. Some parts of BGP are not explained here because they are common to other dynamic routing protocols. When determining your network topology, note that the number of available or supported routes is not set by the configuration but depends on the available memory on the FortiSwitch units.

This section covers the following topics:

• BGP and IPv6
• Role of routers in BGP networks
• Speaker routers
• Peer routers or neighbors
• Route reflectors
• Confederations
• Network Layer Reachability Information
• BGP attributes
• AS_PATH
• MULTI_EXIT_DESC
• COMMUNITY
• NEXT_HOP
• ATOMIC_AGGREGATE
• ORIGIN

BGP and IPv6

FortiSwitch units support IPv6 over BGP using the same config router bgp CLI command as IPv4 but different subcommands.

The main CLI keywords have IPv6 equivalents that are identified by the “6” on the end of the keyword, such as config network6 or set allowas-in6. For more information about IPv6 BGP keywords, see the FortiSwitchOS CLI Reference.

Role of routers in BGP networks

Dynamic routing has a number of different roles that routers can fill. BGP has a number of custom roles that routers can fill. These include speaker routers, peer routers or neighbors, and route reflectors.

Speaker routers

Any router that is configured for BGP is considered a BGP speaker. This means that a speaker router advertises BGP routes to its peers.

Any routers on the network that are not speaker routers are not treated as BGP routers.

Peer routers or neighbors

In a BGP network, all neighboring BGP routers or peer routers are routers that are connected to a FortiSwitch unit. A FortiSwitch unit learns about all other routers through these peers.

You need to manually configure BGP peers on a FortiSwitch unit as neighbors. Otherwise, these routers are not seen as peers but simply as other routers on the network that do not support BGP. Optionally, you can use MD5 authentication to password-protect BGP sessions with those neighbors (see RFC 2385).

You can configure up to 1000 BGP neighbors on a FortiSwitch unit. You can clear all or some BGP neighbor connections (sessions), using the execute router clear bgp CLI command.

For example, if you have 10 routes in the BGP routing table and you want to clear the specific route to IP address 10.10.10.1, enter the following CLI command:

execute router clear bgp ip 10.10.10.1

To remove all routes for autonomous system (AS) number 650001, enter the following CLI command:

execute router clear bgp as 650001

To remove route flap dampening information for the 10.10.0.0/16 subnet, enter the following CLI command:

execute router clear bgp dampening 10.10.0.0/16

In the following diagram, Router A is directly connected to five other routers in a network that contains 12 routers. These routers (the ones in the blue circle) are Router A’s peers or neighbors.

Router A and its five peer routers

As a minimum, when configuring BGP neighbors, you must enter their IP address and the AS number (remote-as). This is all of the information the GUI allows you to enter for a neighbor.

The following BGP commands are related to neighbors:

config router bgp

config neighbor

edit "<IPv4_IPv6_address>"

set advertisement-interval <0-600>

set allowas-in-enable {disable | enable}

set allowas-in <1-10>

set allowas-in-enable6 {disable | enable}

set allowas-in6 <1-10>

set attribute-unchanged {as-path | MED | next-hop}

set attribute-unchanged6 {as-path | MED | next-hop}

set activate {disable | enable}

set activate6 {disable | enable}

set bfd {disable | enable}

set capability-dynamic {disable | enable}

set capability-orf {both | none | receive | send}

set capability-orf6 {both | none | receive | send}

set capability-default-originate {disable | enable}

set capability-default-originate6 {disable | enable}

set dont-capability-negotiate {disable | enable}

set ebgp-enforce-multihop {disable | enable}

set ebgp-multihop-ttl <1-255>

set ebgp-ttl-security-hops <1-254>

set next-hop-self {disable | enable}

set next-hop-self6 {disable | enable}

set override-capability {disable | enable}

set passive {disable | enable}

set remove-private-as {disable | enable}

set remove-private-as6 {disable | enable}

set route-reflector-client {disable | enable}

set route-reflector-client6 {disable | enable}

set route-server-client {disable | enable}

set route-server-client6 {disable | enable}

set shutdown {disable | enable}

set soft-reconfiguration {disable | enable}

set soft-reconfiguration6 {disable | enable}

set as-override {disable | enable}

set as-override6 {disable | enable}

set strict-capability-match {disable | enable}

set description <string>

set distribute-list-in <string>

set distribute-list-in6 <string>

set distribute-list-out <string>

set distribute-list-out6 <string>

set filter-list-in <string>

set filter-list-in6 <string>

set filter-list-out <string>

set filter-list-out6 <string>

set interface <interface_name>

set maximum-prefix <1-4294967295>

set maximum-prefix6 <1-4294967295>

set prefix-list-in <string>

set prefix-list-in6 <string>

set prefix-list-out <string>

set prefix-list-out6 <string>

set remote-as <MANDATORY_1-4294967295>

set route-map-in <string>

set route-map-in6 <string>

set route-map-out <string>

set route-map-out6 <string>

set send-community {both | disable | extended | standard}

set send-community6 {both | disable | extended | standard}

set keep-alive-timer <0-65535>

set holdtime-timer <0, 3-65535>

set connect-timer <0-65535>

set unsuppress-map <string>

set unsuppress-map6 <string>

set update-source {interface_name}

set weight <0-65535>

end

end

end

Route reflectors

Route reflectors (RRs) in iBGP concentrate route updates so other routers only need to talk to the RRs to get all of the updates. This results in smaller routing tables, fewer connections between routers, faster responses to network topology changes, and less administration bandwidth. iBGP RRs are defined in RFC 1966.

In an iBGP RR configuration, the AS is divided into different clusters that each include client and reflector routers. The client routers supply the reflector routers with the client’s route updates. The reflectors pass this information along to other RRs and border routers. Only the reflectors need to be configured, not the clients, because the clients find the closest reflector and communicate with it automatically. The reflectors communicate with each other as peers. A FortiSwitch unit can be configured as either reflectors or clients.

Because RRs are processing more than the client routers, the reflectors should have more resources to handle the extra workload.

Smaller networks running iBGP typically do not require RRs. However, RRs are a useful feature for large companies, where their AS may include 100 routers or more. For example, a full mesh 20 router configuration within an AS, there would have to be 190 unique iBGP sessions just for routing updates within the AS. The number of sessions jumps to 435 sessions for just 30 routers, or 4950 sessions for 100 routers. Based on these numbers, updating this many sessions will quickly consume the limited bandwidth and processing resources of the routers involved.

The following diagram illustrates how RRs can improve the situation when only six routers are involved. The AS without RRs requires 15 sessions between the routers. In the AS with RRs, the two RRs receive route updates from the reflector clients (unlabeled routers in the diagram) in their cluster, as well as other RRs, and pass them on to the border router. The RR configuration requires only six sessions. This example shows a reduction of 60% for the number of required sessions.

Required sessions within an AS with and without RRs

The iBGP commands related to RRs include:

config router bgp

config neighbor

edit "<IPv4_IPv6_address>"

set route-reflector-client {disable | enable}

set route-reflector-client6 {disable | enable}

end

end

Confederations

Confederations were introduced to reduce the number of iBGP advertisements on a segment of the network and reduce the size of the routing tables. Confederations essentially break up an AS into smaller units. Confederations are defined in RFC 3065 and RFC 1965.

Within a confederation, all routers communicate with each other in a full mesh arrangement. Communications between confederations is more like inter-AS communications because many of the attributes are changed as they would be for BGP communications leaving the AS, or eBGP.

Confederations are useful when merging autonomous systems. Each AS being merged can easily become a confederation, which requires few changes. Any additional permanent changes can then be implemented over time, as required. After merging, if the border router becomes a route reflector, then each confederation only needs to communicate with one other router instead of five others.

Confederations and RRs perform similar functions: they both sub-divide large autonomous systems for more efficient operation. They differ in that route reflector clusters can include routers that are not members of a cluster, whereas routers in a confederation must belong to that confederation. Also, confederations place their confederation numbers in the AS_PATH attribute, making it easier to trace.

NOTE: While confederations essentially create sub-autonomous systems, all the confederations within an AS appear as a single AS to external autonomous systems.

Confederation related BGP commands include the following:

config router bgp

set confederation-identifier <peerid_integer>

end

Network Layer Reachability Information

Network Layer Reachability Information (NLRI) is unique to BGP-4. It is sent as part of the update messages sent between BGP routers and contains information necessary to supernet, or aggregate route, information. The NLRI includes the length and prefix that, when combined, are the address of the aggregated routes referred to.

There is only one NLRI entry per BGP update message.

BGP attributes

Each route in a BGP network has a set of attributes associated with it. These attributes define the route and are modified, as required, along the route.

BGP can work well with mostly default settings, but if you're going to change settings you need to understand the roles of each attribute and how they affect those settings.

The BGP attributes include the ones listed in the following table.

Attribute	Description
AS_PATH	A list of autonomous systems a route has passed through. For more information, see AS_PATH.
MULTI_EXIT_DESC (MED)	Which router to use to exit an AS with more than one external connection. For more information, see MULTI_EXIT_DESC.
COMMUNITY	Used to apply attributes to a group of routes. For more information, see COMMUNITY.
NEXT_HOP	Where the IP packets should be forwarded to, like a gateway in static routing. For more information, see NEXT_HOP.
ATOMIC_AGGREGATE	Used when routes have been summarized to tell downstream routers not to de-aggregate the route. For more information, see ATOMIC_AGGREGATE.
ORIGIN	Used to determine if the route is from the local AS or not. For more information, see ORIGIN.
LOCAL_PREF	Used only within an AS to select the best route to a location (like MED).

Inbound policies on FortiSwitch units can change the NEXT-HOP, LOCAL-PREF, MED, and AS-PATH attributes of an internal BGP (iBGP) route for its local route selection purposes. However, outbound policies on the device cannot affect these attributes.

AS_PATH

AS_PATH is the BGP attribute that keeps track of each AS that a route advertisement has passed through. AS_PATH is used by confederations and by external BGP (eBGP) to help prevent routing loops. A router knows there is a loop if it receives an AS_PATH with that router's AS in it. The diagram shows the route between Router A and Router B. The AS_PATH from A to B would read 701,702,703 for each AS that the route passes through.

As of the beginning of 2010, the industry upgraded from 2-byte to 4-byte AS_PATHs. This upgrade was due to the imminent exhaustion of 2-byte AS_PATH numbers. FortiOS supports 4-byte AS_PATHs in its BGP implementation.

AS_PATH of 701,702, 703 between routers A and B

The BGP commands related to AS_PATH include the following:

config router bgp

set bestpath-as-path-ignore {enable | disable}

end

MULTI_EXIT_DESC

BGP AS systems can have one or more routers that connect them to other autonomous systems. For autonomous systems with more than one connecting router, the Multi-Exit Discriminator (MED) lists which router is best to use when leaving the AS. The MED is based on attributes, such as delay. It is a recommendation only, as some networks may have different priorities.

BGP updates advertise the best path to a destination network. When a FortiSwitch unit receives a BGP update, the FortiSwitch unit examines the MED attribute of potential routes to determine the best path to a destination network before recording the path in the local FortiSwitch routing table.

FortiSwitch units have the option to treat any routes without an MED attribute as the worst possible routing choice. This can be useful because a lack of MED information is a lack of routing information, which can be suspicious as a possible hacking attempt or an attack on the network. At best, it signifies an unreliable route to select.

The BGP commands related to MED include the following:

config router bgp

set always-compare-med {enable | disable}

set bestpath-med-confed {enable | disable}

set bestpath-med-missing-as-worst {enable | disable}

set deterministic-med {enable | disable}

config neighbor

edit "<IPv4_IPv6_address>"

set attribute-unchanged [as-path] [med] [next-hop]

set attribute-unchanged6 {as-path | MED | next-hop}

end

end

end

COMMUNITY

A community is a group of routes that have the same routing policies applied to them. This saves time and resources. A community is defined by the COMMUNITY attribute of a BGP route.

A FortiSwitch unit can set the COMMUNITY attribute of a route to assign the route to predefined paths (see RFC 1997). The FortiSwitch unit can examine the COMMUNITY attribute of learned routes to perform local filtering and/or redistribution.

The BGP commands related to COMMUNITY include the following:

config router bgp

set send-community {both | disable | extended | standard}

set send-community6 {both | disable | extended | standard}

end

NEXT_HOP

The NEXT_HOP attribute says what IP address the packets should be forwarded to next. Each time the route is advertised, this value is updated. The NEXT_HOP attribute is much like a gateway in static routing.

FortiSwitch units allow you to change the advertising of the FortiSwitch unit’s IP address (instead of the neighbor’s IP address) in the NEXT_HOP information that is sent to iBGP peers. This is changed with the config neighbor, set next-hop-self command.

The BGP commands related to NEXT_HOP include the following:

config router bgp

config neighbor

edit "<IPv4_IPv6_address>"

set attribute-unchanged [as-path] [med] [next-hop]

set attribute-unchanged6 {as-path | MED | next-hop}

set next-hop-self {enable | disable}

set next-hop-self6 {disable | enable}

next

end

end

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE attribute is used when routes have been summarized. It indicates which AS and which router summarize the routes. It also tells downstream routers not to de-aggregate the route. Summarized routes are routes with similar information that have been combined, or aggregated, into one route that is easier to send in updates for. When it reaches its destination, the summarized routes are split back up into the individual routes.

The FortiSwitch unit does not specifically set this attribute in the BGP router command, but it is used in the route map command.

The CLI commands related to ATOMIC_AGGREGATE include the following:

config router route-map

edit <route_map_name>

set protocol bgp

config rule

edit <route_map_rule_id>

set set-aggregator-as <id_integer>

set set-aggregator-ip <address_ipv4>

set set-atomic-aggregate {enable | disable}

end

end

end

ORIGIN

The ORIGIN attribute records where the route came from. The options can be iBGP, eBGP, or incomplete. This information is important because internal routes (iBGP) are, by default, higher priority than external routes (eBGP). However, incomplete ORIGINs are the lowest priority of the three.

The CLI commands related to ORIGIN include the following:

config router route-map

edit <route_map_name>

set protocol bgp

config rule

edit <route_map_rule_id>

set match-origin {egp | igp | incomplete | none}

end

end

end