[j-nsp] cgnat routing architecture
Faizal Rachman
faizalr81 at gmail.com
Tue Apr 12 06:02:45 EDT 2016
Hi Aaron,
Here's example for generating 0/0 into your PE :
policy-statement DEFAULT-TO-OSPF-v4 {
term 1 {
from {
protocol static;
prefix-list DEFAULT-IPv4;
condition DEFAULT-EXISTS-IPv4;
}
then {
external {
type 1;
}
accept;
}
}
}
prefix-list DEFAULT-IPv4 {
0.0.0.0/0;
}
condition DEFAULT-EXISTS-IPv4 {
if-route-exists {
0.0.0.0/0;
table one.inet.0;
}
}
This export policy applied on the ospf protocol in vrf six, assuming your
vrf six has ospf neighbor ship with your PE.
Your vrf six will have static 0/0 to your ms interface, and will always
have 0/0, but redistribution to your PE will be depend on the availability
of 'internet access' in your vrf one.
Aggregate route for 0/0 only in your vrf one, and should have contributing
route from your internet availability (e.g eBGP).
Thanks.
Faizal R
On Tue, Apr 12, 2016 at 9:33 AM, Aaron <aaron1 at gvtc.com> wrote:
> I’m unable to see this work. I tried the following…
>
>
>
> But first let me state my goal again… I simply want to create a condition
> whereas if I have the 0/0 route in vrf “one” to go ahead and generate the
> route 0/0 into vrf “six”. And so conversely, if I lose the 0/0 route in
> vrf one, then I should likewise stop advertising 0/0 into vrf six.
>
>
>
> …this shows and aggregate route, but it’s hidden and has NO contributing
> routes, the 0/0 route doesn’t get advertised into vrf six…
>
>
>
> set routing-instances six routing-options generate route 0.0.0.0/0 policy
> gen-route-policy
>
> set policy-options policy-statement gen-route-policy term 1 from rib
> one.inet.0
>
> set policy-options policy-statement gen-route-policy term 1 from
> route-filter 0.0.0.0/0 exact
>
> set policy-options policy-statement gen-route-policy term 1 then accept
>
> set policy-options policy-statement gen-route-policy term 2 then reject
>
>
>
> ...this doesn't work either...
>
>
>
> set routing-instances six routing-options generate route 0.0.0.0/0 policy
> gen-route-policy
>
> set policy-options policy-statement gen-route-policy term 1 from rib
> bgp.l3vpn.0
>
> set policy-options policy-statement gen-route-policy term 1 from
> route-filter 0.0.0.0/0 exact
>
> set policy-options policy-statement gen-route-policy term 1 then accept
>
> set policy-options policy-statement gen-route-policy term 2 then reject
>
>
>
> agould at eng-lab-mx104-cgn# run show route 0/0 exact table six.inet.0
> hidden detail
>
>
>
> six.inet.0: 4 destinations, 4 routes (3 active, 0 holddown, 1 hidden)
>
> 0.0.0.0/0 (1 entry, 0 announced)
>
> Aggregate
>
> Next hop type: Reject
>
> Address: 0x260afec
>
> Next-hop reference count: 1
>
> State: <Hidden Int Ext>
>
> Age: 1:21
>
> Validation State: unverified
>
> Task: Aggregate
>
> AS path: I
>
> Flags: Generate Depth: 0 Inactive
>
>
>
> [edit]
>
>
>
> …then I tried this, and I do see 0/0 sent into vrf six and learned on
> other PE’s in vpn six, BUT if I deactive routing-instance one on this
> routers, the 0/0 route is STILL advertised into vrf six... so my condition
> of checking one.inet.0 for 0/0 doesn't seem to be working…. For some reason
> this is simply working because of a direct /30 route and a bgp learned /24
>
>
>
> set routing-instances six routing-options generate route 0.0.0.0/0 policy
> gen-route-policy
>
> set policy-options policy-statement gen-route-policy term 1 from condition
> condition1
>
> set policy-options policy-statement gen-route-policy term 1 then accept
>
> set policy-options policy-statement gen-route-policy term 2 then reject
>
> set policy-options condition condition1 if-route-exists address-family
> inet 0.0.0.0/0
>
> set policy-options condition condition1 if-route-exists address-family
> inet table one
>
>
>
> agould at eng-lab-mx104-cgn# run show route table six.inet.0 0.0.0.0/0 exact
> detail
>
>
>
> six.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
>
> 0.0.0.0/0 (1 entry, 1 announced)
>
> *Aggregate Preference: 130
>
> Next hop type: Router, Next hop index: 559
>
> Address: 0x2dd17d0
>
> Next-hop reference count: 2
>
> Next hop: via ms-1/0/0.1, selected
>
> Session Id: 0xf9
>
> State: <Active Int Ext>
>
> Age: 1:35:20
>
> Validation State: unverified
>
> Task: Aggregate
>
> Announcement bits (2): 0-KRT 1-BGP_RT_Background
>
> AS path: I
>
> Flags: Generate Depth: 0 Active
>
> Contributing Routes (2):
>
> 10.144.1.4/30 proto Direct
>
> 10.144.0.0/24 proto BGP
>
>
>
> [edit]
>
>
>
>
>
>
>
>
>
> *From:* Faizal Rachman [mailto:faizalr81 at gmail.com]
> *Sent:* Monday, April 11, 2016 4:55 AM
> *To:* Aaron <aaron1 at gvtc.com>
> *Cc:* juniper-nsp <juniper-nsp at puck.nether.net>
> *Subject:* Re: [j-nsp] cgnat routing architecture
>
>
>
> Hi Aaron,
>
> You should apply dynamic redistribution of default route to your internal
> network. First you need to have dynamic 0/0 in your outside domain, it can
> be generated (aggregated) from routes contributed by bgp (assuming your
> cgnat also running ebgp to your upstream provider), or generated by router
> above cgnat, and redistribute this 0/0 to your cgnat.
>
> Secondly, your inside domain will have default static route to your
> external domain, and also redistribute this 0/0 to your internal network
> based on condition, which is 0/0 exist in your outside domain. Once your
> bgp down, your outside domain will lose 0/0, and your inside domain will
> stop redistributing 0/0 to your internal network.
>
> Thanks.
>
>
>
> Faizal R
>
>
>
>
>
> On Wed, Apr 6, 2016 at 7:19 AM, Aaron <aaron1 at gvtc.com> wrote:
>
> My customers are currently in a vrf for internet access. they all have
> public ip addresses. I'm running low on IP's and I'm planning a CGNat
> deployment.
>
>
>
> Call my current vrf "one"
>
>
>
> I'm planning on creating a new inside nat domain, and throwing customers
> into that new vrf.
>
>
>
> Call the new vrf "three"
>
>
>
> I'm currently testing a Juniper MX104 with MS-MIC-16G and it seems to be
> working nicely thus far. (actually I'm testing redundant cgn nodes, the
> other one is a cisco asr9k w/vsm-500)
>
>
>
> On the juniper cgn node I have ..
>
>
>
> ms-1/0/0.2 - vrf "one" - service-domain outside
>
>
>
> ms-1/0/0.1 - vrf "three" - service-domain inside
>
>
>
> My current way of getting traffic towards the nat's is via static routes
> and
> thus being advertised into vrf "three" where remote pe's learn about those
> dual default routes and it all works good... but. static routes always
> scare
> me when not tied to some other logic.
>
>
>
> My concerns are that if the wan (nat outside, ms-1/0/0/2, vrf "one") side
> of
> the nat node dies, then I don't want traffic arriving at that nat node and
> being dropped/blackholed.
>
>
>
> What are the best ways to conditionally advertise a few routes based on
> some
> external reachability info ?
>
>
>
> I've recently learned about rib-groups and doing inter-vrf route leaking..
> I
> wonder if I should learn the vrf "one" default route and leak it into vrf
> "three" across the control plane of those dual nat nodes.
>
>
>
> I've recently learned about conditionally generated routes and wonder if
> there's a nice solution there.
>
>
>
> I welcome any and all suggestions.
>
>
>
> Thanks y'all
>
>
>
> Aaron
>
>
>
>
>
>
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
>
> --
>
> Regards,
> Faizal R
>
--
Regards,
Faizal R
More information about the juniper-nsp
mailing list