BGP Influencing inbound path

[paddyxdoyle]

Hi All,

I'm trying to influence our routing so that traffic that is coming into our network via a certain AS number will hopefully avoid that AS number and take a different path. I'm thinking of doing this using AS prepends to the specific AS number, is the following example correct please?

The AS i want to avoid is listed below as 22222, the "match community 2" statement is a community ACL we use to match ours and our customers prefixes that we advertise to the net.

ip as-path access-list 1 permit _22222$

!

route-map test-out permit 5

match as-path 1

set as-path prepend 11111 11111 11111 11111

!

route-map test-out permit 10

match community 2

!

The reason behind this is we are trying to get a reliable connection back from a host. This hosts AS has two paths out, one is very unreliable and the other is fine. So hopefully by sending our prefixes to the unreliable AS with prepends, the target AS will see this information and take the better path back to our network.

If this is correct, Is this the best way to achieve these results?

Thanks in advance

PJ

[Edison Ortiz]

If you want your host to be advertised with a preferred path via one AS, you need to match your host route and set a as-prepend out to the neighbor via the unwanted path.

For instance:

ip prefix-list host->22222 permit host [host]

route-map test-out permit 5

match ip prefix-list host->22222

set as-path prepend 11111 11111 11111 11111

!

route-map test-out permit 10

HTH,

__

Edison.

[vdadlaney]

Hi,

If applicable you could also leak a more specific route to the preferred AS hence traffic will always come in via the path that has the more specific route.

It would be helpful if you could give a bit more details on the topology if possible. Thx

[mheusing]

Hi PJ,

You are right that AS path prepending is the only way to possibly achieve a desired return traffic pattern beyond the ASes you are peering with.

The technical reason is that the well-known mandatory attributes in BGP are origin, next hop - which changes as routes are propagated - and AS path. So the latter is the only adjustable attribute, where we can be sure it will be propagated beyond the neighboring AS.

As you also might know, there are "better" attributes like Local Preference, which basically means that any AS in the internet can ignore your path prepending and implement a policy conflicting with yours. There is a big "A" in AS, i.e. they are autonomous, which is why I wrote "possibly achieve" above.

Be careful with AS path prepending however, as you cannot only do this for a "connection back from a host". The AS path prepended will be seen by the whole internet and thus change the routing behaviour of all ASes out there.

After this introduction let me summarize what I understood your situation is. You are concerned about traffic returning to your AS following the BGP updates you announce to the internet - your "community 2" routes - especially from a particular host. The topology is either:

A) your AS is 11111, host is in AS 55555 and should not go through 22222, inbetween there are many ASes and you are peering with at least two e.g. 33333, 44444.

AS 55555 and any other AS inbetween 11111 and 55555 might have a policy conflicting with yours. E.g. AS 55555 might choose AS 22222 as prefered exit to the internet (with weight or local preference), because AS 22222 is cheaper for them, they have a faster connection to them or the like.

Thus, there is NO solution, which will ENSURE your desired result.

B) your AS is 11111, host is in AS 55555 and traffic should not go through 22222, which you are peering with together with another AS e.g. 33333

The config you gave is not achieving the desired result. What you can try to do:

router bgp 11111

neighbor 2.2.2.2 remote-as 22222

neighbor 2.2.2.2 route-map AS-Prep out

neighbor 3.3.3.3 remote-as 33333

route-map AS-Prep permit 10

match community 2

set as-path prepend 11111 11111 11111 11111

route-map AS-Prep permit 9999

You can also try this for case A) and cross fingers ... ;-)

Hope this helps! Please use the rating sytem.

Regards,

Martin

[paddyxdoyle]

Thanks for all of your answers so far.

I should explain some more what i'm trying to do

There is a host in an AS number which i will call 55555, this AS has two paths into it. On one path there is a lot of packet loss constantly via 33333 and on the other there is none via 44444

I can influence our outbound traffic to take the best path with no packet loss to AS 55555 via 44444 however i need to try and influence the return traffic back into our network also by the same path.

Using AS Path prepends is not really an option as i don't want this change to affect all of our traffic patterns to and from the Internet, i need it to be as specific as possible.

I'm now thinking that vdadlaney`s solution will work the best and we should advertise a more specific prefix to the prefered destination and influence the path back into our network that way. As i'm sure you have guessed I have never done this before, we currently advertise 2 prefixes, one is a /19 and the other a /21, out to the Internet.

The prefix that the customer in questions uses is part of the /19. The customer has a /28 subnet so my understanding is that we would aggregate the customers /28 into a /24 and advertise that out via this prefered path to the destination host.

Forgive my ignorance here but would i also need to create another network statement along side my /19 to deaggregate for this /24 network, for example:

network 10.1.0.0 mask 255.255.224.0 (our /19)

network 10.1.1.0 mask 255.255.255.0 (/24 block customer uses)

ip prefix-list specific seq 10 permit 10.1.1.0/24

route-map traffic-out permit 5

match ip address prefix-list specific

!

route-map traffic-out permit 10

match community 2

!

!community2 includes our /19, /21 and customer prefixes.

Hope this all makes sense!

Thanks

PJ

[mheusing]

Hi PJ,

The idea with the /24 announced besides your /19 combined with the AS path prepending gives you the best chances to achieve your result. The statements in my first post still apply - you cannot enforce a policy upon another AS.

A potential config:

The config would then look like:

network 10.1.0.0 mask 255.255.224.0

network 10.1.1.0 mask 255.255.255.0

ip route 10.1.1.0 255.255.255.0 Null0 254

ip prefix-list specific seq 10 permit 10.1.1.0/24

route-map traffic-out permit 5

match ip address prefix-list specific

set as-path prepend 11111 11111 11111 11111

!

route-map traffic-out permit 10

match community 2

!

Remember, without AS path prepending announcing additionally the /24 would not change the path selection in the remote AS, as the attributes of the /19 and the /24 are identical.

Note again: in case you are NOT peering with 33333 directly, there is no guarantee that you can influence the path selection in AS 22222.

So give it a try with your AS path prepending and if it does NOT work, remove it. To get a better understanding of what your routes look like in the internet, please use the route-servers and looking glasses provided by other SPs. They will help you to understand remote routing decisions. A starting point to access those can be www.traceroute.org - simply because I easily can remember the URL.

Hope this helps! Please use the rating system.

Regards,

Martin

[paddyxdoyle]

Hi Martin,

Thanks for the reply, i'll give this a try tonight. Unfortunately the AS in question is a Russian ISP and i can't see their looking glass anywhere.

I'll report back.

Cheers

PJ

[paddyxdoyle]

Cheers Martin and all, it's working now.

:)