Network Juniors

BGP States from start up to peering

1 – Idle: the initial state of a BGP connection. In this state, the BGP speaker is waiting for a BGP start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.

2 – Connect: In this state, BGP is waiting for the TCP connection to be formed. If the TCP connection completes, BGP will move to the OpenSent stage; if the connection cannot complete, BGP goes to Active

3 – Active: In the Active state, the BGP speaker is attempting to initiate a TCP session with the BGP speaker it wants to peer with. If this can be done, the BGP state goes to OpenSent state.

4 – OpenSent: the BGP speaker is waiting to receive an OPEN message from the remote BGP speaker

5 – OpenConfirm: Once the BGP speaker receives the OPEN message and no error is detected, the BGP speaker sends a KEEPALIVE message to the remote BGP speaker

6 – Established: All of the neighbor negotiations are complete. You will see a number (2 in this case), which tells us the number of prefixes the router has received from a neighbor or peer group.

Memorizing the BGP decision process steps is very useful and you should remember them. The table below lists the complete path selection process:

WLOA-OMNI

1. Prefer highest weight (local to router)
2. Prefer highest local preference (global within AS)
3. Prefer route originated by the local router (next hop = 0.0.0.0)
4. Prefer shortest AS path
5. Prefer lowest origin code (IGP < EGP )
6. Prefer lowest MED (exchanged between autonomous systems)
7. Prefer EBGP path over IBGP path
8. Prefer the path through the closest IGP neighbor (IGP cost)
9. Prefer oldest route for EBGP paths
10. Prefer the path with the lowest neighbor BGP router ID
11. Prefer the path with the lowest neighbor IP address
----------------------------------------------------------------------------------------------------------------------------------

Q.What technique should be used on BGP edge routers to prevent a multi-homed autonomous system from becoming a transit system?

A transit AS is an AS that routes traffic from one external AS to another external AS. Let’s see an example below:

Suppose your company has 2 internet links to 2 different ISPs. If one connection to the ISP goes down, your traffic can be sent through the other ISP. It is a good way to make sure your company can access the internet any time. But if your routers are not configured carefully, your company AS may become a transit AS. For example, AS 65002 learned the route 10.10.10.0/24 from ISP1. If R2 advertises that route to ISP2 then ISP2 may use it to send traffic to that network -> your company becomes a transit AS.

There are two popular ways to prevent a multi-homed autonomous system from becoming a transit system:

+ Use a distribute-list or filter-list to filter all networks not originating from inside the autonomous system.
+ Use the no-export community attribute on all networks not originating from inside the autonomous
system.

_________________________________________________________________________________

Q.what is the Synchronization Rule ?

The synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP. To understand why this rule exists, let’s take an example if this rule is not there.

Suppose Rt-A wants RT-B to access its local LAN 1.1.1.0, so it advertises this network through R1. R1 and R3 are running IBGP so R1 sends this update to R3 through R2 (using the next-hop-self to use its own interface’s IP address). In turn, R3 announces to RT-B that it can reach 1.1.1.0 via R3.

Now Rt-B really wants to send traffic to 1.1.1.0 so it will send to R3. R3 does a look up and sees that the network can be reachable via R1. It then does a lookup for R1′s IP address and sees that it is reachable via R2 -> so it forwards packets to R2. But R2, running IGP (like OSPF), does not find an entry for 1.1.1.0 so R2 drops all the packets for that network – a black-hole is created!

That is why the BGP synchronization rule is born. With this rule, when R3 receives an advertisement for 1.1.1.0 from R1, it adds that route to its BGP table and before sending advertisement to RT-B, it first checks its IGP routing table to see whether an entry exists for that route. In this example, R3′s IGP routing table does not know how to reach 1.1.1.0 so R3 will not advertise this network to RT-B. This route is only advertised to RT-B when IGP makes an entry in the routing table for 1.1.1.0.

Well, now you understand the importance of BGP Synchronization rule but now I wish to explain why this rule causes trouble in fully-meshed IBGP!

Synchronization prevents fully-meshed IBGP from working properly. Because no IGP is running so R3 cannot advertise any route to RT-B even if no black-hole exists in this topology.

Note: A “fully-meshed” can be a physical fully-meshed topology or a topology where all routers in the same AS established IBGP connections with each other (although they do not need to be directly connected). So in the topology above, the connection between R1 & R3 is represented by a dashed line, which means it can be physically connected or not (but an IBGP connection must be established on both routers).

____________________________________________________________________________

Q.What is the problem caused by Split Horizon in BGP ?

BGP split-horizon rule states that a route learned from one IBGP neighbor will not be advertised to another IBGP neighbor so IBGP sessions should be fully meshed. For example in the topology below, routes learned from R1 about AS 200 will be advertised to R2. For R2, the route learned from R1 is a route learned from one IBGP neighbor so R2 will not advertise this route to R3 and AS 100 can never be a transit AS -> IBGP sessions should be fully meshed within a transit AS -> D is correct.

________________________________________________________________________
BGP Basics:

Only one BGP process per router.
There is two types of BGP, IBGP & EBGP, if the as-numbers of the peering routers are the same then its IBGP, if they are different then its EBGP.
BGP uses AS numbers [1-64511] as public and [64512-65535] as private.
BGP uses TCP as its reliable transport protocol and it runs over TCP port 179.
The router with the higher router-id establishes the BGP peering session.
BGP uses Keepalive messages to detect the presence of its neighbor, Keepalive interval value is 60 sec, and Holdtime is 180 sec by default [1:3 ratio], Holdtime value is exchanged in the Open Message, and you can only modify the Holdtime value, BGP peers use the lower Holdtime value configured on either of them.
BGP uses triggered updates, 5 sec interval for IBGP and 30 sec interval for EBGP.
Mandatory well known attributes must exist in each routing update.
If multiple paths exist for the same network, only one is selected as the best route and the remaining routes are stored in the memory, Router propagates best routes only to its neighbors.
If multi path load sharing is enabled, router can select multiple paths to a single destination and installs them int the routing table, multiple path load sharing in BGP supports up to 16 paths.
Before a route is installed in the routing table, the router checks if its learned from another routing protocol rather than BGP, if it was learned from another routing protocol the router compares the Administrative Distance [AD] and prefers the lower.
BGP Split Horizon Rule: When a router receives an update it never sends it back to the source which it received from.
IBGP Split Horizon Rule: Routes learned from an IBGP neighbor is never sent to other IBGP neighbors, thus all IBGP routers inside an AS needs full mesh for consistent routing decisions.
AS-Path loop prevention mechanism: When a router receives an update containing its own AS number; it silently ignores the update.
EBGP peers should be reachable for all BGP speaking routers inside an AS, this is achieved by either redistributing connected interfaces of the EBGP peers into IGP, or run IGP over the EBGP peers interface and make them passive so that they don’t exchange IGP information, or finally use the “neighbor ip-address next-hop-self” command so that the edge router announces it self as the next hop for the IBGP peers.
BGP sessions can be initiated using loopback interfaces, IGP or Static Routes are used for providing reachability between loopbacks, also the update source for the BGP session should be modified in order to successfully establish the session using the “neighbor ip-address update-source loopbacknumber” command. For EBGP sessions to be established successfully using the loopback interfaces you will need to use the “neighbor ip-address ebgp-multihop value“ command.
IGP is used inside an AS to provide full reachability required for establishing IBGP sessions, fast convergence in case of physical failure in one of the multiple paths between IBGP routers, and next hop resolving “aka recursive look up” for appropriate packet forwarding.

BGP Path Attributes:

Mandatory Well Known Attributes:
- Next-hop:ip address of the router sending the updates, by default it changes when a route is advertised to EBGP neighbor but not when its advertised to IBGP neighbor.
- AS-Path:Sequence of ASs path a route has traveled through.
- Origin: Indicates how BGP learned the route [IGP - EBGP - ?].
Discretionary Well Known Attributes:
- Local Preference:used for consistent routing policy inside an AS.
- Atomic Aggregate: informs a neighbor router that the originating router aggregated the routes.
Transitive Optional Attributes:
- Aggregator:Specify the ip address and the AS number of the router that performed the aggregation.
- Community: Route tagging mechanism used in filtering or route selection process.

Non-Transitive Optional Attributes:
- Multi-Exit Discriminator [MED]: Discriminate between multiple exit points within an AS.
- Cost Community: Used to influence best-path selection for IBGP and confederations only.
- Originator-id: Used as a loop prevention mechanism in case of multiple Route Reflectors.

BGP Session Establishment Process:

Single BGP process is started on the router using “router bgp as-number” command.
Neighbors must be configured manually on both sides using “neighbor ip-address remote-as as-number“ command.
It uses TCP port 179 and the session of the router with the higher Router-id is retained.
The first state of the BGP session is IDLE which indicates that the router is currently not attempting any session establishment, for a router to change its IDLE state; the configured neighbor ip address should be reachable.
When peers are correctly configured the state is changes to ACTIVE which indicates that the router is actively sending connections attempts to its neighbor.
When the TCP connection attempt succeed, the router sends an Open Message containing BGP session information and changes the state to be OpenSent.The Open Message contains [BGP version number - AS of local router - Holdtime - Router-ID - Optional parameters].
If the neighbor router accepts the parameters in the Open Message; it replies with its own Open Message, the local router receives the Open Message and changes the state to OpenConfirm, and it verifies the parameters of the neighbor router, if accepted a keepalive message is sent as signal of acceptance and then the state is changed to Established.

Route Selection Criteria:

Next-hop: If not reachable the route is not installed in the routing table.
Weight: Local to the router.
Local Preference: Local within an AS.
Originated Routes: Routes originated using the network or summary commands.
AS-Path: Prefers the shortest path.
Origin Code: IGP < EGP < ?
MED: Prefers the lowest value.
EBGP routes over IBGP routes.
For IBGP: Prefers path via closest IGP neighbor [Next-Hop with lowest IGP metric].
For EBGP: Oldest path.
Lowest BGP Router-id.

Advertising Networks:

There are three ways to announce networks into BGP:

Network command, Redistribution and Aggregation.
when either of the three ways is used the AS-Path will appear empty indicating that the route is locally originated, when the route traverses through other ASes, the forwarding router prepends its own AS number to the AS-Path.
Network command operates differently in BGP; indicates which routes will be injected in the BGP table not which interface will BGP run over.
Using a Route-Map with the Network command allows you to alter Weight, Local Preference, MED and tagging the route.
When redistributing routes into BGP, they carry an origin of incomplete “?“. – Conditional Route Injection: is injecting a route into BGP with no matching route in the routing table, this is achieved by using the “bgp inject-map map-name exist-map map-name” command.

Summarization & Aggregation:

Automatic summarization is enabled by default.
For a router to install a classful network in the BGP table when Automatic summarization is enabled; A classful network statement with a classful mask and at least one subnet of this classful network should exist in the routing table.
When Automatic summarization is enabled; all redistributed subnets will be summarized to their classful network.
When summarization is disabled, an exact match must be found in the routing table.
Aggregation is summarization of routes when it is advertised to other neighbors, and its configured using “aggregate-address ip-address mask”command.
For an aggregate route to be advertised to other neighbors; a route within the range of the aggregate must exist in the BGP table in order to install the aggregate in the BGP table.
By default both the aggregate and the specific routes are advertised to the neighbors, to advertise the aggregate only you will have to use the “summary-only” keyword with the aggregate command.

Securing BGP Peers:

MD5 authentication between BGP peers by using the “neighbor ip-address password password” command.
TTL-Security: The router compares the TTL value received with the locally configured hop count value, this option is supported for both directly connected and multihop EBGP peers. the command for this option is “neighbor ip-address ebgp-multihop ttl“; where TTL is a numeric value.

Multihoming:

Multihoming is a customer being connected to a single ISP with multiple links or connected to multiple ISP’s.
Multihomed customers should run BGP with their ISPs using public AS and provider independent address space.
Multihomed customers should advertise their own address space only to their ISPs and do not advertise routes learned from their ISPs do avoid acting as a Transit-AS between their ISPs.
For influencing Upstream ISP selection, Weight and Local Preference can be used inside a Multihomed Customer AS.
For influencing Downstream ISP selection, MED can be used if the customer is multihomed to a single ISP as MED doesn’t traverse through ASes, and AS-path Prepending can be used if the customer is multihomed to multiple ISPs because AS-path attribute traverses through ASes.

AS-Path Filtering:

Used to announce or accept prefixes based on AS-Path Attribute.

It uses Regular Expressions.
Its implemented on per neighbor basis.
Use “ip as-path access-list number [permit/deny] as-regular-expression” & “neighbor ip-address filter-list access-list-number [in/out]” commands.

Regular Expressions:

| –> Logical OR.
[123] [1-4]–> matches any single character from those between braces.
dot (.)–> matches any character, even if it was a space.
^–> matches beginning of the string.
$–> matches end of the string.
Underscore (_)–> matches any delimiter [beginning, end, space, tab, comma]
Braces ( ) –> matches two or more AS numbers.
\–> removes the meaning of the special character following it so it could be matched if found in an AS-Path eg. as () in confederations.
*–> character is repeated zero times or more.
?–> character is repeated zero or one time.
+–> character is repeated one or more times.

Prefix-List filtering:

Used to filter announce and accept specific prefixes.
It has some advantages over IP Access Lists as: Provide flexibility in editing, inserting and deleting individual lines, Matches based on subnetmask, etc…
Its implemented on per neighbor basis.
An with no Le/Ge matches exactly the specified prefix.
An entry with Le/Ge matches any route within the range specified.
Configuration example:
- “ip prefix-list name seq number [permit/deny] prefix/length ge value le value” “neighbor ip-addressprefix-list name [in/out]” “redistribute-list prefix-list name out routing-process“.

Out Bound Route Filtering [ORF]:

Its implemented on per neighbor basis.
Its a BGP feature that allows a router to accept a prefix-list from a neighbor and apply it to locally configured ORF neighbor.
A router can install an inbound prefix-list to a peer as an outbound prefix-list.
Its used to minimize the number of updates sent between neighbors and reduce system resources.
Configuration example:
- “neighbor prefix-list name [in/out]” “neighbor capability orf prefix-list [send/receive/both]”

ORF message contains:

Address Family Information [AFI]/ Subsequent AFI
ORF types
When to refresh
List of ORF entries

ORF Types:

type 1 –> Network Layer Reachability Information [NLRI]
type 2 –> Communities
type 3 –> Extended Communities
type 128 –> Prefix-List

Route-Map Filtering:

Route-Map matches: prefix-list/access-list/route originator/next-hop/origin/AS-path/community/IGP tag/IGP type[internal/external].
Route-Map can set: origin/next-hop/weight/local preference/MED/community.
IP Policy List: is grouping of route-map match clauses then attaching to route-map.
Its implemented on per neighbor basis.
Route Map Continue Cause: its like the match and the set causes of the route-map, when a match in the route-map is successful continue clause -if configured- jumps to a pre-specified route-map entry, the continue clause takes place if a match is successful, if not then it is ignored.
If the route-map has no match clause, the continue clause takes place automatically, if a match is successful the continue clause takes place, if not then it is ignored.
Configuration example:
- “ip policy-list name [permit/deny]match [as-path/metric/community]route-map name permit seq-number match policy-map namematch ip address prefix-list namematch ip next-hop prefix-listnamematch ip route-source prefix-list name continue seq-number neighbor ip-address route-mapname[in/out]”

AS-Path Prepending:

Used to influence other ASes to select a specific return path towards an AS.
Used to distribute the load of returning traffic for multihomed customers, however in this case you will have to monitor the traffic and prepend AS to path as needed to accomplish the traffic load.
To avoid BGP AS-Path loop prevention mechanism, use only the AS number of the sending AS.
Service Providers use AS-Path filter to allow routes that are originated from Customers AS only, if the Customer is going to use AS-Path prepending the Service Provider will have to change their filter to allow AS-Path containing more than one copy of Customer’s AS number.
AS-Path prepending is applied using Route-Maps on per neighbor basis. ”route-map route-map-name permit 10 set as-path prepend as-no as-no as-no neighbor ip-address route-map route-map-name out”.

BGP hide local AS:

The “neighbor ip-address local-as as-number [no-prepend [replace-as [dual-as]]]”
- no-prepend: does not prepend local AS number to any learned EBGP routes.
- replace-as: replaces the local AS number with the one set int the command to the AS-path attribute.
- dual-as: allows the establishment of EBGP sessions using either the real AS number or using the AS number set in the command.

This usually happens while connecting two different BGP networks with different AS numbers to not disturb the established peerings [i.e. when an ISP buys another ISP and merging both networks into only one network].
Its drawback : if you configured the above command with an AS number that already exists for one of the IBGP peers, when this IBGP receives the route it will detect its own AS number in the AS path and it will ignore this route considering it as a routing loop.

Multi-Exit Discriminator [MED]:

MED is used to discriminate between multiple exit points within an AS.
MED is used to influence path selection in neighbor AS.
MED doesn’t traverse outside the receiving AS.
Default value is Zero and in comparison the lower value the better, to change the default value use “default-metric number” command.
MED can be set in ways:
- Using a Route-Map
- Inherited from an IGP by either using the BGP Network command or redistributing into BGP.

MED is compared when different values are received from same AS, if “bgp always-compare-med” is used MED from different ASes will be also compared.
In intra-confederations MED is not compared and to compare it “bgp bestpath med confed” should be used.
BGP sets a missing MED value to infinite value, however Cisco IOS does set it to Zero, to change this behavior of Cisco IOS the “bgp bestpath med missing-med-worst” command should be used.
“bgp deterministic-med” allows BGP to compare the MED values after the AS-Path attribute directly.

Communities:

Its a mean of tagging routes and used in filtering or route selection.
By default its stripped in outgoing BGP updates, to enable sending communities the “neighbor ip-address send-community” should be used in per-neighbor basis.
There is no limitation on the number of communities specified for a route.
Route-Map is used for setting the community value, it can be applied with redistribution, network command, neighbor command and aggregate command.
In Route-Map configuration, the “additive” keyword prepends new Community value to the existing Community values, if not used it will override the existing Community values. “set community value[value ...][additive]”
The “ip bgp-community new-format” command is recommended when the Community value contains AS numbers.

Community list “ip community-list 1-99 permit|deny value [value ...]”:
- Values in one line must match to be accepted, if no matches the list acts as an Access-List and denies the route.
- Keyword “internet” acts as permit any.

Extended Community list “ip community-list 100-199 permit|deny regexp”
- Matches are based on regular expressions.
- To match any use “.*” value.

Named Community list “ip community-list standard|expanded name permit|deny value|regexp”.
Sequenced Extended Community List “ip extcommunity-list 100-199|standard list-name permit|denyregexp” or “ip extcommunity-list 0-99|expanded list-name permit|deny [rt extcom-value][soo extcom-value]”
- Allow automatic sequencing or resequencing for BGP Extended Community List
- Allow insertion and deletion of lines in the BGP Extended Community List.
- Rt: Specifies the Route Target of Extended Community attribute.
- Soo: Specifies the Site Of Origin Extended Community attribute.
BGP Cost community “set extcommunity cost [igp] community-id cost-value”
- Its a non-transitive attribute.
- Its used to influence best-path selection for IBGP and confederations only.
- Default value is 2147483647 and in comparison the lower value the better.
- The keyword “IGP”influences the best-path selection at the POI [point of insertion] which follows the IGP metric comparison in BGP route selection criteria. In case if the POI step is not valid the cost community is silently ignored.

BGP Link Bandwidth:

Used for load balancing over unequal bandwidth links.
Enabled by using “bgp dmzlink-bw”.
Routes learned from a directly connected external neighbor propagates through the IBGP network with the bandwidth of the external link.
The “neighbor ip-address dmzlink-bw” command is used to advertise the bandwidth of links used to exit an AS, its configured on the DMZ interface that connect single hop EBGP neighbor.

Route Reflectors:

Route Reflectors are router running BGP that are allowed to break the IBGP loop prevention rules and advertise routes that are received from IBGP pears.
Route Reflectors eliminates the need of full mesh IBGP.
Route Reflector advertises the best routes only.
When Route Reflector receives a route update from a Route Reflector Client; it sends the route to all other peers.
When Route Reflector receives a route update from a Non Route Reflector Client; it sends the route to all of its Clients and EBGP peers only.
When a Route Reflector Client receives an IBGP route update; it sends it to EBGP neighbors only.
When a Route Reflector Client receives an EBGP route update; it sends it to all of its neighbors.
In case of redundant Route Reflectors; Route Reflector Clusters is used to prevent routing loops, the Route Reflector adds Cluster-id and Originator-id to the advertised route updates.
Originator-id is a non-transitive optional attribute.
When a Route Reflector receives a route update with its own Cluster-id; it silently ignores the route update.
When a Route Reflector Client receives a route update with Originator-id same as its Router-id; it silently ignores the route update.
When a Route Reflector receives two IBGP route updates; the non reflected route update [the one with no Originator-id] is preferred.
When a Route Reflector receives two IBGP route updates ; the one with the shortest Cluster-list is preferred.
Route Reflector configuration:
- “neighbor ip-address route-reflector-client”
- “bgp cluster-id cluster-id”

Confederations:

Confederations splits the AS into smaller ASes to reduce the number of BGP sessions needed for full mesh IBGP.
Confederations eliminates the need of full mesh IBGP, however its needed inside each Confederation which can be achieved by setting a Route Reflector inside the Confederation.
When communicating to real EBGP neighbors, internal ASes are hidden and only one external AS is announced to all real EBGP neighbors.
Intra-Confederation EBGP sessions are used between Member-ASes, however it is slightly different from the Real EBGP sessions as is behaves like IBGP in passing BGP attributes as Local-Preference, MED, Next-Hop.
Entire Confederation should use same IGP as they all use same Next-Hop ip- addresses.
Intra-Confederation AS-Path appears between parentheses ( ).
To configure Confederations:
- Start the BGP process with the Member-AS number.
- Set the external “Real” AS number.
- List all Member-ASes of the Confederation on each router with EBGP Session.
- “router bgp member-as” “bgp confederation identifier external-as” “bgp confederation peers list-of-member-as”

Peer Groups:

Used to configure multiple neighbors with similar requirements, also used as a BGP performance enhancement tool since the router builds a single update for all Peer Group members which reduces the CPU load.
IBGP & EBGP neighbors cannot be mixed in one Peer Group.
Peer Group parameters can be overridden by per-neighbor configurations on incoming updates only.
Peer Group configuration: “neighbor group-name peer-group” “neighbor group-name bgp-parameters” “neighbor ip-address peer-group group-name”

Route Dampening:

Used to reduce processing load caused by flapping routes.
IBGP routes are not dampened.
When an EBGP route flaps it gets 1000 Penalty Points, when the Penalty Points exceeds the Suppress Limit the route is dampened. The Penalty Points decay through the use of a decay algorithm, when it drops below the reuse limit the route is re-advertised.
Flapping history of a route forgotten after the Penalty drops below than half of the Reuse Limit.
After enabling Route Dampening; routes in the BGP Table are never removed, the route is kept in the BGP Table and marked as history “h”.
To enable Route Dampening, the “bgp dampening [half-life reuse suppress max-suppress-time] [route-map route-map-name] command is used.
- half-time → time for penalty to decrease to half [default value is 15 minutes].
- suppress → limit in which penalty of a route exceeds the route is suppressed [default value is 2000].
- reuse → limit in which penalty of route drops below, the route is unsuppressed [default value is 750].
- max-suppress-time → no route is suppressed longer than this duration [default value is 60 minutes & maximum us 255 minutes].
Useful commands:
- To clear the statistics of routes flaps “clear ip bgp flap-statistics”.
- To release Dampened Routes “clear ip bgp dampening”.
- “show ip bgp dampened-paths”.
- “show ip bgp flap-statistics [ regexp regexp | filter-list access-list | ip-address mask [longer-prefix] ]”.

Network Juniors

Friday, March 15, 2013

Can we implement BGP without IGP Protocol ? If yes, then how can we do it ? If no, why ?

BGP; Why we need to create static route to advertise a network?

Before BGP advertised its network, it checks the forwarding table for an exact match of network number and mask on router’s routing table.

Monday, January 14, 2013

BGP Foundations

About Me