CCNP ENARSI (300-410) : BGP (BORDER GATEWAY PROTOCOL)

6. 7_4 Controlling BGP Routing Updates

In this section, we are going to take a look at controlling BGP route updates. If there is more than one route between your network and the ISP, you may need to filtercertain information during the exchange of BGP updates to affect route selection or to implement a management policy. You can filter the BGP updates via PerfectsList, as well as the route map. And let's take a look at the Perfects List filtering first. Here we have a rather BGPN autonomous number. And we have the neighbour's statement, which is peering with this guy. And we are using the prefix list, any two, any eight to 24 net while we are peering. Okay? And we are using this perfect list inbound. So we define an IP Perfects List with this name which permits all routes which are greater than or equal to eight and less than or equal to 24. So, what exactly does the Perfects List saying mean? thePerfects List named any eight to 24. The net is configured to match rods from any network that has a mask length of eight to 24 bits. The zero network and length combination does not match a specific network. Rather, it defines any network. As you know, the parameters are greater than or equal to eight. And Le 24 specifies that any network with a mask length of between eight and 24 matches the Perfect List entry. And here is the ASPATHaccess list filtering autonomous systems. This guy (650) does not want to act as a transit autonomous system between its service providers. Let's say that this situation is avoided by ensuringthat only locally sourced rods are sent to the ISP. And then the customer avoids receiving IP packets from the ISPs' destinations outside its own autonomous systems. All right, what's going on in this scenario is we have gateway one and gateway two. We are defining an Ipaspat access list,one that permits something like that. That means locally originated rods. Then, under the BDP statement, when we are neighbouring with ISP two and ISP one, we are using this aspad access list as a filter list to outbound. Alright, the ASPATH list in here permits only the empty string matched by the regular expiration. And this guy, this guy, who represents,as I told you, locally sourced routes. By applying this filter list to all neighbors, the customer announced only its local routes. And here is the route map filtering. How we can configure route map filtering in route map filtering. What we are doing is just defining some ISP one out and ISP two out as two separate IP prefix lists. First, this is one of two statements that are permitted, with this IP address and ISP being the other. Perfects. Then I'm defining gearrotmap, which has the name of ISP one out. And I'm matching the IP address that I'm using here and here. Okay? Then under the BGP statement, when I'm peering with this IP address, I'm using this rot map. Okay, this is going to be ISP one outrotmap,and this is going to be ISP two outrotmap. Okay, what is P? One outrotmap is saying to me that I just hit the IP address in this prefix and ISP Two is saying to me that I just hit the IP prefix list in this. So I have this rod and this rodber, as you can see. So I'm announcing this prefix just to ISP one. And I'm only announcing this prefix to ISP two. And lastly, we are going to talk about the BGP peer group. When you configure BGP on a router,it's possible that some of the BGP neighbours share the exact same configuration. This can be annoying since you have to type the exact same commands for each of these neighbors. Also, when BGP prepares updates, it does this separately for each neighbor. This means that it has to use CPUresources to prepare the update for each neighbor. To simplify the configuration of BGP and reduce the number of updates BGPhas created, we can use peer groups. Let's take a look at the figure now. We have John C.Jazz Owen and Jules Rodders. And we're looking at them rather than at each other. Okay, here's the configuration of Jazz rudder: BGPone, two, three, and neighbour with John C. The same configuration can be found here and here. But when we take a look from the perspective of John's, what I have to define is and for Jazz,define a remote autonomous system, define a route reflector clientcommand, which we are going to talk about later, and define and remotely as I said. Okay? And for Owen, it's the same thing. For example, neighbour Owen's IP address will have a range of one, two, or three. And my neighbor, Owen, is a rod reflector client. And for Jazz, I'm going to type the same thing. For jewels, I'm going to type the same thing again for simplicity. What I'm doing is I'm defining these three separate guys as a peer group. So I'm implementing these commands to the peer group instead of typing for instead of typing separately for each neighbor. Neighbor Peers is a peer group. That's the name of the peer group. peers and neighbors. They are in the remote as one, two, and three, and they are my rod reflector clients. Okay? And after defining this peer group, the only thing I'm doing is attaching the neighbours to the peer group by typing neighbor, neighbor's IPaddress, peer group, and peer group name.

7. 7_5 Configuring BGP For IPv6 Internet Connection

In this section we are going to talk about configuring BGP four IP version six internet connections. The normal version of BGP can only carry four unicast packets. BGP supports IPV for unicast, IPV for multicast, IP version six unicast and IP version six multicast addresses. And today we can use multiprotocol BGP, which supports different address types, as you can see. And let's take a look at how to configure multiprotocol BGP. In this example, we are using IP version sixadjacency and IP version six prefix as well. The configuration is almost the same as with the normal BGP. In place of one, we are using BGP and an autonomous number. Then we are defining a neighbour statement, as in hereafter we are typing the address family IP version six. Then in the AF mode we are defining our neighbors. I'm sorry, we are activating our neighbours. We are defining here and we are activating in the AF mode. Then we are advertising the route under the AFmode as well as we want to advertise the same things for the router two as well. And let's take a look at the multiprotocol BGP for IP version six with IPV for adjacency and an IP version six prefix. This time the neighbour is being defined with IP version four IP addresses. As you can see, because I'm using an IPversion for prefix between random two, we're getting into the address family and advertising the network that we want to advertise on here. We're activating the neighbour by using Activate Comment with IPV four IP addresses.

8. 7_6 Advanced BGP Configuration

In our next section, we are going to talk about advanced BGP configuration. The first thing we are going to take a look at is BGP route summarization BGP rodsummarization is done with the aggregate address command. Okay, here is our topology. We have four routers, and in other parts we type the show Ipdgp. We see the routes from zero to seven. We see the error in this. Then in router three, if you want to use summarization, we use aggregate address and the IP address and submask for this direction. And after that, when we type show ipbgp on router four, we are going to see 0127 again, but an aggregateroute which has a subnet mask of 21 as well. Okay, cool. If we use the summaryonly command in BGProd summarization, only the summarised route is advertised. This time let's use the aggregate address IP and the summit mask with the summary only keyword. Then, when we check the show Ipbgp output from router four, we won't see these guys; instead, all we'll see is a summer route. Let's talk about the BGP community feature. The BGP community feature allows routers to tag routes and filter them using those labels. In this respect, routes act as a community rather than a single route. The community feature is an optional and switchable feature. If a router does not understand the concepts of community, it passes these concepts to the next router. There are four well-known community features which may use the previously defined community settings and they internet no export, no promotion local ass The internet promotes the relevant route to the internet and other related routes. No export, does not send the relevant routes to any neighbours No advertisement sends the associated rod to any neighbours or locals. Do not send the relevant rod outside the local area. And here's the configuration of the BGP communities. We have four others in our topology, as you can see. And we'll use letter two to promote this prefix to the router tree. This prefix will be advertised to router three,but we are going to let router three not advertise this guy to router four. How can we accomplish this? All right, what we're going to do is on routertwo, we are defining first an IP perfects list, which has a name of 100 networks, and we are hitting this perfects in the IP perfects list. Then we are defining a rot map which has a noexport 100 network name and we are matching the IP address here and we are setting a community with no export. Alright, then we are defining a rap map permit20 statement to permit the rest of the things. Then under the BGP statement, we are using the Rob Map no export 100 network out. All right, then we will use the send community command. Then when we take a look at router trees, they show an Ipbgp table. We can see the entry for this network. But when we take a look at Rather Four, we don't see anything related to 100, 100, 100, and zero networks. BGP specifies that routes learnt via IBGPare never propagated to other IBGP peers. The result is that a full mesh of IBGP peers is required within an autonomous term. For example, with only 13 Rodders, 78IBGP sessions would need to be maintained. With the BGP Rod reflector, the need for full mesh of IBGP neighbours is removed. Because the Rod reflector has the ability to distribute IBGP routes to other IBGP routers, The Rod reflector reduces the number of BGP neighbours and sessions in an asso band can be used more efficiently. Other routers can learn different routes by enabling the route reflector. And here is the configuration of the route reflector. So we have a route reflector in here and we have Router One and Router Two. In router one, Here's the BGP configuration. Rather, 100 BGP. We are advertising a network and we are neighbours with just rod reflectors. That's important. That's the key point. And in Rodger Two, we are just next to the Rod reflector, as you can see. Again, let's take a look at the Rod reflector. We are now peering with Router One in Rod reflector. And we're looking at Rodder Two. What we define as remote and update source loopback. Okay? I already know this. Here is the key difference. We are using the Route reflectorclient command for each router, okay? That's the key difference, and that's the only difference while we are defining the route reflector. Okay? In summarization, on the client routers, we are just peering with the Route reflector and the Route reflector is peering with all the other guys in the network. And we are using the route reflector client command. And here is how we can propagate a default route on BGP that spreads straight forward. The command is just the default origin.

9. BGP ROUTE REFLECTORS

In this section, we will talk about PGP Route Reflectors. So, RFC 119 Six introduces the idea that IPGP peering can be configured so that it reflects routes to and from an IBGP peer. The router that is reflecting routes is known as a route reflector, and the route that is receiving reflected routes is known as a route reflector client. As a result of the IBGP BGP Split horizon rule, all IBGP peers within an as must be fully meshed. You may ask why. Whereas EBGP uses the as path for loop avoidance,IBGP neighbours do not add their number to the as path when sending the updates. So what does IBGP use for loop prevention? And that is simple. That is the split horizon. The rules of the IBGP Split Horizon state that any routes learned from an IBGP neighbour must never be advertised to any other IBGP neighbor. This, of course, presents complexity and scalability issues for both the PGP routers and the network due to the number of unique PGP sessions required. For example, the total number of unit BGP sessions required within the as can be calculated using the following whereN is the number of BGP speakers within the as, so you can see here when N is the BGP speaker. And let's say you have ten BGP routers. That means you will have ten nine divided by two. That means you need to have 45 PGPsessions only for the ten BJP speakers. So, one solution to reduce the number of BGP peerings within Nas is Rod reflection. Rather than each BGP system having to peer with every other BGP system with the Autonom system, each BGP speaker instead peers with a route reflector. Routes sent to the route reflector are then reflected to all of the other PGP speakers. The rod reflector reflects routes considered best only. Additionally, a route reflector is not allowed to change any attribute of the reflected route, including the next hope attribute that is so important to keep in mind, guys. So also, there are two types of internal peers to a Rub reflector: client and noncliented. Let's look at the differences now. So, furthermore, and to summarize, only the route reflector is aware of who is a client and who is a nonclient to the route reflector. The nonclient is simply another IBGP peer. Because of this, the route reflector must add hair to the BGP Split horizon role, and hence routes from a non-client are only reflected to clients. So let's summarise what we said now. So let's say this is the Rot reflector in here,and if it receives an update from a client, it sends it to all clients and nonclients. But if the route reflector receives a PGP update from Anclient,it is just sent to IBGP Route reflector clients. So when we check the route reflector operation again,when the peer type is declined, a route from a client peer is reflected to all the nonclient peers and declined peers, and an error from an unknown client is reflected to all the clients. So let's check the configuration for the Rod reflector. Here you can see we have a one-route reflector and that is the router one. And when we're trying to configure the route reflector, we're just typing router BGP and the as number. Then we define the neighbour neighbour and just type the Rod reflector client and configuration is really simple and on rather one. If you just type "show Ipbgp for thisparticular network", you can see here if it's received from a route reflector client or not. And for this scenario, this route is received from an aroute reflector client, and that is three, three, three. So another thing is that removing the fullmesh requirements in an IBGP topology introduces the potential for routing loops. When RFC 119 Six was drafted for the other BGProute reflectors, specific attributes were added to prevent loopsies. One of them is the originator ID, and the other one is the cluster list. When it comes to the originator ID, the first routerreflector creates it and sets the value to the router ID of the router that injected and also advertised the route into the as. If the originator ID is already populated on an NLRI, it should not be overwritten. If a route receives an NLRI with its routerID in the originator attribute, the NLR is discarded. So when it comes to the cluster list, this nonsensitive BGP attribute is updated by the route reflector. This attribute is appended. That means not being overridden by the route reflector with its cluster ID. By default, this is the BGP identifier. If a rod reflector receives an NLR with its clusterID in the cluster list attribute, the NLR is discarded.

ExamSnap's Cisco 300-410 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Cisco 300-410 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.