QoS Policy Propagation on BGP (QPPB)

QPPB, allows packets to be classified based on access lists, BGP community lists, and BGP autonomous system (AS) paths.

The supported classification policies include IP Precedence setting and the ability to tag the packet with a QoS class identifier internal to the router. After a packet has been classified, you can use other QoS features, such as committed access rate (CAR) and weighted random early detection (WRED).

A Networker Blog

BGP.- Filter Tools Summary

Prefix-lists and filter-lists, both in and out, filter routes and discard those that are not permitted.

Weight setting is applicable only on incoming routes because a router never propagates the weight attribute to its neighbors.

Route-maps can be filters that discard routes but can also be used to modify and set various attributes on both incoming and outgoing routes.

Filtering Tool Summary

A Networker Blog

Basic BGP .- Part 3 – AS Path Prepending.

When connections to multiple providers are required it is important that Border Gateway Protocol (BGP) select the optimum route for traffic to use. The optimum, or best, route may not be what the network designer intended based on design criteria, administrative policies, or corporate mandate. Fortunately, BGP provides many tools for administrators to influence route selection. One of these tools is autonomous system (AS)-path prepending.

You can manipulate AS paths by prepending AS numbers to existing AS paths. Normally, you perform AS-path prepending on outgoing EBGP updates over the non desired return path

You can configure prepending on a router for all routing updates that you send to a neighbour or only on a subset of them.

When you are manually manipulating AS paths, the only valid AS number that you can prepend is the AS number of the sender. Prepending any other AS number will cause problems.

The longer the AS path that is announced to the EBGP neighbour on the other side of the backup link, the less likely it is that incoming traffic will be received from that neighbour.

A Networker Blog

The BGP MED – Deterministic vs Always-compare. tin tin !!!

For a Summary of this great protocol please check out this link: BGP Summary

Main Cisco Document Link about the topic in this post.

 

the topology used:

 Note: When BGP receives multiple routes to a particular destination, it lists them in the reverse order that they were received, from the newest to the oldest. BGP then compares the routes in pairs, starting with the newest entry and moving toward the oldest entry (starting at top of the list and moving down). For example, entry1 and entry2 are compared. The better of these two is then compared to entry3, and so on.

we can see that to get to the 3.3.3.3 network, R1 is choosing R3 as the best path because of Step 7 of the BGP Algorithm Process should win here again (Ebgp over IGBP), without comparing any med value.

the show

 

we can test this decision process, by turning down the peering relationship between R1 and R3

 we can see that we prefer now the path towards R2, because of a lower MED value, if we change the metric to something higher than R4’s metric announced to R1, in R2 (say 200).

and having that route announce from R2 to R1

R1 is  going now to preferring the path over R4, because of a better MED Value (lower value), Lets change the MED again to 100 in R2 for the BGP Peering relationship between R4 and R2,  now R1 is going to prefer the path to reach the 3.3.3.3/32 network over R2 because we are comparing the MED Values in the same Group (AS 4,3)

We can see that R1 is preferring R2 to reach the network, so this is very OK, routers are talking here 🙂

Now, lets enable again then the relationship with R3 again, and proceed test out the Example 2

here, we have 3 entries now, and 1 of the entries is arriving from a different autonomous system number, we do not compare the MED value by default in this case, entry 1 is the Best path because of the administrative distance (External [20]Vs Internal [200]) , so we stop at step 7 on the decision process… and the Step 6 is not analyzed  this step indicates that comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored

Example 2: bgp deterministic-med Disabled, bgp always-compare-med Enabled

 Entry1 is compared to entry2. These entries are from different neighbor autonomous systems, but since the bgp always-compare-med command is enabled, MED is used in the comparison. Of these two entries, entry1 is better because it has a lower MED. Next, entry1 is compared to entry3. The MED is checked again because the entries are now from the same autonomous system. Entry3 is chosen as the best path.

entry1: AS(PATH) 500, med 150, external, rid 172.16.13.1 entry2: AS(PATH) 100, med 200, external, rid 1.1.1.1 entry3: AS(PATH) 500, med 100, internal, rid 172.16.8.4

  

 from this output we determine that Entry 1 received from 2.2.2.2, with AS 4,3, Entry 2 received from 4.4.4.4 with AS 4,3 and Entry 3 comes from 3.3.3.3, with AS 3,3.

Entry 1 is evaluated with Entry 2, since both entries  transport the same AS information, the Step 6 of the decision process is now perform,  and the best path is Entry 1 because it has the lowest MED and wins over the med that carried in Entry 2. Step 6 of the decision process. Now Entry 1 is compared with Entry 3,  and Entry 1 (lowest MED) is the winner of the election process because of the ALWAYS-COMPARE-MED, configuration done in the BGP Process. And this is testable by the outputs before enabling the always-compare-med, so we are like relaxing a little bit the rule of step 6 … This comparison only occurs if the first (the neighboring) AS is the same in the two paths. and instead of not comparing the MED Value of the route received over to different AS,  with this command we can now compare the entries with the MED Value even if the Entries are not from the same AS.

Example 3: bgp deterministic-med Enabled, bgp always-compare-med Disabled

When the bgp deterministic-med command is enabled, routes from the same autonomous system are grouped together, and the best entries of each group are compared. The BGP table looks like this:

entry1: AS(PATH) 100, med 200, external, rid 1.1.1.1 entry2: AS(PATH) 500, med 100, internal, rid 172.16.8.4 entry3: AS(PATH) 500, med 150, external, rid 172.16.13.1

There is a group for AS 100 and a group for AS 500. The best entries for each group are compared. Entry1 is the best of its group because it is the only route from AS 100. Entry2 is the best for AS 500 because it has the lowest MED. Next, entry1 is compared to entry2. Since the two entries are not from the same neighbor autonomous system, the MED is not considered in the comparison. The external BGP route wins over the internal BGP route, making entry1 the best route.

 

Group 1: Entry 1 = 3,3 from 3.3.3.3

Group 2: Entry 2 = 4,3 from 2.2.2.2  vs Entry 3 = 4,3 from 4.4.4.4  

Entry 1 is the only one on that group so no other entries on that group to compare. so he is the winner by forfeit. Now Group 2 is now evaluated, and here we have 2 entries, Entry 2 and Entry 3 are compared and Entry 2 wins the process because of a better MED Value (lowest metric again step 6), now the winners of each group are compared and Entry 1 from Group 1 is compared with the winner of Group 2 (Entry 2), and Entry 1 wins because of step 7, since we are not using the always-compared-med in the BGP Routing Process, so step 6 is not checked here.The winner of each group are compared and the winner depends now on the BGP Process based on step 6 (if always compare med is enabled) or step 7 if this command is not enabled. This reminds me to those football chart 🙂

Example 4: Both Commands Enabled

Now if we enable always-compared-med & deterministic-med, entry 2 of group #2 wins against entry 1 of group #1, because of a lower MED Value.

Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems. The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for setting MED.

HYEI

Victor Cappuccio.-  

A Networker Blog

Do you still need that route?

The BGP advertisement is configured on the customer edge routers using the network command. Route advertisement is conditioned by the appearance of a corresponding network or subnet in the routing table of the edge router. If the network or subnet is manually entered into the routing table by configuring a static route to null 0, the condition is always true because the static route is always there, and the BGP advertisement is always performed.

If the customer edge router loses connectivity to the rest of the customer network but is still connected to the ISP network, BGP advertisement must cease. In this case, BGP advertisement can be stopped if BGP advertisements are bound to the reachability status of a specific subnet in the core of the customer network, according to the customer IGP. The problem with using a static route to null 0 is that it conditions the network statement in the BGP configuration so that BGP always advertises the route. If the customer edge router loses connectivity with the rest of the customer network, the router continues to advertise the entire customer address space. The ISP network receives a valid route from the customer edge router. Traffic is sent to this router, but because the router has lost connectivity with the rest of the network, the traffic is dropped (routed to the null 0 interface using the static route).

Rack1R1#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2809856] via 192.168.13.3, 00:00:39, Serial1/1
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.13.3, 00:00:41, Serial1/1
D 192.168.23.0/24 [90/2681856] via 192.168.13.3, 00:00:40, Serial1/1</pre>
 Rack1R1#conf te
 Enter configuration commands, one per line.  End with CNTL/Z.
 Rack1R1(config)#router bgp 12
 Rack1R1(config-router)#neigh 2.2.2.2 remote-as 12
 Rack1R1(config-router)#neigh 2.2.2.2 up lo0
 Rack1R1(config-router)#
 Rack1R1(config-router)#do show ip bgp summ
 BGP router identifier 1.1.1.1, local AS number 12
 BGP table version is 1, main routing table version 1
 Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
 2.2.2.2         4    12       0       0        0    0    0 never    Active
 Rack1R1(config-router)#exit

 %BGP-5-ADJCHANGE: neighbor 2.2.2.2; Up
 Rack1R1(config)#do show ip route 2.2.2.2
 Routing entry for 2.2.2.0/24
 Known via "eigrp 100", distance 90, metric 2809856, type internal
 Redistributing via eigrp 100
 Last update from 192.168.13.3 on Serial1/1, 00:01:44 ago
 Routing Descriptor Blocks:
 * 192.168.13.3, from 192.168.13.3, 00:01:44 ago, via Serial1/1
 Route metric is 2809856, traffic share count is 1
 Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

Rack1R1(config)#do show ip route 3.3.3.3
 Routing entry for 3.3.3.0/24
 Known via "eigrp 100", distance 90, metric 2297856, type internal
 Redistributing via eigrp 100
 Last update from 192.168.13.3 on Serial1/1, 00:02:09 ago
 Routing Descriptor Blocks:
 * 192.168.13.3, from 192.168.13.3, 00:02:09 ago, via Serial1/1
 Route metric is 2297856, traffic share count is 1
 Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

 Rack1R1(config)#ip route 100.10.10.1 255.255.255.255 3.3.3.3
 Rack1R1(config)#do show ip route 100.10.10.1
 Routing entry for 100.10.10.1/32
 Known via "static", distance 1, metric 0
 Routing Descriptor Blocks:
 * 3.3.3.3
 Route metric is 0, traffic share count is 1

Rack1R1(config)#ip route 100.20.10.1 255.255.255.255 null0
 Rack1R1(config)#do show ip route stat
 100.0.0.0/32 is subnetted, 2 subnets
 S       100.10.10.1 [1/0] via 3.3.3.3
 S       100.20.10.1 is directly connected, Null0
 Rack1R1(config)#do deb ip routing
 IP routing debugging is on
Rack1R1(config)#router bgp 12
 Rack1R1(config-router)#red static
 Rack1R1(config-router)#do show ip bgp
 BGP table version is 3, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
 *100.10.10.1/32 0.0.0.0 0         32768 ?
 *100.20.10.1/32 0.0.0.0 0         32768 ?

Lets Shut down the lo0

 RT: delete route to 3.3.3.0 via 192.168.13.3, eigrp metric [90/2297856]
 RT: SET_LAST_RDB for 3.3.3.0/24
 OLD rdb: via 192.168.13.3, Serial1/1

 RT: no routes to 3.3.3.0
 RT: NET-RED 3.3.3.0/24
 RT: delete subnet route to 3.3.3.0/24
 RT: NET-RED 3.3.3.0/24
 RT: delete network route to 3.0.0.0
 RT: NET-RED 3.0.0.0/8
 Rack1R1(config-router)#do show ip bgp
 BGP table version is 3, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, ; best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
 *100.10.10.1/32   0.0.0.0         0         32768 ?
 *100.20.10.1/32   0.0.0.0         0         32768 ?

 Rack1R1(config-router)#bgp scan-time 5
 Rack1R1(config-router)#do show ip bgp
 BGP table version is 3, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, ; best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
 *100.10.10.1/32 0.0.0.0 0         32768 ?
 *100.20.10.1/32 0.0.0.0 0         32768 ?
 Rack1R1(config-router)#do show ip bgp
 BGP table version is 3, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
 100.10.10.1/32  0.0.0.0 0         32768 ?
 100.20.10.1/32 0.0.0.0 0         32768 ?

Rack1R1(config-router)#do show ip route sta
 100.0.0.0/32 is subnetted, 1 subnets
 S       100.20.10.1 is directly connected, Null0
Rack1R1(config-router)#

 RT: del 100.10.10.1/32 via 3.3.3.3, static metric [1/0]
 RT: delete subnet route to 100.10.10.1/32
 RT: NET-RED 100.10.10.1/32
 Rack1R1(config-router)#do show ip bgp
 BGP table version is 4, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
 * 100.20.10.1/32 0.0.0.0 0         32768 ?

So the static route to the null 0 will always be up and advertised via BGP

A Networker Blog