cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1002
Views
0
Helpful
2
Replies

Route appears on RD but not under VRF

hakenkreuz
Level 1
Level 1

Why routes are shown when using the RD, but not showing when using the VRF, hence routes are not being advertised to the CPE.

 

VRF has set the correct RD

 

ASR1002

 

PE#show bgp vpnv4 unicast RD 1418:1081 10.253.13.80/29
BGP routing table entry for 1418:1081:10.253.13.80/29, version 214911496
Paths: (2 available, best #2, no table)
Flag: 0x820
Advertised to update-groups: (Pending Update Generation)
14377
Refresh Epoch 12
1418
200.85.229.11 (via default) from 200.85.229.11 (200.47.28.5)
Origin IGP, localpref 50, valid, external
Extended Community: RT:1418:1081
mpls labels in/out 1325/20422
rx pathid: 0, tx pathid: 0
Refresh Epoch 12
(14588) 1418
200.89.30.21 (metric 2) (via default) from 200.89.30.21 (200.89.30.21)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Extended Community: RT:14187:1081
mpls labels in/out 1325/7695
rx pathid: 0, tx pathid: 0x0


PE#show bgp vpnv4 unicast vrf FA 10.253.13.80/29
% Network not in table


PE#S IP VRF FA
Name Default RD Interfaces
FA 1418:1081 Gi0/0/1.1552

1 Accepted Solution

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello hakenkreuz,

there is another VPNv4 path that is considered best

 

>> 200.89.30.21 (metric 2) (via default) from 200.89.30.21 (200.89.30.21)
Origin IGP, metric 0, localpref 100, valid, confed-internal, >>>>best
Extended Community: >>>>>RT:14187:1081
mpls labels in/out 1325/7695

 

But note it is using a different RT value RT:14187:1081 that your local VRF does not import.

 

You can fix this by adding

vrf FA

route-target import 14187:1081

 

on your local PE node if that route is a valid and expected advertisement

 

it tells also the best path has no local table to import it

 

>> PE#show bgp vpnv4 unicast RD 1418:1081 10.253.13.80/29
BGP routing table entry for 1418:1081:10.253.13.80/29, version 214911496
Paths: (2 available, best #2, no table)

 

This path is preferred because of higher local preference 100 compared to local pref 50 for path 1.

 

Another way to fix it is to increase the local preference on VPNv4 routes received by neighbor 200.85.229.11.

To be noted path1 is an eBGP MP in AF VPNv4 (external)

path 2 comes from a BGP confederation (confed internal)

 

Hope to help

Giuseppe

 

 

View solution in original post

2 Replies 2

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello hakenkreuz,

there is another VPNv4 path that is considered best

 

>> 200.89.30.21 (metric 2) (via default) from 200.89.30.21 (200.89.30.21)
Origin IGP, metric 0, localpref 100, valid, confed-internal, >>>>best
Extended Community: >>>>>RT:14187:1081
mpls labels in/out 1325/7695

 

But note it is using a different RT value RT:14187:1081 that your local VRF does not import.

 

You can fix this by adding

vrf FA

route-target import 14187:1081

 

on your local PE node if that route is a valid and expected advertisement

 

it tells also the best path has no local table to import it

 

>> PE#show bgp vpnv4 unicast RD 1418:1081 10.253.13.80/29
BGP routing table entry for 1418:1081:10.253.13.80/29, version 214911496
Paths: (2 available, best #2, no table)

 

This path is preferred because of higher local preference 100 compared to local pref 50 for path 1.

 

Another way to fix it is to increase the local preference on VPNv4 routes received by neighbor 200.85.229.11.

To be noted path1 is an eBGP MP in AF VPNv4 (external)

path 2 comes from a BGP confederation (confed internal)

 

Hope to help

Giuseppe

 

 

Thanks Giuseppe

 

Your reply lead me to the fix of the problem.

 

There was a typo on the import|export VRF configuration, thats why the prefixes weren't coming to the VRF.

 

Keep on the good work!

Review Cisco Networking products for a $25 gift card