This topic is to discuss the following lesson:
I’m glad to be the first to say, GREAT LESSON man 
Thanks @joseph!
AIGP is easy to configure but it does take time to explain what the issue is with “regular” BGP in a scenario with multiple IGPs, and how things like MED/AS Path won’t fix it.
Rene
One thing Rene, I noticed in the config on R1 at the end of the lesson, there are two route-maps.
I think the highlighted one needs to be removed.
Hello Joseph
Yes, I think you are correct! I’ll let Rene know.
Thanks!
Laz
Hi Rene,
First of all, thank you very much for sharing this post.
However in section 1.2.1.2, R4 keeping MED 30 and R5 keeping MED 40 they why would AS123 prefers path via R3-R5 ??
Please correct me if I misunderstood anything.
Hello Abhishek
Yes, you are correct, the configuration on the route map on R5 should be set metric 20 and not 40. I will let Rene know to correct this…
Thanks in advance!
Laz
Hello @mandeabhi10,
Sorry for the confusion. R5 should set the metric to 20, like in the picture. I just fixed this.
Rene
Hi Rene,
Thank you for the post 
- In the second diagram of section 1.2, if we advertise R5 with high MED value then i think we can send traffic from AS 456 to AS123 via R4.
- In Same diagram if we use AS-PAth prepending then also i think we can achieve optimal path.
- 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 )
- Could you also explain how AIGRP metric calculated in that diagram ?
Correct if i misunderstood anything.
thanks again.
Hello Vinay
I’ll try to respond to each question specifically.
- Remember that the MED value influences how neighboring ASes enter your AS. Changing the MED value of R5 will not affect traffic from AS356 to AS123 in any way. It only affects traffic in the other direction.
- AS-Path prepending will not work, for the same reason that MED did not work.
For 3 and 4, I believe there is a typo in the lesson. The diagram shows the costs of the OSPF links between routers, but the configurations as well as the show output display different values. It is true that the lowest metric should be chosen, and according to the diagram it was (but not according to the show output.)
I will let Rene know of the typo. Thanks for being thorough and pointing that out!
I hope this has been helpful!
Laz
Hello Rene,
great lesson and easy to understand as always. However I do have a question that couldn’t find a good answer so far.
AIGP is an optional non-transitive attribute, like MED, which means it stays within the AS. When a router receives a prefix with such attribute, it must remove it before sending it to eBGP peers right? In your topology, when R1 advertises the prefix with AIGP to R2 and R3 they can both use it. However, I would expect that they will remove it when they advertise it to R4 and R5. At least this is true for MED. Why AIGP is an exception to this rule?
Hello Ilias
AIGP is non-transitive in the sense that the accumulated metric that is determined using AIGP occurs only within the AS. You can’t accumulate the metric along the path of R1, R2, R3, and R4 using AIGP simply because that path traverses two ASes.
However, that accumulated metric from within the AS is then advertised to neighboring ASes using eBGP. This does not violate the non-transitive nature of the attribute.
Similarly, if you look at the MED attribute lesson, you will find that the MED attribute is exchanged between autonomous systems.
I hope this has been helpful!
Laz
1 Like
Hello Laz,
many thanks for your reply. Based on that, I would like your feedback on the below as well.
I had the impression that non-transitive attributes are not advertised to eBGP peers. What is the difference between transitive and non-transitive then?
That’s true but only if MED is applied via a route-map directly to the BGP neighbor (as shown in the examples). Correct me if I am wrong, but the order of operations here is important. If for example I use the network command and apply a route-map, then MED won’t be advertised to eBGP peers. The local router would have already processed the MED value in its BGP table and since the attribute is non-transitive it won’t be advertised to neighboring ASes.
From the above I understand that if AIGP has been advertised, let’s say, 3 ASes away, then it will still show the value that originally created in the first AS. The intermediate ASes will never touch/add on that value?
Hello Ilias
That’s a fair point. Doing a bit more research, the definition of “transitive” and “non-transitive” seems to be a bit blurry. In some cases, I have found that it is defined as an attribute that is NEVER exchanged between eBGP peers. In others, it seems to indicate that it is an attribute that if received from an eBGP peer, should not be further propagated, but will be taken into account for the local AS.
Actually, I’ve labbed this up and found that the MED will indeed be advertised to neighboring ASes if you use a route map on the network command. So this seems to support the latter definition of non-transitive. However, I found that this MED value is never further propagated to other ASes, which again supports this notion.
Actually, like the MED in the previous example, the AIGP will only be shared with the neighboring eBGP peer and will not be further propagated to other ASes. Again, it seems that AIGP and MED, both non-transitive attributes, are behaving in the same way.
I hope this has been helpful!
Laz
1 Like
Many thanks for your time and explanations Lazaros. Really appreciated.
1 Like
Might be a stupid question, but what if I kept the MED at R4 and R2 quiet low so traffic egressing to AS 456 and AS 123
goes through this link between R2 and R4 , this will achieve the optimum path without AIGP , correct ?
1 Like
Hello Hisham
In the lesson, Rene attempted to use MED to resolve the issue. You can see that the modified MED resolves the issue in one direction, but it does not resolve it in the other. In order to resolve it in both directions, you need AIGP.
I hope this has been helpful!
Laz
Hello Rene,
First of all, thanks for the great lesson on AIGP! I, however, have a little difficulty in understanding why R1 chose R2 as its next hop after enabling AIGP.
From the topology, in AS 456, the OSPF metric to 6.6.6.6/32 is 20 for R4 and 10 for R5. When this AIGP metric is being advertised to their corresponding eBGP peers (R4 to R2 and R5 to R3), R2 should have a higher AIGP metric than R3. Despite a higher AIGP metric on R2, why does R1 still prefer R2 as its next hop? I believe the other attributes like weight, LP and Origin are similar for both R2 and R3.
Please help me understand what I’m missing out here 