Solution to IBGP horizontal segmentation:
Horizontal segmentation of IBGP: when a router learns a BGP route from an IBGP peer, it will no longer announce the route information to other IBGP peers.
1. Route reflector:
Principle:
An IBGP is configured as a routing reflector (RR), and the device configured as a routing reflector will reflect the learned routing information under certain conditions.
When a device is designated as a routing reflector (RR), one or more neighbors must be designated as his customers. The system formed between the routing reflector and the customer is called the reflection cluster (as a whole). Each cluster is set with a cluster ID (the cluster ID is the RID of the RR in the reflection cluster), while other undefined neighbors are called non customers (there can be multiple RRs in a region)
Reflection rule:
① if RR learns an IBGP route from a customer, it will be reflected to all its customers and non customers (as well as EBGP)
② if RR learns an IBGP route from non customers, it will be reflected to all its customers (and EBGP), but not to other non customers
③ when the router performs route reflection, it only reflects the best route in its own BGP route (the transmission rules are the same as that of BGP route, and the route transmitted by the reflector is the preferred route ">")
Problems of reflector:
Because the horizontal segmentation of IBGP is mainly for loop generation, and the reflection of the routing reflector is equivalent to breaking the horizontal segmentation rules of IBGP, there may be a routing loop.
In order to avoid the routing loop, two properties are specially introduced to avoid the loop (originator \u ID and cluster list: originator ID and cluster list), These two attributes are only used for anti ring in IBGP (when RR performs route reflection, other attributes remain unchanged except the above two attributes will be added to the route information).
Originator ID: the originator ID is the RID of the originator of this route information. When a route is reflected by RR, this attribute will be added to the reflected route information. If the RR receives a routing message with the originator ID, it will not modify this attribute.
When a device receives the routing information and finds that the originator ID in it is its own local RID, it will not accept the routing information to avoid routing backhaul
Cluster list: if there are multiple reflections in an AS, there must be multiple reflection clusters. When reflecting the routing information, each RR will add the local cluster ID to the cluster list attribute in the routing information.
to configure:
As shown in the figure, at this time, there are three IBGP in AS2 area. In addition to allowing them to build neighbors with each other, we can also let them establish a routing reflector. At this time, we can choose to establish a routing reflector on R11, so that the routing information in AS1 area can be forwarded to other customers in AS2 area through EBGP peers. (note the forwarding rules of RR customers and non customers at this time)
[r11-bgp]peer 2.2.2.2 reflect-client
[r11-bgp]peer 4.4.4.4 reflect-client
#At this time, set R10 and R11 as the customers of the routing reflector, and R11 as the RR
//It should be noted that the routing reflector is established based on the IBGP peer, so it is necessary to establish the IBGP peer in the AS first2. Federal:
The Federation EBGP relationship only inherits the routing rules between EBGP, but it cannot modify the routing attributes like EBGP peers. It also needs to abide by the AS-BY-AS rules, which is a special existence.
The anti ring between federal EBGP directly adopts the EBGP horizontal segmentation mechanism to prevent the ring, which is directly in AS_ Add the member AS number in the path attribute to prevent ring, but the federal AS number will be enclosed in parentheses to distinguish. This attribute is mainly used for AS internal ring protection, so it will not be passed to EBGP peers.
be careful:
① Federation EBGP does not need to be based on IBGP peer relationship!!!
② the federated EBGP is used for neighbor building between federations, but the federated EBGP is not the real EBGP peer, so it is necessary to set the TTL to 1 (> 1) when establishing the federated EBGP
③ the federal EBGP is established by dividing private AS areas within a public AS area, so the establishment of the federal EBGP needs to declare its public area
④ all federal EBGP neighbors (EBGP,IBGP) need to declare the areas to be established
⑤ the Federation only achieves the IBGP horizontal segmentation between federations, but the Federation still needs to establish routing reflectors or neighbors to complete the horizontal segmentation and destruction within the federal region
to configure:
//Establishment of IBGP and EBGP peer relationship in the Federation
[r2]bgp 64512
#When a federate starts the BGP process, it specifies the private number of the Federation to start
[r2-bgp]router-id 2.2.2.2
#Declare local RID
[r2-bgp]confederation id 2
#Federation members must declare their true AS number in the process
[r2-bgp]peer 12.0.0.1 as-number 1
#Establish relationships with EBGP peers
//Establishment of IBGP peer in Federation
[r2]bgp 64512
#When a federate starts the BGP process, it specifies the private number of the Federation to start
[r2-bgp]router-id 2.2.2.2
#Declare local RID
[r2-bgp]confederation id 2
#Federation members must declare their true AS number in the process
[r2-bgp]peer 3.3.3.3 as-number 64512
#When establishing IBGP neighbor relationship with federated members, specify the federal private number of peer IBGP
[r2-bgp]peer 3.3.3.3 connect-interface LoopBack 0
#Establish BGP peer using loopback
//Establishment of EBGP peer between Federations
[r3]bgp 64512
[r3-bgp]router-id 3.3.3.3
[r3-bgp]confederation id 2
[r3-bgp]confederation peer-as 64513
#Before establishing a federated EBGP peer relationship, specify the other party's Federation number as the direct neighbor Federation
[r3-bgp]peer 4.4.4.4 as-number 64513
[r3-bgp]peer 4.4.4.4 connect-interface LoopBack 0
[r3-bgp]peer 4.4.4.4 ebgp-max-hop 2
#Since the Federation EBGP is established under the IBGP peer, the TTL needs to be modified Routing principle of BGP:
prerequisite:
Select the route with status code "*" and compare the route information with status code ">"
Example:
At this time, R4 in AS2 can receive the BGP loopback routing information of R1
<r4>display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 2
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.2.1 0 100 0 1i
* i 192.168.3.1 0 100 0 1i
Route selection principle:
Top to bottom matching
1. The route with the highest value of the preferred value attribute is preferred
Preferred value is Huawei's private attribute, which means weight. Pv attribute is the attribute with the highest routing priority of the equipment. The larger the value, the better. This attribute will not be passed, but can only be modified on the device. The routing entries passed out will not carry this value (not passed). That is, after the peer receives the route, this attribute is still the local default value.
If only the PV value of a route information is modified, the priority of all routes of this route will be modified recursively (all routes on this route will be preferred). If you only modify the PV value of a single route information, you need to do load sharing (make different traffic take different routes to share the routing pressure of a single line), and use the routing strategy for traffic operation.
- Directly modify the local PV value
[r4-bgp]peer 192.168.3.1 preferred-value 100
#Modify the PV value of the routing information sent by the corresponding neighbor, and the neighbor of IBGP is the corresponding loopback route
//At this time, compare the preferred scheme of the same route before and after
//Before modifying PV
[r4-bgp]display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 2
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.2.1 0 100 0 1i
* i 192.168.3.1 0 100 0 1i
//After modifying PV
[r4-bgp]display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 2
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.3.1 0 100 100 1i
* i 192.168.2.1 0 100 0 1i- Range flow control through filter list
//Use prefix list to grab range traffic (192.169.1.0 / 24)
[r4]ip ip-prefix lxb permit 192.169.1.0 24
[r4]route-policy lxb permit node 10
Info: New Sequence of this List.
[r4-route-policy]if-match ip-prefix lxb
[r4-route-policy]apply preferred-value 100
//If the prefix list lxb is matched, the operation of pv+100 is performed
[r4-route-policy]q
//The prefix list needs to be configured by default
[r4]route-policy lxb permit node 20
Info: New Sequence of this List.
[r4-route-policy]q
//Call the filter list in the BGP process (because PV modifies the local value, so it needs to be modified locally).
[r4]bgp 2
[r4-bgp]peer 192.168.3.1 route-policy lxb import
//At this point, view the routing list of BGP again
[r4-bgp]display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 4
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.2.1 0 100 0 1i
* i 192.168.3.1 0 100 0 1i
*>i 192.169.1.0 192.168.3.1 0 100 100 1i
* i 192.168.2.1 0 100 0 1i2. The route with the largest value of local preference attribute is preferred
Local preference is the local priority attribute, which defaults to 100 (the larger the better).
LP value is an attribute used internally by IBGP and can be passed between IBGP neighbors. This attribute (the most commonly used attribute in IBGP) will not be carried when passing it to EBGP neighbors. You can modify the traffic using the routing strategy.
- Modify the LP value of IBGP directly
//Modify the LP value on other routers
[r3-bgp]default local-preference 200
//View the routing priority on the bgp routing table
[r4-bgp]display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 4
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.3.1 0 200 0 1i
* i 192.168.2.1 0 100 0 1i
*>i 192.169.1.0 192.168.3.1 0 200 0 1i
* i 192.168.2.1 0 100 0 1i- Operate with routing policy
//Fetch prefix list on R3
[r3]ip ip-prefix lxb permit 192.168.1.0 24
//Modify using policy
[r3]route-policy lxb permit node 10
Info: New Sequence of this List.
[r3-route-policy]if-match ip-prefix lxb
[r3-route-policy]apply local-preference 200
[r3-route-policy]q
//Release other flows
[r3]route-policy lxb permit node 20
Info: New Sequence of this List.
[r3-route-policy]q
//Calling policy in BGP process
[r3]bgp 2
[r3-bgp]peer 192.168.4.1 route-policy lxb export
//At this point, check the routing on R4 again
[r4-bgp]display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 4
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.3.1 0 200 0 1i
* i 192.168.2.1 0 100 0 1i
*>i 192.169.1.0 192.168.2.1 0 100 0 1i
* i 192.168.3.1 0 100 0 1i3. BGP routes originating locally are better than those learned from other peers
The routing information originating locally is always greater than that learned from others
Priority of local originating route: manual aggregation > automatic aggregation > Network > republish
You can use routing policies to modify traffic
4. Priority as_ The path property the shortest route
AS_ Basic principle of path routing: the fewer as numbers recorded, the better
① enable AS during aggregation routing_ After set, enclose different AS detailed routes with AS numbers in curly brackets and put them into AS_ In the paths attribute. However, when comparing route selection, no matter how many AS numbers are contained in braces, they will be treated AS one
② when federating, AS is also required to be used for ring protection within the Federation, which will be expressed in parentheses. When comparing routes, the contents in parentheses will not be considered.
# by modifying as_ Path to change the routing due to the added as_ The path number may exist in the real network. AS_ The path attribute can also prevent the ring, which may lead to the addition of as_ Path cannot accept routing information. (therefore, the self added AS_PATH should preferably be the local as number, such as 2)
You can use routing policies to modify traffic
//Use prefix list to grab traffic
[r2]ip ip-prefix lxb permit 192.168.1.0 24
//Modify using routing policy
[r2]route-policy lxb permit node 10
Info: New Sequence of this List.
[r2-route-policy]if-match ip-prefix lxb
[r2-route-policy]apply as-path 2 23 2 24 additive
#Add AS_ Path additive refers to adding an AS number to the original AS number
#Add AS_ Path overwrite refers to adding the AS number after knowing the original AS number
[r2-route-policy]q
//Default venting
[r2]route-policy lxb permit node 20
Info: New Sequence of this List.
[r2-route-policy]q
//Import strategy in the exit direction of R2
[r2]bgp 2
[r2-bgp]peer 192.168.4.1 route-policy lxb export
//At this time, view the BGP routing table of R4
<r4>display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 4
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.3.1 0 100 0 1i
* i 192.168.2.1 0 100 0 2 23 2 24 1i
*>i 192.169.1.0 192.168.2.1 0 100 0 1i
* i 192.168.3.1 0 100 0 1i
5. Give priority to the optimal route with Origin attribute
IGP (network) > EGP > others (reissued)
# you can use the routing policy to modify the traffic
//Use prefix list to grab traffic
[r2]ip ip-prefix lxb permit 192.168.1.0 24
//Use the filter list for minor operations
[r2]route-policy lxb permit node 10
Info: New Sequence of this List.
[r2-route-policy]if-match ip-prefix lxb
#Modify ori to?
[r2-route-policy]apply origin incomplete
[r2-route-policy]q
//Apply prefix list
[r2]bgp 2
[r2-bgp]peer 192.168.4.1 route-policy lxb export
//At this time, go to R4 to check the routing
<r4>display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.3.1 0 100 0 1i
* i 192.168.2.1 0 100 0 1?
*>i 192.169.1.0 192.168.3.1 0 100 0 1i6. The route with the lowest MED value is preferred
MED multi outlet authentication attribute: the initial value is the overhead value inherited from IGP protocol / static route / direct route in the routing table. This attribute can affect how the traffic of other AS flows into their own AS
When announcing, BGP protocol can announce any route entry in the route table. By default, the overhead value of these routes is inherited into the MED attribute of BGP route.
If the BGP route announced locally is passed to the EBGP neighbor, it will carry the MED value to facilitate the equipment in the AS where the EBGP neighbor is located to select the route; If the BGP route learned locally through the IBGP neighbor, it will also be passed to its own EBGP neighbor, but the MED value will be set to 0 (because this measure is not generated locally), that is, all devices with EBGP neighbor relationship are recommended to declare the route of internal AS.
Note: when comparing MED, multiple identical route information must come from the same AS, and AS_ The latest value of the AS number in the path must be the same, otherwise there is no comparability (it needs to come from the latest same area)
At this time, if R12 does not turn on the MED value and R13 turns on the MED value, R11 knows that the cost of arriving at R14 is 5, and then passes it to R10 through the AS. At this time, R10 will send information to R12 because it is directly connected with R12, and the cost of arriving at R14 is 5, but this is obviously wrong. Therefore, when using the MED value, it is necessary to turn on all the MED values or!!!
7. Give priority to routes learned from EBGP peers (EBGP > iBGP)
The border router gives priority to the routing information learned from the EBGP peer rather than the IBGP peer
//Announce 192.169.1.0/24 on R1 and R4 at the same time
[r1-bgp]network 192.169.1.1
[r4-bgp]network 192.169.1.1
//Now go to R2 to view BGP routing information
#At this time, the priority is from
<r2>display bgp routing-table
BGP Local router ID is 2.2.2.2
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 192.168.1.0 12.0.0.1 0 0 1i
*>i 192.169.1.0 192.168.4.1 0 100 0 i
* 12.0.0.1 0 0 1i8. Priority to next_ The route with the smallest IGP metric of hop
Compare the cost value of the local route to the next one, which is independent of other parameters (cost of local arrival)
//Modify ospf value of R2
[r2-LoopBack0]ospf cost 10
//At this time, go to check the BGP routing
[r4-bgp]display bgp routing-table
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 4
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.1.0 192.168.3.1 0 100 0 1i
* i 192.168.2.1 0 100 0 1i
*>i 192.169.1.0 192.168.3.1 0 100 0 1i
* i 192.168.2.1 0 100 0 1i9. Priority Cluster_list short routes
At this time, AS3 will give priority to the route with fewer routers in the as Federation (as shown in the figure, AS64513 will be selected at this time)
10. Route with the smallest originator_ID
Since IBGP within the Federation still has a horizontal segmentation mechanism, RR (routing reflector) needs to be used at this time, and RR carries the originator ID. at this time, the routing information of the day when the originator ID is small will be selected (as shown in AS64512)
11. The route declared by the peer with the minimum ip address is preferred
If the number of routers in the Federation is the same and the RR is the same router, R4 will choose the smallest IBGP peer (in this case, who has the smallest IP address when comparing R3 and R6 neighbors)
Community attributes of BGP:
The community attribute of BGP can be similarly understood as routing tag. You can enter different community attributes into different BGP routes, and then announce the community attributes carried. You can grab traffic and formulate strategies according to the community attributes in the route.
The community attribute itself is actually a label used to distinguish routes - composed of 32-bit binary
Composition - two ways of writing: 1. Direct decimal representation; 2. Sixteen digits: Sixteen digits --- the first 16 digits are set AS the AS number of the AS where the route is located, and the last 16 digits are user-defined numbers.
Note that multiple community attributes can be entered in a route
There are several recognized community attributes defined in BGP
① 0X0000 00000 --- internet
All BGP routes belong to the "internet" community by default. If the route filter is used to match the route whose community attribute is internet, any BGP route will be matched
② 0XFFF FFF02 --- advertise
Routes with this community attribute will not be advertised to their peers
③ 0XFFF FFF01 --- no-export
Routes with this community attribute cannot notify their own EBGP neighbors (excluding federal EBGP neighbors)
④ 0XFFF FFF03 --- no-export-subconfed
Routes with this community attribute cannot notify their own EBGP neighbors (including federal EBGP neighbors)