Routing

HI Experts 

 i am running a INTER_AS MPLS VPN OPTION C with the other ISP  . I am trying to filter MPLS VPN Routes based on the community  With regex .  Does any one can let me know if there is widcard support on target commnunities . 

set protocols bgp group ebgp-TEST-AS-mpls-peer type external
set protocols bgp group ebgp-TEST-AS-mpls-peer local-address 10.10.10.10
set protocols bgp group ebgp-TEST-AS-mpls-peer import ebgp-TEST-AS-mpls-peer-community-filter
set protocols bgp group ebgp-TEST-AS-mpls-peer family inet unicast
set protocols bgp group ebgp-TEST-AS-mpls-peer family inet-vpn unicast
set protocols bgp group ebgp-TEST-AS-mpls-peer family l2vpn signaling
set protocols bgp group ebgp-TEST-AS-mpls-peer peer-as 65000
set protocols bgp group ebgp-TEST-AS-mpls-peer local-as 64900
set protocols bgp group ebgp-TEST-AS-mpls-peer local-as loops 2
set protocols bgp group ebgp-TEST-AS-mpls-peer neighbor 10.10.10.9
set protocols bgp group ebgp-TEST-AS-mpls-peer vpn-apply-export
set protocols bgp group ebgp-TEST-AS-mpls-peer export export-test-mpls-peering

set policy-options policy-statement ebgp-TEST-AS-mpls-peer-community-filter term internal-as-block from as-path 64900
set policy-options policy-statement ebgp-TEST-AS-mpls-peer-community-filter term internal-as-block then reject
set policy-options policy-statement ebgp-TEST-AS-mpls-peer-community-filter term drop-community from community ORIG-IN-AS64000
set policy-options policy-statement ebgp-TEST-AS-mpls-peer-community-filter term drop-community then reject
set policy-options policy-statement ebgp-TEST-AS-mpls-peer-community-filter term accept-all then accept

set policy-options community cloud-customers members "target:^490:...."
set policy-options community ORIG-IN-AS64000 members target:64900:65000

set policy-options policy-statement export-test-mpls-peering term reject-AS64000 from community ORIG-IN-AS64000
set policy-options policy-statement export-test-mpls-peering term reject-AS64000 then reject
set policy-options policy-statement export-test-mpls-peering term accept-cloud-customer from community cloud-customers
set policy-options policy-statement export-test-mpls-peering term accept-cloud-customer then accept
set policy-options policy-statement export-test-mpls-peering term last then reject

when the export policy has the term last ( as mentioned in  policy export-test-mpls-peering ) . All vpn routes stops advertising if i take it out all the mpls vpn routes are being advertised . So the Question is policy is not working as it should be . But my doubt is on the widcard mask on the target communities suuport 

Platform MX80 Junos [11.4R7.5 ] 

Thanks for replying back 

Hi Gosain,

could you clarify first if this is Option B or Option C?

Also, could you also explain what type of RTs are you intending to match with:

set policy-options community cloud-customers members "target:^490:...."

and what happens when you change the 'term accept-cloud-customer' only from this policy?:

set policy-options policy-statement export-test-mpls-peering term reject-AS64000 from community ORIG-IN-AS64000
set policy-options policy-statement export-test-mpls-peering term reject-AS64000 then reject
set policy-options policy-statement export-test-mpls-peering term accept-cloud-customer from community cloud-customers
set policy-options policy-statement export-test-mpls-peering term accept-cloud-customer then accept
set policy-options policy-statement export-test-mpls-peering term last then reject

and refer to another non-regexp community instead? (i.e. target:4900:xxxx)

Thanks,

Gonzalo

Hi Gonzalo 

I have put an attachment in PPT with topology and notes .   This is more like Option B . 

Also, could you also explain what type of RTs are you intending to match with:set policy-options community cloud-customers members "target:^490:...."

Gosain : RT are in range of 490:25xx  to 490:35xx  specified as vlan ids .

and what happens when you change the 'term accept-cloud-customer' only from this policy?:

gosain : Doesnt make any different advertise the whole lot to my ISP . I.e target with 490:xxxx and target:64900:65000

and  i want to stop advertising the RT 64900:65000 to my ISP  but want to advertise target:490:xxxx to ISP 

gonzallo : and refer to another non-regexp community instead? (i.e. target:4900:xxxx)

At the moment the VRF import and export policies are accepting the routes in each vrf using the specifiec targets  for each customer. But that does  not help in export policy for stopping the unintended advertisement of route targets .  I am ok with individuals vrf controling the routes import and export . 

Hope this helps 

Attachment(s)

MPLS.pptx   74 KB 1 version

tried to change the community from regexp to single community e.g target:490:2522 ... and accep the polcy only with cloud customer ( without term last  reject  and without term orgin-in AS ) 

still does same things . advertising the all the routes to ISP PEER and not the 490:2522 specific routes only . 

Hi Gosain:

Also, could you also explain what type of RTs are you intending to match with:set policy-options community cloud-customers members "target:^490:...."

Gosain : RT are in range of 490:25xx  to 490:35xx  specified as vlan ids .

Can you try with a regexp like the following?

[edit policy-options community cloud-customers]
root@cr8# show
members "target:490:[2-3]5.*";

Please make sure that ^ is removed from your regexp, it is originally intended to match the beginning of the complete community attribute, not a particular field. The ":" character is actually your delimiter among fields.

tried to change the community from regexp to single community e.g target:490:2522 ... and accep the polcy only with cloud customer ( without term last  reject  and without term orgin-in AS ) 

still does same things . advertising the all the routes to ISP PEER and not the 490:2522 specific routes only . 

If I understand correctly, I believe that the issue here is that you have a single accepting term in the eBGP export policy, but still the default BGP policy to advertise routes applies in the end because there is no final reject.

Thanks,

Gonzalo

Thanks Gonzalo , 

regexp changed to "target:490:[2].*" done the magic for me .

Could you please also care to explain of the vpn-apply-export statement to the bgp group has any value here . My understanding is that it evaluates the VPN first then bgp policy . 

However i have removed the policy but things seems to be working fine then i have delete the family " route-target " also from the bgp group as well and things seems alright .

Do we need to have the vpn-apply-export and route-target statement in the bgp hierarchy or its has no functional value here . 

thanks 

Gaurav 

Hi, 

I have a similar requirement for InterAS L3VPN Option B whereby I need to filter out specific RTs sent to the peer.

Was thinking of tagging at our PE end all routes to be exported in the L3VPN with a particular community say 'community 65000:1' and at the ASBR apply export policy to export routes matching this community. Was hoping that would provide more granular control into what we are exporting to the peer.

Below is the config

PE side:-

policy-options {

 community TEST members 65000:1;

 community RT-65000:100 members target:65000:100;

 policy-statement VRF-EXPORT {

  term T1 {

   from {

    protocol static;

    tag 100;

   }

   then {

    community set RT-65000:100;

    community add TEST;

    accept;

   }

  }

  term DEFAULT-REJECT {

   then reject;

   }

 }

}

routing-instances {

 TEST {

  ........

  vrf-export VRF-EPORT;

  .......

}

ASBR end:

protocols {

 bgp {

  group MPLS-INTERAS-B {

   ....

   family inet-vpn {

    unicast;

   }

   .....

   export EXPORT-TO-PEER;

  }

 }

}

policy-options {

 community TEST members 65000:1;

 policy-statement EXPORT-TO-PEER {

  term T1 {

   from {

    protocol bgp;

    community TEST;

   }

   then {

    community delete TEST;

    accept;

   }

  }

  term DEFAULT-REJECT {

   then reject;

  }

 }

}

Appreciate to have your thoughts on this.

Will be implementing this config soon and will be able to see how it goes then.

hi you need to use

if i understand it correct

PE --- ASBR(1) ------->ASBR(2) - PE2

@ASBR1

1. "vpn apply export " in the bgp neighbor hierarchy

2.  under policy statements you should accept the  community accept and last term reject .

3 . Apply the policy statement as export on bgp neighbor .

NB  " i have observed that when you apply vpn-apply-export statement or route target statement in bgp group hierarchy . bgp session resets. so better to try that in outage window .

Hi,

Thanks for the feedback.

Agree for the 'vpn-apply-export'. Found out from below post (Message 5), this would be required to effectively apply the export policy on bgp protocol level.

http://forums.juniper.net/t5/Routing/quot-VPN-Apply-Export-quot-Advertised-VPN-routes-removed-after/td-p/166610

Also, this KB: https://kb.juniper.net/InfoCenter/index?page=content&id=KB27326&actp=search

So, I believe this would be an alternative means of filtering the exported inet-vpn routes to the peer.

Thank You

Ashvin

Hi, 

I haven't tested myself, but please note the difference:

12.2 release

http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/policy-bgp-communities-extended-communities-match-conditions-overview.html  states that: "Regular expressions are not supported for the extended communities attribute."

12.3 release

http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/policy-bgp-communities-extended-communities-match-conditions-overview.html states: "Regular expressions are also supported for the extended communities attribute.The only exception is for VPN import policies (vrf-import), which do not support regular expressions for the extended communities attribute."

There is caveat in 12.3 release notes for the vrf-import policies:

 http://www.juniper.net/documentation/en_US/junos12.3/information-products/topic-collections/release-notes/12.3/topic-69606.html#jd0e13334

Krasi

thanks krasi .. 

i cant apply the vrf wild card masking within the VRF while putting the VRF-IMPORT and EXPORT Polcies . but when you apply the  BGP Export policy to the group . It should control the RT advertisement ( using regexp)    &  juniper says that VPN-APPLY-EXPORT statement in BGP group should evaluate the VRF first than BGP . 

Another  intersting one is applying the   " family route-target" statement to bgp group statement cause the peer to reset the connections and bgp reconverges.