[c-nsp] Setting up a Internet Gateway (NAT-PE) for MPLS VPNCustomers

[David Freedman]

We provide customers with a managed CE router on a stick which does NAT
and stateful inspection, these may hang off any PE router of our
choosing, in reality we implement these as virtual systems on a larger
devices with 802.1q trunks to the PE routers.

Dave.


Oliver Boehmer (oboehmer) wrote:
> Andy Saykao <> wrote on Thursday, August 14, 2008 4:58 AM:
> 
>> Hi All
>>
>> We are looking at providing our Layer 3 MPLS VPN customers with the
>> option of a managed internet gateway via a NAT-PE router. This would
>> mean that remote sites no longer have to access the internet via the
>> Central Site model as this is the way we've been implementing Internet
>> access for MPLS VPN customers.
>>
>> As all our MPLS VPN customers are using private IP addresses, NAT
>> would have to obviously take place at the NAT-PE router.
>>
> [...]
>> My delimma is that I'm not entirely sure which router should be
>> designated as the NAT-PE router to act as the Internet Gateway for our
>> MPLS VPN customers or if we need to put in a new PE router somewhere?
>>
>> So what I've brainstormed are the following ideas...
>>
>> 1/ Do we set the P router up as the NAT-PE router? I'm reluctant to do
>> this because this is the core router that handles Internet traffic for
>> all our customers and I don't want to mess it up.
> 
> Agreed, I wouldn't take this path either. NAT is stateful, so future
> scalability is a concern, which is limited if you did this on your
> core/P node (turning it into a PE).
> 
>> 2/  Can the NAT-PE router be assigned to either PE1 or PE2? If so, I'm
>> unsure how to apply NAT because there is only one interface on the PE
>> router connecting to the P router so I'm not really sure where the ip
>> nat inside and outside command would go - unless we use NAT on a stick
>> which I don't think is recommended in a production environment.
> 
> I would actually vote for some "on-a-stick" deployment, which is what
> many customers do (as far as I know). NPE-G1/G2 are popular platforms
> for this..
> 
>> 3/ Lastly, do we need to put in a new router to act as the NAT-PE
>> router? If so, where would this be placed - maybe between the P router
>> and the Internet?
> 
> I would add a new node, and put it somewhere "close" to the P
> router/internet connection. You can scale by adding addtl. routers and
> distribute your VPN customers across these nodes. The config would be
> along this line:
> 
> you use two interfaces (can be sub-interfaces): One MPLS interface
> (running LDP and your IGP), and one plain-IP interface. Both connect to
> the P node.
> You create a static default in the vrf pointing over the IP interface
> into the global table and create per-vrf NAT statements.
> 
> int Gig0/0.10
>  ip address 192.168.0.2 255.255.255.252
>  mpls ip
>  ip nat inside
> !
> int gig0/0.20
>  ip address 192.168.10.2 255.255.255.252
>  ip nat outside
> !
> ip route vrf foo 0.0.0.0 0.0.0.0 Gig0/0.20 192.168.10.1 global
> !
> ip nat pool NAT-foo 10.1.1.1 10.1.1.10 netmask 255.255.255.240 add-route
> 
> ip nat source list nat-acl-foo pool NAT-foo vrf foo overload  
> !
> ip access-list extended nat-acl-foo 
>  ! define what should be translated
>  
> and you define MP-iBGP and advertise the static defaults into the
> respective VPNs.
> 
> something like this. the only addtl. challenge is to advertise the NAT
> pool(s) over the gig0/0.20 interface so you send the return traffic from
> the Internet back over this outside interface. you could use a dedicated
> ipv4-bgp session or another IGP instance, for example..
> 
> I hope you'll get the idea..
> 
> 	oli
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>