notes: Troubleshooting BGP Filtering

1. Problem: Standard Access List Fails to Capture Subnets

debugs and verification:

R1# router bgp 1  

neighbor 131.108.1.2 remote-as 2  

neighbor 131.108.1.2 distribute-list 1 in 

!

access-list 1 permit 13.13.0.0 0.0.255.255

distribute-list 1 means that any BGP updates that come from 131.108.1.2 will be examined by access list 1.

Access list 1 has a permit statement for 13.13.0.0 with an exact match of the first two octets (13.13); it doesn't care about the last two octets (0.0).

using standard access-list doesnt care about the mask  so show ip bgp  command output shows, some subnets of 13.13.0.0  with some variable subnets.

Solution:

- use extended access-list.

access-list 101 permit ip 13.13.0.0 0.0.255.255 255.255.0.0 0.0.0.0 

The extended access list has two parts:

• The network part— 13.13.0.0 0.0.255.255, which allows 13.13.x.x, where x can any number between 0 and 255.
• The mask part— 255.255.0.0 0.0.0.0. With all 0s in wildcard, the mask can only be 255.255.0.0, meaning /16.

 2.  Problem: Extended Access Lists Fails to Capture the Correct Masked Route

To reduce the size of Internet BGP/routing tables, BGP operators are forced to advertise aggregated prefixes and suppress subnetted IP blocks. To achieve this, almost all ISPs expect their peering ISPs and customers to advertise aggregated blocks of, say, /21 (255.255.248.0) of IP blocks and will refuse to accept any prefix with a mask greater than /21. Proper BGP filtering must be in place at peering points so that prefixes with masks greater than /21 can be filtered out and only prefixes with masks less than /21 are accepted.

verification:

show ip bgp

Solution:

The two solutions are as follows:

a.  Use an extended access list.

An extended access list that would permit any IP network whose mask is /21 or lower (20, 19, and so on) is configured as follows:

access-list 101 permit ip 0.0.0.0 255.255.255.255 255.255.248.0 255.255.248.0

0.0.0.0 255.255.255.255 means any IP network.

255.255.248.0 255.255.248.0 means that a mask of this prefix can be only /21 or lower (/20, /19, and so on). Cisco IOS Software has an implicit deny at the end of each access list, so all prefixes whose masks are greater than 21 are denied.

router bgp 109 

neighbor 131.108.1.2 remote-as 110 

neighbor 131.108.1.2 distribute-list 101 Out 

b.  Use a prefix list.

Apart from distribute lists, prefix lists can be used to achieve the same goal.

You can apply the following prefix list to R1 and R2 in a similar fashion as a distribute list with both the neighbor statement and with a route map:

ip prefix-list FILTERING seq 5 permit 0.0.0.0/0 le  21 

0.0.0.0 means any prefix, and /0 le 21 means that the mask of any prefix could be from 0 and less than or equal (le) to 21. All other higher-masked prefixes (/22, /25, /26, and so on) will be denied because of an implicit deny at the end of each Cisco IOS Software filter.

The distribute list and prefix list take effect when updates come from a neighbor. If BGP updates already have been received, applying the distribute list or prefix list will have no effect. To receive updates from neighbors, routers must restart the BGP session by using the commands clear ip bgp neighbor or clear ip bgp neighbor soft in, if soft reconfiguration is enabled. Refer to the Cisco IOS Software manual for more details on this command. A recent feature of Cisco IOS Software called route refresh automatically requests fresher updates from a neighbor when any policy, such as a distribute list or a prefix list, gets applied. This feature does not require clearing of the current BGP session.

3.  Problem: AS_PATH Filtering Using Regular Expressions

All BGP updates that contain an announcement of IP prefixes have an AS_PATH field that lists all the autonomous systems that this update has traversed. BGP operators use filtering against this AS_PATH field to allow or deny IP prefixes and also to apply BGP policy based on AS_PATH filtering. This method offers greater flexibility in applying just a single line of filtering and not listing all IP prefixes, as in the case of distribute lists or prefix lists.

notes: Troubleshooting BGP Best-Path Calculation Issues

1.  Problem: Path with Lowest RID Is Not Chosen as Best

This is the scenario in which two or more paths from EBGP neighbors have identical BGP attributes and BGP best-path selection is done based on the RID. The BGP best-path selection rule states that, in case all other attributes are identical, the path with the lowest RID should be selected as best. In this case, the path with the highest RID is selected as best.

In Cisco IOS Software, if BGP selects a best path based on the RID and a new path comes in with a lower RID, with all other attributes being equal, the previously selected best path will not be toggled and will remain unchanged. This is done intentionally in Cisco IOS Software to maintain stability in BGP paths because newly selected paths must be advertised to all BGP neighbors, and the previous one must be withdrawn. To avoid this churn, BGP in Cisco IOS Software does not select a new best path if the previous path selected was done based on RID.

debugs and verification:

show ip bgp a.b.c.d  - resuls shows that the one with highest RID is the best route.

Solution:

bgp bestpath compare-routerid

this command compare the RIDs of all the paths and pick the lowest RID as the best in BGP best-path calculation. The effect of this configuration change takes place when the BGP scanner runs. (It runs every minute in Cisco IOS Software.)

2.  Problem: Lowest MED Not Selected as Best Path

One BGP rule that must be kept in mind is the rule of MED comparison. By default, Cisco IOS Software will not compare the MEDs if two paths came from different autonomous systems.

debugs and verification:

show ip bgp a.b.c.d

example scenario:

The output in 15-95 shows that R1 has three paths in this order:

Path 1: This path is from R5 (RID 5.5.5.5), with a MED of 30.

Path 2: This path is from R4 (RID 4.4.4.4), with a MED of 40.

Path 3: This path is from R3 (RID 3.3.3.3) with a MED of 50.

If the best-path selection algorithm described in Chapter 14 were run, the following would be the selection process:

- Path 1 is compared with Path 2. All BGP attributes are the same except for the MED. However, these two paths came from different autonomous systems—110 and 111, respectively—so the MED will not be the tiebreaker and will be ignored. The tiebreaker will be the RID. Based on the RID, path 2 has a lower RID (4.4.4.4) than path 1 (5.5.5.5). Therefore, path 2 is the winner.

- The winner of Step 1, path 2, is compared with path 3. Again, the MED will be ignored because of a different AS_PATH. The lower RID of path 3 (3.3.3.3) will win again path 2's RID (4.4.4.4).

- Path 3 is selected as best even though it has a higher MED than any of the paths (MED 50).

Solution:

bgp always-compare-med 

The best path is the one that has the lowest MED. As stated earlier, choosing the path with the lowest MED could be crucial if links between autonomous systems are of different bandwidth and a path from a higher-bandwidth neighbor is sending a lower MED.

In addition, one important design recommendation is that the command bgp always-compare-med should be enabled on all the routes in an AS running BGP; otherwise, packet forwarding loops might occur. For example, Router A running this command might point its best path to Router B, whereas Router B without this command might point the best path back to Router A, resulting in a routing loop.

notes: Troubleshooting Inbound IP Traffic Flow Issues Because of BGP Policies

1.  Problem: Multiple Connections Exist to an AS, but All the Traffic Comes in Through One BGP Neighbor, X, in the same AS—Cause: Either BGP Neighbor at X Has a BGP Policy Configured to Make Itself Preferred over the Other Peering Points, or the Networks Are Advertised to Attract Traffic from Only X.

debugs and verification:

There might be multiple reasons for this behavior, but two of the most common scenarios are as follows:

Case1:  Upstream AS  has the BGP policy configured so that all updates from your AS at location X get the LOCAL_PREFERENCE higher than at all other neighbors with your AS. This results in making X the preferred exit point from upstream AS 110 to  your AS  for some local subnets.



show ip bgp a.b.c.d

Case2:  Your AS is influencing traffic by advertising different MED values for the prefix some of your local subnet at different locations.

Solution

Return traffic influence can be desired as in Case 2, or it might happen as in Case 1.

In Case 1, in which upstream AS changed its BGP policy by altering the LOCAL_PREFERENCE, BGP does not offer any commands for your AS to influence the upstream AS policy. Each AS can force its own policy, and the outside AS cannot change that. The solution for the Case 1 problem lies with the local AS administrator requesting AS 110 to remove any policy that affects your local AS.

In Case 2, your AS announced a MED and upstream AS was not configured to change LOCAL_PREFERENCE (as in Case 1).

If the MED announcement is not producing the desired behavior for your local AS inbound traffic management, these MEDs should be removed, and the normal BGP policies of upstream AS should decide on the best entry into AS 109.

In larger BGP networks with numerous exit points and multiple BGP AS connections, traffic balance could become a challenge. Therefore, careful BGP policies and peering agreements must be created between BGP speakers, and traffic flow must be carefully observed.

2.  Problem: Multiple Connections Exist to Several BGP Neighbors, but Most of the Traffic from Internet to 100.100.100.0/24 Always Comes in Through One BGP Neighbor from AS 110—Cause: Route Advertisements for 100.100.100.0/24 in AS 109 Attract Internet Traffic Through That BGP Neighbor in AS 110

Topology:

When a BGP prefix is observed from a global Internet point-of-view, few BGP attributes stay intact from the originator of that prefix. For example, AS_PATH, ORIGIN_CODE and AGGREGATOR are the most common BGP attributes that get carried no matter how many autonomous systems a BGP update crosses. The most popular attributes, LOCAL_PREFERENCE and MED, do not cross an AS boundary. Therefore, they do not play any role in influencing return traffic from sources multiple autonomous systems away.

the most common BGP attributes that get used in the BGP best-path algorithm are LOCAL_PREFERENCE, AS_PATH and MED. Out of these, AS_PATH is the only attribute that stays intact from the originator of the prefix to any Internet BGP speaker.

Solution:

a.  AS 109 advertises network 100.100.100.0/24 with a much longer AS_PATH list to all BGP neighbors except AS 110. If autonomous systems 110, 112, and 113 do not make any additional changes in the BGP policy, autonomous systems 112 and 113 always go through AS 110 to reach 100.100.100.0/24.

This results in all traffic to network 100.100.100.0/24 entering AS 109 to traverse AS 110; the links between AS 109 and AS 111 for redundancy.

b.  AS 109 advertises 100.100.100.0/24 only to AS 110, not to BGP neighbor AS 111. Therefore, traffic from the Internet sees only one path to reach 100.100.100.0/24—through AS 110 to AS 109. However, this case loses redundancy if AS 109 loses its BGP session with AS 110.

notes: Troubleshooting Load-Balancing Scenarios in Small BGP Networks

1.  Problem: Load Balancing and Managing Outbound Traffic from a Single Router When Dual Homed to Same ISP—Cause: BGP Installs Only One Best Path in the Routing Table

In multihomed scenarios, a common concern that enterprise network operators face is improperly utilizing the external links going to the ISP. Typically, enterprise customers dual-home to either the same or different ISPs to load-share outgoing and incoming traffic.

debugs and verification:

show ip bgp a.b.c.d

show ip route a.b.c.d

Solution:

Cisco IOS Software allows, by configuration, the installation of more than one route for the same prefix,  This does come with a tight check: Multiple paths that are candidates to go in the routing table have the exact same BGP attribute except for the router ID (RID). If two or more paths have identical attributes except for the RID, they can go in the routing table and load sharing can be achieved for traffic going to that prefix.

maximum-path  n

The maximum-path n command allows two equal BGP paths to be installed in the routing table. Cisco IOS Software allows a maximum of six equal paths. the BGP output, only one path has "best" in its output, but both have "multipath" and thus both will be installed in the routing table.

2. Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network—Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist

If multiple paths are received from different IBGP neighbors for the same prefix, only one best path will be selected and installed in the routing table. This results in other alternate paths being unused.

debugs and verification:

show ip bgp a.b.c.d

show ip route a.b.c.d

Solution:

maximum-path ibgp n

For maximum-paths ibgp to work, the following conditions must be met:

In both paths, all BGP attributes—LOCAL_PREF, MED,ORIGIN, and AS_PATH (entire AS_PATH)—must be identical.

Both paths must be learned through IBGP.

Both paths must be synchronized.

Both paths must have a reachable next hop.

Both paths must have an EQUAL IGP cost to the next hop.

notes: Troubleshooting Outbound IP Traffic Flow Issues Because of BGP Policies

1.  Problem: Multiple Exit Points Exist but Traffic Goes Out Through One or Few Exit Routers—Cause: BGP Policy Definition Causes Traffic to Exit from One Place


Solution:

Using the BGP attribute LOCAL_PREFERENCE is done commonly to predictably control the traffic leaving the local AS

by using route-map to match againts the network prefix or AS path.

- With the size of the BGP routing table today, it is difficult to manage traffic on a prefix-by-prefix basis.
- BGP attribute manipulation based on AS_PATH is a fairly common practice among savvy BGP operators because wildcard operations allow covering a larger number of prefixes to be checked in fewer lines of configuration.

2.  Problem: Traffic Takes a Different Interface from What Shows in Routing Table—Cause: Next Hop of the Route Is Reachable Through Another Path

debugs and verification:

show ip bgp a.b.c.d.

show ip route next-hop ip

traceroute

Solution:

A router might provide a route to BGP neighbor but might never be in a forwarding path to reach that route. This is because packets are forwarded to the next-hop address of the actual route, which might not be the same router that gave the route in the first place.

3. Problem: Multiple BGP Connections to the Same BGP Neighbor AS, but Traffic Goes Out Through Only One Connection—Cause: BGP Neighbor Is Influencing Outbound Traffic by Sending MED or Prepended AS_PATH. 

Typically, BGP networks are multihomed to different ISPs or the same ISP to provide redundancy or to load-share traffic. In some scenarios, the BGP network might be dual homed to the same ISP and might be running BGP with that ISP. Instead of load sharing traffic to the ISP over multiple connections, traffic might exit only from one connection.

Solution:

it can be solved in a number of ways.

a.  Request upstream AS to send the proper MED for each prefix.

MED exchange with an EBGP peer is a tricky and bilateral game. Typically, BGP carriers accept MEDs only on a mutual basis in a process in which both carriers accept each other's MED. Accepting MED means that BGP carriers carry each other's traffic through the backbone and try to route the traffic in an optimal fashion.

b.  Don't accept MED from upstream AS

Request upstream AS  either to not send the MED or to manually set the MED to 0 at peering points X, Y, and Z and for all prefixes from upstream AS 110. This results your local AS picking the closest exit point, X, Y, or Z, for Prefixes P1, P2, and P3 through the lowest IGP (OSPF, IS-IS, and so on) cost to reach these exit points. Manually setting the MED to 0 can be done through a route map.

route-map influencing_traffic permit 10
set metric 0
!
R1# router BGP 109
neighbor 4.4.4.4 remote-as 110
neighbor 4.4.4.4 route-map influencing_traffic in

This route map should be applied at all EBGP connections between your AS and upstream AS.  

c.  Manually change LOCAL_PREFERENCE for P1, P2, and P3 at all the exit points, X, Y, and Z.

   

To use this solution, local AS  must know which exit point is closer to which prefix.

4.  Problem: Asymmetrical Routing Occurs and Causes a Problem Especially When NAT and Time-Sensitive Applications Are Used—Cause: Outbound and Inbound Advertisement

Asymmetric routing means that packets flowing to a given destination don't use the same exit point as the packets coming back from that same destination. This is not a problem in itself, but it can cause some issues when Network Address Translation (NAT) or a time-sensitive application is involved.

debugs and verification:

- traceroute 

Solution:

The asymmetrical routing issue is a fairly difficult problem to tackle and sometimes is un-avoidable. Asymmetrical routing might be an issue in cases of NAT when only one device maintains the NAT table; therefore, packets must come in and out of the same device. Time-sensitive applications also might face problems when the exit path offers good throughput but the entry path is sluggish, making the overall round-trip time (RTT) bad.

Example topology:

viable solutions:

1.  In the BGP configuration of AS 109, only R1 advertises 131.108.1.0/24 to R3 in AS 110. AS 110 will have only one way to reach 131.108.1.0/24, and that is through the R3–R1 link, ensuring symmetrical routing.

2.  Both R1 and R2 are running EBGP with R3 and R4, respectively. From R1, adver-tise 131.108.1.0/24 to R3 with a MED of 1; from R2, advertise 131.108.1.0/24 to R4 with a MED of 20. AS 110 will have two advertisements, but the path from the lower MED (R1) will win and, in case the R1–R3 BGP connection fails, the path from R2 to R4 will be used. The use of the MED is discussed in detail in previous sections.

3.  Using the as-path prepend option in Cisco IOS Software, R2 advertises 131.108.1.0/24 with the 

AS_PATH list containing AS 109 several times.

router bgp 109
network 131.108.1.0 mask 255.255.255.0
neighbor 4.4.4.4 remote-as 110
neighbor 4.4.4.4 route-map SYMMETRICAL out
!
route-map SYMMETRICAL permit 10
match ip address 1
set as-path prepend 109 109 109

route-map SYMMETRICAL permit 20
!
access-list 1 permit 131.108.1.0

In short, proper BGP announcements must be made at exit points and routes must be learned at the right place of the AS. Smaller enterprise networks can achieve this rather easily with the prepended AS path solution, but larger enterprise and ISP networks face a bigger challenge to ensure symmetrical routing. This is because ISPs have a larger number of prefixes to advertise, a larger number of exit points, and a larger number of BGP peering relationships. Unless symmetrical routing is not a must, especially in the case of NAT, most networks today run fine with asymmetrical routing.

 

note: Troubleshooting BGP Route-Reflection Issues

Route reflectors (RR), discussed in RFCs 1966 and 2796, are used to avoid IBGP full mesh in an AS, as required by RFC 1771. Route reflection ensures that all IBGP speakers in an AS receive BGP updates from all parts of the network without having to run IBGP between all the routers in the network. Route reflection reduces the number of required IBGP connections and also offers faster convergence in an IBGP network when compared with a full-mesh IBGP network. Route-reflector clients (RRCs) typically peer IBGP with one or more RR, and they can have EBGP connections unconditionally. Logical BGP connections between RR and RRC typically follow the physical connection topology. These are some of the common rules that help BGP operators troubleshoot BGP route-reflector issues 1.  Problem: Configuration Mistakes—Cause: Failed to Configure IBGP Neighbor as a Route-Reflector Client   The neighbor IP address must be the same in the route-reflector-client statement as in the remote-as configuration. The Cisco IOS Software BGP parser detects the misconfigured RRC IP address if BGP does not have an IBGP neighbor configured with this address. Solution: A BGP operator accidentally might configure a different IP address in the RRC than is configured in the neighbor statement where the remote AS is configured. If this problem is detected, the IP address must be corrected. 2.  Problem: Route-Reflector Client Stores an Extra BGP Update—Cause: Client-to-Client Reflection    Debug and Verification:   show ip bgp a.b.c.d Solution:   Turning off client-to-client reflection solves this problem. This problem arises only when an RRC peers IBGP with another RRC. When an RRC peers only with the RR, BGP does not run into this issue. 3.  Problem: Convergence Time Improvement for RR and Clients—Cause: Use of Peer Groups   When an RR is serving many clients, any update that it receives from IBGP/EBGP peers must be generated and propagated as separate updates for each RRC. If the number of BGP updates and RRCs is large, this process could become CPU-intensive for the RR. This results in slower propagation of BGP updates and hence results in slower convergence in the network overall. Peer-group clubs configure BGP neighbors in one group. Any common update that needs to go to all members of the peer group are processed only once, and all members receive the copy of that processed update. A router that has a peer group does not process update for all members of the group, resulting in huge CPU processing savings. Overall convergence of the networks improves greatly. Solution: When peering to several neighbors, use the Cisco IOS Software BGP peer group feature to avoid the processing duplication required to generate the same update to every neighbor. In peer groups, BGP neighbors (in this case, all RRCs) are listed as members of a peer group that share the same outbound policy. RR computes an update for the first member of the peer group and simply replicates the same update to all members. This greatly reduces the number of CPU cycles that the RR has to spend to compute update for each RRC. In addition, using peer groups speeds up the process of propagating BGP updates to RRCs; therefore, RRCs converge faster in case of any churn. Peer groups can be used in normal IBGP and EBGP scenarios to get this benefit, with the condition that all peer-group members are configured with same outbound policy. 4.  Problem: Loss of Redundancy Between Route Reflectors and Route-Reflector Client—Cause: Cluster List Check in RR Drops Redundant Route from Other RR   A cluster is made up of an RR and its clients. A cluster can have one or more RR and is identified by a cluster ID that is the router ID of the RR. Because each RR has a unique router ID, each cluster has only one RR by default. Network operators must manually configure identical cluster IDs on two or more RRs to configure them in the same cluster. When a BGP update traverses from an RR to other neighbors, RR adds its cluster ID in the list called the cluster list, which contains all cluster IDs that any BGP update has traversed. The cluster list is synonymous with the AS_PATH list, which contains AS lists that any update has traversed. Just as in AS_PATH loop detection, in which updates are dropped if the AS_PATH contains a local AS, the cluster list detects loops if they contain a local cluster ID. debug and verification: show ip bgp a.b.c.d debug ip bgp update Solution: result of the cluster list check. It is recommended that in cases similar to those depicted in Figure 15-33, RRs should not be put in the same cluster. The cluster ID will be picked as the router ID (RID) of each RR and is guaranteed to be unique because all RIDs are unique in any network.  RRs should not be put in the same cluster. The cluster ID will be picked as the router ID (RID) of each RR and is guaranteed to be unique because all RIDs are unique in any network.

notes: Troubleshooting BGP Route Not Installing in Routing Table

If the BGP process fails to create an IP routing table entry, all traffic destined for missing IP subnets in the routing table will be dropped. This is a generic behavior of hop-by-hop IP packet forwarding done by routers

 1. IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP Routes Are Not Synchronized

IBGP will not install or propagate a route to other BGP speakers unless IBGP-learned routes are synchronized. Synchronization means that for an IBGP-learned route, there must exist an identical route in the IP routing table provided by an IGP (OSPF, IS-IS, and so on).

debugs and verification:

show ip bgp a.b.c.d

Solution:

- Synchronize all BGP routes.

 R1# router ospf 1

 redistribute static subnets

 network 131.108.1.0 0.0.0.255 area 0

R1# router bgp 109

 network 100.100.100.0 mask 255.255.255.0

 neighbor 131.108.10.2 remote-as 109

 neighbor 131.108.10.2 update-source Loopback0

ip route 100.100.100.0 255.255.255.0 Null0

- Turning off synchronization

   This method is widely used in almost all BGP networks

no synchronization

2.  IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP Next Hop Not Reachable

The cause of this problem is most common in IBGP-learned routes where BGP next-hop address should have been learned through an Interior Gateway Protocol (IGP). Failure to reach the next hop is an IGP problem, and BGP is merely a victim. With BGP, when IP prefixes are advertised to an IBGP neighbor, the NEXT-HOP attribute of the prefix does not change. The IBGP receiver must have an IP route to reach this next hop.

Debugs and Verification:

show ip route a.b.c.d.

sho ip bgp a.b.c.d  - next hop is inaccessible

Solution:

BGP requires the next hop of any BGP route to resolve to a physical interface. This might or might not require multiple recursive lookups in the IP routing table. Two common solutions exist for addressing this problem:

a.  Announce the EBGP next hop through an IGP using a static route or redistribution.

b.  Change the next hop to an internal peering address.

This solution is more widely used and is the preferred method of announcing the next hop to IBGP peer.

3.  Problem: EBGP-Learned Route Not Getting Installed in IP Routing Table

3a.  EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP Routes Are Dampened.

Dampening is the way to minimize instability in a local BGP network caused by unstable BGP routes from EBGP neighbors. RFC 2439, "BGP Route Flap Damping," describes in detail how dampening works. In short, dampening is the way to assign a penalty for a flapping BGP route. A withdrawal of a prefix is considered a flap. A penalty of 1000 is assigned for each flap; if the flap penalty reaches the suppress limit because of continued flaps (default 2000), the BGP path is suppressed and is taken out of the routing table. This penalty is decayed exponentially based on the half-life time (default 15 minutes). When the penalty reaches the reuse value (default 750), the path is unsuppressed and is installed in the routing table and advertised to other BGP neighbors. Any dampened path can be suppressed only until the max suppress time (default 60 minutes). Dampening is applied only to EBGP neighbors, not to IBGP neighbors.

router bgp 1009
bgp dampening half-life-time reuse suppress maximum-suppress-time

half-life-time— Range is 1 to 45 minutes. Current default is 15 minutes.

reuse— Range is 1 to 20,000. Default is 750.

suppress— Range is 1 to 20,000. Default is 2000.

max-suppress-time— Maximum duration that a route can be suppressed. Range is 1 to 255. Default is four times half-life-time.

debug and verifications:

R1#debug ip bgp dampening 1

R1#debug ip bgp updates 1

access-list 1 permit 100.100.100.0 0.0.0.0

Solution:

1.  Wait for the penalty to go below the reuse limit (750).

2.  Remove dampening altogether from the BGP configuration.

3.  Clear the flap statistics.

 clear ip bgp dampening a.b.c.d

3b.  EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP Next Hop Not Reachable in Case of Multihop EBGP

In a multihop EBGP session, EBGP speakers are not directly connected. Peering between loopback addresses of adjacent routers also is considered multihop.

This problem of an EBGP multihop route not getting installed in an IP routing table is identical to the IBGP next hop issue; however, most of the commonly seen problems occur when the router fails to resolve the next-hop address to an interface.

In this problem, the multihop EBGP next hop is reachable through a BGP route whose next hop is again the original multihop BGP next hop. For example, to reach prefix A, the next hop is prefix B; to reach prefix B, the next hop is again B. This is considered a recursion problem in which a router cannot resolve to an interface to reach the next hop B.

show ip route a.b.c.d

show ip bgp a.b.c.d

Solution:

The solution to this problem based on this cause is to simply have a more specific route for the next-hop address. In the case of EBGP, this is commonly done by having a static route for the multihop EBGP peering address.

This instance is observed in the case of multihop EBGP sessions when the next-hop address is not directly connected and the IP routing table must have an explicit route to the next-hop address.

 4.  EBGP-Learned Route Not Getting Installed in the Routing Table—Cause: Multiexit Discriminator (MED) Value Is Infinite

In Cisco IOS Software, if a multiexit discriminator (MED) is set to infinite 4294967295, the router will not install this route in the routing table.

The infinite metric sometimes is used in route servers, which provide a mirror view of the Internet BGP table. Setting the metric to infinity prohibits such routes from going in the IP routing table, so no IP traffic will use those routes. This case is discussed here just to show a corner case of a BGP path not getting installed in the routing table. Such a configuration is not seen in real BGP networks.

notes: Troubleshooting BGP Route Advertisement /Origination and Receiving

Another common problem after neighbor relationship issues that BGP operators face occurs in BGP route advertisement/origination and receiving. BGP originates routes only by configuration. However, it needs no configuration in receiving routes.

1.  Problem: BGP Route Not Getting Originated
 

1.a  BGP Route Not Getting Originated—Cause: IP Routing Table Does Not Have a Matching Route

BGP requires the IP routing table to have an exact matching entry for the prefix that BGP is trying to advertise using network and redistribute command. The prefix and mask of the network that BGP is trying to advertise must be identical in the IP routing table and in the BGP configuration. BGP will fail to originate any prefix related to this network if this discrepancy exists.

debugs and verification:

Case 1: Matching Route Does Not Exist in the Routing Table

show ip route a.b.c.d

show ip bgp a.b.c.d

Case 2: Route Exists in the IP Routing Table but Masks Differ from What Is in the IP Routing Table and What Is in the BGP Configuration

Solution:

Identical advertising BGP routes must exist in the IP routing table when network and redistribute commands are used. The IP routing table learns such routes either dynam-ically through a routing protocol or by a static route.

Commonly, BGP operators define a static route for the prefix being advertised. This way, the IP routing table is guaranteed to have a valid IP routing table entry of the advertised prefix.

ip route 100.100.100.0 255.255.255.0 null 0  

note: be carefull of using a null route, null route is used just to have an exact match, It is assumed that a more specific route of 100.100.100.0/24 exists in the IP routing table.

1.b.  BGP Route Not Getting Originated—Cause: Configuration Error

Configuration mistakes often cause BGP failure to advertise IP prefixes. Multiple ways to originate IP prefixes in BGP exist, and each method requires strict syntax in configuration. Therefore, it is essential that BGP operators thoroughly understand Cisco IOS Software configuration guidelines.

 Debugs and verification:

Three ways exist to originate prefixes in BGP:

  - Use a network statement.

  - Use an aggregate statement.

  - Redistribute other protocol/static routes in BGP

Case 1: BGP Prefix Origination with the network Statement

-  an exact match does not exist in the routing table.

Case 2: BGP Prefix Origination with the aggregate-address Command

- The explanation behind this failure is that the aggregate-address configuration requires the BGP table to contain at least one route that is more specific than the aggregate.

Case 3: BGP Prefix Origination by Redistributing Dynamic Protocols or Static Routes

- You can configure BGP to redistribute any dynamic routing protocol, such as OSPF, or static routes to originate any route. Cisco IOS Software strictly checks such a configuration and expects configuration guidelines to be met for the advertisement of any redistributed route.

solution:

All three methods commonly are used, but Cases 1 and 2 offer the most stability in BGP advertisement. Case 3 requires redistribution of an IP routing table learned by some other IGP protocol or static routes in BGP. Any flapping in IGP or static routes results in BGP churn.

2.  Problem in Propagating/Originating BGP Route to IBGP/EBGP Neighbors—Cause: Misconfigured Filters
 

A scenario might arise in which the BGP configuration to originate and propagate routes looks good, but BGP neighbors are not receiving the routes. The originator's BGP table shows all the routes. There is a possibility that configured filters are the cause of the problem.

Debugs and Verifications:

Using a distribute list allows for standard access lists (1 to 99) and extended access lists (100 to 199). 

R1# access-list 1 permit 100.100.100.0  

router bgp 109  

no synchronization  

neighbor 131.108.1.2 remote-as 109  

neighbor 131.108.1.2 distribute-list 1 out 

R1# access-list 101 permit ip host 100.100.100.0 host 255.255.255.0 

router bgp 109  

no synchronization  

neighbor 131.108.1.2 remote-as 109 

neighbor 131.108.1.2 distribute-list 101 out 

One common mistake that operators make is not realizing that there is an implicit deny at the end of each access list. All networks are denied except for those that are explicitly permitted in the access list. Also, standard and extended access lists are treated differently when it comes to BGP filters. In standard access lists, the mask portion is not checked and only the prefix portion is checked.

Similarly, when other methods are applied to filter BGP updates—namely, filter lists, prefix lists, route maps, distribute lists, and so on—care must be taken to understand the behavior of each method.

Solution:  

there are several other ways to filter BGP updates, and care must be taken in terms of what exactly is configured. Each kind of filter offers the power to control the BGP advertisement, but improper or incorrect use can result in incorrect or incomplete advertisements.

3.  Problem in Propagating BGP Route to IBGP Neighbor but Not to EBGP Neighbor—Cause: BGP Route Was from Another IBGP Speaker

When IBGP speakers in an AS are not fully meshed and have no route reflector or confederation configuration, any route that is learned from an IBGP neighbor will not be given to any other IBGP neighbor. Such routes are advertised only to EBGP neighbors

debugs and verification:

show ip bgp a.b.c.d

Solution:

It is essential that IBGP-learned routes are propagated to other BGP speakers. BGP operators can use three methods to address this problem:

Use IBGP full mesh.

Design a route-reflector model.

Design a confederation model.

a.  Use IBGP full mesh

Having an IBGP full mesh is unacceptable even in a small ISP network.

For larger ISPs that maintain several hundred BGP speakers, IBGP full mesh would harm them more than providing benefit. 

b.   Design a route-reflector model.

Servers peer BGP with all clients in the cluster. A cluster is a set of servers and clients. Clients peer BGP only with servers. Clients advertise BGP updates to servers, and servers then reflect them to other clients.  

c.  Design a confederation model.

RFC 1965 explains how an AS confederation for BGP can avoid full IBGP mesh. With confederations, the BGP network is divided into small sub–autonomous systems. These sub–autonomous systems are connected to other sub–autonomous systems. These sub–autonomous systems need not be fully meshed. BGP speakers within a sub–autonomous system must have a full mesh of IBGP. If the number of sub–autonomous systems grows to a large number of IBGP speakers, sub–autonomous system IBGP speakers use route reflectors. All routers take a configuration change when moved from an IBGP model to a confederation model.

4.  Problem in Propagating IBGP Route to IBGP/EBGP Neighbor—Cause: IBGP Route Was Not Synchronized

A scenario might arise in which an IBGP learned route is not propagated to any BGP neighbor, whether IBGP or EBGP. One case could be that when an IBGP-learned route is not synchronized, that route is not considered as a candidate to advertise to other BGP neighbors.

verification:

show ip bgp a.b.c.d  -- in the output shows not synchronized.

Solution:

either turn off synchronization or make the routes synchronized by redistributing them in the IGP at the router that first introduced this route in IBGP domain.

notes: Troubleshooting BGP Neighbor Relationships

1.  Problem:  Directly connected external BGP neighbors not initializing

1.a.  Directly Connected External BGP Neighbors Not Coming Up—Cause: Layer 2 Is Down, Preventing Communication with Directly Connected BGP Neighbor

verification:  show ip bgp summary
                  show ip bgp neighbors a.b.c.d
       ping a.b.c.d
       show interface

- will show what is the state of neighbor relationship between the 2 router.

This might be because of cable issues or a hardware problem.

Layer 2 encapsulation failure can also cause IP connectivity to break. Layer 2 encapsulation failure can occur because of corruption in the ARP table in case of Ethernet or an incorrect DLCI–VPI/VCI mapping in cases of Frame Relay and ATM, respectively. Fixing these should enable basic IP connectivity, and the BGP neighbor relationship should initialize.

Solution:  verify the cable connection, encapsulation.

1.b Directly Connected External BGP Neighbors Not Coming Up—Cause: Incorrect Neighbor IP Address in BGP Configuration.

 Misconfiguration of the neighbor address is a fairly common mistake, and it can be caught with visual inspection of the configuration. However, in a large IP network, this might not be a trivial task.

verification:  debug ip bgp 

solution:  correct neighbor address should be configured,   also wrong AS can cause the neighbor relationship to fail.

2.  Nondirectly connected external BGP neighbors not initializing

  2.a  Nondirectly Connected External BGP Neighbors Not Coming Up—Cause: Route to the Nondirectly Connected Peer Address Is Missing from the Routing Table

When BGP tries to peer the neighbor relationship with IP addresses that are not directly connected, the IP routing table must have the route to that IP address.

verification:   show ip bgp summary 

                    show ip bgp neighbors a.b.c.d
        ping a.b.c.d
        show ip route

Solution:

BGP relies on an IP routing table to reach a peer address. It is irrelevant how the route to the peer address is learned, as long as the route is present in the routing table.  Using a static route is a common practice. A simple rule of thumb is that R1 and R2 must have most specific routes for each other's loopback addresses through any other protocol other than BGP.

2.b  Nondirectly Connected External BGP Neighbors Not Coming Up—Cause: ebgp-multihop Command Is Missing in BGP Configuration.

By default, in Cisco IOS Software, BGP packets sent to an external BGP neighbor have their IP Time To Live (TTL) set to 1. If an EBGP neighbor is not directly connected, the first device in the path will drop BGP packets with TTL equal to 1 to that EBGP neighbor.

verification:  show ip bgp summary 

                   show ip bgp neighbors a.b.c.d


Solution:  Use the ebgp-multihop command to increase the IP TTL value to the desired number

neighbor a.b.c.d ebgp-multihop x 

2.c Nondirectly Connected External BGP Neighbors Not Coming Up—Cause: update-source interface Command Is Missing

By default in Cisco IOS Software, the source of the BGP packet is the outgoing interface IP address as taken from the routing table.

In BGP, the neighbor's IP address must be statically defined in configuration. If an EBGP speaker does not receive a BGP update from a IP source that is identical to what it has configured, it rejects that update. The update-source command in BGP changes the source address of the IP packet. Instead of picking the outgoing interface as a source IP address, BGP packets will be sourced with the interface IP address configured with the update-source command.

verification:  show ip route  - to verify the outgoing interface.

Solution:
Correct update source interface must be configured on both ends of the router.
The update-source command ensures that the source address is the correct interface, which the other router expects.

3.  Internal BGP neighbors not initializing


  3.a.  The route to the nondirectly connected IBGP neighbor address is missing. (same solution as above)

  3.b  The update-source interface command is missing in BGP configuration. (same solution as above)


4.  BGP neighbors (external and internal) not initializing

     4.a BGP Neighbors (External and Internal) Not Coming Up—Cause: Interface Access List Blocking BGP Packets

 Interface access list/filters are another common cause of BGP neighbor activation problems. If an interface access list unintentionally blocks TCP packets that carry BGP protocol packets, the BGP neighbor will not come up.

 verification:  show access-list

Solution:

An interface access list must permit the BGP port (TCP port 179) explicitly or implicitly to allow neighbor relationships.

example:

access-list 101 deny udp any any  

access-list 101 permit tcp any any eq bgp  

access-list 101 permit ip any any

notes: BGP Policy Accounting

- BGP policy accounting measures and classifies IP traffic that is sent to, or received from, different peers.
- Policy accounting is enabled on a input interface, and counters based on parameters such as community-lists, ASN,

AS-paths are used to identify the IP traffic.

command:

- Accounting: Based on community-lists, ASN, AS-paths
- IP-prec-map: QOS policy based on the IP precedence

bgp-policy {accounting|ip-prec-map}

- Range (1-8) representing the bucket into which packet and byte statistics are collected for a specific classification

set traffic-index {bucket-number} 

- Enables BGP policy accounting

table-map {name-of-route-map}

notes: BGP next-hop tracking & Fast Peering Sessions

- This is enabled by default when a supporting Cisco IOS software image is installed.
- BGP prefixes are automatically tracked as peering sessions are established.
- Next-hop changes are rapidly reported to the BGP routing process as they are updated in the Routing Information Base (RIB).
- This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the
RIB. When a best-path calculation is run inbetween BGP scanner cycles, only next-hop changes are tracked and processed.

commands:

- Disables next-hop tracking (enabled by default)

router bgp {asn}

no bgp nexthop trigger enable

Fast Peering Sessions

- Enable BGP to monitor the peering session of a specified neighbor for adjacency changes and to deactivate the peering session.
- BGP fast peering session deactivation is event driven and is configured on a per-neighbor basis.
- Adjacency changes are detected, and terminated peering sessions are deactivated in between the BGP scanning intervals.
- A route-map can be used to deactivate the peering session based a specific prefix.
- Only the "match ip address" and "match source-protocol" commands are supported in fast peering route-maps.


configuration sets:

- Match any route with a prefix of /28 or more specific

ip prefix-list FILTER28 seq 5 permit 0.0.0.0/0 ge 28 

!

 - Reference the filter

route-map CHECK-NBR permit 10

match ip address prefix-list FILTER28

!

- Reset the session if a /28 or more specfic prefix dissappears

router bgp 45000

neighbor 192.168.1.2 remote-as 40000

neighbor 192.168.1.2 fall-over route-map CHECK-NBR


command:

- Enables BGP fast peering session fall-over

router bgp {asn}

neighbor {IP} fall-over [bfd | route-map]

notes: BGP Fast External Fallover & Maximum Prefix

Fast External Fallover
- Fast External Fallover for external peers are triggered by a session flap, based upon the receipt of
an interface change notification.
- By default, when a local BGP interfaces goes down, the BGP neighbors on that interface is shutdown as soon as a interface reset
is detected, appose to waiting for the holddown timer (default = 180sec) to expire.
- Disabling BGP fast external fallover, will wait for the holddown timer to expire, before shutting down the neighbor sessions


commands:

- [Disables] Enables Fast External Fallover globally, thus waits for hold-time to expire

router bgp {asn}

[no] bgp fast-external-fallover 

Interface Configurationg

int s0/0

ip bgp fast-external-fallover permit - Allows per-interface fast external fallover
ip bgp fast-external-fallover deny - Prevents per-interface fast external fallover
no ip bgp fast-external-fallover - ONLY removes previously configured interface config, doesnot disable fall-over


Maximum Prefix

neighbor {IP} maximum-prefix {max no} [threshold] [warning-only] [restart {interval}]

- Controls how many prefixes can be received from a neighbor
- [Threshold]: The percentage when message is logged (default is 75%)
- [Warning-only]: When exceeding the maximum number apose to dropping the session
- [Restart] : Re-establish the session after the specified interval in minutes

notes: Regular Expressions

| - Represents 'OR' Statements
EX: '21|31' = Will match either 21 or 31 in a line.

[ ] - SQUARE BRACKET :Represents a range of characters
EX: [1-4] = Will match any in the range 1 to 4.
EX: [67] = Will match either 6 or 7.

. - DOT : Matches any single character
EX: [1-4].[67] = Match 1/2/3/4 then anything character, then 6/7, thus 156 or 397.

^ - CAROT : Matches beginning of string
EX: ^21 in '213 317 31 218 731' = Will only match the first 21.

$ - DOLLAR : Matches end of string
EX: $31 in '213 317 31 218 731' = Will only match the 31 at the end.

_ - UNDERSCORE : Matches any Delimiter (beginning, end, space, tab, comma)
EX: _31_ in '213 317 31 218 731' = Will only match the 31 in the middle.

( ) - PARENTHESIS : are used for "and" operations. To group things together.
EX: (213|218)_31 = Matches 213 or 218 followed by 31, ie '213 317' or '218 31'.

{An Atom is a single preceding character or preceding group }
{The special characters *,?,+ all apply repetition to what immediately precedes them}.

* - ASTERISK : Matches ZERO or MORE atoms(single or group of characters)
EX : _23(_78)*_45_ = Will match "23 45" or "23 78 45" OR "23 78 78 78 78 45".

? - QUESTION MARK : Matches ZERO or ONE atoms
EX : _23(_78)?_45_ = Will match "23 45" OR "23 78 45".

+ - PLUS : Matches ONE or more Atoms
EX : _23(_78)+_45_ = Will match "23 78 45" OR "23 78 78 78 78 78 78 45".

\ - BACKSLASH : Removes the special meaning of one of the above characters.
EX: ^\(213_ = will match (213 at the beginning of string.

REGEX Examples
*-----------------*
_100_ - Passes/passed through AS 100 
^100$ - Directly connected to AS 100 (begins and ends in AS 100
_100$ - Originated in AS 100
^100_ - Networks behind AS 100
^[0-9]+$ - AS Paths that is one AS long
^([0-9]+)(_\1)*$ - Networks originating in neighboring AS, with possible prependings
^$ - Networks originating in LOCAL AS
.* - Matches everything

notes: BGP Peer Groups and Peer Templates

- Benefits
 Reduces the amount of system resources (CPU and memory) necessary in an update generation.
Mostly used to simplify large repeating BGP configurations.
- Individual parameters specified in a peer group can be overridden or removed, on a neighbor-by-neighbor basis.
- Configurable parameters include the following:
Community propagation.
Source interface for TCP session.
eBGP multihop sessions.
MD5 password.
Neighbor weight
Filter-lists and distribute-lists
Route-maps.


commands:

- Creates a BGP peer group
- Peer group names are case-sensitive

router bgp 1

neighbor {group-name} peer-group

- Specifies any BGP parameter for the peer group

neighbor {group-name} {any-bgp-parameter}

 - Assigns a BGP neighbor to a peer group, thus inheriting the peer-group parameters

neighbor {ip} peer-group {group-name}

 - Overrides a BGP parameter specified for the peer group with a neighbor parameter

neighbor {ip} {any-bgp-parameter} 

 - Removes a BGP parameter specified for the peer group with the neighbor parameter
no neighbor {ip} {any-bgp-parameter}

- Displays the specified peer group or all peer groups
 sh ip bgp peer-group [peer-group-name]

 - Displays summary status of all neighbors in the peer group

sh ip bgp peer-group [peer-group-name] summary

 - Clears BGP session with all peer group members

clear ip bgp [peer-group-name] [[soft] in|out]

 - Displays info about peer-group update-group calculation, the additions and the removals of members
- Displays info about peer groups, peer-policy, and peer-session templates

  debug ip bgp groups [index-group] [peer-ip]

There are two types of peer templates:

1.  Peer Session Templates: Are used to group and apply the configuration of general session commands to groups of neighbors that share common session configuration elements.

2.  Peer Policy Templates: Are used to group and apply the configuration of commands that are applied within specific NLRI

configuration mode.

- Creates a peer policy template, enter policy-template config-mode
- Specifies the client a RR-client
- Specifies a weight for all routes from a neighbor

 router bgp 6024

 template peer-policy POLICY 

 route-reflector-client 

 weight 300 

 exit-peer-policy

 !
- Creates a peer session template, enter session-template config-mode
- Configures peering ASN with a remote neighbor
- Use the Loopback interface for sourcing traffic

 template peer-session iBGP 

 remote-as 6024 

 update-source Loopback1 

 exit-peer-session

!
- Sends a peer session template to a neighbor to inherit
- Configures this peer session template to inherit the configuration

 neighbor 7.7.2.2 inherit peer-session iBGP

 neighbor 7.7.2.2 inherit peer-policy POLICY

notes: BGP Route-Dampening

- Is designed to reduce router processing load caused by unstable routes.
- Defined in RFC 2439.
- Each time an eBGP route flaps, it gets 1000 penalty points (This cannot be configured or changed).
- IGBP routes are not dampened.
- The penalty placed on a route decays according to the exponential decay algorithm.
- When the penalty exceeds the suppress limit, the route is dampened (no longer used or propagated to other neighbors).
- A dampened route is propagated again when the penalty drops below the reuse limit.
- A route is never dampened for more time than the maximum suppress limit.
- An unreachable route with a flap history is put in the history state. It stays in the BGP table but only to maintain the flap history. (marked with 'h' in the BGP table)
- A penalty is applied on the individual path in the BGP table, not on the IP prefix.
- Using a (clear ip bgp *) is regarded as a flap to neighbors, which could cause that path to be suppressed.
- Using a (clear ip bgp * [soft] in) is NOT regarded as a flap to neighbors.




 commands:

 - Displays the dampened routes

sh ip bgp dampened-paths 

- Displays flap statistics for all routes with dampening history

sh ip bgp flap-stat [regexp|filter-list|ip]

 - Clears the flap statistics but does not release dampened routes
clear ip bgp {ip} flap-stat [regexp|filter-list|prefix]

- Releases all the dampened routes or just the specified network
- Flap statistics also cleared when the BGP session with the neighbor is lost

 clear ip bgp dampening [prefix] 

 - Displays the BGP dampening events
debug ip bgp dampening

- Route-map to configure dampening for specifics routes only

route-map name 

match ip addess {acl}

set dampening [half-life][reuse][suppress][max-suppress-time]

bgp dampening [half-life][reuse][suppress][max-suppress-time] [route-map map-name]

[half-life] - Decay time in which the penalty is halved (Def = 15min)
[suppress] - The value at which a route is dampened (Def = 2000)
[reuse] - The value when the dampened route is reused (Def = 750)
[max-suppress-time] - Maximum time to suppress the route (Def = 60Min)
[route-map] - Using route-map to dampen specific routes
- Specified without a route-map applies to all routes

notes: BGP Route Maps

- Default statement is "permit".
- Default sequence number is 10 and the default increment is 5.
- If route is not matched by any statements it is dropped.
- 'Permit all' is achieved by specifying a "permit" without "match" clause.
- Match conditions in one statement are AND'd together.

configuration set:

route-map RMAP permit 45

match ip address prefix-list LIST - Allowes only matched routes
!

router bgp 1

neighbor 10.1.1.1 route-map RMAP in - Prefixes not permitted by the route-map are discarded


MATCH criteria:
- Network number and subnet matched with an IP-prefix list
- Route originator
- BGP next-hop address
- BGP origin
- Tag attached to IGP route
- AS-path
- BGP community attached to BGP route.
- IGP route type (internal/external)

SET options:
- Origin
- BGP community
- BGP next-hop
- Local preference
- Weight
- MED

Route-map policy-list
- Adds the capability for a network operator to group route-map match clauses into named lists called policy-lists.
- Policy lists with groups of match clauses can be pre-configured and then referenced within different route maps.
- Eliminates the need to manually reconfigure each recurring group of match clauses that occur in different route-maps.


Route-map continue feature
- Introduces the continue clause to BGP route-map configuration, providing more programmable policy configuration and route filtering.
- Configures a route-map to go to another route-map entry with a higher sequence number.
- The continue clause will be executed if the route-map entry does not contain a match clause.


command set for continue feature:

route-map MYNAME permit 10

match ip add 1

set as-path prepend 2001

continue 30

route-map MYNAME permit 20

match next-hop 10.1.2.3

set local pref 150

route-map MYNAME permit 30

set as-path prepend 2001 2001

commands:

- Displays the policy list/s

sh ip policy-list {name22} 

- Creates the policy list

ip policy-list {name22} {permit | deny}

- Configured the route-map to reference the policy-list
- Executes various set functions

route-map {name} [permit|deny] {seq_no}

match policy-list {name22}

set {parameter}

notes: BGP Network Migration

- Hide local-ASN feature is useful when necessary to connect to different SP's with more than one ASN number
- [no-prepend]: Does not prepend the "local" ASN to any routes received
- [replace-as]: Prepends only the "local" ASN in the AS-path The configured ASN from the BGP process is not prepended
- [dual-as]: Configures the eBGP neighbor to establish peering session with either real ASN or both

neighbor {ip} local-as {asn} [no-prepend [replace-as] [dual-as]]]



- Private AS numbers are removed from the tail(left) only of the AS-path before the update is sent
- Private AS numbers followed by a public AS number are not removed

neighbor {ip} remove-private-as

notes: Outbound Route Filtering

- The purpose of outbound route filtering is to reduce the amount of BGP traffic and CPU use needed to process routing updates.
- With ORF routers exchange inbound filter configurations, which are used as outbound filters on neighboring routers.

ORF entries are part of the route refresh message.
- Negotiation of prefix-list ORF capability is done during BGP session setup.
- The side that has the prefix-list uses the 'send' option, and is configured with the prefix-list inbound.
- The side that sends the routes uses the 'receive' option.
- ORF requires the session to be reset after configured.
- Inbound route refresh is required, and only the inbound prefix-list filter is pushed to the neighbor and used by that neighbor the outbound direction.
- ORF-capable BGP speaker will install ORFs per neighbor.


commands:

- Enables negotiation of prefix-list ORF capability

router bgp 1

neighbor {ip} capability orf prefix-list {send|receive|both}

- Specifies the prefix that will be send to the ORF capable neighbor

neighbor {ip} prefix-list {name} in

- Useful dto verify neighbor capabilities

sh ip bgp neighbor

- Triggers a route refresh from ORF receivers
- [prefix-filter] option to refresh the remote filter

clear ip bgp {ip} in [prefix-filter]