Prefix announcement problem between VRF's

[tolga.kulaber]

We are working on a VRF topology as attached.
We try to limit the ip addresses on CustC and CustD to route-map. 

We see the 172.16.20.0/24 prefix on CustD from the CustC device, but we cannot access it.

Device config and topology are attached.

İs there an incorrect config or a command we skipped?
Can you help me.

The definitions in the core device are as follows;

ip vrf CustC
rd 65001:30
export map CUSTC_to_CUSTD
route-target export 65001:30
route-target import 65001:30
!
ip vrf CustD
rd 65001:40
export map CUSTD_to_CUSTC
route-target export 65001:40
route-target import 65001:40

route-map CUSTC_to_CUSTD permit 10
match ip address 1
set extcommunity rt 65001:40
!
route-map CUSTD_to_CUSTC permit 20
match ip address 2
set extcommunity rt 65001:30
!
!
access-list 1 remark CUSTC_to_CUSTD
access-list 1 permit 10.40.0.0 0.0.0.255
access-list 1 deny any
access-list 2 remark CUSTD_to_CUSTC
access-list 2 permit 172.16.20.0 0.0.0.255
access-list 2 deny any

--------------------------------------

Cust-C#sh ip route

   172.16.0.0/24 is subnetted, 1 subnets
O E2 172.16.20.0 [110/20] via 10.254.254.17, 00:00:01, Ethernet0/1

Cust-C#ping 172.16.20.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

[paul driver]

Hello

---

@tolga.kulaber wrote:

Cust-C#sh ip route

   172.16.0.0/24 is subnetted, 1 subnets
O E2 172.16.20.0 [110/20] via 10.254.254.17, 00:00:01, Ethernet0/1

Cust-C#ping 172.16.20.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

---

sh ip bgp vpnv4 vrf CustC
sh ip bgp vpnv4 vrf CustD
ping vrf CustC x.x.x.x
ping vrf CustD x.x.x.x

[tolga.kulaber]

CORE-2#sh ip bgp vpnv4 all
BGP table version is 90, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:30
*> 10.30.0.0/24 10.254.254.18 20 32768 ?
*> 10.40.0.0/24 10.254.254.18 20 32768 ?
*> 10.254.254.16/30 0.0.0.0 0 32768 ?
*> 172.16.20.0/24 10.254.254.22 20 32768 ?
Route Distinguisher: 65000:40
*> 10.0.222.0/24 10.254.254.22 20 32768 ?
*> 10.40.0.0/24 10.254.254.18 20 32768 ?
*> 10.254.254.20/30 0.0.0.0 0 32768 ?
*> 172.16.20.0/24 10.254.254.22 20 32768 ?
CORE-2#
CORE-2#
CORE-2#ping vrf CustC 172.16.20.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

[paul driver]

Hello

Curious ! Do you have advertised the connected interfaces of the CE/PE rtrs ?

[tolga.kulaber]

Hi my friend,

Yes,

*> 10.254.254.16/30 0.0.0.0 0 32768 ?
*> 10.254.254.20/30 0.0.0.0 0 32768 ?

[Jaderson Pessoa · Accepted solution]

Hello my friend,

I think that your ping is not sent from Ethernet0/0.40 and your CustD know just network 10.40.0.0/24, try to ping from this interface.

ping 172.16.20.1 source Ethernet0/0.40 <<<< i think that it will work.

[tolga.kulaber]

We remove the "export map" command in vrf definitions and write "route-target import 65001: 40" in C vrf, we get access. but when I want to do prefix based blocking, it does not have access.

ip vrf CustC
rd 65001:30
export map CUSTC_to_CUSTD
route-target export 65001:30
route-target import 65001:30
!
ip vrf CustD
rd 65001:40
export map CUSTD_to_CUSTC
route-target export 65001:40
route-target import 65001:40

[tolga.kulaber]

I can ping this way via CustC, but I cannot access "ping vrf CustC 172.16.20.1" via Core router.

[Cristian Matei]

Hi,

     The order of operation is as follows:

              - a route is received by the PE ingress from the CE, on a  VRF enabled interface

              - as it gets redistributed into BGP, all configured "route-target export" values are attached first

              - second, if you have an export map (used to filter which prefixes are allowed to be exported and, optionally with what RT values), the export map is inspected and policies applied

You would need to use the "additive" keyword in most cases in real-life environments when defining the route-map, as you want an additional RT value just in order to make some restrictions, you don't want remote site of the same customers not being able to import the routes due to proper RT value missing; without the "additive" keyword, all configured export-values under the VRF are removed. In your case, just to prove the functionality, it can work as you configured it as well. I also recommend using prefix-lists when matching on IGP routes, as you can match on both the prefix and the prefix-length; standard ACL allows you to match on the prefix, not also on the prefix-length, so you may end up matching more prefixes than desired.

Try the following config, it should work. Even though i could have used the same additional RT value in the route-map for both directions, i used different one so that it's more clear which RT value is used in which direction.

ip prefix-list CUSTC_to_CUSTD permit 10.40.0.0/x (replace x with the proper mask)

ip prefix-list CUSTD_to_CUSTC permit 172.16.20.0/x (replace x with the proper mask)

!

route-map CUSTC_to_CUSTD permit 10
match ip address prefix-list CUSTC_to_CUSTD
set extcommunity rt 65001:130 additive
!
route-map CUSTD_to_CUSTC permit 20
match ip address prefix-list CUSTD_to_CUSTC
set extcommunity rt 65001:140 additive

!

ip vrf CustC
rd 65001:30
export map CUSTC_to_CUSTD
route-target export 65001:30
route-target import 65001:30

route-target import 65001:140
!
ip vrf CustD
rd 65001:40
export map CUSTD_to_CUSTC
route-target export 65001:40
route-target import 65001:40

route-target import 65001:130

Ensure to have mutual redistribution between your PE-CE IGP and BGP.

Regards,

Cristian Matei.

[Cristian Matei]

Hi,

 @tolga.kulaber Have you tested the solution?

Regards,

Cristian Matei.

[tolga.kulaber]

It works when I try it the way you mentioned. but he was also working with ACL. By accessing the CustC router, I can access the ip address on CustD. but I cannot access "ping vrf CustC 172.16.20.1" via Core router.

[Cristian Matei · Accepted solution]

Hi,

   So, going to CustC and CustD routers, you should now see routes as expected, and also have IP connectivity. If you want to test connectivity from the core router (PE) towards each customer, you need to do it a follows:

         ping vrf CustC 10.40.0.x and ping vrf CustD 172.16.20.x, and this will work.

When you say "ping vrf CustC 172.16.20.x" you're telling the router to try and reach out vrf CustC the IP of 172.16.20.x, the router generates the packet with a source address of its only interface in VRF CustC, which is the PE-CE interconnect 10.254.254.16, so the packet leaves the core router with a source address of 10.254.254.17 and destination of 172.16.20.1. The ICMP Echo Request should be functional, but the ICMP Echo Reply should not, as based on your export-map filter, you don't advertise the PE-CE interconnect of VRF CustC into VRF CustD, thus your CustD router has no route back. You can confirm this by doing this ping and doing "debug ip icmp" on the router of CustD, seeing that ICMP Request comes in, but there is no ICMP Reply out.

Regards,

Cristian Matei.