Special AS-path filtering case

[Justin-]

Hi guys,

Let's say I have this topology with interconnected ASes:

                                    AS40

                                       |

AS10 -------------- AS30

     |                                 |

     ------- AS20--------

Is it possible to make AS10 deny any traffic from AS30 unless the latter is the source (from AS10 configuration, not from AS30) ? I know how to do it from AS30, but I doubt it is feasible from AS10 (I tried with no luck).

Thanks,

Justin

[paul driver]

Hello

---

@Justin- wrote:

Hi guys,

Let's say I have this topology with interconnected ASes:

                                    AS40

                                       |

AS10 -------------- AS30

     |                                 |

     ------- AS20--------

Is it possible to make AS10 deny any traffic from AS30 unless the latter is the source (from AS10 configuration, not from AS30) ? I know how to do it from AS30, but I doubt it is feasible from AS10 (I tried with no luck).

---

ip as-path access-list 10 deny _30_40$
ip as-path access-list 10 permit .*

router bgp 10
neighbour x.x.x.x (as30) filter-list 10 in

[Justin-]

@paul driver,

Thanks for your reply. Actually, I already tried several possibilities, including this one. Your solution is sort of the opposite of what I want. With this configuration, the traffic from AS10 is routed through AS20-AS30 to reach AS40. What I'm searching for is a way to allow direct traffic from AS30 to AS10 but NOT transit traffic from AS40 through AS30 to AS10.

As an example:

- (AS30 -> AS10): directly to AS10

- (AS40 -> AS10): AS40 -> AS30 -> AS20 -> AS10

All of this by configuring AS10 *only* (not AS30).

[Georg Pauwen]

Hello, 

try:

ip as-path access-list 10 permit ^30$

!

router bgp 10
neighbour x.x.x.x (as30) filter-list 10 in

[paul driver]

Hello

---

@Justin- wrote

Thanks for your reply. Actually, I already tried several possibilities, including this one. Your solution is sort of the opposite of what I want. With this configuration, the traffic from AS10 is routed through AS20-AS30 to reach AS40. What I'm searching for is a way to allow direct traffic from AS30 to AS10 but NOT transit traffic from AS40 through AS30 to AS10.

As an example:

- (AS30 -> AS10): directly to AS10

- (AS40 -> AS10): AS40 -> AS30 -> AS20 -> AS10

All of this by configuring AS10 *only* (not AS30).

---

Well it is possible however Im not so sure if its a recommended approach as it could be very administrative

To accommodate the return traffic from AS40 ,AS-prepend on AS10 towards AS30 and apply local PBR at AS30 for it local routes return path via AS10

Rtr AS10

route-map AS-Prepend permit 10
 set as-path prepend 10 10 10

ip as-path access-list 10 deny _30_40$
ip as-path access-list 10 permit .*

router bgp 10
neighbour x.x.x.x (as30) filter-list 10 in
neighbor x.x.x.x (as30) route-map AS-Prepend out

RTR-AS30
ip local policy route-map PBR
access-list 100 permit ip host x.x.x.x  x.x.x.x y.y.y..y

route-map PBR permit 10
match ip address 100
set ip next-hop <AS10 next hop>

[Jon Marshall · Accepted solution]

If the intention is to influence the traffic both ways then as far as I know you can't do this. 

You can apply Georg's suggestion and this would mean traffic to AS 30 would go direct and traffic to AS 40 would go via AS 20 which is part of what you want. 

But traffic inbound to AS 10 from AS 40 will go direct from AS 30 (return traffic being routed the long way round) and there is nothing you can do as far as I can see on any router because you are trying to route based on source IPs. 

Jon

[Justin-]

@Jon Marshall

Thanks for confirmation. In fact, it was my first guess as it seems logical not to choose for another AS how to route its own traffic.

[paul driver]

Hello

@Justin- is the solution provided with PBR not applicable to you then?

[Justin-]

Sorry @paul driver, I forgot to give you a feedback.

Indeed, this solution does not fit as I did not want to touch AS30, if possible. I was almost sure it was not possible and was searching for either *the* solution (in case I was wrong) or for confirmation. @Jon Marshall's answer seems to confirm what I was thinking, just as your answer. However, thanks for your reply and the effort.