Routing
Highlighted
Routing

Filtering via as-path in Outbound BGP Policy

‎09-02-2013 08:22 AM

This may or may not be possible and I admit there are several other ways of doing it but I just want to confirm if my logic is correct.

 

In this simplistic scenario, there are two BGP peers, a Sender and a Receiver.

 

The sender is sending the following routes to the receiver :-

 

inet.0: 878 destinations, 2052 routes (877 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  0.0.0.0/4               192.168.0.30                            110047427 1620 61671 I
  0.0.0.0/5               192.168.0.30                            110047427 1620 61671 27075 I
  1.64.0.0/10             192.168.0.30                            110047427 1620 61671 I
  1.84.160.0/20           192.168.0.30                            110047427 1620 33112 I
  1.96.0.0/11             192.168.0.30                            110047427 1620 33112 63164 40776 51777 I
  1.161.192.0/21          192.168.0.30                            110047427 1620 33112 30404 32138 45045 I
* 1.166.89.0/24           192.168.0.30                            110047427 56422 47123 34908 57085 3090 19128 21300 I
  1.176.0.0/12            192.168.0.30                            110047427 1620 33112 49129 16320 52954 I
  2.0.0.0/7               192.168.0.30                            110047427 1620 61671 60177 3091 5721 1770 35283 6098 41407 I
* 3.49.128.0/19           192.168.0.30                            110047427 56422 7923 42335 17359 9293 38097 38522 61520 I
  3.189.0.0/16            192.168.0.30                            110047427 1620 33112 41164 7136 6370 35389 39823 16965 I
  3.214.25.0/24           192.168.0.30                            110047427 1620 61671 62186 11282 7796 I
* 4.0.0.0/6               192.168.0.30                            110047427 56422 235 4628 20905 9158 9476 23720 14923 ?
  4.16.128.0/17           192.168.0.30                            110047427 1620 33003 49129 50466 22491 57331 43943 48281 I
* 4.53.208.0/21           192.168.0.30                            110047427 36024 50292 3128 3431 18053 I
  4.84.128.0/18           192.168.0.30                            110047427 1620 33112 63164 28164 56111 39848 I
  4.173.41.0/24           192.168.0.30                            110047427 1620 33003 30404 22363 54666 40669 53365 I
  6.83.176.0/21           192.168.0.30                            110047427 1620 33003 63164 14519 59474 20051 I
  7.0.0.0/8               192.168.0.30                            110047427 1620 33112 52411 37841 5705 22477 16750 I
  7.211.182.0/26          192.168.0.30                            110047427 1620 61671 27075 I
  8.0.0.0/5               192.168.0.30                            110047427 1620 33003 60177 56572 I
  8.89.200.0/22           192.168.0.30                            110047427 1620 33112 60177 I
  9.25.169.128/25         192.168.0.30                            110047427 1620 61671 52411 15641 16003 I
* 9.33.64.0/18            192.168.0.30                            110047427 36024 37067 11245 27513 33190 13781 5510 43311 I
  9.70.67.0/24            192.168.0.30                            110047427 1620 61671 49129 31278 I

 Now, the requirement is that the sender not advertise/receiver not receive any router advertised directly to the sender by AS 110047427.

 

I first tried to use the following export policy for the session at the sender :

 

lab@Sun# show policy-options 
policy-statement PS_AS_1620 {
    term 1 {
        from {
            protocol bgp;
            as-path AS_1679.12483;
        }
        then reject;
    }
}
as-path AS_1679.12483 "110047427 .*";
lab@Sun# show protocols bgp 
group AS_1620 {
    export PS_AS_1620;
    peer-as 1620;
    neighbor 192.168.1.3;
    neighbor 192.168.1.4;
}

 

 When I try to see the routes being advertised now (after a soft and a hard clear on the session), I see the following :-

lab@Sun# ...vertising-protocol bgp 192.168.1.4 aspath-regex ^110047427.*    

inet.0: 874 destinations, 2002 routes (874 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 1.166.89.0/24           Self                                    110047427 56422 47123 34908 57085 3090 19128 21300 I
* 3.49.128.0/19           Self                                    110047427 56422 7923 42335 17359 9293 38097 38522 61520 I
* 4.0.0.0/6               Self                                    110047427 56422 235 4628 20905 9158 9476 23720 14923 ?
* 4.53.208.0/21           Self                                    110047427 36024 50292 3128 3431 18053 I
* 9.33.64.0/18            Self                                    110047427 36024 37067 11245 27513 33190 13781 5510 43311 I
* 13.72.0.0/14            Self                                    110047427 36024 I
* 14.112.0.0/13           Self                                    110047427 36024 235 40715 37080 2972 49542 1158 45383 I
* 17.120.0.0/14           Self                                    110047427 36024 47123 23881 3357 28731 61363 27064 6147 ?
* 19.32.0.0/12            Self                                    110047427 36024 50292 21137 647 50666 27452 50874 I
* 24.32.0.0/13            Self                                    110047427 36024 I

So, I would say the export policy had no effect at all.

 

But the same policy filters as desired on the inbound side. Same policy, applied to the Receiver as an import policy. That means the receiver filters out all the routes that have a 110047427 at the start of the AS path. 

 

Is this normal or is this a flaw in my logic?

 

Thanks in advance,

 

Nic

5 REPLIES 5
Routing

Re: Filtering via as-path in Outbound BGP Policy

‎09-02-2013 08:37 AM

Modify the AS-path as follows:

 

as-path AS_1679.12483 "^110047427 .*" 

[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Routing

Re: Filtering via as-path in Outbound BGP Policy

[ Edited ]
‎09-02-2013 08:55 AM

I have tried that particular RegEx and it did not work either.

 

In any case, as per http://www.juniper.net/techpubs/en_US/junos12.3/topics/usage-guidelines/policy-configuring-as-path-r... as far as the ^ character is concerned:-

 

1. As per my understanding, the character is used for Community attribute only and not AS Path

2. The character is added implicitly so that makes its use optional.

 

This is also visible in the following example from the doc:

 

Path whose first AS number is 123 and second AS number is either 56 or 78

123 (56|78)

123 56

123 78

 

Thanks,

 

Nic

Routing

Re: Filtering via as-path in Outbound BGP Policy

‎09-02-2013 12:30 PM

When used with community, it represents a single character; when used with with AS path, it represents the complete AS number.

[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Routing

Re: Filtering via as-path in Outbound BGP Policy

‎09-02-2013 01:06 PM

I see. Point noted. But it is implicit in Junos so the following two regex would be the same :-

 

 "^110047427 .*" =  "110047427 .*"

 

And on the inbound policy, I can verify this as such.

 

The crux of the problem still remains. Is this policy, even modified with the ^ character supposed to work as an export policy? I can corroborate that on Junos 11.4 and 12.1, it does not.

 

Reiterating, the same policy has the desired effect when applied as import on the receiver but does not have the effect when applied as an export policy on the sender.

 

Thanks for pointing out the intricacies of the ^ character.

 

Nic 

Routing

Re: Filtering via as-path in Outbound BGP Policy

‎09-02-2013 01:40 PM


Yes it must be set as an export policy to the neighbors, because you are looking for routes that have an origin in AS 110047427 and rejecting them, meaning they should not be advertised to the neighbors. I should have been more careful. And I think you are correct that this would mean the same. I would say try this for the AS path. I have not worked on the routing protocol for a while, and I do not have a lab for testing and making sure now. Try it this way instead. I am not sure why the first time did not work.
May be it should have been;

 

"110047427*" but if it fails to achieve the objective, then try this

 

".* 110047427"

If I am not mistaken, the . represents a single AS, but I will research later.

[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]