[rbak-nsp] NAT Example Requests

Thu Aug 11 07:27:57 EDT 2016

On 2016-08-09 00:36, Michael J. Gage wrote:
>
> Your assumption is correct.
>
> This will be for a IPTV SetTopBox Environment.
>
>  
>
> We will be providing DHCP on a quiet network to the STB VLAN.
>
> We want to allow access to specific internet based resources (advanced
> STB features).
>
>  
>
> To break things down to a step by step, I would like to at least get a
> functional dynamic NAT for outbound traffic.
>
> I can collapse to a single context to complete the proof of concept phase.
>

Well, in theory it is possible, but our configuration for similar case
is different.
We have NAT on subscriber's profile - (policy access list can do
exception which classes to ignore so not to NAT).

In your case, defaultroute must be set to next-hop - another context,
and in that public context you might want
to use static NAT function.
But we have not tested this..

However, separate context for management (context local) is a good idea
that we use.
All other functions as BGP, BRAS, IPTV are in separate contexts.

Marcin

>  
>
> Any help is appreciated.
>
>  
>
> *From:*Marcin Kuczera [mailto:marcin at leon.pl]
> *Sent:* Monday, August 08, 2016 3:09 PM
> *To:* Michael J. Gage
> *Cc:* redback-nsp at puck.nether.net
> *Subject:* Re: [rbak-nsp] NAT Example Requests
>
>  
>
> On 2016-08-06 00:22, Michael J. Gage wrote:
>
>     We would like to utilize multiple contexts.
>
>      
>
>     ?         context subscriber
>
>     ?         context internet
>
>     ?         context management
>
>      
>
>     The subscribers will connect via DHCP in the subscriber context
>     assigned via a dynamic private IP pool.
>
>     They will have access to servers and services within that context
>     without the need for NAT.
>
>      
>
>     The internet context will have public IP address and servers as
>     well as ACLs for limiting public access.
>
>     We will need to set up NAT for limited internet access for the
>     subscribers from the subscriber context.
>
>     We also want the option of creating static NAPT (port forwarding)
>     to devices in both the subscriber and management contexts.
>
>      
>
>     We are currently using a SE400 with four 10ge-1-port line cards
>     that we were hoping to use in two separate two port link-groups
>     for failover.
>
>     We would like to terminate different classes of subscribers on
>     separate dot1q pvc trunks via one link-group and use the other one
>     for an upstream link.
>
>      
>
>     We have an enhanced NAT license if we need it, but I would prefer
>     to only use it only if it is required.
>
>
> Is it for SetTopBoxes for IPTV ?
>
> What you need is inter-context routing I guess. Is it ?
> Why am I asking... this is not usual configuation for subscribers that
> are behind NAT.
>
> Marcin
>
>
>
>
>  
>
> Thank you for your help.
>
>  
>
> *From:*redback-nsp [mailto:redback-nsp-bounces at puck.nether.net] *On
> Behalf Of *Marcin Kuczera
> *Sent:* Friday, August 05, 2016 12:22 PM
> *To:* redback-nsp at puck.nether.net <mailto:redback-nsp at puck.nether.net>
> *Subject:* Re: [rbak-nsp] NAT Example Requests
>
>  
>
> On 2016-08-04 23:13, Michael J. Gage wrote:
>
>     We would like to use a NAT policy on traffic between contexts.
>
>      
>
>     Two context, one public and one private.
>
>      
>
>     The goal is to have a public IP context that performs NAT and a
>     separate private context that only routes between interfaces with
>     a default inter-context route.
>
>      
>
>     Suggestions and examples are appreciated.
>
>
> The problem is, that NAT policy for subscribers should be directly
> connected with subscriber's profile (CLIPS/PPP).
> In other case, this will be regular NAT, without all the features like
> CGNAT, logging, lawful-intercept etc..
>
> I'am not sure what is that you want to achieve ?
>
> Btw, could you share with me - what GPON equipment are you using ?
>
> Regards,
> Marcin
>
>
>
>  
>
>  
>
> Michael Gage
>
> Network Operations
>
> LocalTel Communications
>
>
>
>
>
> _______________________________________________
> redback-nsp mailing list
> redback-nsp at puck.nether.net <mailto:redback-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/redback-nsp
>
>  
>
> -- 
>
> *Marcin Kuczera*/ Wiceprezes Zarządu / CTO
> +48 32 440 80 71/ marcin.kuczera at leon.pl <mailto:marcin.kuczera at leon.pl>
>
> *Leon Sp. z o.o.*
> ul. Kilińskiego 33d, 44-200 Rybnik
> http://www.leon.pl/
>
> INTERNET | TELEWIZJA | TELEFON
>
> KRS 0000223101 Sąd Rejonowy w Gliwicach
> Kapitał zakładowy 282.500 zł
> NIP: 6332068698
>
>  
>
> -- 
>
> *Marcin Kuczera*/ Wiceprezes Zarządu / CTO
> +48 32 440 80 71/ marcin.kuczera at leon.pl <mailto:marcin.kuczera at leon.pl>
>
> *Leon Sp. z o.o.*
> ul. Kilińskiego 33d, 44-200 Rybnik
> http://www.leon.pl/
>
> INTERNET | TELEWIZJA | TELEFON
>
> KRS 0000223101 Sąd Rejonowy w Gliwicach
> Kapitał zakładowy 282.500 zł
> NIP: 6332068698
>

-- 

Marcin Kuczera / Wiceprezes Zarządu / CTO
+48 32 440 80 71/ marcin.kuczera at leon.pl <mailto:marcin.kuczera at leon.pl>

Leon Sp. z o.o.
ul. Kilińskiego 33d, 44-200 Rybnik
http://www.leon.pl/

INTERNET | TELEWIZJA | TELEFON

KRS 0000223101 Sąd Rejonowy w Gliwicach
Kapitał zakładowy 282.500 zł
NIP: 6332068698

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/redback-nsp/attachments/20160811/a023d3f3/attachment-0001.html>