6.7. BGP

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

Overview

Border Gateway Protocol (BGP) allows the exchange of routing information between an Autonomous System (AS) and other Autonomous Systems. The Clavister NetShield Firewall can act as a single AS and use BGP to both import routes from and export routes to other autonomous systems.

BGP is implemented in cOS Stream in a similar way to OSPF. A single BGPProcess object must be defined which identifies the firewall as an AS with an AS number and router ID. Other objects are then added to define BGP neighbors as well as what routes can be imported from these neighbors and what routes can be exported to them.

BGP can both import and export routes from/to local routing tables as well as OSPF-processes.

In the simplest scenario, BGP setup will involve the following 3 steps:

A. Set up a BGP process that can communicate with other BGP processes.

B. Add process rules to import routes from BGP processes.

C. Add rules to export routes to BGP processes.

A detailed description of these three steps along with examples are given next.

A. Set up a BGP process that can communicate with BGP neighbors:

Create a BGPProcess object and set the ASNum and RouterID properties. Only a single BGPProcess object instance can be created in a firewall. The RouterID must be specified as an IPv4 address.
Add BGPNeighbor object as a child of the BGPProcess for each neighbor that the process will exchange routes with. At least one must be added.

The IPAddress and RemoteASNum properties must be specified for the neighbor. IPv4 and IPv6 neighbor addresses can be mixed in a single process. The RemoteASNum property value must match the AS number of the neighbor BGP process but the IPAddress does not have to be the same as the Router ID of the neighbor.

Example 6.16. Setting Up a BGP Process with Neighbors

This example shows how a BGP process is created with associated neighbors. It is assumed the process will have a private AS number of 64512 and its ID specified as the private IPv4 address 192.168.0.10.

A single BGP neighbor will be associated with the process that has the IPv4 address 10.0.0.100.

Note that this and later examples use private IP addresses and private AS numbers. It is assumed that the AS is not connected to the public Internet.

Command-Line Interface

Add the BGPProcess object:

System:/> add BGPProcess my_bgp ASNum=64512 RouterID=192.168.0.10

Change the CLI context to be the BGP process:

System:/> cc BGPProcess my_bgp

Add a BGPNeighbor as a child:

System:/BGPProcess/my_bgp> add BGPNeighbor
			IPAddress=10.0.0.100
			RemoteASNum=64513

B. Add process rules to import routes from neighbors:

Add at least one RouteExportRuleBGP object as a child of the BGPProcess. The DestinationRouteIn property must be set to a network range. Only routes within that range will be imported from neighbors to one or more destinations. The destinations are specified in the next step.
Add at least one ExportToRoutingTable object as a child of the RouteExportRuleBGP created in the previous step. This new child object must have its Destination property set to a destination for the imported routes. The destination can be either a RoutingTable object or an OSPFProcess object.

Multiple ExportToRoutingTable objects could be added if there is a need to send the same imported routes to multiple destinations.

Example 6.17. Adding Rules to Import Routes to a BGP Process

This example continues from the previous example and adds rules to the BGP process to import routes from neighbors. Only routes within the network 10.0.1.0/24 will be imported and they will be inserted into cOS Stream's main routing table.

Command-Line Interface

Make sure the CLI context is the BGP process:

System:/> cc BGPProcess my_bgp

Add a child RouteExportRuleBGP object to import all routes within 10.0.1.0/24:

System:/BGPProcess/my_bgp> add RouteExportRuleBGP 
			DestinationNetworkIn=10.0.1.0/24

Change the CLI context to be the rule:

System:/BGPProcess/my_bgp> cc RouteExportRuleBGP 1

Add an ExportToRoutingTable object as a child to specify the destination:

System:/BGPProcess/my_bgp/RouteExportRuleBGP/1> 
			add ExportToRoutingTable
			Destination=main

Return to the default CLI context:

System:/BGPProcess/my_bgp/RouteExportRuleBGP/1> cc
System:/>

C. Add rules to export routes to neighbors:

Add at least one RouteExportRule object as a child of a RoutingTable object. The DestinationNetworkIn property of the object must be set to a network range for the routes that will be exported.
Add an ExportToBGP object as a child of the RouteExportRule. The ExportToProcess property of this object must be set to the BGPProcess object created previously.

Example 6.18. Adding Rules to Export Routes to BGP Neighbors

This example continues from the previous example and adds a rule to cOS Stream's main routing table to export routes to BGP neighbors.

Command-Line Interface

Change the CLI context to be the main routing table:

System:/> cc RoutingTable main

Add a child RouteExportRule object to export all routes within 10.0.2.0/24:

System:/RoutingTable/main> add RouteExportRule 
			DestinationNetworkIn=10.0.2.0/24

Change the CLI context to be the rule:

System:/RoutingTable/main> cc RouteExportRule 1

Add an ExportToRoutingTable object as a child to specify the destination:

System:/RoutingTable/main/RouteExportRule/1> 
			add ExportToBGP
			ExportToProcess=my_bgp

Return to the default CLI context:

System:/RoutingTable/main/RouteExportRule/1> cc
System:/>

Dynamically Applying Changes to Exchanged Routes

It is possible to dynamically apply specified modifications to given routes as they are exported to a particular neighbor or imported from a particular neighbor. The modifications could, for example, involve changing the route's next-hop or metric, or a variety of other parameters such as community related options.

Specifying such dynamic changes is done with the following steps:

Specify the affected route(s) by creating a RoutePrefixList object and add one or more child RoutePrefixEntry objects. Set the Network property of each RoutePrefixEntry object to filter out the affected routes.
Create a RouteMap object to specify the change to be made. The MatchIP property of this object is set to the RoutePrefixList created in the previous step and the appropriate property should be chosen to make the required change.

For example, the SetNextHop property would be used to change the next-hop of the routes filtered by the RoutePrefixList. All the available properties that can be set can be found under the entry for the RouteMap object in the separate CLI Reference Guide.
For the BGPNeigbor object to which the changes will apply, set its RouteMapOut property to the RouteMap created in the previous step, if exported routes are to be changed. If routes imported from the neighbor are to be changed, the RouteMapIn property should be set to the RouteMap.

Using these steps is illustrated in the example below.

Example 6.19. Applying Dynamic Changes to BGP Routes

This example will change the next-hop of the exported route for the host at IP address 10.0.2.15.

Command-Line Interface

Create a new RoutePrefixList object:

System:/> add DynRouteObject RoutePrefixList my_net

Change the CLI context to this list:

System:/> cc DynRouteObject RoutePrefixList my_net

Add a child RoutePrefixEntry object to specify the host:

System:/RoutePrefixList/my_net> add RoutePrefixEntry 
			Action=Allow
			Network=10.0.2.15

Return to the default CLI context:

System:/RoutePrefixList/my_net> cc

Create a new RouteMap object:

System:/> add DynRouteObject RouteMap my_map

Change the CLI context to this map:

System:/> cc DynRouteObject RouteMap my_map

Add a child RouteMapEntry object to specify the desired change:

System:/RouteMap/my_map> add RouteMapEntry 
			Action=Allow
			MatchIP=my_net
			SetNextHop=10.0.0.90

Return to the default CLI context:

System:/RoutingTable/main/RouteExportRule/1> cc

Change the CLI context to be the BGP process:

System:/> cc BGPProcess my_bgp

Set the route map to use for routes exported a specific neighbor:

System:/BGPProcess my_bgp> set BGPNeighbor 1 
			RouteMapOut=my_map

Return to the default CLI context:

System:/RoutingTable/main/RouteExportRule/1> cc
System:/>

	Note: Configuration with BGP
	When BGP is configured with SIIT or NAT64, BGP export needs to be configured accordingly. This is discussed further in section 3.2 of RFC 6052.

Using BFD

Using Bidirectional Forwarding Detection (BFD) with BGP allows very fast failover time when a neighbor becomes unreachable. By default, it is disabled with BGP and is enabled by setting the value of the property FalloverDetection to BFD in the relevant BGPNeighbor object.

The following should be noted about using BFD:

For BFD to function, it must be enabled in all communicating BGP neighbors. In other words, on both sides of each neighbor pair.
For a standalone firewall that is not part of an HA cluster, enabling both BFD and the GracefulRestart property of the BGPProcess object should be avoided. This is because BFD will detect neighbor failure instantly and GracefulRestart will try to send traffic regardless of failure.
For an cOS Stream HA cluster, both BFD and GracefulRestart can be enabled together (enabling GracefulRestart is a requirement for HA).
The following four properties in BGPNeighbor can be used to modify BFD behavior:
- BFDTransmitInterval
  
  The minimum interval between transmitting BFD hello packets to a neighbor with which a BFD session has been established (default, 250 msecs).
- BFDReceiveInterval
  
  The minimum expected interval between receiving BFD hello packets from a neighbor with which a BFD session has been established (default, 250 msecs).
- BFDHelloMultiplier
  
  The number of hello packets not received from a neighbor before the neighbor is consider unreachable (default, 3).
- BFDSlowTimerInterval
  
  This determines how fast a new BFD session is started and can be used to slow asynchronous sessions (default, 2000 msecs)
These properties are also discussed in the separate cOS Stream CLI Reference Guide.

BGP With High Availability Clusters

If a failover occurs in an HA cluster that is running BGP, the following should be noted:

To allow BGP to restart, the GracefulRestart and GracefulReset properties of the BGPProcess object should be enabled, as well as the GracefulRestart property of all BGPNeighbor objects.

These properties, or their equivalent, should also be enabled on any BGP routers communicating with the firewall.
The routes set up by BGP are state synchronized and will be unaffected by the failover. This means that all traffic flows that use these routes will be unaffected after the failover completes.
The objects involved in BGP setup, such as the BGPProcess object, are not state synchronized. This means that the BGP mechanisms will be automatically set up again by cOS Stream after the failover.
The GracefulRestartTime and GracefulStalePath properties of the BGPProcess object should be set to the appropriate values. If the restart is too fast, information can be lost. It should be long enough to allow all internal BGP mechanisms to be fully initialized. The more routes and complexity, the more time that is required. Other factors include the number BGP peers and uplink speed. Trial and error may be required to find the appropriate settings.
As mentioned earlier, BFD could also be enabled for an HA cluster. However, note that BFD is separate from the HA cluster failover mechanism. A BFD failure will never trigger an HA failover.