[j-nsp] IPv6 to IPv4 NAT on the MS-DPC

Tue Jun 1 11:11:24 EDT 2010

This is just a spitball idea but maybe you could create a 4th vrf, the
"IPv4 management vrf" and put the 10.10.10.10/32 NAT there. Then you
could just leak that route to the two customer vrfs and would not have
the duplicate NAT problem. Or maybe you could even do that within the
management vrf if it doesn't have to stay IPv6 only... Just some
thoughts - I have never done any of this before. Good luck.
~Chris

On Mon, May 31, 2010 at 04:16, Peter Krupl <Peter.Krupl at siminn.dk> wrote:
> Hi Group,
>
> I have 3 vrf's
> vrf_1, the "management" vrf.
> vrf_2 + vrf_3, the "customer" vrf's.
>
> By representing each IPv4 base customer VRF to the management vrf as a IPv6 prefix,
> i can get distinctive addressing towards each customer VRF, even if the customer vrf's have
> overlapping addresses. The management network is a pure IPv6 network.
>
> Bu as always there is a catch. I want to resent the management network to each customer vrf
> with the SAME ipv4 prefix. This enables a consistent CE configuration across all customer VRF's,
> syslog, snmp, shell acl's etc... stay the same, regardless of which VRF the CE resides in.
>
> In my example the management  station is 1::1/128, and it is presented as 10.10.10.10/32 to each
> customer vrf.
>
> The customer vrf_2 is represented as 2::1/128 which is mapped to vrf_2 1.1.1.1.
> The customer vrf_3 is represented as 3::1/128 which is mapped to vrf_2 1.1.1.1.
>
> The configuration won't commit, it returns the following message:
> root at test-mx# commit
> [edit services]
>  'service-set ss_vrf1_to_vrf3'
>    NAT pool 10.10.10.10/32 is already used by service set ss_vrf1_to_vrf2
> error: configuration check-out failed
>
> The connections from the customer VRF, to the management vrf work as they should,
> but the source translation from the management vrf to the customer vrf's doesn't.
>
> I suspect that the configuration is checked but the fact that the source pools reside I different vrf's
> is seemingly ignored.
>
> Do you think juniper will be able to make q quick  fix if i open a case ?
> Or is there a more severe issue which I fail to se ?
>
> Here is my config (the relevant parts):
>
> set interfaces sp-1/0/0 unit 2 family inet
> set interfaces sp-1/0/0 unit 2 service-domain outside
> set interfaces sp-1/0/0 unit 3 family inet
> set interfaces sp-1/0/0 unit 3 service-domain outside
> set interfaces sp-1/0/0 unit 12 family inet6
> set interfaces sp-1/0/0 unit 12 service-domain inside
> set interfaces sp-1/0/0 unit 13 family inet6
> set interfaces sp-1/0/0 unit 13 service-domain inside
> set interfaces lo0 unit 1 family inet6 address 1::1/128
> set interfaces lo0 unit 2 family inet address 1.1.1.1/32
> set interfaces lo0 unit 3 family inet address 1.1.1.1/32
>
> set routing-instances vrf_1 instance-type vrf
> set routing-instances vrf_1 interface sp-1/0/0.12
> set routing-instances vrf_1 interface lo0.1
> set routing-instances vrf_1 route-distinguisher 1:1
> set routing-instances vrf_1 vrf-target target:1:1
> set routing-instances vrf_2 instance-type vrf
> set routing-instances vrf_2 interface sp-1/0/0.2
> set routing-instances vrf_2 interface lo0.2
> set routing-instances vrf_2 route-distinguisher 1:2
> set routing-instances vrf_2 vrf-target target:1:2
> set routing-instances vrf_3 instance-type vrf
> set routing-instances vrf_3 interface sp-1/0/0.3
> set routing-instances vrf_3 interface lo0.3
> set routing-instances vrf_3 route-distinguisher 1:3
> set routing-instances vrf_3 vrf-target target:1:3
>
> set services service-set ss_vrf1_to_vrf2 nat-rules vrf1_to_vrf2
> set services service-set ss_vrf1_to_vrf2 nat-rules vrf2_to_vrf1
> set services service-set ss_vrf1_to_vrf2 next-hop-service inside-service-interface sp-1/0/0.12
> set services service-set ss_vrf1_to_vrf2 next-hop-service outside-service-interface sp-1/0/0.2
> set services service-set ss_vrf1_to_vrf3 nat-rules vrf3_to_vrf1
> set services service-set ss_vrf1_to_vrf3 nat-rules vrf1_to_vrf3
> set services service-set ss_vrf1_to_vrf3 next-hop-service inside-service-interface sp-1/0/0.13
> set services service-set ss_vrf1_to_vrf3 next-hop-service outside-service-interface sp-1/0/0.3
> set services nat rule vrf1_to_vrf2 match-direction input
> set services nat rule vrf1_to_vrf2 term 1 from source-address 1::1/128
> set services nat rule vrf1_to_vrf2 term 1 from destination-address 2::1/128
> set services nat rule vrf1_to_vrf2 term 1 then translated source-prefix 10.10.10.10/32
> set services nat rule vrf1_to_vrf2 term 1 then translated destination-prefix 1.1.1.1/32
> set services nat rule vrf1_to_vrf2 term 1 then translated translation-type source static
> set services nat rule vrf1_to_vrf2 term 1 then translated translation-type destination static
> set services nat rule vrf2_to_vrf1 match-direction output
> set services nat rule vrf2_to_vrf1 term 1 from source-address 1.1.1.1/32
> set services nat rule vrf2_to_vrf1 term 1 from destination-address 10.10.10.10/32
> set services nat rule vrf2_to_vrf1 term 1 then translated source-prefix 2::1/128
> set services nat rule vrf2_to_vrf1 term 1 then translated destination-prefix 1::1/128
> set services nat rule vrf2_to_vrf1 term 1 then translated translation-type source static
> set services nat rule vrf2_to_vrf1 term 1 then translated translation-type destination static
> set services nat rule vrf1_to_vrf3 match-direction input
> set services nat rule vrf1_to_vrf3 term 1 from source-address 1::1/128
> set services nat rule vrf1_to_vrf3 term 1 from destination-address 3::1/128
> set services nat rule vrf1_to_vrf3 term 1 then translated source-prefix 10.10.10.10/32
> set services nat rule vrf1_to_vrf3 term 1 then translated destination-prefix 1.1.1.1/32
> set services nat rule vrf1_to_vrf3 term 1 then translated translation-type source static
> set services nat rule vrf1_to_vrf3 term 1 then translated translation-type destination static
> set services nat rule vrf3_to_vrf1 match-direction output
> set services nat rule vrf3_to_vrf1 term 1 from source-address 1.1.1.1/32
> set services nat rule vrf3_to_vrf1 term 1 from destination-address 10.10.10.10/32
> set services nat rule vrf3_to_vrf1 term 1 then translated source-prefix 3::1/128
> set services nat rule vrf3_to_vrf1 term 1 then translated destination-prefix 1::1/128
> set services nat rule vrf3_to_vrf1 term 1 then translated translation-type source static
> set services nat rule vrf3_to_vrf1 term 1 then translated translation-type destination static
>
>
>
>
>
> Kind Reagards,
> Peter Krupl
>
> Netværksspecialist
> Teknik
> Direkte +45 3525 4752
> Mobil
> Kundeservice +45 7026 2300
> Fax +45 7026 2301
>
> Stationsparken 25 . 2600 Glostrup . Danmark . siminn.dk
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org