[c-nsp] VASI interface and NAT on ASR1k

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Melbourne wrote:
> Hi,
> 
> Does anyone have any pointers to some real-world use cases for VASI
> interfaces on an ASR1k? I have a corner case where I can't use MP-BGP to
> import a route from one VRF into another, when the next-hop of the route is
> in a separate VRF (the case is VRF-aware IPsec with FVRF/iVRF
> configuration). It looks like the issue can be worked around using VASI
> interfaces (i.e. a vasileft/vasiright pair). I have used a /30 to address
> the VASI interfaces and this appears to work, but is this best practice? NAT
> may be another useful requirement in this scenario, but I have seen other
> cisco-nsp postings which suggests 'ip nat outside' shouldn't be configured
> on an interface which isn't in the global table. A suggestions is that "ip
> nat enable" and hence NVI be used in preference to classic NAT for VASI
> interfaces? VASI does appear to be a rather poorly documented feature in
> IOS-XE :)
> 

VASI interfaces are really designed to allow for services (encryption for
example) to be applied prior to label imposition on packets that would be
label forwarded toward the core.  The VASI-left interface serves as a
pseudo-CE and the VASI-right serves as a pseudo-PE.

In the VASI scenarios I've seen, BGP is used to send routes learned from
the MP-BGP sessions to the PE-CE BGP sessions and vice versa.  So, in
essence, you have three different BGP domains, the PE-CE, the MP-BGP, and
the inter-VASI.  In effect, you have two different "redistributions" going
on.  This is the result of having the VASI interfaces "shimmed" between the
real interfaces facing the CE and the P/PE MPLS core.

In those scenarios, the VASI interfaces were addressed out of the same /30
subnet.  A BGP session was then established between those VASI interface
addresses to advertise the routes from the VASI-left VRF to the VASI-right
VRF.  The VASI-right VRF was the same VRF (same RD/RTs) as the VPN on the
other PEs and the VASI-left was a separate VRF (different RD) that serves
as the pseudo-CE.  There was no need to have the VASI-left pseudo-CE
configured for import/export of route targets and the VASI-right VRF was
not configured to import the VASI-left route targets.  The BGP session
between the VASI interfaces propagates the routes without the need for
import/export of the RTs.

In the scenario we were testing, we were able to have GETVPN on the MPLS
P/PE side providing PE to PE encryption within the MPLS core.

- -- 
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9eZEUACgkQE1XcgMgrtyYc7QCghIFYcYdVAIhLa6Z8BG9KPjPD
H0sAn3OISw2e7oq8QxNVqFSiocTA4dLS
=pklf
-----END PGP SIGNATURE-----