22 Oct

Arista – dealing with inactive routes in BGP

In EOS, BGP implementation normally considers only active routes in RIB for advertisement to its peers.

In certain deployments, IGP protocol like OSPF may carry same set of prefixes as BGP (especially if we use OSPF to form iBGP). In addition, routes from OSPF and BGP may be mutually redistributed. As a result, when local BGP process advertises these prefixes to its neighbors, it would always choose OSPF routes over corresponding BGP routes (admin distance of OSPF is better than that of BGP).

For a Cisco network engineer, this is totally deviate from their normal understanding. In Cisco, if the similar situation happened, it only marked as rib failure, but the BGP prefixes are still advertised out to other BGP peer.

Coincidentally, I encountered this situation and I will share my findings and workaround for reference.

Option 1 – advertise-inactive

This is documented by Arista, basically it tells the BGP to advertised out prefixes even though it is inactive (inactive due to better AD is exist in other routing protocol).
https://eos.arista.com/eos-4-15-0f/bgp-advertise-inactive/

Option 2 – override the AD for prefixes learnt from iBGP peer

ip prefix-list default-only seq 10 permit 0.0.0.0/0
!
route-map set-distance-for-default permit 10
    match ip address prefix-list default-only
    set distance 20
 !
 route-map set-distance-for-default permit 20
!
router bgp 65999
   neighbor 10.3.36.2 route-map set-distance-for-default in

For my case, the 0.0.0.0/0 is not installed in BGP because the switch is also receiving the same prefix from OSPF. Above config will set the AD for 0.0.0.0/0 to 20 (instead of 200) when it received the BGP update from the peer. I can set it to any value as long as it is lower than 110 (OSPF)

https://eos.arista.com/forum/change-ad-for-specific-prefix-in-bgp-or-ospf/



04 Jul

BGP as-path regular expressions

A regular expression is the character pattern that can be matched against an input string. Regular expressions can be built using letters (A through Z, a through z), numbers (0 through 9) and other keyboard characters, such as the exclamation point (!) or a tilde (~). A regular expression can be a single-character pattern or a multiple-character pattern. Certain keyboard characters such as caret (^) and dollar sign ($) have special meaning and allow complex regular expressions to be built. Characters with special meaning can be used as simple keyboard characters by preceding them with a backslash (\). When a Border Gateway Protocol (BGP) update exits an Autonomous System (AS), the AS path attribute of the route gets updated. The AS number of the AS is prepended to an existing list of AS numbers. BGP can be configured to use regular expressions for route filtering based on the AS path attribute.

Range

A range is a sequence of characters contained within left and right square brackets. For example: [abcd]

Atom

An atom is a single character, such as the following:

. (Matches any single character)

^ (Matches the beginning of the input string)

$ (Matches the end of the input string)

\ (Matches the character)

– (Matches a comma (,), left brace ({), right brace (}), the beginning of the input string, the end of the input string, or a space.

Piece

A piece is an atom followed by one of the following symbols:

* (Matches 0 or more sequences of the atom)

+ (Matches 1 or more sequences of the atom)

? (Matches the atom or the null string)

Branch

A branch is a 0 or more concatenated pieces.

Examples of regular expressions follow:

a* (Any occurrence of the letter “a”, including none)

a+ ( At least one occurrence of the letter “a” should be present)

ab?a (This matches “aa” or “aba”)

_100_ (Via AS100)

_100$ (Origin AS100)

^100 .* (Coming from AS100)

^$ (Originated from this AS)

Refer to Using Regular Expressions in BGP for sample configurations on regular expression filtering

To test in live network using public looking glass server:
https://www.netdigix.com/servers.html

Additional readings:

http://www.quagga.net/docs/docs-multi/AS-Path-Regular-Expression.html

http://www.cisco.com/warp/public/459/26.html

http://www.avici.com/documentation/HTMLDocs/02223-06_revBA/Routing_Pol7.html

18 Jan

BGP RIB-Failure

When a Router receives a BGP UPDATE packet that contains Network Layer Reachability Information (NLRI) – this is, a route; the packet is processed in the next order:

– Step 1. BGP checks for the NLRI (prefix received) against any BGP inbound filter configured on the Router.

– Step 2. If the NLRI is not filtered, the prefix can be seen in the BGP table with the show ip bgp command.

– Step 3. If the Routing Table already has the same prefix/prefix-length entry with a lower Administrative Distance (AD) as seen in show ip route, BGP marks the route received with RIB-Failure.

*You can display BGP routes that are not inserted in the IP routing table with the show ip bgp rib-failure command, which also explains why the BGP route was not inserted in the IP routing table.

*all routes shown in show ip bgp rib-failure command will still advertised to all BGP peers.

*Network Layer Reachability Information (NLRI)

The Network Layer Reachability Information (NLRI) is exchanged between BGP routers using UPDATE messages. An NLRI is composed of a LENGTH and a PREFIX. The length is a network mask in CIDR notation (eg. /25) specifying the number of network bits, and the prefix is the Network address for that subnet.

The NLRI is unique to BGP version 4 and allows BGP to carry supernetting information, as well as perform aggregation.

The NLRI would look something like one of these:

     /25, 204.149.16.128
     /23, 206.134.32
     /8, 10

Reference:
1. https://blog.ipspace.net/2007/12/what-is-bgp-rib-failure.html
2. https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213286-understand-bgp-rib-failure-and-the-bgp-s.html#anc4
3. https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5816-bgpfaq-5816.html#anc27

02 Jan

BGP Aggregate experiment

The BGP aggregate-address can be used to summarise a set of networks into a single prefix. For this post, I just wanted to show the difference between aggregate-address and aggregate-address with summary only.

We have below topology. I’m going to summarise prefixes in R1.

R1 config

hostname R1
!
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.252
!
router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 neighbor 10.10.10.2 remote-as 20
!
ip route 192.168.1.0 255.255.255.0 Null0
ip route 192.168.2.0 255.255.255.0 Null0
ip route 192.168.3.0 255.255.255.0 Null0
!

R2 config

hostname R2
!
interface GigabitEthernet0/0
 ip address 10.10.10.2 255.255.255.252
!
router bgp 20
 bgp log-neighbor-changes
 neighbor 10.10.10.1 remote-as 10
!

Case 1: without aggregate-address

R2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.10.10.1               0             0 10 i
 *>  192.168.2.0      10.10.10.1               0             0 10 i
 *>  192.168.3.0      10.10.10.1               0             0 10 i

Case 2: with aggregate-address
R1 config

router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 aggregate-address 192.168.0.0 255.255.252.0
Router#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.0.0/22   10.10.10.1               0             0 10 i
 *>  192.168.1.0      10.10.10.1               0             0 10 i
 *>  192.168.2.0      10.10.10.1               0             0 10 i
 *>  192.168.3.0      10.10.10.1               0             0 10 i

Note that we will be having the original /24 routes (longer prefix) and summarised /22 route.

Case 3: aggregate-address with summary only
R1 config

router bgp 10
 bgp log-neighbor-changes
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 aggregate-address 192.168.0.0 255.255.252.0 summary-only
R2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.0.0/22   10.10.10.1               0             0 10 i

All the longer-prefixes inside of the aggregate address are suppressed.