-----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----- _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
