Solutions to the problem of data packet forwarding In the previous two articles, we solved two problems: the routing conflicts in the local PE and the conflicts in the propagation process of the routing network, the problem of the schematic diagram RD format has been solved. However, when data is forwarded, if there are 10.0.0.0/24 routes in the two local VRFs of the receiving PE, when it receives a packet with a destination address of 10.0.0.1, how does it know to send this packet? Which VRF is the CE connected to? Certainly need to add some information in the forwarded message. Of course, this information can be taken care of by RD. It is only necessary to transform the processing flow of MPLS VPN so that the data can also be carried when carrying RD. But the RD has a total of 64 bits, which is too large, which will reduce the forwarding efficiency. To ensure efficiency, only a short, fixed-length mark is needed. Since the public network tunnel is already provided by MPLS, and MPLS supports nesting of multiple layers of labels, this label can be defined as the format of MPLS labels. Who will assign this label? The routing is private VPN, and LDP knows nothing about it. This task of assigning VPN private network routing labels can only be accomplished by extended BGP. Similar to the LDP protocol, label distribution is done before data forwarding occurs. The difference is that MP-IBGP assigns labels simultaneously with route exchange. MP_REACH_NLRI Address-family VPN-IPv4 Address family   Next-hop It is the PE router itself, usually the LOOPBACK address NTRL   Lable 24 bits, same as mpls tag, but without ttl Prefix Rd:64bit+ip prefix   We know that BGP exchange routing is accomplished through NLRI (Network Layer Reachability Information). Through the transformation of BGP protocol, the modified MP-IBGP will append various information such as RD and label when NLRI information exchange. In this way, the routing exchange and data forwarding problems of the entire MPLS VPN are solved. Let's introduce the process of routing exchange and data forwarding of MPLS L3VPN. MPLS L3VPN routing exchange and data forwarding process As mentioned earlier, when MPLS L3VPN routes are exchanged, the PE router runs a single routing protocol (MP-IBGP) to exchange all VPN routes. To support the overlapping of VPN client spaces, add RD to the VPN address space to make it unique. And use the RT attribute to indicate the VRF to which the route belongs. We can summarize it as follows. The routing exchange process of MPLS VPN is mainly divided into four parts: ■ Routing exchange between CE and PE; ■ The process of VRF route injection into MP-IBGP; ■ Public network label distribution process; ■ The process of MP-IBGP route injection into VRF. Let's analyze the whole process of MPLS VPN routing exchange between PEs through examples. Route exchange between CE and PE Schematic diagram of route exchange between CE and PE The exchange process is as follows: Configure VRF for different VPN sites on the PE. PE maintains multiple independent routing tables, including public and private network (VRF) routing tables, including: ■ Public network routing table: contains all the routes between PE and P routers, and is backed by the backbone network IGP Produce ■ Private network routing table: The routing and forwarding table that contains the reachable information of this VPN user. Routing information is exchanged between PE and CE through standard EBGP, OSPF, RIP or static routes. In this process, except that the PE device needs to store the routes from the CE device in different VRFs (this is only related to the route receiving interface and has nothing to do with other MPLS VPN features), other operations are no different from ordinary route switching. Static routing and RIP are standard protocols. All CE terminals can use the same routing protocol, but each VRF on the PE terminal needs to run a different instance, and there is no interference with each other. Simple introduction of each other. The situation of EBGP is similar to RIP. It is also ordinary EBGP instead of MP-EBPG, which only exchanges the VPN routes filtered by PE. However, choosing OSPF as the routing protocol between PE and CE is relatively complicated. Many modifications to OSPF are required to carry the LSAs of this site in the extended community attribute of BGP and exchange LSAs with OSPF in the remote VPN. OSPF in each site can have area 0, and the backbone network can be regarded as super area 0. At this time, OSPF changes from a two-level topology (backbone area + non-backbone area) to a three-level topology (super backbone area + backbone area + non-backbone area). For more detailed introduction of OSPF in MPLS VPN network, please refer to other related documents of MPLS VPN, which will not be described in detail here. This completes the route exchange process from CE to PE. The process of VRF route injection into MP-IBGP VRF route injected into MP-IBGP and route exchange diagram between PE As shown in the figure, the process of injecting VRF routes into MP-IBGP and exchanging them between PE devices through MP-IBGP is as follows: After receiving the routing information from the CE, the PE router needs to add RD to the route (RD is manually configured) to make it a VPN-IPv4 route. Then change the next hop attribute to yourself (usually your own loopback address) in the route advertisement, add a private network label to this route (generated automatically by the MP-IBGP protocol, no configuration required), and add the RT attribute (RT Need to be manually configured). After this series of work is completed, the PE sends it to all other PE neighbors. Other PE neighbors also perform the same operation to exchange routes on different CE ends. Public network label distribution process Schematic diagram of the public network label allocation process The private network routing exchange between PEs needs to cross the MPLS backbone network. In this process, standard MPLS forwarding needs to be performed. Therefore, to properly route the route to the peer PE, you need to know the public network label that reaches the peer PE. As shown in the figure, the process of public network label assignment is as follows: First, the PE and P routers learn the address of the next hop of the BGP neighbor through the backbone network IGP. By running the LDP protocol, labels are assigned, and LSP channels are established. The label stack is used for packet forwarding. The outer label is used to indicate how to reach the next hop of BGP. The inner label indicates the outbound interface of the packet or which VRF (which VPN) it belongs to. MPLS node forwarding is based on the outer label, regardless of the inner label. At this time, through the outer label space of MPLS, normal routing exchange can be performed between PE devices. The process of MP-IBGP route injection into VRF Schematic diagram of the process of MP-IBGP route injection into VRF As shown in the figure, after receiving the route sent by the sending PE, the receiving PE changes the VPN-v4 route to an IPv4 route, and adds the route entry to the corresponding VRF according to the import RT attribute of the local VRF. The private network label Keep it, record it in the forwarding table, and use it for forwarding. It is then introduced by the routing protocol of this VRF and passed to the corresponding CE. When sending to CE, the next hop is the interface address of the receiving PE. This completes the process of injecting MP-IBGP routes into VRF. After the above four steps, the routing exchange of the entire MPLS VPN network is completed. At this point, the VPN is constructed and normal business data can be forwarded. Conclusion In those articles, <mpls vpn architecture-1、2、3> I will introduce the what is rd and rt value. And what is vrf, if you want to know more , please view those articles in our blog website. If you desire to pass the Cisco exams and looking for the most reliable and clear to understand the material so, now it is very easy for you to get it at SPOTO. We are presenting you here the most up-to-date questions & answers of Cisco exams, accurate according to the updated exam.

Foreword BGP ring defense is implemented through AS_PATH, and AS_PATH is only changed when the route leaves the AS. Therefore, within the AS, IBGP does not have EBGP ring defense capabilities. In order to prevent the occurrence of loops, BGP routers will not be from IBGP neighbor The learned routes are advertised to other IBGP neighbors. BGP stipulates that the routes learned through one IBGP will not be propagated to all other IBGP neighbors. This is the BGP split horizon rule. Due to the principle of split horizon, BGP requires that within the AS, IBGP must be fully interconnected (here it is specified by the neighbor command). (The root cause is that within the AS, the AS-PATH will not change and the AS_PATH anti-ring cannot be used, so loops are prone to occur) Split horizon: R3 does not send to other IBGP neighbor R2 after receiving the update from IBGP neighbor R4. As a result, R2 and R1 cannot get the route of R4 It is also split horizontally, both in BGP and IGP; then: IGP split horizon: The routing information learned from an interface will no longer be advertised from that interface. It is from that mouth that no longer comes out from this mouth. Horizontal split of BGP: The routing information learned from any IBGP neighbors is no longer forwarded to any IBGP router. To put it bluntly is a dead end, no longer in control. So, someone asked, since the same is horizontal split, why are the standards different? IGP can also send updates to other routers, is BGP too worried? If BGP is right, does IGP cause a loop? Answer: Yes! IGP still has a loop to do so! However, this loop is a loop of a large network, so IGP uses other methods to solve this problem, such as the 16-hop RIP (otherwise, if a horizontal split is all done, RIP does not need the 16-hop setting); the reason is The horizontal split of IGP is just to prevent problems in a small area such as regional networks (such as adjacent routers). If the network is large and the interconnection is complicated, loops may still occur. This situation is intolerable for BGP, a protocol that carries such core and large-scale routing. There is no need to explain this point. Therefore, BGP adopts such a brutal version of horizontal splitting. How to solve the problem that split horizon causes R4 and R2 to fail to get the route. So how to solve this kind of problem? Option One Let the routers in the AS domain be physically fully connected, add a physical link between RTB and RTC, and establish an IBGP neighbor relationship between RTC and RTB, so that RTC can directly pass its own route to the RTB router. The RTB router directly passes the route to RTA through the EBGP neighbor relationship. This fully connected network deployment solution, on the one hand, has a high networking cost, and on the other hand, the increase in the number of BGP connections correspondingly increases the resource consumption of the system, and the fully connected network deployment has poor scalability. Is there a simpler way? Option II Make the routers in the AS domain fully logically connected, make the IGP routes of RTB and RTC reachable to each other, establish an IBGP neighbor relationship between RTB and RTC, so that RTC can directly pass its own route to RTB router, which is directly Routes to RTA through EBGP neighbor relationship. The ultimate solution-RR No need to add physical link or new IBGP neighbor relationship-configure BGP route reflector. The RTD is configured with a route reflector, and both RTB and RTC configure a reflector RTD client. In this way, according to the reflector's route reflection principle, RTC can easily reflect its own route to RTB, and RTB passes the EBGP neighbor relationship. Modified application network diagram: Route Reflector (RR): Allows the routes learned from IBGP peers to be reflected to BGP devices of other IBGP peers. Client: IBGP device that forms a reflection neighbor relationship with RR. Within the AS, the client only needs to be directly connected to the RR. Non-Client: IBGP device that is neither an RR nor a client. Between the non-client and RR within the AS, The purpose of the route reflector (RR) is to simplify the configuration of IBGP neighbors. After using the reflector, it allows the reflector to send routing information from the IBGP neighbor to another IBGP neighbor or a group of neighbors. The router allows the router configured as a route reflector to transmit the routes learned by IBGP to other IBGP peers to modify the horizontal isolation rules of BGP, so that fully interconnected IBGP peers are no longer needed. Reflection function The route reflector will reflect the information between the clients in turn. The route reflector and all its clients form a group. Multiple route reflectors are allowed in a group. A route reflector can configure other route reflectors as its clients or non-clients; a route reflector transmits route updates between its clients and non-clients Rules: If the route update is received from a non-client, it is only reflected to the client; if the route update is received from a client, it is reflected to all non-clients and clients, except for the originator of this route update ; If the routing update is received from the EBGP neighbor, it will be reflected to all clients and non-clients. Reflection process Public network route BGP route delivery process Pass a route from RTC to the RTA router through the route reflector, RTA Router ID is 1.1.1.1, RTB Router ID is 2.2.2.2, RTD Router ID is 3.3.3.3, RTC Router ID is 4.4.4.4. RTC publishes a route 4.4.4.4/32 to the IBGP reflector. The reflector RTD learns the route and reflects the route 4.4.4.4/32 to the client RTB. RTD: Sh ip bgp route 4.4.4.4 BGP local router ID：3.3.3.3 Local AS number： Path：1 available，1 best BGP routing table entry information of 4.4.4.4/32 RR-client route From：30.0.0.2 （4.4.4.4） Relay Nexthop：0.0.0.0 Original nexthop：30.0.0.2 AS-path：（null） Origin：incomplete Attribute value：MED 0， localpref 100，pref-val 0，pre 255 State：valid，internal，best， Advertised to such 1 peers：20.0.0.1 The client RTB learns the 4.4.4.4/32 route reflected by the reflector. The Originator of the route is 4.4.4.4 (that is, RTC router), and the Cluster list is 3.3.3.3 (that is, the route is reflected by the reflector RTD router) , Original nexthop is 30.0.0.2 (the route initiates the next hop), Relay Nexthop is 20.0.0.2 (the route relays the next hop). RTB: Sh ip bgp route 4.4.4.4 BGP local router ID：2.2.2.2 Local AS number：100 Path：1 available，1 best BGP routing table entry information of 4.4.4.4/32 RR-client route From：20.0.0.2（3.3.3.3） Relay Nexthop：20.0.0.2 Original nexthop：30.0.0.2 AS-path：（null） Origin：incomplete Attribute value：MED 0，localpref 100，pref-val 0，pre 255 State：valid，internal，best， Originator：4.4.4.4 Cluster list：3.3.3.3 Advertised to such 1 peers：10.0.0.1 The RTA router learned the route 4.4.4.4/32 through the EBGP neighbor relationship. RTA: Sh ip bgp route 4.4.4.4 BGP local router ID：1.1.1.1 Local AS number ：200 Path：1 available，1 best BGP routing table entry information of 4.4.4.4/32 From：10.0.0.2 （2.2.2.2） Original nexthop：10.0.0.2 AS-path：100 Origin：incomplete Attribute value：pref-val 0，pre 255 State：valid，external，best， Not advertised to any peers yet In this way, the route reflector successfully shields the BGP horizontal isolation rules and passes the route to the RTA router. Route reflector (RR) configuration: ①: Enable BGP ②: Establish neighbors under the same BGP-AS. ③: Specify the router and the AS where it is located. ④: Specify the source. ⑤: (neighbor) RR client-configure the client. ⑥：neighbor router-id route-reflector-client RTD: Router bgp 100 bgp router-id 3.3.3.3 neighbor 2.2.2.2 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 2.2.2.2  route-reflector-client neighbor 4.4.4.4  route-reflector-client Note: if you  are interested in the article, and you can follow SPOTO. And, you want to take any certifed exam, and you can contact us now!