AS prepend with iBGP

[Victor Frolov (VMcS)]

Hello,

During the configuration the routers managed by IOS (tested with 12.2 and 15.2), I found that the AS-path prepending does not work on iBGP sessions or when the route-map is used in a network statement. In both cases, the set as-path prepend route map command is ignored without an error message.

That behavior confirmed by some articles, but I cannot found the explanation for the reason of this brhavior. As well as I know, this behavior is not a part of BGP specification and, for exemple, there is no the limitation like this in Nokia (Alcatel) SROS.

This is not an academical question, I have the next use case where I need to manipulate with AS prepend in iBGP.

I have IP/MPLS network with full-meshed PE routers (RR are not used) and few servers with anycast IPv4 and IPv6 addresses. Some servers are directly connected to PE routers, but some servers are connected to CE routers.
CE has its own ASN and use eBGP to advertise server's IP anycast addresses to PE, which readvertise these adresses to the rest of PE be iBGP.

The same anycast addresses of the serves connected directly to PE routers are advertised by network command in bgp configuration. The expected behavior for the third PE in the network - to get for mentionned anycast address the route to the nearest server (nearest due to the lowest IGP cost to next-hop in BGP path selection).

However, if the nearest server is a server connected to CE, this route will be discarded following the AS path lenght compare - the prefix annonced from CE has CE's AS in the path (against the prefix annonced from PE where server is directly connected - this prefix is originated from PE with empty AS path).

To aligne the length of AS paths for the both cases, I would like to prepend the AS paths for the prefixes originated from PE by some foo AS.

But it does not work. The rout-map applied to network command has two actions : to set community and to set an AS prepend with a foo value. The route is well advertised by iBGP in the network, but when I look on the third PE, I see this prefix has a right community, but empty AS path. It's mean that rout-map is applied correctly, but AS prepend instriction was ignored.

Could you please explain the reason of this behavior? And what is a recommended solution?

Thank you!

With best regards,

Victor

[Dennis Mink]

IBGP peers do not prepend their ASN to the AS_PATH, because the NLRIs would fail the validity check and would not install the prefix into the IP routing table

[Victor Frolov (VMcS)]

Hello Dennis,

Thank you for your answer, but your quote from Troubleshooting BGP book do not explaine the subject and it still not clear for me.

I can not found what does the validity check consist. I suppose that the router check if for the prefix with IGP like origin, received from iBGP peer, the AS_PATH should be empty? But this is only my hypothesis. Do you know where the validity check is described on details?

RFC 4271 in the section 6.3 (UPDATE Message Error Handling) has nothing about origin/AS_path verification.

Only one point that could explain the mentionned behavior is :

Section 5.1.2 (AS_PATH) of the same RFC :

When a BGP speaker originates a route then:
...
b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero).

Nothing about "MUST include an empty AS_PATH" nor at least "SHOULD include an empty AS_PATH". Also, this is instruction for originator, there nothing said that receiver should (or must) check it and do not install the prefix into the RIB if the check is failed.

Also, in the same section :
Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration.

Well, we can say that it seems that Cisco follow to RFC' instructions, but on the other side, these instructions are not mandatory, as well as ignored by another network equipment vendors.

I try to understand:
- how validity check work exactly?
- what is real risk for network if AS_path prepending will be applied on the iBGP session? especially considering that I have the real use case described above, where the AS_path prepend applied to iBGP seems to be the best and logically correct solution.
- If in Cisco IOS (I guess that in IOS-XR the same behavior) is not possible to prepend as_path in iBGP, then what is recomended solution ? I guess that delete the AS path in the route received from eBGP peer in order to egalise the lengths of AS_paths obviously is not a good solution.

Thank you!

With best regards,

Victor

[Georg Pauwen]

Can you draw out (post a schematic drawing) of what you are trying to achieve ? AS-PATH indeed will not work for iBGP, for the reason stated by Dennis...

[Victor Frolov (VMcS)]

Hello Georg,

I have attached the diagram to this post.
Unfortunately, the answer of Dennis do not explain the behavior, also there is no solution or workaround.

With best regards,

Victor

[bobinsid]

Hello Victor,

Looking at your diagram you mentioned "PE3 receives two routes for ServerIP, from PE1 and PE2". May I know how you received a route from PE1 as PE1 received the route from a iBGP peer and by default it cannot send a iBGP learned route to another iBGP peer(PE3)?  
Correct me if I missed any specific configs you mentioned above.

Regards
Bobin

[Celcius]

You can influence that decision by changing one of the attributes that is taken into consideration before the AS_PATH is. The Best Path Selection algorithm follows the following order in selecting the best path (assuming the preconditions are met, i.e. e.g. Next-Hop must be accessible/reachable, AS_PATH must not contain our ASN, and so on...):

1. Weight (higher, more preferable; local per device - not recommended)

2. Local_Pref (higher, more preferable; local per AS - recommended)

3. Locally injected routes

4. AS_PATH length (shorter, more preferable)

5. Origin code (IGP > EGB > ?)

6. MED (lower, more preferable)

7. Neighbor type (eBGP-learned-routes, more preferable)

8. IGP Metric to the Next-Hop (lower, more preferable)

9. Peer Rtr-ID (lower, more preferable)

10. NLRI Age (oldest, more preferable; only applicable to eBGP ones)

11. Cluster List (shorter, more preferable)

12. Peer IP (lower, more preferable)

So you can simply change Local-Preference in one of your PEs, i.e. make it higher in one to be preferred by the entire AS, or lower on the other to make it less preferred in the entire AS.

[paul driver]

Hello

As-path seq is advertised to all ibgp peers but to manipulate ibgp peers, you can  utilize Local -Preference attribute so your internal ibgp peers take a alternate path based on the higher LP value it receives 

As for the next-hop-self command this needs to be applied on the PE2 rtr towards PE1 & PE3 ibgp peers and not CE rtr