Accumulated IGP Metric Attribute (AIGP)

Lessons Discussion
21

Hello Sampreetha

The ultimate goal here is to ensure that traffic flowing in both directions will take the path that has the shortest metric. When doing so, we want BGP to take into account the IGP metrics involved as well.

What is the best path that a packet should take from R1 to the L0 interface of R6? Based on the metrics involved as shown on the diagrams, that would be R1 to R2 to R4 to R6 with a total metric of 10+20+10 = 40. The alternative, via R3 and R4 would have a metric of 30+10+10 = 50. So the correct path was indeed chosen.

You must remember that AIGP takes into account the total metric of the whole path, including the IGP metric of AS456 and the IGP metric for the portion of the path found within AS123.

I hope this has been helpful!

Laz

22

hello @lagapidis
I understood the lessonā€™s proposal, but I only changed the metric on one side, from AS 123 to 456, and I got the same result for the traffic going to 6.6.6.6 going through r2-r4-r6, and the traffic going back to 1.1. 1.1 became r4-r2-r1, without needing AIGP.

I just applied the metric on r2 and r3, with that the return traffic that was the problem started to follow the correct path according to the internal costs of the two ASā€™s

would this be worth a solution to the problem presented by rene?

print aigp forun LN-1
print aigp forun LN-11300Ɨ1182 339 KB

1 Like
23

Hello Yuri

Yes indeed you are correct that this scenario would correctly route traffic between the loopback across the most efficient routing path. However, it is not the preferred method. What happens if the IGP metrics change in AS 456 due to a change in the network topology or configuration? When the IGP reconverges the IGP metrics may also change. The MED would not take this into account to change the routing path between ASes.

Using AIGP will actually insert an extra attribute in the BGP path selection algorithm. The fourth step in the BGP path selection is that BGP prefers the path with the shortest AS path. When you enable AIGP, BGP prefers the lowest AIGP metric first. So any change in the IGP will be detected and cause the appropriate change in routing between the ASes.

Itā€™s a good exercise however that you found a solution for this particular scenario without the use of AIGPā€¦

I hope this has been helpful!

Laz

PS Nice to see you on the forum again Yuri!!

24

@lagapidis

thanks a lot for the feedback!

I understood your point about a possible change in the costs of the igp and with that the AIGP plays its role 100%. It became very clear to me now.

thanks for the reception again. you and the Networklessons team are fantastic.

1 Like
25

Hi Rene,
Why are we settup up the med based on IGP metric? We know that based on IGP metric it wont work. Whyd dont we reverse the med values on R4 and R5 ? Appreicate if you could explain it and thanks for such a great lesson.

1 Like
26

Hello Anil

In section 1.2.1.2 of the lesson, Rene is adjusting the metric in an attempt to ensure that the most optimal path is being taken. However, it is proven that this attempt fails. This was done as a demonstration to show that it is not possible.

This is why the AIGP metric is used. The AIGP metric actually adds an additional BGP attribute right after step three, Originate in the BGP path selection algorithm. Only that will resolve the problem as shown in the lesson.

I hope this has been helpful!

Laz

27

Hi Lagapides,
Sorry, I repeat the Vinay question. I could not find answer or an explation.
After configruing AIGP, i belive lowest AIGRP metric will be prefered. However R1 chooses highest AIGRP metric and R6 chooses lowest AIGRP metric. ( I am little confused here )
In my CML the outputs are the same as yours. The problem, is why from R1 the best path does BGP use is with the higher aigrp-metric of 30? 30 > 20 , no?

28

Hello Dan

Thanks for pointing this out. I went into the lab and labbed it up myself and indeed, I found that with the AIGP setup described in the lesson, I get the same output as the lab. I see that R1 prefers 2.2.2.2 as the next hop, even though the AIGP is 30 compared to 20 for the 3.3.3.3 next hop.

On the contrary, from R6, it uses the lower AIGP metric of the 4.4.4.4 next hop. I will look into this with Rene to see why this is taking placeā€¦

Iā€™ll get back to you soon!

Laz

29

Hello Dan

Letā€™s take a look again at the entry of the 6.6.6.6 prefix on R1:

R1#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 5
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  456
    2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
      Origin IGP, aigp-metric 30, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  456
    3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
      Origin IGP, aigp-metric 20, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

The path chosen was using R2, or 2.2.2.2 as the next hop. You can see from the above output that it gives an aigp-metric of 30 whereas the alternate route via R3 gives an aigp-metric of 20. However, these are just the metrics that R4 and R5 have advertised to R2 and R3 respectively. They are not the total metric to the destination.

How do we determine the total metric used to choose R2? Well, R1 takes a look at the advertised AIGP metrics, and adds the local IGP metrics for each path.

So for communication via R2, we have an advertised AIGP metric of 30, plus a metric of 20 to reach R2 (the value in parentheses in the above output), for a total metric of 50.

For communication via R3, we have an advertised AIGP metric of 20, plus a metric of 40 to reach R3 (again in the parentheses) for a total of 60.

So R1 chooses the path with the lower metric of 50. If we look at the output of the routing table for the 6.6.6.6 prefix what do we see?

R1#show ip route 6.6.6.6 | include metric
  Known via "bgp 123", distance 200, metric 50
      Route metric is 50, traffic share count is 1

A route with a metric of 50, which is what we got using the above procedure.

Similarly, for traffic from R6 to the destination of 1.1.1.1, using the same procedure we see we have a metric of 50 when routing traffic via R4 and a metric of 60 for traffic via R5, therefore tha path via R4 is chosen. Does that make sense?

I hope this has been helpful!

Laz

30

Hi Laz,

Thank you very much! I understand, logic.

Kind regards,
Dan

31

Hi Laz, thanks you for your information. Hisham is asking about just to set much low MED in R2 and R4 in order to shift the forward and return path to R1-R2-R4-R6 direction. If like that, in this scenario, we dont need MED.

32

Hello Jack

Yes I understand. If we were to set the MED on R2 and R4 to a value of 10, then yes, in both directions you would be able to cause traffic to be routed via R2 and R4. However, even if R2 was set with a MED of 10, there is still the possibility that AS 456 will decide to route traffic via R5. The point here is that MED does not guarantee proper routing.

While MED can provide simple hints to neighboring ASes regarding preferred entry paths, it may not be enough for more complex and dynamic routing requirements. AIGP offers a more comprehensive and standardized approach, considering the entire path. The use of AIGP can provide more granular control and optimization of routing decisions across multiple ASes, particularly in more complex networks with diverse connectivity and policy requirements.

I hope this has been helpful!

Laz

33

Hi Rene
I didnā€™t really understand this lesson. I get very confused with the route maps. I donā€™t remember reading a lesson on route-maps yet. Even the previous attribute lessons referenced route maps but there isnā€™t a lesson before these ones that explained what route maps are or how to use them. This section (BGP Attributes) seems to assume that you already have an understanding of route maps.

34

Hello Pancratius

Yes, route-maps are an important part of this particular feature of BGP. Indeed, route maps are a very useful tool for manipulating routes in general when those are being advertised using BGP or other routing protocols. You can take a look at the following lesson to learn more about route maps and how they are configured:

In the meantime, let me just mention that a route map is a feature that allows for the modification and management of routing behavior and other route-related operations. It is often used to control and influence the distribution of routes, filter routes, and set conditions based on specific criteria.

Route maps resemble ā€œif-thenā€ statements in programming. Each route map contains one or more entries, each with a sequence number. Each entry can match certain criteria and then apply actions based on those matches. For example, in the lesson, a route map is created that matches the prefix 1.1.1.1 and modifies the MED value for that prefix. This modification is applied to the BGP update as it leaves the router and is sent to the BGP neighbor.

Take a look at the lesson shared above and if you have any further questions let us know!

I hope this has been helpful!

Laz

35

Ok thanks. I missed it because I was not looking at the CCNP course. I was literally just in the BGP section. I will go through the CCNA course first. Thanks

1 Like
36

I copied the configs and built a CML instance like yours. Unfortunately, this is the result when running a show ip bgp 6.6.6.6 on R1. I only see a route from one neighbor, not both. What am I doing incorrectly:

R1#show ip bgp 
BGP table version is 1, 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, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *    1.1.1.1/32       0.0.0.0                  0         32768 i
 * i  6.6.6.6/32       3.3.3.3                 20    100      0 456 i
R1#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 3
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  456
    3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
R1#
37

I read somewhere that, ā€˜AIGP (attribute code 26) is defined as optional transitive in RFC 7311. BGP routers that understand AIGP can update and compare it; routers that do not understand it will pass it along marked as ā€œpartial,ā€ per standard BGP rules for unknown optional transitive attributes.ā€™ Please clarify: is it transitive or not?

38

Hello Roger

The results that appear in your post are those that we also see in the section of the lesson where MED is configured. This can be determined from the fact that the 3.3.3.3 shows ā€œmetric 20ā€. AIGP doesnā€™t seem to be configured in your scenario here. Otherwise, you would see ā€œaigp-metricā€.

So I suggest you check your AIGP configuration, as well as your MED config. When you configure AIGP, you should go back to the config that you started off with, without the MED configuration, as suggested in the lesson. Let us know if this helps you in your troubleshooting process, and let us know if we can be of any further helpā€¦

I hope this has been helpful!

Laz

39

Hello Amogu

Thatā€™s an interesting point, thanks for sharing that! Actually, according to RFC 7311, it says the following:

In this document, we define a new optional, non-transitive BGP
attribute, called the ā€œAccumulated IGP Metric Attributeā€, or ā€œAIGP
attributeā€, and specify the procedures for using it.

So it is indeed optional, but it is non-transitive. Remember, a non-transitive attribute is one that, once received from another BGP peer, is never forwarded to other peers. The ā€œoptionalā€ part simply means that if it is not recognized, it is quietly ignored and not passed on to other BGP peers.

Note that a BGP router that generates the actual attribute will obviously advertise it. But it wonā€™t be readvertised by those routers that received it.

Can you explain where you saw this particular explanation so that we can further help you understand AIGP?

I hope this has been helpful!

Laz