[j-nsp] cgnat routing architecture
Aaron
aaron1 at gvtc.com
Mon Apr 11 22:33:29 EDT 2016
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 <mailto: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 <mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Regards,
Faizal R
More information about the juniper-nsp
mailing list