Inter-VRF-Lite routing (7/7)


Customer VRFs & Common service VRF + Static NAT NVI

– R1 separates Customers and common site traffic inside different routing instances “vhost4”, “vhost5” and “vhost7”.

– Both customers with overlapping address schemes communicate with a common site using static NAT NVI.

– With static NAT NVI overlapping customer VRFs are allowed to communicate directly with each other. (Picture 2-2-2a)

Picture 2-2-2: topology


Picture 2-2-2a: traffic flow with NVI


R1 CONFIGURATION

VRF “vhost4”

Static route to the non-directly connected 10.0.0.0/24

ip route vrf vhost4 10.0.0.0 255.255.255.0 155.1.0.4

Because the virtual prefix 20.0.0.7 doesn’t belong to an attached subnet, a static route is needed to route traffic with that destination to outside interface.

ip route vrf vhost4 20.0.0.7 255.255.255.255 FastEthernet2/0 172.1.1.7

Because the virtual prefix 50.0.0.0/24 is not an attached subnet, a static route is needed to route traffic with that destination to the corresponding vrf interface.

ip route vrf vhost4 50.0.0.0 255.255.255.0 Serial1/0.105 155.1.0.5

The same logic is reproduced with vrf “vhost5”

ip route vrf vhost5 10.0.0.0 255.255.255.0 155.1.0.5

ip route vrf vhost5 20.0.0.7 255.255.255.255 FastEthernet2/0 172.1.1.7

ip route vrf vhost5 40.0.0.0 255.255.255.0 Serial1/0.104 155.1.0.4

Keep in mind that with NAT NVI, Routing is always performed before Translation, so R1 need to know where to route traffic. (Picture 2-2-1a)

ip route vrf vhost7 10.0.0.0 255.255.255.0 Serial1/0.104 155.1.0.5

ip route vrf vhost7 10.0.0.0 255.255.255.0 Serial1/0.104 155.1.0.4

ip route vrf vhost7 40.0.0.0 255.255.255.0 Serial1/0.104 155.1.0.4

ip route vrf vhost7 50.0.0.0 255.255.255.0 Serial1/0.105 155.1.0.5

NAT NVI Configuration:

Caveat: Because NAT NVI has no concept of inside/outside domain, we use “ip nat source…” NOT “ip nat inside source…”

ip nat source static 172.1.1.7 20.0.0.7 vrf vhost7

ip nat source static 10.0.0.1 40.0.0.4 vrf vhost4

ip nat source static 10.0.0.1 50.0.0.5 vrf vhost5

Customer VRF-to-common site VRF traffic testing

vhost#p vrf vhost5 20.0.0.7

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.0.0.7, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/84/168 ms

vhost#

vhost#p vrf vhost4 20.0.0.7

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.0.0.7, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/54/168 ms

vhost#

NAT Debugging on R1:

R1(config)#

*Mar 15 22:50:22.701: NAT: s=10.0.0.1->50.0.0.5, d=20.0.0.7 [225]

*Mar 15 22:50:22.705: NAT: s=50.0.0.5, d=20.0.0.7->172.1.1.7 [225] s_vrf=> vhost5, d_vrf=> vhost7

*Mar 15 22:50:22.709: NAT-NVI: IP route found: s=50.0.0.5, d=172.1.1.7

*Mar 15 22:50:22.749: NAT: s=172.1.1.7->20.0.0.7, d=50.0.0.5 [225]

*Mar 15 22:50:22.749: NAT: s=20.0.0.7, d=50.0.0.5->10.0.0.1 [225] s_vrf=> vhost7, d_vrf=> vhost5

*Mar 15 22:50:22.753: NAT-NVI: IP route found: s=20.0.0.7, d=10.0.0.1

*Mar 15 22:50:22.813: NAT: s=10.0.0.1->50.0.0.5, d=20.0.0.7 [226]

R1(config)#

*Mar 15 22:50:40.253: NAT: s=10.0.0.1->40.0.0.4, d=20.0.0.7 [230]

*Mar 15 22:50:40.253: NAT: s=40.0.0.4, d=20.0.0.7->172.1.1.7 [230] s_vrf=> vhost4, d_vrf=> vhost7

*Mar 15 22:50:40.257: NAT-NVI: IP route found: s=40.0.0.4, d=172.1.1.7

*Mar 15 22:50:40.333: NAT: s=172.1.1.7->20.0.0.7, d=40.0.0.4 [230]

*Mar 15 22:50:40.337: NAT: s=20.0.0.7, d=40.0.0.4->10.0.0.1 [230] s_vrf=> vhost7, d_vrf=> vhost4

*Mar 15 22:50:40.341: NAT-NVI: IP route found: s=20.0.0.7, d=10.0.0.1

R1(config)#

Customer- to-Customer communication

vhost#p vrf vhost5 40.0.0.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 40.0.0.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/48/144 ms

vhost#p vrf vhost4 50.0.0.5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 50.0.0.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/64/204 ms

vhost#

NAT Debugging on R1:

R1(config)#

*Mar 15 22:53:44.269: NAT: s=10.0.0.1->50.0.0.5, d=40.0.0.4 [250]

*Mar 15 22:53:44.269: NAT: s=50.0.0.5, d=40.0.0.4->10.0.0.1 [250] s_vrf=> vhost5, d_vrf=> vhost4

*Mar 15 22:53:44.273: NAT-NVI: IP route found: s=50.0.0.5, d=10.0.0.1

*Mar 15 22:53:44.349: NAT: s=10.0.0.1->40.0.0.4, d=50.0.0.5 [250]

*Mar 15 22:53:44.353: NAT: s=40.0.0.4, d=50.0.0.5->10.0.0.1 [250] s_vrf=> vhost4, d_vrf=> vhost5

*Mar 15 22:53:44.353: NAT-NVI: IP route found: s=40.0.0.4, d=10.0.0.1

R1(config)#

*Mar 15 22:54:02.057: NAT: s=10.0.0.1->40.0.0.4, d=50.0.0.5 [255]

*Mar 15 22:54:02.057: NAT: s=40.0.0.4, d=50.0.0.5->10.0.0.1 [255] s_vrf=> vhost4, d_vrf=> vhost5

*Mar 15 22:54:02.061: NAT-NVI: IP route found: s=40.0.0.4, d=10.0.0.1

*Mar 15 22:54:02.153: NAT: s=10.0.0.1->50.0.0.5, d=40.0.0.4 [255]

*Mar 15 22:54:02.157: NAT: s=50.0.0.5, d=40.0.0.4->10.0.0.1 [255] s_vrf=> vhost5, d_vrf=> vhost4

*Mar 15 22:54:02.161: NAT-NVI: IP route found: s=50.0.0.5, d=10.0.0.1

traceroute test

vhost#trace vrf vhost5 40.0.0.4

Type escape sequence to abort.

Tracing the route to 40.0.0.4

1 10.0.0.5 96 msec 64 msec 4 msec

2 155.1.0.15 64 msec 4 msec 32 msec

3 155.1.0.4 116 msec 84 msec 208 msec

4 40.0.0.4 136 msec * 164 msec

vhost#

vhost#trace vrf vhost4 50.0.0.5

Type escape sequence to abort.

Tracing the route to 50.0.0.5

1 10.0.0.4 80 msec 68 msec 4 msec

2 155.1.0.14 44 msec 20 msec 12 msec

3 155.1.0.5 104 msec 104 msec 112 msec

4 50.0.0.5 84 msec * 136 msec

vhost#

Back to main article

Conclusion:

The main purpose of VRF-Lite is to separate routing instances providing a certain level of security, but depending on your policy you may need to provide intercommunications between VRFs, hence, the negative connotation behind “Route leaking”.

In case customers deploy dynamic routing you can redistribute static routes to the customer (BGP or IGP).

Whatever the complexity of the topology or features deployed, Inter-VRF communications depends on:

– Static routes from inside a given VRF toward other VRF interfaces

– NAT translation deployed in case of overlapping prefixes

Note:

To not confuse with inter-VRF communications in MPLS and MP-BGP; where RT (route target) import/export policy is required.

“MP-BGP” is a routing protocol using the routed protocol “vpnv4”

“vpnv4” is a routed protocol = Customer VRF prefix + RD

“MP-BGP update” format = vpnv4 + RT + label

“RT” is BGP extended community

Advertisements

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

7 Responses to Inter-VRF-Lite routing (7/7)

  1. Pingback: Inter-VRF-Lite routing « CCIE, the beginning!

  2. Oumar Dakissia says:

    Hi there,

    I read trough your docs, I liked the way you explained things in diagram. It is a good reference document that you have carefully put together for the public and your deserve credit for that.

    I have a question here and I hope you will have a minute to point me to the right direction.
    I have a similar setup as the one you explained in this part of document “Inter-VRF-Lite routing (7/7)”, except that my gateway router R1 is directly connected to the internet (f0/0) and no vrf is required in the outside.
    I have 2 sub-interface on the inside, both in separate vrf. I just did not manage to inject the default route to each vrf. I can not ping outside if sourced from one of the VRFs, I believe the NAT problem.
    I hope that you may point the finger to what is missing in my configuration.
    Note: the 2 vrf do no need to communicate to one another, they simply need internet access route.

    Here is my basic configuration on R1:
    Thanks you in advance.
    Oumar

    hostname lab12
    !
    ip vrf VRF1
    rd 15:15
    route-target export 15:15
    route-target import 15:15
    !
    ip vrf VRF2
    rd 16:16
    route-target export 16:16
    route-target import 16:16
    !
    interface FastEthernet0/0
    description <>
    ip address 1.1.1.1 255.255.255.0
    ip nat outside
    !
    interface FastEthernet0/1
    !
    interface FastEthernet0/1.15
    description <>
    encapsulation dot1Q 15
    ip vrf forwarding VRF1
    ip address 192.168.15.5 255.255.255.192
    ip nat inside
    !
    interface FastEthernet0/1.16
    description <>
    encapsulation dot1Q 16
    ip vrf forwarding VRF2
    ip address 192.168.16.5 255.255.255.192
    ip nat inside
    !
    ip route 0.0.0.0 0.0.0.0 1.1.1.2
    !
    ip route vrf VRF1 0.0.0.0 0.0.0.0 FastEthernet0/0 1.1.1.2 global
    ip route vrf VRF2 0.0.0.0 0.0.0.0 FastEthernet0/0 1.1.1.2 global
    !
    ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1
    ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1
    !
    ip nat inside source list 15 interface FastEthernet0/0 overload
    ip nat inside source list 16 interface FastEthernet0/0 overload
    !
    access-list 15 permit 192.168.15.0 0.255.255.255
    access-list 15 permit 10.10.0.0 0.0.255.255
    access-list 16 permit 192.168.16.0 0.255.255.255
    access-list 16 permit 10.10.0.0 0.0.255.255

    • cciethebeginning says:

      Hi Oumar,

      Thank you for your encouragements, I suggest looking in the following direction :

      – Inside NAT Operations must be per VRF-basis
      ip nat inside source list 15 interface FastEthernet0/0 overload VRF1
      ip nat inside source list 16 interface FastEthernet0/0 overload VRF2
      – You need routes from the global VRF instance to “inside locals” in VRF

      Here is a more detailed explanation of the whole troubleshooting process, hope will help:

      Troubleshooting tools :
      – Enable debug ip ICMP at the source & destination (If your using routers) or a packet sniffer to see if they are receiving ICMP traffic.
      – Enable debug ip nat, to check whether NAT operating correctly.
      – Enable debug ip packet

      Note : “debug” to be avoided in production env. it is mainly for educational & lab purpose.

      I) Phase1 (Forwarding traffic)

      1)For traffic coming to the inside NAT interface (VRF1/VRF2), traffic is routed then translated
      (src = inside local) => (dst = outside local)
      *** You can check the VRF1/VRF2 routing table for a route to “outside local” pointing to “Global” VRF instance egress (here comes in place inter-VRF leaking)

      2)NAT operation
      (src = inside local) replaced by (src = inside global)
      (dst = outside local) replaced by (dst = outside global)
      This should be verified through debug ip nat & the NAT translation table

      3)Traffic forwarding
      (src = inside global) => (dst = outside global)

      The destination receiving ping request is a sign of successful forwarding traffic

      II) Phase2 (Returning traffic)
      Caveat : The order of operation for returning traffic coming in the outside NAT interface is different :

      1)NAT operation is performed according to the existing translation table, then routing
      (src = outside global) replaced by (src = outside local)
      (dst = inside global) replaced by (dst = inside local)
      this is verifiable through “debug ip nat”
      2)Now global VRF instance need to route traffic (src = outside local) => (dst = inside local)
      *** so the inside local should be found in the global VRF instance
      this is verifiable through “debug ip packet”

  3. Oumar says:

    Hi,

    Thank you so much for your time and support.
    I am pleased that my config is working great after I implemented your
    solution. The only problem I have now is the internet access restriction for remote
    vpn clients [I have added ACL 100 – permit any any – but it does not resolve the problem].

    Thanks again
    Oumar

    • cciethebeginning says:

      Hi Oumar,

      It’s is probably not the permissive ACL (any any), because the router whether it ends or starts encryption tunnels it operates on clear data, i.e. entered data is 1st decrypted then input ACL performed, or outbound traffic is marked for encryption (crypto-map), filtered through outbound ACL, then encrypted.
      ACL_NAT_IPSEC

      I will be posting a series of posts about the order of operations on the router, hope it will help, keep tuned : )

  4. Dinesh says:

    Great Post. I’m working on the same deployment & only issue I’m having is, I have a backup router next to R1 which is configured with HSRP for fail over. Is there anyway to do the NAT failover from R1 router to the Backup router if R1 is unavailable?

  5. ajnouri says:

    Hi Dinesh, thanks and sorry for the late reply.

    I believe there is no “stateful” version of NAT NVI, but you still can deploy traditional NAT in each customer VRF with HSRP (which is resumed to the outside as simple gratuitous arp message that will direct the downstream to the active HSRP)

    I think the more appropriate design would be “Customer VRFs & Common service global RIB + Traditional NAT” + HSRP deployment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: