What I meant was, doesn't the prepend get propagated across AS? and if I say I add
my AS number 3 times going toward one provider for a particular subnet that I am advertising no matter what, from the rest of world point of view the preferred route is never going to be toward the provider that is showing the multiple AS path to me? That is what I expected but that's not what happened.
I have two subnets I am advertising to isp A and isp B
All being equal there are a number of factors that will influence whether traffic toward 188.8.131.52 or 184.108.40.206 will enter me via isp A or isp B. However, to me if I advertized 220.127.116.11 and 18.104.22.168 to ISP A and prepend my AS multiple times, it seems to me that traffic destined for 22.214.171.124 or 126.96.36.199 will always come via ISP B because it will have the shortest AS path. My question is that when I create the route-map to influence the AS-PATH can it be done on a subnet by subnet basis by matching on an address in the route map? If so, then I am puzzled why it didn't work. I artificially increased the AS-PATH length for all networks going to ISP A yet I continued to see traffic coming in vial ISP A anyway.
As I explained in my previous post, the as path length is not the first thing to be considered when comparing to BGP paths. For instance, the local preference as a higher preference in the BGP best path selection algorithm.
This means that if your provider sets the local preference higher for their customer routes than for their peer and transit routes, the longer as path will have no affect and the routes received directly from you will be preferred even anyway.
One way to address this is to verify whether your provider allow you to influence the local preference value they will use on your directly received prefixes. Providers very often allow this to happen by looking at community values received from you and set the value accordingly.
For example, let's say your provider is 60999, they would accept the following value and act accordingly:
60999:70 sets the local preference to 70
60999:80 sets the local preference to 80
and so on
If your provider offer tat possibility, it will allow you to tell your provider to prefer peer and transit routes over your directly received routes via the local preference setting.
Harold Ritter Sr. Technical Leader CCIE 4168 (R&S, SP) firstname.lastname@example.org México móvil: +52 1 55 8312 4915 Cisco México Paseo de la Reforma 222 Piso 19 Cuauhtémoc, Juárez Ciudad de México, 06600 México
I defer to your expertise but from what I read about local preference this is something my provider can set on incoming routes. I can't set it toward them. It is an internal AS not cross AS. Even so to me it is irrelevant. So what if provider A or provider B sets a local preference. This can't go beyond their AS boundary. AS path should be propagated across AS boundaries. I don't understand you comment about transit routes. These are not transit routes, they are direct to each provider. Believe me, I would like to understand this better.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...