Best practises for BGP configuration

There are several best practices that should be followed when configuring BGP (Border Gateway Protocol) to ensure optimal routing and network stability. Here are some key considerations and configuration parameters:

Mục lục

no synchronization

In BGP (Border Gateway Protocol), synchronization refers to the requirement that a router will not advertise a route learned from an eBGP (External BGP) neighbor to another eBGP neighbor or an IGP (Interior Gateway Protocol) neighbor until it has been learned through the IGP as well.

By default, synchronization is enabled in BGP, which means that if a router receives a route from an eBGP neighbor, it will not advertise it to any other neighbor until it has confirmed that the same route is present in the IGP routing table. The reason for this requirement is to avoid forwarding loops and suboptimal routing.

However, there are some scenarios where synchronization can cause problems or unnecessary delays in the propagation of routing information. For example, in a network where all the routers are running BGP, synchronization is not necessary because all the routers already have the same routing information. In such cases, disabling synchronization can improve convergence time and reduce complexity.

The “no synchronization” command in the BGP configuration turns off synchronization for the router, which means that the router will advertise BGP-learned routes to other eBGP neighbors without checking if the same route is present in the IGP routing table. It should be noted that disabling synchronization requires careful planning and configuration to avoid routing loops and other issues.

bgp log-neighbor-changes

The “bgp log-neighbor-changes” command is used to enable logging of BGP neighbor changes. When this command is enabled, the router logs all changes in the BGP neighbor state, such as when a new neighbor is established, when a neighbor goes down, or when a neighbor comes back up.

Enabling this command is useful for troubleshooting BGP issues, as it provides visibility into changes in the BGP neighbor state. For example, if a BGP neighbor goes down and stays down, the logs can help identify the cause of the issue, such as a network connectivity problem or a misconfiguration.

In addition, logging BGP neighbor changes can be helpful in monitoring the overall health of the BGP peering relationships. The logs can provide insight into the frequency and duration of neighbor changes, which can help identify potential stability issues or flapping routes.

Overall, enabling the “bgp log-neighbor-changes” command is a best practice for BGP configuration and can be useful for troubleshooting and monitoring purposes.

When the “bgp log-neighbor-changes” command is enabled on a router, it will generate syslog messages for any BGP neighbor state changes, such as when a neighbor comes up or goes down. These syslog messages will be sent to the syslog server or logging buffer specified in the router’s configuration.

The exact location and method of logging can vary depending on the router platform and configuration. In Cisco IOS routers, for example, the syslog messages can be viewed using the “show logging” command or by accessing the router’s syslog server. Other router vendors and platforms may have different methods for accessing and viewing syslog messages.

In addition to syslog messages, some routers may also generate SNMP traps or other notifications for BGP neighbor state changes when the “bgp log-neighbor-changes” command is enabled. These notifications can be configured to alert network administrators or management systems of any significant BGP events, allowing for quick troubleshooting and resolution of issues.

no auto-summary

In BGP, the no auto-summary command disables the default behavior of summarizing network prefixes at the classful network boundary. By default, BGP summarizes the network prefixes it advertises based on their classful network boundaries. However, this can result in suboptimal routing and network connectivity issues.

For example, consider a scenario where a network has two subnets of 192.168.1.0/24 and 192.168.2.0/24. If BGP is configured with auto-summary, it will advertise these two subnets as 192.168.0.0/16. This can cause routing problems if there are other networks in the same 192.168.0.0/16 network that are not reachable through this BGP router.

By disabling auto-summary, BGP advertises the exact network prefixes, without summarizing them at the classful network boundary. This ensures accurate routing information and better connectivity.

If auto-summary is not disabled, it can lead to incorrect routing information being advertised, causing traffic to be misrouted or dropped. This can result in network outages and downtime, and can also impact the performance of applications and services that rely on network connectivity.

Therefore, it is recommended to disable auto-summary in BGP configuration to ensure accurate routing information and better network connectivity.

Redistribute connected Top of Form

The redistribute connected command in BGP is used to advertise routes learned through directly connected networks into the BGP routing domain.

Advantages:

It allows BGP routers to advertise local routes that are not learned through an IGP (Interior Gateway Protocol) such as OSPF or EIGRP.
It simplifies routing administration because network administrators do not need to manually configure all the prefixes in BGP.

Disadvantages:

It can increase the size of the BGP table with unnecessary routes. Therefore, it’s recommended to use prefix lists to filter unwanted routes and advertise only necessary routes.
If not configured properly, it can lead to suboptimal routing, blackholing, and other routing problems. Therefore, it’s important to ensure that the connected networks advertised through BGP are properly aggregated and summarized.

Design best practices

Use prefix-lists or route-maps to filter unwanted routes and advertise only necessary routes.
Aggregating and summarizing the routes before redistributing them into BGP can reduce the size of the BGP table and improve the efficiency of the routing protocol.
Redistributing connected routes into BGP can be useful in small networks, but in larger networks, it’s recommended to use a dynamic routing protocol like OSPF or EIGRP to propagate the network routes instead of relying on manual redistribution.

Overall, the redistribute connected command in BGP is a useful tool for network administrators to advertise local routes into the BGP routing domain. However, it should be used with care, and proper filtering and summarization techniques should be employed to avoid any potential issues.

In BGP, the redistribute connected command is used to redistribute routes learned from directly connected networks into BGP. This means that routes that are not learned through BGP, but are directly connected to the router, can be advertised to other BGP routers in the network.

A route map can be used with the redistribute connected command to filter which connected routes are redistributed into BGP and to apply any necessary modifications to the routes before they are advertised.

Using the redistribute connected command with a route map provides flexibility in filtering and modifying the routes learned from directly connected networks before they are advertised into BGP. This helps in designing an efficient and optimized BGP network.

redistribute static

In BGP, “redistribute static” is a command used to redistribute static routes into BGP. It allows the BGP process to advertise the static routes to other routers in the network. By using the “redistribute static” command, static routes that are not learned via a routing protocol can be advertised in BGP.

When redistributing static routes into BGP, it is often useful to use route maps to control the advertisement of these routes. Route maps can be used to set attributes such as the next-hop address, MED, or BGP community values. Route maps can also be used to filter which static routes are advertised into BGP.

Advantages of using “redistribute static” in BGP include the ability to advertise static routes that are not learned via a routing protocol, and the ability to control how static routes are advertised using route maps.

Disadvantages of using “redistribute static” in BGP include the potential for suboptimal routing if static routes are not properly filtered or if the next-hop address is not set correctly.

Best design practice for using “redistribute static” in BGP is to carefully filter which static routes are advertised using route maps and to ensure that the next-hop address is set correctly. It is also important to monitor the routing table and ensure that there are no suboptimal routing paths caused by the redistribution of static routes into BGP.

remote as

In BGP, the remote-as parameter is used to specify the autonomous system number of the BGP neighbor. It is required to establish a BGP session with a remote peer.

BGP supports two types of AS numbers: private AS numbers and public AS numbers. Public AS numbers are assigned by the Internet Assigned Numbers Authority (IANA) and are globally unique. Private AS numbers are not registered with IANA and are used for internal routing within an organization.

When configuring BGP, it’s considered a best practice to use private AS numbers for internal routing and public AS numbers for peering with external networks.

There are different ways to configure remote-as in BGP neighbor:

Configuring a static remote-as: This involves specifying the AS number of the remote neighbor manually. This method is typically used when the neighbor is a customer or a peer with a known AS number.
Using neighbor templates: This involves creating a template for BGP neighbors and applying it to multiple peers. This method simplifies configuration and reduces errors. eg :

template peer bgp-neighbor
remote-as <neighbor_ASnumber>
ebgp-multihop 2
address-family ipv4 unicast
route-reflector-client
router bgp <ASnumber>
neighbor <neighbor1_IP> use neighbor bgp-neighbor
neighbor <neighbor2_IP> use neighbor bgp-neighbor

local as

The “local-as” command in BGP is used to set the local AS number to a value different from the actual AS number. This command can be used for several purposes, such as:

AS migration: When an organization merges with another organization that uses a different AS number, the “local-as” command can be used to temporarily maintain the old AS number while the migration process takes place.
AS translation: When an organization connects to a provider that requires a specific AS number for BGP peering, the “local-as” command can be used to translate the local AS number to the required AS number.
AS confederation: When multiple autonomous systems need to be represented as a single AS number, the “local-as” command can be used to configure a confederation.

It is important to note that the “local-as” command should be used with caution, as it can cause confusion and routing issues if not configured correctly. It is recommended to use it only in specific scenarios where it is necessary and to follow best practices and design considerations.

Nexthop self

In BGP, the Next Hop attribute is used to determine the best path to reach a destination. When BGP is used between routers in different autonomous systems (EBGP), the next hop address for a prefix advertised to a neighbor is typically set to the IP address of the advertising router’s interface that is used to reach the neighbor. However, when BGP is used between routers within the same autonomous system (IBGP), the next hop address for a prefix advertised to a neighbor is not changed by default, and this can cause routing problems.

To address this issue, the “next-hop-self” command is used in BGP configuration. This command instructs the router to set the next hop address for prefixes advertised to IBGP peers to the IP address of the router’s interface that is used to establish the BGP session with the neighbor. This ensures that the next hop address is reachable within the same AS and prevents routing loops.

One potential disadvantage of using the “next-hop-self” command is that it can cause the routing table to become larger if the same prefix is advertised by multiple routers. In such cases, it is important to ensure that the routing policies and filters are designed in a way that minimizes the number of duplicate routes.

In summary, the “next-hop-self” command is an important feature of BGP that is used to ensure proper routing within an autonomous system. However, it should be used with caution and proper design considerations to avoid potential routing problems.

allowas-in

The allowas-in feature in BGP is used to allow routes to be accepted by a BGP speaker even if the AS number in the AS_PATH attribute of the route is the same as the AS number of the BGP speaker itself. This is useful when there are multiple BGP speakers within the same AS, and they need to exchange routing information with each other.

For example, suppose there are two BGP routers within the same AS 65505, named R1 and R2. R1 has an eBGP session with a router in another AS, and it learns a route to the destination network 192.168.1.0/24. R1 advertises this route to R2, which is also in AS 65505. However, when R2 receives the route, it sees that the AS_PATH attribute contains the AS number 65505, which is the same as its own AS number. By default, R2 will reject this route since it appears to be a routing loop.

To allow R2 to accept the route from R1, the allowas-in feature can be used. This allows R2 to accept routes with its own AS number in the AS_PATH attribute, up to a certain limit. For example, the allowas-in command can be configured with a value of 2, which means that R2 will accept routes with up to two occurrences of its own AS number in the AS_PATH attribute. This prevents the possibility of routing loops, while still allowing the exchange of routing information between the BGP speakers within the same AS.

send-community

In BGP (Border Gateway Protocol), the send-community attribute is used to include BGP community values in outgoing updates. The BGP community attribute is a tag that can be assigned to a prefix to provide additional information about the prefix to other BGP routers in the network.

When the send-community attribute is configured, BGP will include the community values associated with the prefix in outgoing BGP updates. This allows other BGP routers in the network to make routing decisions based on the community values.

By following these best practices and configuring BGP with the appropriate parameters, you can ensure that your network has optimal routing and stability let me know what are the other best practices and your thought on this article.

Source: Kamchalabdhan TT