LSN44 steering on the inside routing context is supported through routes received from the BGP-VPN protocol. NAT-related BGP-VPN routes are received from BGP-VPN peers in the outside routing contexts and are imported in the inside routing context. This way, the routing information for NAT is dynamically updated without operator intervention. Typical users are operators using NAT who are peering with third parties and frequently re-purposing their IPv4 prefixes based on usage or redundancy. A cloud solution is an example of these types of peering partners.
A typical network design describing this scenario is shown in Figure: Connectivity diagram.
Dynamic import of BGP-VPN routes with the next-hop leading to NAT (ISA or VM-ESA) is performed through a routing policy where:
A route received on the outside by BGP-VPN is matched against the configured route target community and installed in the outside VPRN automatically. Alternatively, the route can be matched against any BGP-VPN supported criteria through an import route policy and installed in the outside routing table.
Within the NAT context on the inside, the BGP-VPN route is imported through an import route policy, where the route is matched against any BGP-VPN supported criteria. In the same route policy, the route is associated with a NAT policy which determines the NAT pool and outside routing context.
An example configuration for the route policy that is referenced as import within a NAT context is shown below.
MD-CLI
configure
policy-options {
policy-statement <policy-name> {
entry <id> {
from {
: <<any match condition supported for BGP-VPN routes
}
action {
action-type accept
nat-policy <nat-policy-name>
}
}
}
}
If the NAT policy under the action is omitted, then a default NAT policy from the inside routing context is used.
The configured route policy is then applied under NAT in the inside routing context.
MD-CLI
configure {
service vprn <name> }
nat }
inside }
large-scale }
nat-policy <name> <<default nat-policy
nat44 }
nat-import <name> }
{
{
{
{