BGP points to remember
===================
You can configure MD5 authentication between two BGP peers, MD5 authentication must be configured with the same password on both BGP peers; otherwise, the connection between them will not be made. If a router has a password configured for a peer, but the other peer does not, a message “No MD5 digest from…” will appear on the console while the routers attempt to establish a Multicast Source Discovery Protocol (MSDP) session between them.
When the aggregate-address command is used within BGP routing, the aggregated address is advertised, along with the more specific routes. The exception to this rule is through the use of the summary-only command. The “summary-only” keyword suppresses the more specific routes and announces only the summarized route.
The weight attribute is a special Cisco attribute that is used in the path selection process when there is more than one route to the same destination. The higher the weight value, the better the path. The default weight is 0.The weight attribute is local to the router and not propagated to other routers.
Below is the list of BGP states in order, from startup to peering:
1 – Idle: the initial state of a BGP connection. In this state, the BGP speaker is waiting for a BGP start event,
generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.
2 – Connect: In this state, BGP is waiting for the TCP connection to be formed. If the TCP connection completes, BGP will move to the OpenSent stage; if the connection cannot complete, BGP goes to Active
3 – Active: In the Active state, the BGP speaker is attempting to initiate a TCP session with the BGP speaker it wants to peer with. If this can be done, the BGP state goes to the OpenSent state.
4 – OpenSent: the BGP speaker is waiting to receive an OPEN message from the remote BGP speaker
5 – OpenConfirm: Once the BGP speaker receives the OPEN message and no error is detected, the BGP speaker sends a KEEPALIVE message to the remote BGP speaker
6 – Established: All of the neighbor negotiations are complete. You will see a number (2 in this case), which tells us the number of prefixes the router has received from a neighbor or peer group.
Notice that the “show ip bgp” command to display BGP topology database
Memorizing the BGP decision process steps is very useful and you should remember them.
===================
You can configure MD5 authentication between two BGP peers, MD5 authentication must be configured with the same password on both BGP peers; otherwise, the connection between them will not be made. If a router has a password configured for a peer, but the other peer does not, a message “No MD5 digest from…” will appear on the console while the routers attempt to establish a Multicast Source Discovery Protocol (MSDP) session between them.
When the aggregate-address command is used within BGP routing, the aggregated address is advertised, along with the more specific routes. The exception to this rule is through the use of the summary-only command. The “summary-only” keyword suppresses the more specific routes and announces only the summarized route.
The weight attribute is a special Cisco attribute that is used in the path selection process when there is more than one route to the same destination. The higher the weight value, the better the path. The default weight is 0.The weight attribute is local to the router and not propagated to other routers.
Below is the list of BGP states in order, from startup to peering:
1 – Idle: the initial state of a BGP connection. In this state, the BGP speaker is waiting for a BGP start event,
generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.
2 – Connect: In this state, BGP is waiting for the TCP connection to be formed. If the TCP connection completes, BGP will move to the OpenSent stage; if the connection cannot complete, BGP goes to Active
3 – Active: In the Active state, the BGP speaker is attempting to initiate a TCP session with the BGP speaker it wants to peer with. If this can be done, the BGP state goes to the OpenSent state.
4 – OpenSent: the BGP speaker is waiting to receive an OPEN message from the remote BGP speaker
5 – OpenConfirm: Once the BGP speaker receives the OPEN message and no error is detected, the BGP speaker sends a KEEPALIVE message to the remote BGP speaker
6 – Established: All of the neighbor negotiations are complete. You will see a number (2 in this case), which tells us the number of prefixes the router has received from a neighbor or peer group.
Notice that the “show ip bgp” command to display BGP topology database
Memorizing the BGP decision process steps is very useful and you should remember them.
The table below lists the complete path selection process:
1. Weight (Bigger is better)
2. Local preference (Bigger is better)
3. Self-originated (Locally injected is better than iBGP/eBGP learned)
4. AS-Path (Smaller is better)
5. Origin (Prefer ORIGIN code I over E, and E over ?)
6. MED (Smaller is better)
7. External (Prefer eBGP over iBGP)
8. IGP cost (Smaller is better)
9. EBGP Peering (Older is better)
10. RID (Lower is better)
Origin, AS_Path, Next_Hop are well-known mandatory BGP attributes that all BGP Updates must include.
Note: There are 4 BGP attribute types:
+ Well-known Mandatory: recognized by all implementations of BGP and must appear in a BGP update message. If missing, a notification error will be generated.
+ Well-Known Discretionary: recognized by all implementations of BGP but may not be sent in the BGP update message (include LOCAL_PREF, ATOMIC_AGGREGATOR).
+ Optional Transitive: may or may not be recognized by all BGP implementations. Because the attribute is transitive, BGP accepts and advertises the attribute even if it is not recognized (include Community attribute).
+ Optional Nontransitive: may or may not be recognized by all BGP implementations. Whether or not the receiving BGP router recognizes the attribute, it is nontransitive and is not passed along to other BGP peers (include MED).
There are two popular ways to prevent a multi-homed autonomous system from becoming a transit system:
+ Use a distribute-list or filter-list to filter all networks not originating from inside the autonomous system.
+ Use the no-export community attribute on all networks not originating from inside the autonomous system.
The AS-PATH attribute is used to prevent BGP routing loops. When receiving a BGP advertisement, the router checks the AS-PATH attribute, if it sees it’s own AS number in the AS-Path then it is a routing loop so the router will not install this route in its BGP table.
A rule of aggregation is “Aggregation applies only to routes that exist in the BGP routing table. An aggregated route is forwarded if at least one more specific route of the aggregation exists in the BGP routing table.
The “show ip bgp” command is used to display entries in the BGP routing table.
The complete synchronization rule is “A BGP router should not use, or advertise to an external neighbor, a route learned by IBGP unless that route is local or is learned from the IGP.”
With the default of synchronization disabled, BGP can use and advertise to external BGP neighbors routes learned from an IBGP neighbor that are not present in the local routing table
The “synchronization” here means “synchronization between iBGP with its IGP (such as OSPF, EIGRP…)
You can disable synchronization if one of the following conditions is true:
Your AS does not pass traffic from one AS to another AS.
All the transit routers in your AS run BGP.
Note: BGP synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.
Unlike other routing protocols, the router must be manually configured with the neighbor information on both sides of the connection.
The eBGP multihop allows a neighbor connection between two external peers that do not have a direct connection. The multihop is only for eBGP and not for iBGP.
BGP neighbor relationship is established when both ends (routers) are manually configured with the “neighbor neighbor-IP remote-as neighbor-AS” command on both sides of the connection. If the neighbor-AS is wrong, the neighbor relationship cannot be established
When two EBGP neighbors want to establish a neighbor relationship without using the directly connected interfaces (for example, use loopback interface), they must tell each other how to reach their interfaces. A static route is the most simple way to do this, especially when they are in different ASs.
BGP split-horizon rule states that a route learned from one IBGP neighbor will not be advertised to another IBGP neighbor so IBGP sessions should be fully meshed.
BGP routers have enormous routing tables so it uses much memory to proceed these routes. When a BGP policy is changed, the BGP session needs to be reset for the policy to take effect. But the resetting results in route churn and route flapping.
There are two ways to clear a BGP session without resetting the TCP session between them (this is often called “soft reset”):
Soft-reconfiguration: stores all received (inbound) routing policy updates without modification in a table so that when a new filter is applied, the router will use this table to calculate the changes without resetting the TCP session between the two BGP peers. This is a memory-intensive (high memory utilization) method and is not recommended.
Route-refresh: allows a BGP router to request a remote peer resend its BGP Adj-RIB-Out. This allows the BGP router to reapply the inbound policy. The route-refresh capability requires no extra memory on the local router
A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. In addition, a BGP peer group also simplifies the BGP configuration
1. Weight (Bigger is better)
2. Local preference (Bigger is better)
3. Self-originated (Locally injected is better than iBGP/eBGP learned)
4. AS-Path (Smaller is better)
5. Origin (Prefer ORIGIN code I over E, and E over ?)
6. MED (Smaller is better)
7. External (Prefer eBGP over iBGP)
8. IGP cost (Smaller is better)
9. EBGP Peering (Older is better)
10. RID (Lower is better)
Origin, AS_Path, Next_Hop are well-known mandatory BGP attributes that all BGP Updates must include.
Note: There are 4 BGP attribute types:
+ Well-known Mandatory: recognized by all implementations of BGP and must appear in a BGP update message. If missing, a notification error will be generated.
+ Well-Known Discretionary: recognized by all implementations of BGP but may not be sent in the BGP update message (include LOCAL_PREF, ATOMIC_AGGREGATOR).
+ Optional Transitive: may or may not be recognized by all BGP implementations. Because the attribute is transitive, BGP accepts and advertises the attribute even if it is not recognized (include Community attribute).
+ Optional Nontransitive: may or may not be recognized by all BGP implementations. Whether or not the receiving BGP router recognizes the attribute, it is nontransitive and is not passed along to other BGP peers (include MED).
There are two popular ways to prevent a multi-homed autonomous system from becoming a transit system:
+ Use a distribute-list or filter-list to filter all networks not originating from inside the autonomous system.
+ Use the no-export community attribute on all networks not originating from inside the autonomous system.
The AS-PATH attribute is used to prevent BGP routing loops. When receiving a BGP advertisement, the router checks the AS-PATH attribute, if it sees it’s own AS number in the AS-Path then it is a routing loop so the router will not install this route in its BGP table.
A rule of aggregation is “Aggregation applies only to routes that exist in the BGP routing table. An aggregated route is forwarded if at least one more specific route of the aggregation exists in the BGP routing table.
The “show ip bgp” command is used to display entries in the BGP routing table.
The complete synchronization rule is “A BGP router should not use, or advertise to an external neighbor, a route learned by IBGP unless that route is local or is learned from the IGP.”
With the default of synchronization disabled, BGP can use and advertise to external BGP neighbors routes learned from an IBGP neighbor that are not present in the local routing table
The “synchronization” here means “synchronization between iBGP with its IGP (such as OSPF, EIGRP…)
You can disable synchronization if one of the following conditions is true:
Your AS does not pass traffic from one AS to another AS.
All the transit routers in your AS run BGP.
Note: BGP synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.
Unlike other routing protocols, the router must be manually configured with the neighbor information on both sides of the connection.
The eBGP multihop allows a neighbor connection between two external peers that do not have a direct connection. The multihop is only for eBGP and not for iBGP.
BGP neighbor relationship is established when both ends (routers) are manually configured with the “neighbor neighbor-IP remote-as neighbor-AS” command on both sides of the connection. If the neighbor-AS is wrong, the neighbor relationship cannot be established
When two EBGP neighbors want to establish a neighbor relationship without using the directly connected interfaces (for example, use loopback interface), they must tell each other how to reach their interfaces. A static route is the most simple way to do this, especially when they are in different ASs.
BGP split-horizon rule states that a route learned from one IBGP neighbor will not be advertised to another IBGP neighbor so IBGP sessions should be fully meshed.
BGP routers have enormous routing tables so it uses much memory to proceed these routes. When a BGP policy is changed, the BGP session needs to be reset for the policy to take effect. But the resetting results in route churn and route flapping.
There are two ways to clear a BGP session without resetting the TCP session between them (this is often called “soft reset”):
Soft-reconfiguration: stores all received (inbound) routing policy updates without modification in a table so that when a new filter is applied, the router will use this table to calculate the changes without resetting the TCP session between the two BGP peers. This is a memory-intensive (high memory utilization) method and is not recommended.
Route-refresh: allows a BGP router to request a remote peer resend its BGP Adj-RIB-Out. This allows the BGP router to reapply the inbound policy. The route-refresh capability requires no extra memory on the local router
A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. In addition, a BGP peer group also simplifies the BGP configuration
No comments:
Post a Comment