Note: the BGP routing strategy notes are mainly distributed in prefix list, distribute list and route map
And new knowledge points, * advertisement map condition advertisement, * ORF and * route splitting
Reference video: Three cups of black tea
Front
0x01: prefix list operation BGP routing
>After operating the above strategy, the BGP route of 12.12.12.0/24 learned by R3 will be matched and filtered by the prefix list
!! R3 show ip bgp reference resourcesBGP table version is 2, local router ID is 33.33.33.33Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 20.1.1.1 0 100 i
0x02: distribute list operation route
There are two deployment schemes for the operation of distribution list in BGP
First:
Second:
The third type (reference only):
0x03: route map operation BGP routing
When configuring the routing policy in CCNP, the most powerful tool is route map
Is route map so powerful in BGP? There is no doubt about it
You can use the route map keyword in the following BGP commands
-
neighbor
-
bgp dampening
-
network
-
redistribute
route-map can be used to call a defined number in different commands for specific purposes.
-
suppress-map
-
unsuppress-map
-
advertise-map
-
*inject-map
-
*exist-map
-
*non-exist-map
-
*table-map
Match statement can match the following conditions or attributes
-
Access-list
-
ip prefix-list
-
local-preference
-
metric
-
Tag
-
AS-PATH
-
BGP community
-
IGP route-type (internal / external )
-
......
Set statement can set
-
Origin
-
Weight
-
BGP community
-
Local preference
-
MED
-
....
Configuration example: associate the network execution policy (change the route to match the delivery of different community values)
!! see R2 Get network Routing community Attribute referenceR2#show ip bgp 1.1.1.0BGP routing table entry for 1.1.1.0/24, version 5Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 100 10.1.1.1 from 10.1.1.1 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, best `Community: 100:1`R2#show ip b 2.2.2.0BGP routing table entry for 2.2.2.0/24, version 6Paths: (1 available, best #1, table Default-IP-Routing-Table)Flag: 0x880 Not advertised to any peer 100 10.1.1.1 from 10.1.1.1 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, best `Community: 100:2`!! We can see that the community attributes of the two are inconsistent!! This effect is achieved by operating the community value of the route map, associating the prefix list and the network route map test
Configuration instance: Associate neighbors and execute policies for specific neighbors 🔺
!! Final view R2 of metric Value attribute, here we pass route-map relation Prefix-list Matching route!! use route-map Operation metric Value, operation keyword is `neighbor`R2#show ip bgp BGP table version is 5, local router ID is 10.1.1.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 1.1.1.0/24 10.1.1.1 1000 0 100 i*> 2.2.2.0/24 10.1.1.1 2000 0 100 i
Configuration instance: republish associated route map
When the republication feature is deployed in BGP route map, you need to pay extra attention to the external OSPF IGP route,
It may require a keyword match
0x04: Policy list of plug-in for route map
About policy list, why do I call it a plug-in?
For me, a plug-in on a browser, such as chrome, is a help tool to enhance the user experience and enhance the operability of the browser
The same is true for the policy list in the route map,
We can think of a policy list as a route map with only match statements
It can use match conditions to play a package instead of using each package. It only needs to be invoked in route-map.
route-map test permit 10
match policy 10
1: Introduction to policy list
-
The route map containing a group of match statements can be defined as a command list in advance, which is called policy list
-
These policy lists can be called in the route map
-
A policy list is like a route map that contains only match statements
-
When the route map is executed, the match statements contained in the policy list called by it will be traversed and the match action will be executed
-
This is a feature used in large and medium-sized networks to make the configuration "modular and maintainable"
Note: with regard to policy list, we should note that this feature is only supported in BGP routing protocol, and may already be supported
2: policy configuration command reference
ip policy as100 permit match as-path 1 match community 1route-map RP permit 10 match policy-list as100 set local-preference 300
3: Configure experimental reference
The experimental requirements are as follows:
My BGP router in AS-400 only wants to receive new routing information about AS 100 and AS 200
Then we can make in direction strategy directly in BGP router of AS-400
The key configuration commands are as follows:
ip prefix-list 1 permit 10.0.0.0/8ip as-path access-list 1 permit ^100_ip as-path access-list 2 permit ^200_-------------------------------------------------------------------------------------ip policy-list as100 permit match as-path 1 ip policy-list as200 permit match as-path 2-------------------------------------------------------------------------------------route-map test permit 10 match ip address prefix-list 1 `match policy-list as100 as200` !! logic or relationship set metric 1000route-map test permit 20
In fact, through this experiment, we won't be very impressed with the policy list. What I am most impressed with here is the AS-PATH attribute of BGP
Because we can realize our various needs and strategies through various attributes of BGP
For example, the requirements in the experimental environment: as long as the routes from AS-200 and AS-100 are new
Then we can associate its as path value. We really sigh that BGP routing design is too powerful
0x05: Advertise-map
Condition announcement: let's have a brief understanding first. I have two routes: A and B
1: When B is alive, I update route B
2: When B hangs up, I update route A
One thing to note: this feature may not be stable enough
0x06: ORF 🔺🔺
This feature can be understood as a feature of optimizing BGP routing
Key words: unicast = = unicast
Observe the above figure:
1: R1 notifies R2 of 10000 BGP routes. In fact, R2 only wants 100 routes that are useful to him
-
At this time, R2 can deploy prefix list and other tools locally in the in direction to match its desired route
-
However, in fact, R1 has clearly sent these 10000 routes to R2. Although R2 has deployed the policy and obtained 100 routes he wants, the remaining 9900 routes will still be sent to R2. R2 just filters them out of the BGP table. This situation will make the routes announced in vain, wasting the bandwidth and resources of the link, And device performance CPU resources,
The most ideal way: R1 updates the route required by R2 to R2
Observe the following figure:
Through the establishment of ORF relationship, R2 will send its own filtering scheme to R1, so that R1 can send the route R2 wants,
It sends a message, and there is a Refresh message route refresh with ORF Message
ORF experimental application
Validation command: show ip BGP neighbors IP address advertised routes
!! R1 The configuration is as followsrouter bgp 100 neighbor 10.1.1.2 remote-as 200 ! address-family ipv4`neighbor 10.1.1.2 activate neighbor 10.1.1.2 capability orf prefix-list receive` network 1.1.1.0 mask 255.255.255.0 network 2.2.2.0 mask 255.255.255.0!end
!! R2 The configuration is as follows!`address-family ipv4 neighbor 10.1.1.1 activate neighbor 10.1.1.1 capability orf prefix-list send neighbor 10.1.1.1 prefix-list 1 in exit-address-family `!ip prefix-list 1 seq 5 deny 1.1.1.0/24ip prefix-list 1 seq 15 permit 0.0.0.0/0 le 32!end
After configuration, R1 activates ORF capability support, receives R2 prefix list refresh information, and only sends routes other than 1.1.1.0/24 to R2
!! R1 verification R1#show ip bgp neighbors 10.1.1.2 advertised-routes BGP table version is 3, local router ID is 2.2.2.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 2.2.2.0/24 0.0.0.0 0 32768 iTotal number of prefixes 1
0x07: route splitting BGP aggregation 🔺
The so-called route splitting is actually based on the summary route
If our requirements are as follows:
1: Routing entries need to be streamlined to reduce the workload of downstream BGP routers
2: At the same time, the downstream BGP router can simplify the summary route to form data diversion
At this time, only route splitting can perfectly meet this requirement. Refer to the following figure:
Detailed background:
Splitting can be accomplished by using conditional injection, which refers to:
When a specific summary route exists, I can generate specific details of its subordinates. These detailed routes will be injected into the local BGP RIB (the local routing table will also load detailed routing information), so AS to provide more detailed routing information (longer prefix) than the summary route in the local AS
Alas, simply put, the details will be split successfully only if the summary route exists. If the summary route does not exist, the split will naturally fail
to configure:
The configuration steps are as follows 🔺🔺
1: Create prefix list matching summary route
2: Create a prefix list to match the update source of this summary route
3: Create a prefix list to match the detailed routes to be injected in the summary routes I want to split
4: Create route map match summary route and match summary route source
5: Create route map set details I want to inject
6: Enter BGP process Association details and association summary.
Experimental reference
The topo diagram is as follows:
!! R1 The configuration process is as follows:interface Loopback0 ip address 1.1.1.1 255.255.255.0!interface Serial0/0 ip address 10.1.1.1 255.255.255.0!router bgp 100 network 1.1.1.0 mask 255.255.255.0 aggregate-address 1.0.0.0 255.0.0.0 as-set summary-only neighbor 10.1.1.2 remote-as 200!end
!! R2 The configuration process is as follows:* The main configuration is R2interface Loopback0 ip address 2.2.2.2 255.255.255.0!interface Serial0/0 ip address 10.1.1.2 255.255.255.0! interface Serial0/1 ip address 20.1.1.1 255.255.255.0!router ospf 1 network 2.2.2.2 0.0.0.0 area 0 network 20.1.1.1 0.0.0.0 area 0!router bgp 200 bgp inject-map mingxi exist-map huizong neighbor 3.3.3.3 remote-as 200 neighbor 3.3.3.3 update-source Loopback0 neighbor 10.1.1.1 remote-as 100!ip prefix-list 1 seq 5 permit 1.0.0.0/8!ip prefix-list 111 seq 5 permit 1.1.1.0/24!ip prefix-list source seq 5 permit 10.1.1.1/32!route-map mingxi permit 10 set ip address prefix-list 111!route-map huizong permit 10 match ip address prefix-list 1 match ip route-source source!end
!! R3 The configuration process is as follows:interface Loopback0 ip address 3.3.3.3 255.255.255.0!interface Serial0/1 ip address 20.1.1.2 255.255.255.0!router ospf 1 network 3.3.3.3 0.0.0.0 area 0 network 20.1.1.2 0.0.0.0 area 0!router bgp 200 neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 update-source Loopback0!end