HPE Aruba Mobility Controller Besic Setup

 

Using CLI 

(Aruba) #configure terminal

Enter Configuration commands, one per line. End with CNTL/Z
 
(Aruba) (config) #ip dhcp pool Guest-User
(Aruba) (config-dhcp)#network 10.10.10.0 255.255.255.0
(Aruba) (config-dhcp)#default-router 10.10.10.1
(Aruba) (config-dhcp)#dns-server 10.10.50.1
(Aruba) (config-dhcp)#exit
(Aruba) (config) #service dhcp    //This command enables the DHCP service on the controller
(Aruba) (config) #end
(Aruba) #

(Aruba) #show ip dhcp database

DHCP enabled

# v-20
subnet 192.168.20.0 netmask 255.255.255.0 {
        option domain-name "10.30.156.130";
        option vendor-class-identifier  "ArubaAP";
        option vendor-encapsulated-options  "10.30.156.140";
        option domain-name-servers 10.30.156.140;
        option routers 192.168.20.1;
        range 192.168.20.2 192.168.20.254;
        authoritative;
}
# Guest-User
subnet 10.10.10.0 netmask 255.255.255.0 {
        option vendor-class-identifier  "ArubaAP";
        option vendor-encapsulated-options  "10.30.156.140";
        option domain-name-servers 10.10.50.1;
        option routers 10.10.10.1;
        range 10.10.10.2 10.10.10.254;
        authoritative;

50 Points to Remember for BGP

BGP is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability, from which routing loops may be pruned and, at the AS level, some policy decisions may be enforced.

Path Vector Messages in BGP: The autonomous system boundary routers (ASBR), that participate in path vector routing, advertise the reachability of networks. every router that receives a path vector message should verify that the publicized  path is in line with its policy. If the messages go with the policy, the ASBR modifies its routing table and also the message before causation it to ensuing neighbor. within the changed message it sends its own AS variety and replaces ensuing router entry with its own identification.
 

There are some things we need to remember for BGP

1. BGP uses TCP port 179 for transport. Router with the higher BGP router-id initiates BGP session from a random port.
2. The interface from which the BGP router ID is taken does not have to be running BGP. Any valid IP address can be used as BGP router-id, even an address that is not locally configured on the router.
3. The BGP router-id must be the same as the OSPF router-id for redistributing the routes from OSPF to BGP or vice versa.
4. If the 'network …' command is configured with the 'mask' option under the BGP process, then an exact match (network/mask) must exist in the IP routing table in order to advertise this route into BGP regardless of 'auto-summary' / 'no auto-summary' command. But the 'network …' command configured without the 'mask' assumes the default classful mask and if 'auto-summary' is configured then BGP will advertise a classful network only if any subnets of the classful network exist in the IP routing table. Again if the 'network …' command is configured without the 'mask' option and if 'no auto-summary' is configured, then that router must have the exact classful network in the IP routing table in order to advertise it in BGP.
5. To accept and attempt BGP connections to the external peers residing on networks that are not directly connected, we need to use either 'neighbor ebgp-multihop …' or 'neighbor ttl-security …' command. These two commands are mutually exclusive. We can use another command 'neighbor disable-connected-check' to accomplish the same task if the BGP neighbor is one-hop away.
6. The synchronization rule states that an iBGP learned prefix cannot be considered best unless there is a matching IGP route for that BGP prefix. BGP only advertises what it considers the best path. This issue can be resolved (1) by redistributing BGP routes into the IGP, (2) by creating a full-mesh of IBGP routers and disabling the synchronization, or (3) by creating a GRE tunnel. When BGP is synchronizing with OSPF, the router ID must match in both protocols in order to make it work.
7. When a prefix is received from an eBGP neighbor, it is advertised to both eBGP & iBGP neighbors. When a prefix is received from an iBGP neighbor, it is advertised ONLY to eBGP neighbors and not to any iBGP neighbors. To advertise iBGP leaned routes to other iBGP peers requires the use of route-reflectors or confederations or a full-mesh of iBGP peers.
8. While sending BGP updates, EBGP peers modify the next-hop value to its own IP address. But iBGP peers do not modify it.
9. The ‘default-information originate’ command, however, requires explicit redistribution of the route 0.0.0.0. . Default routes can be injected into BGP in one of three ways: (1) using the 'network …' command (default route must exist in the local routing table), (2) using the 'default-information originate' command (a redistribution statement must also be configured to redistribute the default route from the local routing table to the BGP table), and (3) using the 'neighbor … default-originate [route-map route-map-name]' command (this method does not even check for the existence of a default route in the IP routing table). The 'default-information originate' command should not be configured with the 'neighbor … default-originate' command on the same router.
10. 'weight' and 'local-preference' are set inbound and they affect outbound traffic. But 'as-path' and 'med' are set outbound and they affect inbound traffic.
11. The weights assigned with the 'set weight …’ route-map command overrides the weights assigned using the 'neighbor…  weight …' command.
12. Origin code 'i' is default on the BGP routes advertised by 'network ...', 'aggregate-address ...' (if all subnet has 'i'), and 'neighbor … default-originate' commands. And origin code '?' is default on the BGP routes advertised by 'redistribute ...', 'aggregate-address ...' (if any single subnet has '?', but can be changed using ‘attribute-map’ option), 'default-information originate', and 'bgp inject-map ...' commands.
13. When BGP originates a route with the ‘network …’ command, MED is copied from the metric of the original route.
14. BGP MED values are not passed beyond the receiving (neighbor) AS.
15. Enabling the ‘bgp deterministic-med’ command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the ‘bgp always-compare-med’ command ensures the comparison of the MED for paths from neighbors in different autonomous systems.
16. The default behavior of BGP routers that run Cisco IOS software is to treat routes without the MED attribute as having a MED of 0, making the route that lacks the MED variable the most preferred. The 'bgp bestpath med missing-as-worst' command can be configured to treat the route that missing MED as the least preferred one.
17. ‘bgp bestpath as-path ignore’ is a hidden command in Cisco IOS which allows BGP to not consider the AS path during best path route selection.
18. There are two ways to create an aggregate address under BGP. The first is to create a static route to null interface in the routing table for the aggregate address and then advertise it with the ‘network …’ command. The second way is to use the ‘aggregate-address …’ command.
19. By default when aggregation is configured in BGP, the 'atomic-aggregate' attribute is attached to the aggregate address if the 'as-set' argument is not used in the 'aggregate-address …' command. The 'as-set' argument reveals the AS numbers which can prevent a routing loop, and once 'as-set' is configured along with the 'aggregate-address …' command, the 'atomic-aggregate' attribute is automatically removed.
20. A router reflector and its clients are known collectively as a cluster. If the cluster contains a single route reflector, the cluster ID is the router ID of the route reflector. If the cluster contains multiple route reflectors, each RR must be manually configured with a cluster ID.
21. A client router in a route reflection cluster can peer with external neighbors, but the only internal neighbor it can peer with is a route reflector in its cluster or other clients in the cluster. Clients cannot peer with routers outside of their own cluster. However, the RR itself can peer with both internal and external neighbors outside of the cluster and can reflect their routes to its clients.
22. In case of route reflection, (1) routes from EBGP are advertised to EBGP, client, non-client (2) routes from client are advertised to EBGP, client, non-client (3) routes from non-client are advertised to EBGP, client.
23. When the 'no bgp client-to-client reflection' command is configured the RR does not reflect routes from one client to another. It does, however, continue to reflect routes from clients to peers outside of the cluster, and from peers outside of the cluster to clients.
24. Standard and extended BGP communities are removed from the reflected routes unless the 'neighbor ... send-community [both]' is configured on the route reflector. The link bandwidth community is removed from reflected route if the route-reflector performs IBGP multipath load-sharing for that route.
25. The “neighbor … nexthop-self” on router reflectors only affects the next hop of eBGP learned routes because the next hop of reflected routes should not be changed. To avoid a common configuration error for reflected routes, the “set ip next-hop” command should not be used in a route map to BGP route reflector clients.
26. Unlike route reflector environments in which only the route reflector itself has to support route reflection, all routers within a confederation must support the confederation functionality.
27. EBGP routes external to the confederation are preferred over EBGP routes to member autonomous systems, which are preferred over iBGP routes.
28. AS_PATH types are AS_SEQUENCE, AS_CONFED_SEQUENCE, AS_SET, and AS_CONFED_SET. AS_SEQUENCE is an ordered set of AS numbers, and AS_SET is an unordered set of AS numbers. AS_CONFED_SEQUENCE and AS_CONFED_SET are the same as AS_SEQUENCE and AS_SET but are used only within BGP confederations.
29. When 'bgp bestpath med confed' command is configured, the router picks the confederation-internal path with the lowest MED and ignores the path with the external AS number.
30. BGP private autonomous system numbers are from 64,512 to 65,535
31. BGP prefixes can be filtered using (1) 'distribute-list', (2) 'prefix-list', (3) 'filter-list', (4) 'policy-list', (5) community/extended community lists, (6) 'route-map' .
32. For BGP, the ‘distance …’ command sets the administrative distance of the External BGP (eBGP) route. This command only affects the routing table and not the BGP table.
33. The 'network … backdoor' command has the same effect as the 'network …' command. The EBGP route is treated as a local BGP route, and the administrative distance is changed to 200. The difference is that the address specified by the network backdoor command is not advertised to EBGP peers.
34. iBGP routes are not redistributed into an IGP unless you use "bgp redistribute-internal" command under BGP routing process.
35. 'bgp inject-map ... exist-map ...' command injects prefixes in the local BGP RIB when a valid parent route exists. Only prefixes that are equal to or more specific than the aggregate route (existing prefix) can be injected. exist-map (route-map) must contain a 'match ip address prefix-list ...' command statement to specify the aggregate prefix and a 'match ip route-source prefix-list ...' command statement to specify the route source. If the parent route is a default route, we can inject any route out of it.
36. A BGP neighbor cannot be configured to work with both peer groups and peer templates. BGP peer templates and BGP peer groups are mutually exclusive.
37. Peer session template can inherit only one session template directly, but peer policy template can inherit multiple policy templates.
38. When the maximum number (as set by the ‘neighbor … maximum-prefix ...’ command) of prefixes are reached, the string "PfxRcd" appears in the entry, the neighbor goes to shutdown  state, and the connection becomes idle.
39. No penalty is applied to a BGP peer reset when route dampening is enabled. Although the reset withdraws the route, no penalty is applied in this instance.
40. In case of iBGP multipath load sharing, when multiple iBGP paths installed in a routing table, a route reflector will advertise only one of the paths (one next hop).
41. For multiple paths to the same destination to be considered as multipaths, all attributes including weight, local preference, autonomous system path (entire attribute and not just length), origin code, MED, and IGP distance must be same. But if 'bgp bestpath as-path multipath-relax' command is configured, the AS paths still have to be the same length, but don't have to be identical.
42. Though BGP Multipath allows the installation of multiple BGP paths (for load sharing purpose) into the IP routing table for the same prefix, it does not affect the bestpath selection. A router still designates one of the paths as the best path and advertises this best path to its neighbors.
43. 'neighbor … dmzlink-bw' command can be used with eBGP and iBGP multipath features to enable unequal cost load balancing over multiple links. BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors.
44. The 'bgp update-delay ...' command is used to tune the maximum time the software will wait after the first neighbor is established until it starts calculating best paths and sending out advertisements.
45. The routers configured with the “neighbor … local-as …” command prepend local-AS in inbound EBGP updates and prepend both actual AS number and local-AS number in outbound EBGP updates
46. The “neighbor … local-as …” command is valid only if the peer is a true eBGP peer. It does not work for two peers in different sub-ASs in a confederation.
47. In a route-map, a continue clause can be executed, without a successful match, if a route map entry does not contain a match clause. But if a match clause exists, the continue clause is executed only if a match occurs. If no successful matches occur, the continue clause is ignored. The continue statement proceeds to the specified route map entry only after configured set actions (if any) are performed.
48. When multiple values are configured in the same community list statement, a logical AND condition is created. All community values must match to satisfy an AND condition. When multiple values are configured in separate community list statements, a logical OR condition is created. The first list that matches a condition is processed.
49. While redistributing OSPF into BGP, by default only OSPF intra-area and inter-area routes are redistributed into BGP.
50. When a BGP router with synchronization enabled has also a OSPF route (redistributed from BGP) for a iBGP-learned route, then the OSPF ASBR router-id must match the originating BGP router-id in order to synchronize BGP route with OSPF route.

BGP - A Detail Explanation

Border Gateway Protocol (BGP)

BGP is a protocol which performs routing information exchange among routers to determine the optimal paths for the traffic flow. A BGP router forms a neighbor relationship by connecting to its neighbors and exchanging the routes, once the connection is established. 

Without BGP the Internet as we know it would be quite a bit more inefficient. As it is today the Internet BGP routing tables have over 300,000 active forwarding entries and this is with stigmatization of over 2 billion addresses. Imagine what these tables would be like without stigmatization.

For those interested, some ISP’s allow the ability to telnet into their edge BGP routers to view the BGP routing tables (Check out ‘route-server.ip.att.net’).

BGP's purpose is not only to exchange its information, but also to exchange network reach-ability and availability information for the Autonomous Systems (AS) paths with other BGP systems on the network. This process allows all systems to construct topology graphs of the entire network infrastructure on both sides of the BGP link.

This process also allows these systems to identify loops and other issues that may affect network performance and availability.

BGP Overview

·  BGP uses the concept of autonomous systems (AS). An autonomous system is a group of networks under a common administration. The Internet Assigned Numbers Authority (IANA) assigns AS numbers: 1 to 64511 are public AS numbers and 64512 to 65535 are private AS numbers.

·  Autonomous systems run Interior Gateway Protocols (IGP) within the system. They run an Exterior Gateway Protocol (EGP) between them. BGP version 4 is the only EGP currently in use.

·  Routing between autonomous systems is called interdomain routing.

·  The administrative distance for EBGP routes is 20. The administrative distance for IBGP routes is 200.

·  BGP neighbors are called peers and must be statically configured.

·  BGP uses TCP port 179. BGP peers exchange incremental, triggered route updates and periodic keepalives.

·  Routers can run only one instance of BGP at a time.

·  BGP is a path-vector protocol. Its route to a network consists of a list of autonomous systems on the path to that network.

·  BGP's loop prevention mechanism is an autonomous system number. When an update about a network leaves an autonomous system, that autonomous system's number is prepended to the list of autonomous systems that have handled that update. When an autonomous system receives an update, it examines the autonomous system list. If it finds its own autonomous system number in that list, the update is discarded.

 

BGP Databases

BGP uses three databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:

• Neighbor database: A list of all configured BGP neighbors. To view it, use the show ip bgp summary command.
• BGP database, or RIB (Routing Information Base): A list of networks known by BGP, along with their paths and attributes. To view it, use the show ip bgp command.
• Routing table: A list of the paths to each network used by the router, and the next hop for each network. To view it, use the show ip route command.

 

BGP Message Types

BGP has four types of messages:

• Open: After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor. Includes information such as autonomous system number, router ID, and hold time.
• Update: Message used to transfer routing information between peers. Includes new routes, withdrawn routes, and path attributes.
• Keepalive: BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session active.
• Notification: When a problem occurs that causes a router to end the BGP peering session, a notification message is sent to the BGP neighbor and the connection is closed.

BGP Routing

As with any routing protocol, BGP maintains routing tables, transmits routing updates, and bases routing decisions on routing metrics. The primary function of a BGP system is to exchange network-reach ability information, including information about the list of autonomous system paths, with other BGP systems. This information can be used to construct a graph of autonomous system connectivity from which routing loops can be pruned and with which autonomous system-level policy decisions can be enforced.
Each BGP router maintains a routing table that lists all feasible paths to a particular network. The router does not refresh the routing table, however. Instead, routing information received from peer routers is retained until an incremental update is received.
BGP devices exchange routing information upon initial data exchange and after incremental updates. When a router first connects to the network, BGP routers exchange their entire BGP routing tables. Similarly, when the routing table changes, routers send the portion of their routing table that has changed. BGP routers do not send regularly scheduled routing updates, and BGP routing updates advertise only the optimal path to a network.

BGP Operation

BGP performs three types of routing: interautonomous system routing, intra-autonomous system routing, and pass-through autonomous system routing.

Interautonomous system routing occurs between two or more BGP routers in different autonomous systems. Peer routers in these systems use BGP to maintain a consistent view of the internetwork topology. BGP neighbors communicating between autonomous systems must reside on the same physical network. The Internet serves as an example of an entity that uses this type of routing because it is comprised of autonomous systems or administrative domains. Many of these domains represent the various institutions, corporations, and entities that make up the Internet. BGP is frequently used to provide path determination to provide optimal routing within the Internet.

Intra-autonomous system routing occurs between two or more BGP routers located within the same autonomous system. Peer routers within the same autonomous system use BGP to maintain a consistent view of the system topology. BGP also is used to determine which router will serve as the connection point for specific external autonomous systems. Once again, the Internet provides an example of interautonomous system routing. An organization, such as a university, could make use of BGP to provide optimal routing within its own administrative domain or autonomous system. The BGP protocol can provide both inter- and intra-autonomous system routing services.

Pass-through autonomous system routing occurs between two or more BGP peer routers that exchange traffic across an autonomous system that does not run BGP. In a pass-through autonomous system environment, the BGP traffic did not originate within the autonomous system in question and is not destined for a node in the autonomous system. BGP must interact with whatever intra-autonomous system routing protocol is being used to successfully transport BGP traffic through that autonomous system.   

Figure: In pass-through autonomous system routing, BGP pairs with another intra-autonomous system-routing protocol.

What is the difference between eBGP and iBGP?

1. EBGP is peering between two different AS, whereas IBGP is between same AS (Autonomous System).

2. Routes learned from eBGP peer will be advertised to other peers (BGP or IBGP); however, routes learned from IBGP peer will not be advertised to other IBGP peers.

3. By default, EBGP peers are set with TTL = 1, which means neighbors are assumed to be directly connected, which is not in the case of IBGP. We can change this behavior for EBGP by using command “neighbor x.x.x.x ebgp-multihop <TTL>”. Multihop is the term used in EBGP only.

4. EBGP routes have administrative distance of 20, whereas IBGP has 200.

5. Next hop remains unchanged when route is advertised to IBGP peer; however, it is changed when it is advertised to EBGP peer by default.

This default behavior of IBGP can be changed by the command “neighbor x.x.x.x next-hop-self”; this changes the next hop, while advertising, as a local route.

 

Configuring BGP

In its most basic configuration BGP acts very similarly to a distance vector routing protocol. Each network which is advertised is selected by choosing the shortest path. BGP just uses a path (Autonomous Systems – AS) hop count instead of a device hop count.
For example, BGP works by routing traffic between AS’s, so if Verizon had AS 12345 and AT&T had AS 54321 then traffic destined for the AT&T network would be routed from Verizon to AT&T with a path of (54321). What this means is in order to reach a specific network on the AT&T network, traffic on the Verizon network would have to be routed to AS 54321.
In the following figure I show three AS’s and their corresponding path metrics:

BGP also has loop prevention built in (although this is an open debate); this is implemented with a simple mechanism which disallows routes to be advertised into an AS if the local AS is part of the path metric.

With the example above, only the most basic AS_Path metric is shown, however there are many different path attributes which can be used with BGP to affect path selection along with AS_Path.

Basic BGP Configuration

The first thing that must be understood is that each BGP device can have both internal and external BGP connections to other devices. Internal BGP connections are within the same AS while external BGP connections are between different AS’s. This is important because the configuration and behavior is slightly different between the two.

eBGP Configuration

 
At its most basic the configuration of eBGP requires only two commands, these include:

1. router bgp as-number
2. neighbor ip-address remote-as remote-as-number

What makes eBGP configuration obvious from iBGP configuration is that the AS-number which is used in the neighbor command is different than the AS-number configured with the router bgp command.
It must also be known that with eBGP by default there is a direct connection requirement which is enforced by an advertised TTL of 1. Now when configuring BGP using loopback interfaces this can become an issue as the packet actually takes two hops from the remote device to the physical interface and from the physical interface to the loopback interface.
This issue can be resolved by using the neighbor ebgp-multihop command on Cisco equipment.

iBGP Configuration

 
iBGP configuration is very similar to eBGP configuration but requires a little understanding of iBGP requirements. By default, iBGP requires that all iBGP devices being used are fully meshed (although there are ways of getting around this). This does not however mean that a direct connection is required but that each iBGP peer must neighbor with each other iBGP router.
The following configuration shows that configuration of an iBGP neighbor is the same as with eBGP:

1. router bgp as-number
2. neighbor ip-address remote-as remote-as-number

The other thing that must be understood is how external BGP routes are advertised into iBGP. See the following figure:

In this example, when Level3-2 advertises the eBGP route for the 192.168.128.0/17 network to Level3-1 it will do this with a next-hop of 10.10.10.1 by default. Now if Level3-1 does not have a valid route to the 10.10.10.1 address then it will be unable to route traffic destined for the 192.168.128.0/17 network.

The most common method of resolving this issue is by using the neighbor neighbor-ip-address next-hop-self-command. When using this command the local eBGP peer will advertise the next-hop with its own IP address and not the address configured with the BGP neighbor command.

In this case, Level3-2 could be configured with the neighbor 10.100.100.2 next-hop-self-command which would advertise the 192.168.128.0/17 network with a next-hop of 10.100.100.1 instead of 10.10.10.1.

BGP Next-Hop Selection

The next hop for a route received from an EBGP neighbor is the IP address of the neighbor that sent the update.
When a BGP router receives an update from an EBGP neighbor, it must pass that update to its IBGP neighbors without changing the next-hop attribute. The next-hop IP address is the IP address of an edge router belonging to the next-hop autonomous system. Therefore, IBGP routers must have a route to the network connecting their autonomous system to that edge router. For example, in Figure, RtrA sends an update to RtrB, listing a next hop of 10.2.2.1, its serial interface. When RtrB forwards that update to RtrC, the next-hop IP address will still be 10.2.2.1. RtrC needs to have a route to the 10.2.2.0 network to have a valid next hop.

To change this behavior, use the neighbor [ip address] next-hop-self-command in BGP configuration mode. In Figure, this configuration goes on RtrB. After you give this command, RtrB advertises its IP address to RtrC as the next hop for networks from AS 65100, rather than the address of RtrA. Thus, RtrC does not have to know about the external network between RtrA and RtrB (network 10.2.2.0).

How does BGP select the best routing path /

BGP Attributes

BGP Best Path Selection Algorithm determines the best route by selecting the shortest path to the destination. An Autonomous System is a single network or a set of networks and routers, which are under the control of one administrative entity. Nevertheless, network administrators frequently manipulate such options as local preference, lowest multi-exit discriminator and weight.

The list of the selection criteria is presented below in the same order in which BGP uses them to select the optimal routes to be injected into the IP Routing table:

1) Weight — weight is the first criterion used by the router and it is set locally on the user’s router. The Weight is not passed to the following router updates. In case there are multiple paths to a certain IP address, BGP always selects the path with the highest weight. The weight parameter can be set either through neighbor command, route maps or via the AS-path access list.

Figure: BGP Weight Attribute

In Figure: BGP Weight Attribute, Router A is receiving an advertisement for network 172.16.1.0 from routers B and C. When Router A receives the advertisement from Router B, the associated weight is set to 50. When Router A receives the advertisement from Router C, the associated weight is set to 100. Both paths for network 172.16.1.0 will be in the BGP routing table, with their respective weights. The route with the highest weight will be installed in the IP routing table.

2) Local Preference — this criterion indicates which route has local preference and BGP selects the one with the highest preference. Local Preference default is 100.

Figure: BGP Local Preference Attribute

In Figure: BGP Local Preference Attribute, AS 100 is receiving two advertisements for network 172.16.1.0 from AS 200. When Router A receives the advertisement for network 172.16.1.0, the corresponding local preference is set to 50. When Router B receives the advertisement for network 172.16.1.0, the corresponding local preference is set to 100. These local preference values will be exchanged between routers A and B. Because Router B has a higher local preference than Router A, Router B will be used as the exit point from AS 100 to reach network 172.16.1.0 in AS 200.

3) Network or Aggregate — this criterion chooses the path that was originated locally via an aggregate or a network, as the aggregation of certain routes in one is quite effective and helps to save a lot of space on the network.

4) Shortest AS_PATH — this criterion is used by BGP only in case it detects two similar paths with nearly the same local preference, weight and locally originated or aggregate addresses.

Figure: BGP AS_PATH Attribute

AS1 originates the route to 172.16.1.0 and advertises this route to AS 2 and AS 3, with the AS_path attribute equal to {1}. AS 3 will advertise back to AS 1 with AS-path attribute {3,1}, and AS 2 will advertise back to AS 1 with AS-path attribute {2,1}. AS 1 will reject these routes when its own AS number is detected in the route advertisement. This is the mechanism that BGP uses to detect routing loops. AS 2 and AS 3 propagate the route to each other with their AS numbers added to the AS_path attribute. These routes will not be installed in the IP routing table because AS 2 and AS 3 are learning a route to 172.16.1.0 from AS 1 with a shorter AS_path list.

5) Lowest origin type — this criterion assigns higher preference to Exterior Gateway Protocol (EGP) and lower preference to Interior Gateway Protocol (IGP).

6) Lowest multi-exit discriminator (MED) — this criterion, representing the external metric of a route, gives preference to the lower MED value.

Figure: BGP Multi-Exit Discriminator Attribute

In Figure: BGP Multi-Exit Discriminator Attribute, Router C is advertising the route 172.16.1.0 with a metric of 10, while Route D is advertising 172.16.1.0 with a metric of 5. The lower value of the metric is preferred, so AS 100 will select the route to router D for network 172.16.1.0 in AS 200. MEDs are advertised throughout the local AS.

7) eBGP over iBGP — just like the “Lowest origin type” criterion, this criterion prefers eBGP rather than iBGP.

8) Lowest IGP metric — this criterion selects the path with the lowest IGP metric to the BGP next hop.

9) Multiple paths — this criterion serves as indication whether multiple routes need to be installed in the routing table.

10) External paths — out of several external paths, this criterion selects the first received path.

11) Lowest router ID — this criterion selects the path which connects to the BGP router that has the lowest router ID.

12) Minimum cluster list — in case multiple paths have the same router ID or originator, this criterion selects the path with the minimum length of the cluster list.

13) Lowest neighbor address — this criterion selects the path, which originates from the lowest neighbor address.

Example Configuration of BGP

To start BGP on a Cisco router, the following command is required:

router bgp autonomous system number

To define networks to be advertised, apply the following command:

network network-number mask network-mask

You must be aware that the network command is not used in the same way you use it when you apply networks in OSPF or EIGRP. With BGP, you use the network command to advertise networks that originate from the router and need to be advertised through BGP.
To identify peer routers, apply the following command:

neighbor ip-address | peer-group name remote-as autonomous system number

Next, we will see how to configure IBGP and EBGP among the three routers in below Figure.

Example-1 displays the IBGP configuration on R1 to R2.

Example-1. IBGP on R1

R1(config)#router bgp ?

  <1-65535>  Autonomous system number

R1(config)#router bgp 1

R1(config-router)#neighbor 131.108.1.2 remote 1 

Example-2 displays the IBGP configuration to R1 and EBGP configuration to R3.

Example-2. IBGP/EBGP on R2

R2(config)#router bgp 1

R2(config-router)#neighbor 131.108.1.1  remote-as 1

R2(config-router)#neighbor 131.108.255.2 remote-as 2

Finally, Example-3 displays the EBGP connection from R3 to R2.

Example-3. EBGP on R3

R3(config)#router bgp ?

  <1-65535>  Autonomous system number

R3(config)#router bgp 2

R3(config-router)#neighbor 131.108.255.1 remote-as 1

At this stage, because no network statements have been applied, no BGP entries are on any routers. Use some loopback interfaces on R1 and advertise them through BGP to R2 and R3.


Example-4 displays the three new loopback addresses on R1, ranging from 131.108.2.0 to 131.108.4.0.

Example-4. Loopback Configuration on R1

R1(config)#interface loopback 0

R1(config-if)#ip address 131.108.2.1 255.255.255.0

R1(config-if)#interface loopback 1

R1(config-if)#ip address 131.108.3.1 255.255.255.0

R1(config-if)#interface loopback 2

R1(config-if)#ip address 131.108.4.1 255.255.255.0

We must next advertise these loopbacks with the network command. Because these networks are local to R1 and present in R1's IP routing table as connected routes, you can apply the network command as displayed in Example-5.

Example-5. network Command on R1

R1(config)#router bgp 1

R1(config-router)#network 131.108.2.0 mask 255.255.255.0

R1(config-router)#network 131.108.3.0 mask 255.255.255.0

R1(config-router)#network 131.108.4.0 mask 255.255.255.0

Example-6 displays the BGP table on R1, using the command show ip bgp.
 

Example-6. show ip bgp on R1

R1#show ip bgp

BGP table version is 4, local router ID is 131.108.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 131.108.2.0/24   0.0.0.0                  0         32768 i

*> 131.108.3.0/24   0.0.0.0                  0         32768 i

*> 131.108.4.0/24   0.0.0.0                  0         32768 i

The BGP table on R1 displays three local networks (next hop is 0.0.0.0 or local interfaces). Example-6 also displays the path as i, or advertised through BGP. The local router ID is 131.108.1.1.




Example-7 displays the BGP table on R2.


Example-7. show ip bgp on R2

R2#show ip bgp 

BGP table version is 7, local router ID is 171.109.3.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

* i131.108.2.0/24   131.108.1.1              0    100      0 i

* i131.108.3.0/24   131.108.1.1              0    100      0 i

* i131.108.4.0/24   131.108.1.1              0    100      0 i

R2's local router is 131.108.1.2, and it learns the remote loopbacks on R1 through the next hop address 131.108.1.1, or R1's Ethernet interface. Notice that R2 has set the local preference to 100 (default value); the origin attribute is set to i or IGP.

Because R1 and R2 are running only IBGP and no other interior gateway protocol, R2's IP routing table does not have the BGP entries inserted because of synchronization. 

Example-8 confirms this with only the locally connected routes visible on R2.

Example-8. show ip route on R2

R2#show ip route

        131.108.0.0/24 is subnetted, 2 subnets

C       131.108.255.0 is directly connected, Serial1/0

C       131.108.1.0 is directly connected, Ethernet0/0

To enable BGP to insert the routes, you must disable synchronization or configure an IGP routing protocol. R2, in turn, does not propagate the loopbacks to R3; therefore, R3 does not have any entries at all, either in the BGP table or IP routing table.
Disable synchronization on R1 and R2.

 Example-9 displays the no synchronization command on R1 and R2.

Example-9. Disabling Synchronization on R1/R2

R1(config)#router bgp 1

R1(config-router)#no synchronization

R2(config)#router bgp 1

R2(config-router)#no synchronization

Example-10 displays R2's routing table.

 

Example-10. R2's Routing Table

R2#sh ip route

        131.108.0.0/24 is subnetted, 5 subnets

C       131.108.255.0 is directly connected, Serial1/0

B       131.108.4.0 [200/0] via 131.108.1.1, 00:00:43

B       131.108.3.0 [200/0] via 131.108.1.1, 00:00:43

B       131.108.2.0 [200/0] via 131.108.1.1, 00:00:43

C       131.108.1.0 is directly connected, Ethernet0/0

The three remote networks are inserted into the IP routing tables as BGP-learned networks.

Example-11 displays R3's BGP and IP routing table.

Example-11. R3's BGP and IP Tables

R3>show ip bgp

BGP table version is 10, local router ID is 131.108.255.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP,? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 131.108.2.0/24   131.108.255.1                          0 1 i

*> 131.108.3.0/24   131.108.255.1                          0 1 i

*> 131.108.4.0/24   131.108.255.1                          0 1 i

R3>show ip route

     131.108.0.0/24 is subnetted, 5 subnets

C       131.108.255.0 is directly connected, Serial0

B       131.108.4.0 [20/0] via 131.108.255.1, 00:02:09

B       131.108.3.0 [20/0] via 131.108.255.1, 00:02:09

B       131.108.2.0 [20/0] via 131.108.255.1, 00:02:09

C       131.108.1.0 is directly connected, Ethernet0

Notice that the next hop address on R3 is R2. The AS path on R3 indicates that the remote networks, 131.108.2.0 to 131.108.4.0/24, transverse autonomous system number 1, as displayed in the BGP table in Example-11.

Verifying BGP Operation

This final scenario looks at Cisco IOS mechanisms for monitoring and verifying BGP routing within a Cisco router network.
Refer to Figure and the BGP topology to see how to use some common show commands to verify that BGP is operating correctly.
Show and debug commands can be valuable, not only in the real-life networks you come across, but also during your certification exams.
This scenario covers the following commands:

• show ip bgp summary— Displays BGP neighbors in summary mode
• show ip bgp— Displays the BGP topology table
• clear ip bgp *— Clears all BGP TCP sessions
• show tcp brief— Displays all TCP sessions (BGP uses TCP)
• debug ip bgp events— Displays any BGP events, such as neighbor state changes
•  

Example 1 displays a sample output taken from R1 in Figure using the IOS show ip bgp summary command.

Example 1. show ip bgp summary on R1

R1#show ip bgp summary

BGP router identifier 131.108.255.13, local AS number 1

BGP table version is 11, main routing table version 11

6 network entries and 10 paths using 854 bytes of memory

3 BGP path attribute entries using 280 bytes of memory

BGP activity 50/44 prefixes, 73/63 paths

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

131.108.1.2     4     1     194     195       11    0    0 00:03:22        2

131.108.255.6   4     1      84      83       11    0    0 00:03:23        3

131.108.255.14  4     1     152     152       11    0    0 00:03:23        3

141.199.1.1     4  1001       0       0        0    0    0 never    Idle

Example 1 displays a lot of useful information, including the local router identifier 131.108.255.13, the local AS of 1, and the BGP table version of 11. (An increasing version number indicates a network change is occurring; if no changes occur, this number remains the same.) It also shows six network paths on R1, using 854 bytes of memory.

Memory is important in BGP because in a large network, such as the Internet, memory can be a limiting factor. As more BGP entries populate the IP routing table, more memory is required.

Example 2 show ip bgp

R1>show ip bgp

BGP table version is 11, local router ID is 131.108.255.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i131.108.255.0/30 131.108.1.2              0    100   1000 i

* i                 131.108.255.14           0    100   1000 i

*> 131.108.255.4/30 0.0.0.0                  0         32768 i

* i                 131.108.255.6            0    100   1000 i

*>i131.108.255.8/30 131.108.1.2              0    100   1000 i

* i                 131.108.255.6            0    100   1000 i

*> 131.108.255.12/30 0.0.0.0                 0         32768 i

* i                 131.108.255.14           0    100   1000 i

*>i141.108.1.0/24   131.108.255.6            0    100   1000 i

*>i151.108.1.0/24   131.108.255.14           0    100   1000 i

Again, the BGP table version is displayed as 11 and the local router ID is 131.108.255.13. The various networks are listed along with the next hop address, metric (MED), local preference (Locpref), weight, and the path. On the left side (part of the status codes) indicates an internal BGP route and the i on the right side of Example 2 indicates the origin. (i is for IGP, part of the origin codes.)

If a BGP configuration change is completed on Cisco IOS routers, the BGP peer session must be cleared. The command to clear all sessions is clear ip bgp *. To clear a single peer router, use the clear ip bgp peer-ip-address command.

Example 3. clear ip bgp * and show ip bgp on R1

R1#clear ip bgp ?

   *                Clear all connections

  <1-65535>        AS number of the peers

  A.B.C.D          BGP neighbor address to clear

  dampening        Clear route flap dampening information

  flap-statistics  Clear route flap statistics

  peer-group       Clear BGP connections of peer-group

R1#clear ip bgp *

R1#show ip bgp

BGP table version is 11, local router ID is 131.108.255.13

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i131.108.255.0/30 131.108.1.2              0    1000   1000 i

* i                 131.108.255.14           0    1000  1000 i

*> 131.108.255.4/30 0.0.0.0                  0         32768 i

* i                 131.108.255.6            0    1000   1000 i

*>i131.108.255.8/30 131.108.1.2              0    1000   1000 i

* i                 131.108.255.6            0    1000   1000 i

*> 131.108.255.12/30 0.0.0.0                 0         32768 i

* i                 131.108.255.14           0    1000   1000 i

*>i141.108.1.0/24   131.108.255.6            0    1000   1000 i

*>i151.108.1.0/24   131.108.255.14           0    100   1000 i

This tool displays a number of options, including clearing BGP sessions based on AS numbers or remote peer address. On Cisco IOS routers, you must clear the BGP sessions if you want a change to take place because BGP does not update changes after a BGP session is established. You can, however, configure soft configurations with the neighbor peer address soft-reconfiguration inbound command, which enables you to make changes and not have to clear the TCP peer, resulting in no downtime.

Example 4 show tcp brief

R1#show tcp brief

TCB       Local Address           Foreign Address        (state)

812CC228  131.108.255.5.11040     131.108.255.6.179      ESTAB

812CF508  131.108.1.1.11039       131.108.1.2.179        ESTAB

812D0054  131.108.255.13.11041    131.108.255.14.179     ESTAB

Router R1, as displayed in Example 4, has three TCP sessions in an established state. The TCP port numbers are also listed. This command is useful because you need to be certain that TCP is active at Layer 4 of the OSI model when troubleshooting to discover why two BGP peers are not sending updates, for example. The foreign addresses list the TCP port as 179, and the local address is a number TCP generates. This tells you that R1 has three TCP sessions active, and you can expect BGP to send updates and keepalives across each TCP session.

Example 5. show tcp brief on R1

R1#sh tcp brief

TCB       Local Address           Foreign Address        (state)

812CF984  131.108.255.5.11042     131.108.255.6.179      ESTAB

812CCB20  131.108.1.1.11044       131.108.1.2.179        ESTAB

812CC6A4  131.108.255.13.11043    131.108.255.14.179     ESTAB

 

Example 6 debug ip bgp keepalives on R1

R1#debug ip bgp keepalives

BGP keepalives debugging is on

4d01h: BGP: 131.108.255.6 sending KEEPALIVE

4d01h: BGP: 131.108.255.6 KEEPALIVE rcvd

4d01h: BGP: 131.108.255.14 sending KEEPALIVE

4d01h: BGP: 131.108.255.14 KEEPALIVE rcvd

4d01h: BGP: 131.108.1.2 sending KEEPALIVE

4d01h: BGP: 131.108.1.2 KEEPALIVE rcvd

R1 is sending and receiving keepalives to the three remote peers to ensure that the remote routers are still active. Assume that R1 is reloaded.

BGP Attributes At a Glance