• Home
• News
• About FireBrick
• Products

• FireBrick 105
• FireBrick FB6000

• Legacy Products

• Buy Firebrick
• Contact Us
• Support

• Reseller Area

• Press Information

FireBrick FB6000

BGP Setup

Overview

The FB6000 series router provides BGP routing capabilities. Depending on the model this may be full BGP or leaf node BGP (which is described later). The design aim has been to make BGP configuration single for a typical small ISP or corporate user.

The key features supported are:-

• Simple pre-set configurations for typical ISP/corporate setup
• RFC4271 Standard BGP capable of handling multiple full internet routing tables
• RFC4893 32 bit AS number handling
• RFC2858 Multi protocol handling of IPv6
• RFC1997 Community tagging, with in-build support of well-known communities
• RFC2918 Route refresh in and out (TBA)
• RFC4724 Graceful restart (TBA)
• RFC2385 TCP MD5 protection (TBA)
• RFC2796 Route reflector peers
• RFC3392 Capabilities negotiation
• RFC3065 Confederation peers
• Multiple independent routing tables allowing independent BGP operations
• Multiple AS operation

Simple example setup

A typical installation may have transit connections from which a complete internet routing table is received, peers which provide their own routes only, internal peers making an IBGP mesh, customers to which transit is provided and customer routes may be accepted. To make this set up simple the <peer> definition contains a type attribute. This allows simple BGP configuration such as:-

<bgp as="12345">
 <peer as="666" name="transit1" type="transit" ip="1.2.3.4"/>
 <peer as="777" name="transit2" type="transit" ip="2.3.4.5 2.3.4.6"/\>
 <peer type="internal" ip="5.6.7.8"/\>
</bgp>

This example has two transit providers, the second of which is actually two peer IP addresses, and one internal connection. Note that the peer AS is optional and unnecessary on internal type as it has to match ours.

The exact elements that apply are defined in the XML/XSD documentation for your software release.

Peer type

The type attribute controls some of the behaviour of the session and some of the default settings as follows.

Route filtering

Each peer has a set of import and export rules which are applied to routes that are imported or exported from the peer. In future there will be named peer groups, route maps and prefix lists.

The objects import and export work in exactly the same way, checking the routes imported or exported against a set of rules and then possibly making changes to the attributes of the routes or even choosing to discard the route.

Each of these objects contain:-

• Cosmetic attributes such as name, comment, and source.
• Route matching attributes allowing specific routes to be selected
• Action attributes defining changes to the route
• A continuation attribute stop defining if the matching stops at this rule (default) or continues to check further rules

The rules are considered in order. The first rule to match all of the matching attributes is used. If no rules match then the default actions from the import/export object are used.

In addition, the top level import/export has a prefix list. If present then this will limit the prefixes processed at a top level, dropping any that do not match the list without even considering the rules.

Matching attributes

The actual attributes are listed in the XML/XSD documentation for the software version. The main ones are:-

• A list of prefixes filters defining which prefixes to match
• There will be community tag checking and AS path checking in future

You can have a rule with no matching attribute which will always be applied, but this is generally pointless as no later rules will be considered. If you want to define defaults then set them in the top level import/export object.

Action attributes

The actual attributes are listed in the XML/XSD documentation for the software version. The main ones are:-

• Adding specific community tags
• Removing specific community tags, including defaults added by the peer type.
• Dropping the route completely
• Changing the MED
• Changing the localpref

You can have a rule with no action attributes. If matched then this means none of the actions are taken and communities, localpref, med, etc., are all unchanged.

Well known community tags

Specific well known communities are supported natively. Some of these are set automatically based on peer type and can be explicitly removed using the detag action. These rules are automatically checked for exporting routes unless overridden on the peer attributes.

Bad optional path attributes

The BGp specification is clear that receipt of a path attribute that we understand but is in some way wrong should cause the BGP session to be shut down. This has a problem if the attribute is one that is not known to intermediate routers in the internet which means a bad content is propagated to multiple routers on the internet and they will drop their session. This can cause a major problem in the internet.

To work around this have, by default, ignore-bad-optional-partial set to true. The effect is that if a path attribute we understand is wrong, and it is optional, and trhe router that sent it to us did not understand or check it (partial bit is set), we ignore the specific route rather than dropping the whole BGP session.

<network> element

The network element defines a prefix that is to be announced by BGP but has no internal on routing.

<route> and <subnet> elements

Subnet and route elements used for normal set-up of internal routing can be announced by BGP using the bgp attribute with the same values as the well known community tags, please true meaning simply announce with no tags, and false meaning the same as no-advertise.

Route feasibility testing

The FB6000 has an aggressive route feasibility test that confirms not only routability of each next-hop but also that it is answering ARP/ND requests. Whenever a next-hop is infeasible then all routes using that next-hop are removed. When it becomes feasible the routes are re-applied. This goes beyond the normal BGP specification and minimises any risk of announcing a blank hole route.

Leaf node

A leaf node BGP router operates such that all received routes are effectively tagged as no-advertise. This means local prefixes from <network> and <route> and <subnet> are announced but no routes received from any peer are sent to any other peer. This also restricts the display of routing information as AS paths and other attributes are not retained for received routes.

The main purpose of leaf node BGP is for an end point connected to one or more transit connections announcing its own prefix to those providers.

Router shutdown

One router shutdown, e.g. for software load, all established BGP sessions have all announced routes cleanly withdrawn, and the session closes cleanly. However, all received routes are retained in the routing table until the final shutdown and restart. This minimises the impact of the shutdown when operating a pair of routers as it allows all outbound traffic to continue while stopping inbound traffic.