Table of contents
The development history of BGP
Application of BGP in enterprises
The difference between distance vector protocol and path vector protocol
Publish routes through the network command
Publishing routes via republishing
1. Use the aggregate command to configure route summary
2. Use the aggregate detail-suppressed command to configure route summary
3. Use the aggregate detail-suppressed as-set command to configure route summary
4. Use the suppress-policy keyword in the aggregate command
BGP Route Reflector and Federation
Anti-loop in route reflection scenario
BGP basics
Whether it is RIP or OSPE that we have learned before, they all belong to the IGP protocol--Interior Gateway Protocol. The BGP protocol we are going to learn in this chapter belongs to the EGP protocol--Exterior Gateway Protocol. Protocol). Although both belong to the category of dynamic routing protocols, there are actually essential differences between the two. We need to slowly study this clearly through subsequent courses.
Of course, the first thing we need to understand is how the IGP protocol and the EGP protocol are divided.
This division is based on the fact that we have already mentioned it when we learned about dynamic routing protocols in the IA stage. That is to divide based on the scope of work.
1. Interior Gateway Protocol IGP. (Interior Gateway Protocol): Runs within an autonomous system. RIP, OSPE, and ISIS are common IGP protocols.
2. Exterior Gateway Protocol EGP (Exterior Gateway Protocol): runs between different autonomous systems. BGP. is currently the most commonly used EGP protocol.
The autonomous system mentioned here is the basis for the division of our scope. We call it As (Autonomous system) in English.
lGP routing protocols such as OSPF and IS-IS are widely used within organizational networks. As the network scale expands and the number of routes in the network continues to grow, lGP can no longer manage large-scale networks, and the concept of AS was born.
1. AS may be different institutions or companies, and they cannot completely trust each other. Using IlGP may risk exposing network information within the AS.
risk. ---autonomy
2. As the scale of the entire network expands, the number of routes further increases, the size of the routing table becomes larger, route convergence slows down, and device performance consumption increases. --- The scope is too large and the protocol cannot run through it
(The above two points are the main reasons for the need for AS division.)
AS refers to a collection of devices managed by the same organization and using a unified routing strategy.
Different ASs are distinguished by AS numbers, which are expressed in two ways: 16bit and 32bit. IANA is responsible for the distribution of AS numbers.
The 16-digit AS number we usually use has a value range of 1-65534 (0 and 65535 are reserved), and 64512-65534 are private AS numbers, which can be used by yourself. Therefore, the truly publicly available AS number is The value is 1-64511. The number is relatively small, so there is a 32-bit extended version of the AS number.
For this purpose, the BGP (Border Gateway Protocol, Border Gateway Protocol) protocol is specifically used between ASs for routing transmission. Compared with the traditional lGP protocol:
1. BGP is based on TCP. As long as a TCP connection can be established, BGP can be established.
2. Only routing information is transmitted and topology information within the AS is not exposed.
3. Triggered updates instead of periodic updates. (too big)
The development history of BGP
Here we only need to know that in the IPV4 environment, we mainly use the BGPM4 version ; and currently, there is also a BGPV4+ version on the market, namely MP-BGP (Muti-protocol -BGP), which can support multiple address families and can Applied in IPV6 environment . Later, we will also need to use it in MPLSVPN.
Application of BGP in enterprises
The content here is mainly related to actual enterprise applications. It can be explained in conjunction with subsequent IP mid-term comprehensive examination experiments, or it can be simply expanded here.
Here we can think about a question, that is, when our BGP completes routing sharing between ASs, what form does it need to be shared?
·Shared routing
·Shared topology
--The way BGP shares routing information between ASs should be to directly transmit routing information instead of sharing topology information, because on the one hand, the topology information is updated more frequently, and secondly, it will expose the topology of this AS, so it is more reasonable to transmit routing information. .
This approach is obviously similar to the distance vector protocol we came across before. However, BGP does not belong to the distance vector protocol, and we usually call it---" path failure protocol "
The difference between distance vector protocol and path vector protocol
Therefore, we found that there is an essential difference between BGP and the IlGP we learned before. The main task of the IGP protocol is to calculate and obtain the unknown network segment information within the AS, while BGP is mainly to calculate the routing information calculated by the IGP protocol. Carry out transportation and transmission without calculating routing.
Characteristics of BGP
Here are some different concerns and characteristics of BGP compared to IGP.
1. Controllability
(1) Because BGP needs to transmit a large amount of routing information, it requires strong controllability to make it easier to manage routing information and configure policies.
(2) To this end, BGP abandoned the cost value and designed many path attributes instead .
(3) Each BGP route carries a variety of path attributes. BGP can control path selection through these path attributes, unlike IS-IS and OSPE, which can only control path selection through Cost. Therefore, in terms of path selection, BGP It has rich operability and can choose the most appropriate path control method in different scenarios.
Origin——Origin attribute
Nexthop - next hop
2.Reliability
(1) BGP only triggers updates and does not update periodically (because the number of updated routes is too large). Therefore, reliability needs to be ensured.
(2) BGP uses TCP as the transport layer protocol, and the TCP port number is 179. BGP sessions between routers are established based on TCP connections.
(3) Two routers that establish a BGP session are peers (Peer) of each other, and BGP peers exchange BGP routing tables.
3.AS-BY-AS
BGP treats an AS as a whole
BGP peering relationship
1. Different from OSEE, IS-IS and other protocols, BGP sessions are established based on TCP. The two routers establishing a BGP peer relationship do not need to be directly connected.
2. By default, BGP uses the packet outgoing interface as the local interface for TCP connections.
3. There are two types of peer relationships in BGP: EBGP and IBGP:
(1)EBGP (External BGP): BGP peer relationship between BGP routers located in different autonomous systems. To establish an EBGP peer relationship between two routers, two conditions must be met:
The two routers belong to different ASs (that is, they have different AS numbers).
When configuring EBGP, the peer IP address specified in the Peer command must be reachable and the TCP connection must be established correctly.
When deploying an EBGP peer relationship, the IP address of the directly connected interface is usually used as the source address. If you use a loopback interface to establish an EBGP peer relationship, you should pay attention to the EBGP multi-hop issue. --- The TTL value in the sent packet will be set to 1.
(2)lBGP (Internal BGP): B.GP adjacency between BGP routers located in the same autonomous system.
When deploying IBGP peer relationships, it is recommended to use the loopback address as the update source address. The Loopback interface is very stable and can ensure reliability with the help of IGP and redundant topology within the AS.
Generally speaking, within the AS, the network has a certain degree of redundancy. If a direct interface is used to establish an IBGP neighbor relationship between R1 and R3, once the interface or direct link fails, the BGP session will be interrupted. However, in fact, due to the existence of redundant links, R1 and R3 The connectivity between them is actually not DOWN (they can still reach each other through R4)
BGP packet
There are 5 packet types in BGP. (The first four are commonly used)
1.open message
The open message is the first message sent after the TCP connection is established and is used to establish the connection relationship between BGP peers.
The parameters that need to be compared and negotiated are as follows:
(1) AS number---BGP open messages will carry the local AS number. By comparing the AS numbers on both ends, you can determine whether the opposite end is in the same AS as the local end. In addition, if the AS number of the other party is different from the AS number written when establishing a local neighbor, the neighbor relationship will not be established.
(2) RID---it can be called BGPldentifier (BGP identifier) here. It is the same as RID in OSPE. It is also composed of 32-bit binary and is written in the format of P address. This value will also be carried in the data packet, and the two sides will be compared to see if the values are the same. If they are the same, it means there is a conflict, which will cause neighbor establishment to fail.
(3) BGP can also perform authentication. If the authentication password is different, neighbor establishment will also fail.
(4) The open message also carries Hold Time--- the keep-alive time . When establishing a peer relationship, both ends must negotiate the Hold Time and keep it consistent. If no Keepalive message or Update message is received from the peer within this time, the BGP connection is considered to be interrupted. --- The default time is 180S . If the keep-alive time of both parties is inconsistent, the smaller one will be implemented.
2.Keepalive message
Keepalive messages are mainly used to keep alive periodically.
(1) The default period keep-alive time is 1/3 of the keep-alive time, and the default is 60 seconds.
(2) This message will also temporarily serve as a confirmation message when the open message negotiates parameters - to confirm whether the parameters in the open message are approved.
3.Update message
Update messages are used to transmit routing information between peers and can be used to publish and revoke routes.
(1) An Update message can advertise multiple routes with the same path attributes. These routes are stored in NLRl (Network LayerReachable Information, network layer reachable information). At the same time, Update can also carry multiple unreachable routes to notify the other party to withdraw the route. These are stored in the Withdrawn Routes field.
4.Notification message
The Notification message is when BGP detects an error state (which may occur when or after the peer relationship is established), it will send a Notification message to the peer to inform the peer of the cause of the error. The BGP connection will be terminated immediately thereafter.
5.Route-refresh message
The Route-refresh message is used to request the peer to resend the routing information of the specified address family. Generally, after the local end modifies the relevant routing policy, the peer resends the Update message, and the local end executes the new routing policy to recalculate BGP routes.
BGP state machine
The difference between the BGP state machine and the QSPE state machine is that the BGP state machine only describes the state changes in the peer relationship establishment process. --Mainly because BGP can separate the neighbor establishment process and the BGP route sending and receiving process.
There are a total of six state machines in BGP.
IDLE---idle state---all devices will first enter the idle state after starting the BGP process.
When the neighbor relationship is manually specified, a check step will be entered. It is necessary to check whether the manually specified IP address is reachable in the local routing table. Only if it is reachable, the TCP session can be established normally. If it is not reachable, the neighbor relationship The establishment failed and stayed in IDLE state.
If the check is successful, it will enter the Connect state --- connection state. ----The status of establishing TCP session connection.
(Note that the peer relationship designation is bidirectional. Both parties will initiate a TCP session connection request. Eventually, two bidirectional TCP session channels will be established. Only one needs to be retained. Therefore, in the open message sent later , the RID parameters will be compared, the TCP session connection initiated by the device with a large RID will be retained, and the connection initiated by the device with a small RID will be closed.)
If the TCP session connection fails, it will enter the Active state. --Try to re-establish the TCP session connection (after multiple failures, it will time out and fall back to the idle state. If successful, it will enter the opensent state.)
If the TCP session connection is successful, it will directly enter the opensent state---send an open message to negotiate parameters and establish a peer relationship. At the same time, it will also receive the open message from the other party, and will check the parameters in it. If the parameters are OK, a keeplive message will be sent for confirmation. It will enter the openconfirm state. ---Wait for the other party to send a keeplive message and confirm the local parameters.
If the keeplive message sent by the other party is received, it means that the parameter negotiation in the open message from both parties is completed, the neighbor relationship is successfully established, and the neighbor relationship will enter the final state---the Established state.
The following is a process diagram of the BGP state machine changes.
BGP working process
Based on our previous understanding of the basics of BGP, we summarize the working process of BGP below.
1. Implement P reachability based on IGP
2. Specify the neighbor relationship, unicast transmission between neighbors, and establish a TCP session channel through a three-way handshake. All communications after BGP will be transmitted based on TCP session channels. Including providing transmission reliability.
3. Use OPEN messages and Keeplive messages to establish neighbor relationships. OPEN packets are used to carry parameters used for neighbor establishment, and keeplive packets are used to confirm parameters. Finally, the establishment of the peer relationship is completed. Generate neighbor table.
4. Use update messages to share routing information. The information will carry the target network number, mask and path attributes; then the routing information sent and collected will be recorded in a table---BGP table.
5. Afterwards, load the optimal routing information in the BGP table (the result of routing attribute selection) into the routing table.
6. After the convergence is completed, keeplive messages will be used for periodic keep-alive. The default keep-alive time is 180S and the sending period is 60S.
7. If an error occurs, a notification message will be used to alert.
8. If a structural mutation occurs, an update report will be used to trigger the update.
BGP routing black hole
The following scenario illustrates the problem.
Since the BGP protocol can establish neighbors indirectly, the BGP protocol may cross devices that are not running the BGP protocol. As a result, after the GP route is transmitted, the control plane shows that it is reachable, but on the data layer, the traffic flows through the devices that are not running the BGP protocol. When, it cannot pass through, forming a routing black hole.
solution
1. Let the devices that do not run the BGP protocol run the BGP protocol---problem. If all devices need to run BGP, they will carry a large amount of routing information, resulting in increased equipment costs.
2. In the IGP protocol, re-publish the routing information of the BGP protocol
3，MPLS
BGP loop problem
BGP adopts a method to solve routing loop problems, which is also called split horizon.
BGP split horizon is divided into two types, one is EBGP split horizon specifically for EBGP peers, and the other is lBGP split horizon specifically for lBGP peers .
EBGP split horizon
EBGP split horizon---a solution to the loop problem that may occur between EBGP peers
The so-called EBGP split horizon is mainly used to prevent loops caused by routing backhaul in the EBGP environment. The BGP protocol records the AS numbers passed by in the routing entries and generates an attribute --- AS_PATH (records the AS numbers of all passed ASs). AS number), then, if there is a local AS number in the AS_PATH attribute in the received routing entry, the routing information will be refused to be learned to prevent route backhauling and the formation of a loop. --- The AS_PATH attribute can also be used for routing, which can reflect the number of ASs passed through.
IBGP split horizon
IBGP Split Horizon---A solution to the loop problem that may occur between IBGP peers
AS64512 will be passed when R1 is passed.
Note: Because the AS-BY-AS feature of EGP requires it to treat an AS as a whole, by default, the path attributes of routing information transmitted within the AS will not change. That is to say, when BGP routes are transmitted within an AS, you cannot rely on the anti-loop capability provided by AS_Path. Then routing loops may occur at this time. IBGP split horizon rules are used to solve this problem.
In the network shown in the figure above, R1 establishes EBGP peer relationships with R2 and R3 respectively, while the three routers in AS 64513 establish IBGP peer relationships in pairs. Now R1 publishes the 10.1.1.0/24 route in AS64512 to BGP. R1 advertises this route to its EBGP peer R2 through BGP. Of course, we are not worried that a loop will occur when this route is transmitted between AS64512 and AS 64513, because AS_Path can prevent loops. But what about routing loop prevention within the AS? When R2 receives the 10.1.1.0/24 route advertised by R1, it advertises this route to its IBGP peers R3 and R4, and R4 advertises the route to lGP. Peer R3, and R3 will advertise the route to R2, which is very likely to cause a routing loop.
Therefore, BGP stipulates that when a router learns a BGP route from an IBGP peer, it will no longer advertise this route to any G peer. This is the IBGP split horizon rule. In this example, the routes learned by R4 from IBGP peer R2 will no longer be advertised to R3 because R3 is also its BGP peer. Similarly, the BGP routes learned by R3 from R2 cannot be advertised to R4.
Therefore, BGP stipulates that when a router learns a BGP route from an LBGP peer, it will no longer advertise this route to any LBGP peer. This is the IBGP split horizon rule. In this example, the routes learned by R4 from IBGP peer R2 will no longer be advertised to R3 because R3 is also its IBGP peer. Similarly, the BGP routes learned by R3 from R2 cannot be advertised to R4.
The IBGP split horizon rule is a very important design, which can largely avoid routing loop problems that may be caused when BGP routes are transmitted within an AS. However, in some scenarios, it will also bring some new problems.
The figure above shows an example in this network where R4 adds an LBGP peer R5. Due to the limitations of the IBGP split horizon rules, R4 cannot advertise the 10.1.1.0/24 route learned from the IBGP peer R2 to another IBGP peer R5. Therefore, this will cause R5 to be unable to learn the route destined for AS64512. routing. In fact, we cannot give up the BGP split horizon rule because it is indeed very important, but in many scenarios we must solve the problem of lIBGP route delivery.
solution:
There are many solutions to this problem. For example, a fully interconnected model of LBGP peer relationships can be established within the AS. Taking AS 64513 as an example, IBGP peer relationships need to be established between all BGP routers in the AS. ---Of course, doing so will increase resource consumption and reduce network scalability.
Therefore, we will also study two technologies in BGP later - route reflector and federation . They are all designed to solve the communication obstacles caused by IBGP split horizon.
Basic configuration of BGP
The basic configuration of BGP can be divided into two parts: establishing peer relationships and publishing routes. (As mentioned earlier, BGP can realize neighbor relationship establishment and route publishing separately)
BGP peer establishment
[R1] bgp 100
[R1-bgp] peer 12.1.1.2 as-number 200
[R2] bgp 200
[R2-bgp] peer 12.1.1.1 as-number 100
or established via loopback
[R1]ip route-static 2.2.2.0 24 12.1.1.2 //Enable routing first
[R1]ip route-static 1.1.1.0 24 12.1.1.1
[R1] bgp 100
[R1-bgp] router-id 1.1.1.1
[R1-bgp] peer 2.2.2.2 as-number 200
[R1-bgp]peer 2.2.2.2 connect-interface LoopBack0
[R1-bgp]2.2.2.2 ebgp-max-hop 2 //TTL
[R2] bgp 200
[R2-bgp] router-id 2.2.2.2
[R2-bgp] peer 1.1.1.1 as-number 100
[R2-bgp]peer 1.1.1.1 connect-interface LoopBack0
[R2-bgp]1.1.1.1 ebgp-max-hop 2
BGP route announcement
Here we build the following topology to complete the previous demonstration of neighbor establishment and route publishing.
Route publishing---For BGP, as long as the routing information exists in the routing table, it can be published
Publish routes through the network command
[R1l-bgp]network 1.1.1.024----Followed by the target network number and mask information
After publishing the route, we will use the update package to pass the routing information out. Of course, we will also record the published routing information in the BGP routing table. As we mentioned earlier, the BGP routing table is a table that records all routing information published and collected by BGP.
Then we can take a look at the BGP table of R1 first . ---We can view it through the command: [r1]display bgp routing-table.
Currently, there is only one route information in the table, because our R1 itself only publishes a route for the 1.0 network segment, and other routers do not publish routing information.
network --- Target network segment and mask information
NextHop ---Whoever sends the routing information will write the next hop; if it is originated by yourself, write 0.0.0.0O as the next hop--- including the next hop and the following are the paths designed by BGP Attributes
Status code---the symbol at the front of the routing entry. Different status codes represent different states of the routing information.
*-represents available . --After receiving the routing entry, all devices will first query the local routing table based on the parameters in the next hop attribute to check the reachability of the address. If it is reachable in the local routing table, it means that the routing information is available; if it is not reachable, the routing information will be unavailable—if the routing entry is unavailable, it will not participate in the selection of routing information.
>--represents preference . ----When multiple routing information reaching the same network segment is received and all are available, the best one will be selected based on the attributes for addition to the table and transmission.
i --The status code is l, which means that the routing information was learned from the IBGP peer.
Because we published this route ourselves, it proves that this route itself is in our routing table, so availability is naturally guaranteed.
Moreover, currently we only have routing information for this 1.0 network segment, so we will definitely let him give priority. Then this route can be passed and added to the table.
After that, we can look at the routing table of R2 and find the routing information added to the table as follows.
1.1.1.0/24 EBGP 255 0 D 12.0.0.1 GigabitEthernet0/0/0 - The next hop field will directly use the address in the next hop attribute. We set the priority of BGP routing information to 255.
Of course, the routing information is also available and excellent on R2, so it can be passed to R2's neighbor, R4. (Check the BGP table of R4)
R4 cannot use R1, so it cannot give R5.
Solution:
[R2]bgp 200
[R2-bgp]peer 4.4.4.4 Inext-hop-local //Make the next hop the local address
If both have bgp, r2 and r4 write peer 3.3.3.3 Inext-hop-local to r3 respectively //Make the next hop the local address and write one to each other.
Publishing routes via republishing
The Network announcement method is the most basic method of advertising routes in the BGP protocol. Of course, this method also has certain disadvantages, that is, when the amount of routes that need to be advertised is relatively large, using this method will be very inefficient.
Therefore, we have another way to advertise routes, which is batch advertising. That's a re-release. We can directly redistribute routes generated by other protocols in BGP to achieve the purpose of batch advertisement.
[r2-bgp]import-route ospf 1 - re-release
After the execution here is completed, you can observe the attributes of the last column in the routing information--- ogn---origin code. There are three types of origin codes.
I---represents that this routing information originates from the AS internal network advertisement.
e --- stands for EGP protocol.
?---In addition to the above two methods, the routing information obtained by other methods is?
BGP route aggregation
In addition to the above two methods for route publishing in BGP, routes can also be published through route aggregation, which can be regarded as the third method for BGP to publish routes. ---- The so-called route aggregation is actually the route summary that I came across before, but it has a different name in BGP.
BGP aggregation is divided into automatic aggregation and manual aggregation. We will explain them respectively.
Automatic aggregation
1. Disadvantages of automatic aggregation:
(1) The automatic aggregation function can only take effect for republished routing entries.
(2) Automatic aggregation can only summarize detailed routes directly to the main category. --- This will create a huge routing black hole. Therefore, the automatic summary function is turned off by default on Huawei devices.
2. Configuration commands
[r1-bgp]summary automatic --- command to enable automatic aggregation
Info: Automatic summarization is valid only for the routes imported through the import-route command. --- An information prompt will appear after the command is executed, indicating that it can only take effect for republished route entries .
After the summary is completed, we find in the BGP table that there will be an additional routing information for the summary network segment, and the next hop is 127.0.0.1.
R2 table, 172.16 route written on R2
After summarization, the routing information will also be published in BGP, and the next hop will point to the local loopback address. Finally, the table will be added, and the outgoing interface will recurse to the empty interface. The effect is that an empty interface route to the summary will be automatically generated on the black hole router to prevent loops.
The two detailed routes above are no longer available, and the status code has an extra s. This s represents suppressed --- suppressed -- the suppressed routing information will no longer be added to the table and transmitted.
Manual aggregation
Because automatic aggregation has the above two shortcomings, if you want to accurately summarize routing information, you need to use manual aggregation.
The command used for manual aggregation is --- aggregate
In the above figure, the router establishes the EBGP peer relationship as shown in the figure. R3 published the 172.16.1.0/24 and 172.16.2.0/24 routes to BGP (of course, in actual situations, there may be more subnet routes published by R3. For simplicity, only two subnets are taken as representatives here). R1 and R2 can learn these two routes through BGP. We can then perform manual aggregation in this scenario.
1. Use the aggregate command to configure route summary
First, generate summary routes for the two subnet routes 172.16.1.0/24 and 172.16.2.0/24 on R1. The key configuration of R1 is as follows:
[R1]bgp 100
[R1-bgp]aggregate 172.16.0.0 16
Using the aggregate command, users can flexibly specify the destination network mask length of summary routes and are not restricted by network address categories. For the sake of simplicity here, we directly configure the summary route as 172.16.0.0/16.
After completing the above configuration, if there is a subnet route under the network 172.16.0.0/16 in R1's BGP routing table, it will generate a BGP summary route 172.16.0.0/16 and advertise this summary route to all BGP Peers include R3 and R2, as shown in Figure 7-34. There are actually two problems here. The first problem is that after configuring the aggregate 172.16.0.016 command, although R1 does generate a summary route, the detailed routes under the summary route will still be advertised , which means that R2 will learn 172.16. 1.0/24, 172.16.2.0/24 routes and summary route 172.16.0.0/16, so the actual route summary configuration done on R1 is of little significance. The number of route prefixes advertised by R1 has not been reduced. The routes of R2 The table size has not been reduced either. Another problem is that the summary route generated by R1 loses the path information of the detailed route (especially the AS_Path attribute), so they will be advertised to R3 and received by it, and loaded into the routing table, thus generating Eliminates the risk of routing loops.
(So where to configure and where to summarize)
2. Use the aggregate detail-suppressed command to configure route summary
Now, we modify the configuration on R1 and modify the aggregate command to:
[R1]bgp 100
[R1-bgplaggregate 172.16.0.0 16 detail-suppressed
Using the aggregate 172.16.0.016 command, R1 will generate the summary route 172.16.0.0/16 and advertise both summary and detailed routes to R2. If the detail-suppressed keyword is added to this command, R1 will only advertise the summary route and suppress Detailed routing, as shown in the figure above. After completing the above configuration, the BGP routing table of R1 is as follows:
3. Use the aggregate detail-suppressed as-set command to configure route summary
When using the aggregate command to configure BGP route summary, if you add the as-set keyword, the generated summary route will inherit the path attribute of the detailed route r, among which the inheritance of the AS_Path attribute is the most critical. Now modify the configuration of R1 as follows:
[R1]bgp 100
[R1-bgp]aggrogate 172.16.0.0 16 deuail-suppressed as-set
No as-set added
add
After completing the above configuration, B1 will suppress the detailed routes 172.16.1.0/24 and 172.16.2.0/24, and only advertise the summary route 172.16.0.0/16 (this is due to the detail-suppresse keyword), and because the as is used in the command -set keyword, so the summary route will inherit the path attributes of the two detailed routes 172.16.1.0/24 and 172.16.10.0/24. We focus on the inheritance of the AS_Path attribute. First check B2’s BGP routing table:
4. Use the suppress-policy keyword in the aggregate command
When using the aggregate command to configure route summary, you can also use the suppress-policy keyword, which is used to advertise summary routes and selected detailed routes (in other words, selectively suppress detailed routes). Taking the above figure as an example, if R1 is required to advertise the summary route 172.16.0.0/16 and other detailed routes except 172.16.1.0/24 to R2, this requirement can be easily achieved using suppress-policy. The configuration of R1 is as follows:
In the above configuration, we first define an I2 prefix list named no-subnet-1, and use this I2 prefix list to allow routing 172.16.1.0/24. Then a Route-Policy named hcnp1 is created, and the defined I prefix list no-subnet-1 is called in node 10 of this Route-Policy. Finally, in the BGP configuration view, use the aggregate 172.16.0.016 suppress-policy hcnp1 command to advertise the summary route 172.16.0.0/16 and the selected detailed routes (suppress the 172.16.1.0/24 route and allow other detailed routes)
BGP Route Reflector and Federation
Route reflectors and federation are two solutions specifically designed for lBGP split horizon. Let's look at these two technologies in turn. route reflector
The role of route reflector
1. After the route reflector is introduced, there are two roles:
(1) RR (Route Reflector): Route Reflector
(2) Client: RR The client RR will reflect the learned routes, so that IBGP routes can be propagated within the AS without establishing an IBGP full interconnection.
2. When specifying a BGP router as the RR, you also need to specify its Client. As for the Client itself, no configuration is required. It does not know that RR exists in the network.
Route reflection rules
When RR receives BGP routes:
1. If a route reflector learns an IBGP route from its own non-customer peers, it will reflect the route to all customers
2. If the route reflector learns an lBGP route from its own client, it will reflect the route to all non-clients and all other clients except this client.
3. If the route is learned from the EBGP peer, it is sent to all customers and non-customer IBGP peers.
Note the difference between "reflection" and "send" here. "Sending" refers to the BGP route delivery behavior under traditional circumstances (equivalent to the scenario where RR does not exist), while "reflection" refers to the route delivery action performed by RR being reflected when following route reflection rules. The route will have special path attributes inserted by RR.
Anti-loop in route reflection scenario
1. The setting of RR invalidates the IBGP split horizon principle, which may cause loops. For this reason, RR will add two special path attributes to BGP routes to avoid loops:
（1）originator_ID
（2）Cluster List
originator_ID
1. When RR reflects a BGP route, it will add Originator_ID to the reflected route. Its value is the BGP Router ID that advertises the route in the local AS.
2. If there are multiple RRs in the AS, the Originator_ID attribute is created by the first RR and will not be changed by subsequent RRs (if any).
3. When a BGP router receives a BGP route carrying the originator_ID attribute, and the value of the Originator_ID attribute is the same as its own Router ID, it will ignore updates about the route.
Cluster List
1. The route reflection cluster includes the reflector RR and its client. Multiple route reflection clusters are allowed to exist in an AS (as shown in the figure above).
2. Each cluster has a unique cluster ID (Cluster_ID, which is the BGP Router ID of RR by default).
3. When a route is reflected by the reflector, the Cluster_ID of the RR (cluster) will be added to the Cluster_list attribute of the route.
4. When RR receives a BGP route carrying the Cluster_list attribute, and the attribute value contains the Cluster_ID of the cluster, RRi exists for the route.
in a loop, so updates about that route will be ignored.
Reflector application
R1 advertises the 10.0.1.0/24 route to BGP. R2 will learn the route from R1 and advertise it to R3. However, the IBGP route learned by R3 from R2 cannot be advertised anymore due to the existence of the split horizon rule. For R4 and R5, you can set R to RR, R4, and R5 as their clients, so that R4 and R5 can learn the BGP route 10.0.1.0/24 normally.
Configuration method
Configure the route reflector and its clients
[R3-bgp]peer 2.2.2.2 reflect-client //Let R2 be the client and R3 be the reflector
federal
Deploying a fully interconnected IBGP peer relationship within an AS can indeed solve the problem of IBGP route delivery, but this is a low-scalability approach and will put a heavy burden on devices in large networks. In the previous chapters, everyone has mastered the method of using route reflectors to solve this problem. Next, we will study another solution, which is federation.
Confederation is also called an alliance. The general idea is to create several small ASs (similar to the concept of sub-ASs) within a large AS, so that a special EBGP peer relationship appears within the AS to solve the problem. The problem of IBGP route delivery within the AS.
In the above figure, AS 3456 does not realize full interconnection of IBGP peers, which will cause routing transmission problems in the AS. Here are a few examples:
1. R3 will advertise the BGP route it learned from R1 to R4, but the latter cannot advertise the route to R5, so R2, R5 and R6 cannot learn the route.
2. The BGP route published by R3 will be advertised to R1 and R4, but R4 cannot advertise the route to R5, so R2, R5 and R6 cannot learn the route.
3. The BGP route published by R4 will be advertised to R3 and R5, but R5 cannot advertise the route to R6, so R6 cannot learn the route.
The above problems can be solved by using BGP federation. As shown in the figure below, we created two "small ASs" within AS 3456 - AS64512 and AS64513. This is a bit like a large city divided into two administrative districts.
That is to say, federated ASs only abide by the routing delivery principle between EBGP, but cannot modify route attributes like EBGP neighbors. It is a unique existence.
So this can be regarded as breaking the IBGP split horizon. How to prevent loops? In this way, you can actually use the EBGP split horizon set, and you can also add the federation's AS number to AS_PATH. However, the federation's AS number Use parentheses to distinguish.
federation configuration
[R2]bfp 64512 --Start the trumpet
[R2-bgp]router-id 1.1.1.1
[R2-bgp]confederation id 200 --- Declare your own large number
[R2-bgp]peer 1.1.1.1 as-number 100
[R2-bgp]peer 1.1.1.1 connect-interface LoopBack0
[R2-bgp]peer 1.1.1.1 ebgp-max-hop 2 ----These are still processed normally
[R2]bfp 64512 --Start the trumpet
[R2-bgp]router-id 2.2.2.2
[R2-bgp]confederation id 200 --- Declare your own large number
[R2-bgp]peer 3.3.3.3 as-number 64512 ----Declare the small AS of R3
[R2-bgp]peer 3.3.3.3 connect-interface LoopBack0
[R2-bgp]peer 3.3.3.3 ebgp-max-hop 2 ----These are still processed normally
[R3]bgp 64512
[R3-bgp]route-id 3.3.3.3
[R3-bgp]peer 2.2.2.2 as-number 64512 ----Declare the small AS of R2
[R3-bgp]peer 2.2.2.2 connect-interface LoopBack 0
[R3-bgp]confederation per-as 64513 --Be sure to specify the AS number of your federation member first. This can be declared on the routers on R3 and RA that need member ASs to establish neighbors.
[R3-bgp]peer 4.4.4.4 as 64513
[R3-bgp]peer 4.4.4.4 connect-interface LoopBack0
[R3-bgp]peer 4.4.4.4 ebgp-max-hop 2----Needs modification when using loopback to establish EBGP neighbors, including EBGP within the federation.
1) 所有配置全部基于小as号进行
[r3]bgp 64512
[r3-bgp]router-id 3.3.3.3
[r3-bgp]peer 2.2.2.2 as-number 64512
[r3-bgp]peer 2.2.2.2 connect-interface LoopBack 0
[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
2）联邦内所有运行BGP协议的设备均声明自己所在的大AS号
[r2]bgp 64512
[r2-bgp]confederation id 2
3）小AS间互指peer；在联邦内的ebgp邻居关系间的两台设备，互相定义对端的小AS号；
[r4-bgp]confederation peer-as 64512
切记：华为设备，必须先定义联邦的id，和互相小AS号后再配置邻居关系建立的命令；
在实际的工程案例中，联邦和反射器是同时被使用，降低配置量；BGP attribute control and routing principles
BGP optimization principles: (The following 11 BGP routing principles summarized by Huawei need to be explained one by one and the path attributes involved.)
When there are multiple routes to the same destination network segment, BGP performs route optimization in the following order:
Discard routes whose next hop is unreachable.
1. The route with the largest Preferred-Value attribute is preferred.
2. The route with the largest Local..Preference attribute value is preferred.
3. Locally originated BGP routes are superior to routes learned from other peers. The priority of locally originated routes is: manual aggregation > automatic aggregation > networkoimport learned from peers.
4．The route with the shortest AS.Path attribute value is preferred.
5. The route with the best Origin attribute is preferred. The Origin attribute values in order of priority from high to low are: IGP, EGP and Incomplete.
6. Prefer the route with the smallest MED attribute value.
7. Prefer routes learned from EBGP peers (EBGP routes have higher priority than IBGP routes).
8. The route with the smallest IGP metric to Next_Hop is preferred.
9. The shortest route in Cluster_List is preferred. indivual
10. Prefer the route advertised by the device with the smallest Router ID (Orginator ID).
11. Prefer the route advertised by the peer with the smallest IP address.
1. BGP route selection: Comparison premise is that multiple BGP routes have the same goal, and all can be optimized (next hop reachable, synchronous shutdown), and have the same priority (administrative distance)
1. Prefer the route with the highest Preference_Value (private attribute, only valid locally).
Not passing the highest authority attribute can interfere with EBGP/IBGP routing selection.
2. Prefer the route with the highest local priority (Local_Preference).
IBGP neighbor relationships can only be passed between, and most often interfere with the routing of IBGP relationships.
3. Prefer manual aggregation>automatic aggregation>network>import>learned from peers.
4. Prefer routes with short AS_Path.
EBGP/IBGP relationships can be interfered with, but can only be modified between EBGP neighbors;
5. Origin type IGP>EGP>Incomplete.
Is the origin attribute i better than e? ; Can be modified at any interface at the control level;
6. For routes from the same AS, a smaller MED value is preferred.
The default is 0. When announcing or re-announced (automatic summary is turned off) routes, the local cost to reach the target is carried.
Attributes most commonly used to interfere with EBGP route selection
7. Prefer routes learned from EBGP (EBGP>IBGP).
8. Prefer the route with the smallest metric of the IGP within the AS.
9. Prefer the shortest route in Cluster_List.
10. Prefer the route with the smallest Organizer_ID.
11. Prefer the route published by the router with the smallest Router_ID.
12. Prefer routes learned by neighbors with smaller IP addresses.
2. Properties:
Both Huawei and cisco have 6 basic attributes. The first one is a private attribute.
The default value of the propagation range is big or small.
1. Preference_Value does not propagate 0 large
Private attributes of Huawei devices
Global operations:
[r3-bgp]pe 2.2.2.2 preferred-value 1 Modify the preference value of all routes learned locally from neighbor 2.2.2.2 to 1;
Load sharing: When accessing different target network segments, let the traffic enter different links for communication; utilize all links instead of only using the only link for communication;
Use prefix to grab the network segment whose attributes need to be modified
[r3]ip ip-prefix w permit 1.1.1.0 24
Customize the strategy to make modifications. Be sure to pay attention to whether an empty table is needed to allow other routes to pass through.
[r3]route-policy w permit node 10
[r3-route-policy]if-match ip-prefix w
[r3-route-policy]apply preferred-value 1
[r3-route-policy]q
[r3]route-policy w permit node 20
[r3-route-policy]q
Then call it for a neighbor in the protocol
[r3]bgp 2
[r3-bgp]peer 2.2.2.2 route-policy w import Because this attribute is private and not passed, when called, it can only be called in the control plane to affect the local BGP generation;
The default value of propagation range is large or small.
2. Local priority IBGP neighbor relationship among the top 100
The first public attribute,
It is also most commonly used to interfere with IBGP routing selection.
most commonly used properties
Global modification;
[r4-bgp]default local-preference 101
All local routing entries transmitted to IBGP, with the local priority modified to 101;
Using local priorities for load sharing
[r2]ip ip-prefix p permit 1.1.1.0 24
[r2]route-policy p permit node 10
[r2-route-policy]if-match ip-prefix p
[r2-route-policy]apply local-preference 101
[r2-route-policy]q
[r2]route-policy p permit node 20
[r2-route-policy]q
[r2]bgp 2
[r2-bgp]pe 3.3.3.3 route-policy p export can be called in the outbound or inbound direction of the control plane, but it must be an IBGP neighbor relationship;
3. as-path prefers paths that pass through a smaller number of ASs; this attribute is automatically added between EBGP neighbor relationships;
[r4]ip ip-prefix as permit 1.1.1.0 24
[r4]route-policy as permit node 10
[r4-route-policy]if-match ip-prefix as
[r4-route-policy]apply as-path 3 4 5 additive
[r4-route-policy]q
[r4]route-policy as permit node 20
[r4-route-policy]q
[r4]bgp 2
[r4-bgp]pe 14.1.1.1 route-policy as import Note: It can be called in the incoming or outgoing direction of the control plane, but it can only operate between ebgp neighbors; it can interfere with ebgp and ibgp relationship routing;
Outbound call x 3 4 5 x is the actual AS number passed; the front-end number is the latest AS number passed;
Incoming calls 3 4 5 x
Remember: the as-path attribute is used for EBGP split horizon. If the artificially added AS number actually exists in the network backend, these routes will not be able to enter these ASs. Solution: repeatedly add the AS numbers that have been passed through;
4. Origin attribute How the entry is generated
network advertises any route i in the local routing table
import Republish local routes learned through other protocols into the BGP protocol?
egp redistributes the routes learned by the early ebg protocol into the BGP protocol e
This attribute can be modified on any interface through which the entire control plane traffic passes;
[r4]ip ip-prefix o permit 1.1.1.0 24
[r4]route-policy o permit node 10
[r4-route-policy]if-match ip-prefix o
[r4-route-policy]apply origin egp 2 The AS configured here is the AS number of the peer neighbor
[r4]route-policy o permit node 20
[r4-route-policy]q
[r4]bgp 2
[r4-bgp]peer 3.3.3.3 route-policy o export
5. The MED multi-exit identification attribute BGP protocol does not have cost by default; MED is an artificial use of the router's preferred path rules - first compare the administrative distance (Huawei is the priority), and then compare the metric value (Huawei is the cost)
The BGP protocol carries the local cost value to reach the target under certain conditions; after the local announces (republishes) the route in its own routing table, it passes it to the local ebgp neighbor, which will carry the cost value; for other AS devices to learn from For routes delivered by the same AS, the path with the smallest MED is preferred;
Administrators can manually modify MDE during the control plane routing process; it is most commonly used to interfere with ebgp routing selection;
Often used by AS1 to interfere with AS2’s routing of AS1;
[r1]ip ip-prefix with permit 1.1.1.0 24
[r1]route-policy med permit node 10
[r1-route-policy]if-match ip-prefix med
[r1-route-policy]apply cost 10
[r1-route-policy]q
r1]route-policy med permit node 20
[r1-route-policy]q
[r1]bgp 1
[r1-bgp]pe 14.1.1.2 route-policy med export
Since in actual projects, administrators can only configure it in one AS, they cannot judge the routing results by checking the BGP table. This can be solved by extending ping.
[r1]ping -r -a 1.1.1.1 3.3.3.3
Discard routes whose next hop is unreachable
3. BGP’s community attributes – BGP’s extended attributes. By default, most manufacturers’ products do not carry community attributes in the BGP protocol.
Example: Community attributes that control the scope of communication
[r1]route-policy com permit node 10
[r1-route-policy]apply community no-advertise Modify attributes for all traffic
[r1]bgp 1
[r1-bgp]peer 12.1.1.2 route-policy com export
By default, Huawei devices do not transmit community attributes. Therefore, when using community attributes, transitivity must be defined.
[r1-bgp]peer 12.1.1.2 advertise-community hop-by-hop behavior, each device needs to enable transitivity
no-advertise If the community attribute exists in the received entries, the route will no longer be passed (neither will be passed)
no-export If the received entry has this community attribute, it will not be passed to the next AS.
no-export-subconfed If the received entry has this community attribute, it will not be passed to the next small AS.
If there is no small AS in the network and only a large AS exists, no-export and no-export-subconfed have the same effect.
Note: At present, most manufacturers do not pass community attributes when transmitting BG protection routing information by default. Therefore, if you need to transmit community attributes, you need to enable it through a command.
[R2-bgp]peer 12.1.1.1 advertise-community
[R1-bgp]peer 12.1.1.2 advertise-community