Routing

Hi experts,

i faced strange issue while work i am using mpls vrf in the network and using single router to provide internet access:-

- add static route of vpn in inet.0 and point to next-table vpn.inet.0

-rib-group to copy all internet routes from inet.0 to vpn.inet.0

and all was fine till i activated external bgp session with family inet-vpn then all inetrnet routes from rib-group no longer advertised.

i searched more and found that when you have vpn RR or ASBR there is default behaviour called vpn-apply-export i tried to modify the export polocy of bgp but couldn't advertise the routes from rib-group

i appreciate if any one could resolve this issue

Regards,

Amir

Hi,

"vpn-apply-export"  enables VRF export and BGP group or neighbor export policies are applied (VRF first, then BGP) before routes are advertised in the VPN routing tables to other PE routers.

Can you post the relevant configurations here?

Regards,

Moses

Hi Moses,

i got this point but my question here when i added external bgp session for inter-as the router no longer advertises the routes imported from rib group

i have tried to add another export policy under the bgp session itself to allow these routes but can't

rib-groups for internet access (point to vpn routes by next-table and import global routing table by rib-groups):-

routing-options {
    interface-routes {
        rib-group inet inet0-to-vpn;
    }
    static {
        route 10.0.0.0/8 next-table vpn.inet.0;
    }
    rib-groups {
        inet0-to-green {
            import-rib [ inet.0 vpn.inet.0 ];
        }
    }

routing-instance:-

vpn {
    instance-type vrf;
    interface x.x;
    route-distinguisher x:x;
    vrf-import green-import;-------------->import bgp contain target 1:1
    vrf-export green-export;--------------->export all routes with target 1:1
    vrf-table-label;
    protocols {
        ospf {
            area 0.0.0.0 {
                interface x.x {
    }
}

Hi,

Can you please post the configuration of the external BGP for inter-as and the relevant policies?

Regards,

Moses N

Hi Amir,


Let me quickly brief on "vpn-apply-export" (sorry if it repeation, but hope it will help us futher).

By default, when you apply a vrf-export policy under routing-instance, all the routes based on the policy will be advertised to remote PE(s).
This would be true, even if you define a filter rule for any of remote PE BGP sessions.

Looking at the below configs, we would like to advertise only routes with community "target:100:100" to 3.3.3.3 while all VPN routes to 2.2.2.2

suryak@PE show protocols bgp group int            
type internal;
local-address 1.1.1.1;
neighbor 3.3.3.3 {
    family inet-vpn {
        unicast;
    }
    export expo_neighbor;
}
neighbor 2.2.2.2 {
    family inet-vpn {
        unicast;
    }
}

suryak@PE show policy-options policy-statement expo_neighbor        
term a {
    from community tar1;
    then accept;
}
term b {
    then reject;
}

community tar1 members target:100:100;
community tar2 members target:100:102;


However as said, without "vpn-apply-export" (as in this cas) all routes would be advertised to 2.2.2.2 much like for 3.3.3.3

suryak@PE# run show route advertising-protocol bgp 2.2.2.2 detail

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100:1:200.1.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:100

* 100:1:200.2.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:102

suryak@PE# run show route advertising-protocol bgp 3.3.3.3 detail    

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100:1:200.1.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:100

* 100:1:200.2.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:102

In this case in order to allow export policy evaluation at global BGP level also, we activate "vpn-apply-export" to filter the routes accordingly.

suryak@PE# show protocols bgp group int
type internal;
local-address 1.1.1.1;
vpn-apply-export;
neighbor 3.3.3.3 {
    family inet-vpn {
        unicast;
    }
    export expo_neighbor;
}
neighbor 2.2.2.2 {
    family inet-vpn {
        unicast;
    }
}

suryak@PE# run show route advertising-protocol bgp 2.2.2.2 detail    

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100:1:200.1.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:100

* 100:1:200.2.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:102

suryak@PE# run show route advertising-protocol bgp 3.3.3.3 detail    

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100:1:200.1.0.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 100:1
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] 65001 I
     Communities: target:100:100


With that understanding, the meaning of below statement in Tech Documentation (if that was what referred in your post), implies that you don't have to enable
"vpn-apply-export" explicitly, as both VPN export policy and global BGP export policy would be evaluated implicitly when PE is RR or ASBR.

"If you configure a PE router as a route reflector or as an AS border router,
the behavior enabled by the vpn-apply-export statement is enabled on these routers automatically"

Looks like this been true until 10.4 release.
http://www.juniper.net/techpubs/en_US/junos10.4/topics/usage-guidelines/vpns-configuring-policies-for-the-vrf-table-on-pe-routers-in-vpns.html#id-10143422

And the same is not true after 11.1 release, which means you have explicitly enable "vpn-export-policy" even in case of PE as RR or ASBR.
http://www.juniper.net/techpubs/en_US/junos11.1/topics/usage-guidelines/vpns-configuring-policies-for-the-vrf-table-on-pe-routers-in-vpns.html#id-10143422

Regards
Surya

Now coming to the actual problem, we need to understand that ASBR uses bgp.l3vpn.0 table (Option B in this case) for importing and exporting VPN-IPv4 routes.
AFAIK, this is as per the JUNOS implementation.

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/nce/mpls-vpn-opt2/implementing-interprovider-layer-3-vpn-option-b.pdf


With PE, NOT BEING AS ASBR, bgp.l3vpn.0 table contains only routes received by remote PE while VPNA.inet.0 table contains all the VPN routes (including the ones
from rib-group)

suryak@PE# run show route table bgp.l3vpn.0

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100:2:172.169.1.0/30                
                   *[BGP/170] 00:00:57, localpref 100, from 3.3.3.3
                      AS path: I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box
100:2:200.0.0.0/24                
                   *[BGP/170] 00:00:57, localpref 100, from 3.3.3.3
                      AS path: 65002 I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box

suryak@PE# run show route table VPNA.inet.0

VPNA.inet.0: 13 destinations, 13 routes (12 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[Direct/0] 02:39:21
                    > via lo0.0
10.0.1.0/30        *[Direct/0] 02:39:21
                    > via ge-2/1/6.0
10.0.1.1/32        *[Local/0] 02:39:21
                      Local via ge-2/1/6.0
10.255.178.43/32   *[Direct/0] 02:39:21
                    > via lo0.0
88.1.1.0/30        *[Direct/0] 02:33:17
                    > via ge-2/1/1.0
88.1.1.1/32        *[Local/0] 02:33:17
                      Local via ge-2/1/1.0
172.168.1.0/30     *[Direct/0] 02:52:17
                    > via ge-3/0/0.0
172.168.1.1/32     *[Local/0] 02:52:17
                      Local via ge-3/0/0.0
172.169.1.0/30     *[BGP/170] 00:01:08, localpref 100, from 3.3.3.3
                      AS path: I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box
200.0.0.0/24       *[BGP/170] 00:01:08, localpref 100, from 3.3.3.3
                      AS path: 65002 I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box
200.1.0.0/24       *[BGP/170] 00:20:47, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 172.168.1.2 via ge-3/0/0.0
200.2.0.0/24       *[BGP/170] 00:20:47, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 172.168.1.2 via ge-3/0/0.0

As we see, in this case the routes from VPNA.inet.0 table is being exported to remote PE (3.3.3.3)

suryak@PE run show route advertising-protocol bgp 3.3.3.3                                

VPNA.inet.0: 13 destinations, 13 routes (12 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 1.1.1.1/32              Self                         100        I
* 10.0.1.0/30             Self                         100        I
* 10.255.178.43/32        Self                         100        I
* 88.1.1.0/30             Self                         100        I
* 172.168.1.0/30          Self                         100        I
* 200.1.0.0/24            Self                         100        65001 I
* 200.2.0.0/24            Self                         100        65001 I


Now with PE, BEING AS ASBR, the routes from bgp.l3vpn.0 are advertised to PE (3.3.3.3)

suryak@PE run show route advertising-protocol bgp 3.3.3.3                                      

bgp.l3vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  100:1:172.168.1.0/30                    
*                         Self                         100        I
  100:1:200.1.0.0/24                    
*                         Self                         100        65001 I
  100:1:200.2.0.0/24                    
*                         Self                         100        65001 I


As only VPN-IPv4 routes are stored in bgp.l3vpn.0 table, you will not see routes that are from rib-group being advertised.

Now comes the million dollar question, how would the routes from local CE would be advertised to remote PE?
While in this case, the routes from local CE are also moved to bgp.l3vpn.0 table as VPN-IPv4 routes.
Hence in this case you see both local CE and remote PE routes in bgp.l3vpn.0 table

suryak@PE run show route table bgp.l3vpn.0

bgp.l3vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100:1:172.168.1.0/30                
                   *[Direct/0] 00:02:49
                    > via ge-3/0/0.0
100:1:200.1.0.0/24                
                   *[BGP/170] 00:02:49, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 172.168.1.2 via ge-3/0/0.0
100:1:200.2.0.0/24                
                   *[BGP/170] 00:02:49, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 172.168.1.2 via ge-3/0/0.0
100:2:172.169.1.0/30                
                   *[BGP/170] 00:02:17, localpref 100, from 3.3.3.3
                      AS path: I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box
100:2:200.0.0.0/24                
                   *[BGP/170] 00:02:17, localpref 100, from 3.3.3.3
                      AS path: 65002 I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box

Hi Surya,

many thanks for all these valuable info.

as you illustrated when the PE becomes ASBR/RR the routes are advertised from bgp.l3vpn.0 not from VPNA.inet.0 and this is my problem as i couldn't move rib-group routes to bgp.l3vpn.0 although it is existing in VPNA.inet.0 and exported by vrf-export.

i tried many policies to call these routes "rib-group routes"  from the global bgp export policy but in vain

and once i deactivate the external inet-vpn peer the routes are advertised and all vpn can gain internet access

Regards,

Amir

Hi Amir,

The only solution that I can provide in this case, is to include a default static route under the routing-instance of PE and ensuring the same is accpeted by vpn-export policy.

suryak@PE# show routing-instances
VPNA {
    instance-type vrf;
::::::::::
::::::::::
    route-distinguisher 100:1;
    vrf-import impo_vpn;
    vrf-export expo_vpn;
    vrf-table-label;
    routing-options {
        static {
            route 0.0.0.0/0 reject;
        }
    }
:::::::::
:::::::::
}


suryak@PE# show policy-options policy-statement expo_vpn  
term a {
    ::::::::::::
    ::::::::::::
}
term b {
    from protocol static ;
    then {
        community add tar1;
        accept;
    }
}
term c {
    then reject;
}


suryak@PE# run show route table bgp.l3vpn.0

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100:1:0.0.0.0/0                 
                   *[Static/5] 00:02:53
                      Reject
100:1:172.168.1.0/30                
                   *[Direct/0] 00:02:53
                    > via ge-3/0/0.0
100:1:200.1.0.0/24                
                   *[BGP/170] 14:41:21, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 172.168.1.2 via ge-3/0/0.0
100:1:200.2.0.0/24                
                   *[BGP/170] 14:41:21, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 172.168.1.2 via ge-3/0/0.0
100:2:172.169.1.0/30                
                   *[BGP/170] 14:40:49, localpref 100, from 3.3.3.3
                      AS path: I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box
100:2:200.0.0.0/24                
                   *[BGP/170] 14:40:49, localpref 100, from 3.3.3.3
                      AS path: 65002 I, validation-state: unverified
                    > to 10.0.1.2 via ge-2/1/6.0, label-switched-path hun-box

suryak@PE# run show route advertising-protocol bgp 3.3.3.3

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  100:1:0.0.0.0/0                     
*                         Self                         100        I
  100:1:172.168.1.0/30                    
*                         Self                         100        I
  100:1:200.1.0.0/24                    
*                         Self                         100        65001 I
  100:1:200.2.0.0/24                    
*                         Self                         100        65001 I

Regards

Surya