07-24-2019 04:15 PM - edited 07-24-2019 04:17 PM
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
Solved! Go to Solution.
07-24-2019 11:49 PM
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
07-24-2019 11:49 PM
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
07-25-2019 07:53 AM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide