Useful Linux commands cheat sheet

BGP conditional advertisement

The post examines what is it conditional advertisement and the steps to configure it in BGP.

In other words, a router configured with conditional advertisement, will advertise a prefix to a peer IF another prefix exists or not exists in the BGP table. 

The goal in my mini-lab is R1 to advertise prefix 100.100.100.100/32 to R2, if it has prefix 200.200.200.200/32 in its BGP table:

 eBGP

 100.100.100.100/32 ---| R1 | -----------------------| R2| --- 200.200.200.200/32

First, we need to match the prefixes used for the condition. This can be achieved via ACL or Prefix-list.

Second, we need to match the ACL (or prefix-list) in a Route-map

Third, we need to configure the condition and attach it to the neighbor (I used exist-map, but you can use non-exist-map, which means -> advertise a prefix to the neighbor, if this prefix doesn't exist in the bgp table)

Last point to remember is that , the conditional prefix is not mandatory to be in the Routing table, but just in the BGP table.


Debug messages when UPDATE for 200.200.200.200/32 is received from R2:

*Mar  1 00:47:59.811: BGP(0): 1.1.1.2 rcvd UPDATE w/ attr: nexthop 1.1.1.2, origin i, metric 0, path 2
*Mar  1 00:47:59.811: BGP(0): 1.1.1.2 rcvd 200.200.200.200/32
*Mar  1 00:47:59.819: BGP(0): Revise route installing 1 of 1 routes for 200.200.200.200/32 -> 1.1.1.2(main) to main IP table
*Mar  1 00:47:59.919: BGP(0): Revise route installing 1 of 1 routes for 200.200.200.200/32 -> 1.1.1.2(main) to main IP table
*Mar  1 00:48:39.411: BPG(0): Condition if-advertise changes to Advertise
*Mar  1 00:48:39.411: BPG(0): Condition if-advertise changes to Advertise
*Mar  1 00:48:39.415: BGP(0): net 100.100.100.100/32 matches ADV MAP advertise: bump version to 9
*Mar  1 00:48:40.163: BGP(0): nettable_walker 100.100.100.100/32 route sourced locally
*Mar  1 00:48:40.163: BGP(0): 1.1.1.2 100.100.100.100/32 matches advertise map advertise, state: Advertise
*Mar  1 00:48:40.167: BGP(0): 1.1.1.2 send UPDATE (format) 100.100.100.100/32, next 1.1.1.1, metric 0, path Local

Debug messages when UPDATE - withdrawn for 200.200.200.200/32 is received from R2:


*Mar  1 00:50:05.635: BGP(0): 1.1.1.2 rcv UPDATE about 200.200.200.200/32 -- withdrawn
*Mar  1 00:50:05.639: BGP(0): no valid path for 200.200.200.200/32
*Mar  1 00:50:05.643: BGP(0): nettable_walker 200.200.200.200/32 no best path
*Mar  1 00:50:39.467: BPG(0): Condition if-advertise changes to Withdraw
*Mar  1 00:50:39.467: BPG(0): Condition if-advertise changes to Withdraw
*Mar  1 00:50:39.471: BGP(0): net 100.100.100.100/32 matches ADV MAP advertise: bump version to 11
*Mar  1 00:50:40.159: BGP(0): nettable_walker 100.100.100.100/32 route sourced locally
*Mar  1 00:50:40.159: BGP(0): 1.1.1.2 100.100.100.100/32 matches advertise map advertise, state: Withdraw
*Mar  1 00:50:40.159: BGP(0): 1.1.1.2 send unreachable 100.100.100.100/32
*Mar  1 00:50:40.163: BGP(0): 1.1.1.2 send UPDATE 100.100.100.100/32 -- unreachable

BGP local-as, no-prepend, replace-as, dual-as

• local-as - this feature allows the router to appear in different AS in addition to the Global AS. The peer has to configure remote-as -> the local-as number. Working for eBGP only. With iBGP the neighborship is flapping:

With iBGP : 

• no-prepend - When configured this feature on the transit router (R1) , will not prepend the local-as number in the updates from R2 and sent to R3

Before:

After:

• replace-as - When configured to a neighbor (R2) , R1 will prepend only the local-as in the updates

Before:

After:

• dual-as - is a feature that allows a peering router to establish neighborship with either global-as, either local-as

R2(config-router)#

*Mar  1 01:08:59.171: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up

R2(config-router)#neighbor 192.168.12.1 remote-as 3

R2(config-router)#

*Mar  1 01:09:12.383: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Down Remote AS changed

R2(config-router)#

*Mar  1 01:09:14.519: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up

OSPF Filtering

Summary of OSPF filtering options

• Prefix suppression 

- can be under interface level or process level

Note: When configured under process level, it will not suppress prefixes associated with Loopback interfaces and Passive interfaces. Under interface level, it will not suppressed the secondary ip address network 

• Filter list (on the ABR)

- area x filter-list prefix "name" [in | out]

• Area range (ABR) and Summary address (ASBR) with not-advertise

- area x range "prefix" not-advertise
- summary-address "prefix" not-advertise

• Distribute list (via acl or prefix-list)

•  Cost and AD

Note: the last two ways are filtering prefixes from/into Routing table, but not from the LSDB. This sometimes can lead to blackholes in the topology.

About the blog

Every blog out there has some goal.

My goal with "The Pursuit of Networking" is to be a place, where I will be writing my own thoughts and findings regarding networking technologies, concepts and future trends.
The posts will be about different technologies, protocols, commands.. etc. as I understand them. Then, I hope somebody will benefit from my notes and actually learn something. But the posts will be completely random and can vary a lot. Don't expect, that I will post everything about OSPF for example. If you are a totally newbie in networking, I suggest first getting a CCNA certification, in order to build a stable foundation.

Before I start writing, I want to say that this is absolutely experimental way for me to study and I will be more than happy to be criticised, because I believe from the critics of others, I can understand my own mistakes and then improve over time. 

Thank you.