[j-nsp] mx80 napt-44 with ms-mic on 13.2R5
ryanL
ryan.landry at gmail.com
Wed Oct 8 16:20:14 EDT 2014
hopefully this renders
peer1 peer2
+ +
| |
| |
+-+---+ +---+-+
| er1 | | er2|
| +-----+ |
++----+ +----++
| X X |
| X X |
| X |
++----+ X X +----++
| cs1| | cs2|
| +-----+ |
+--+--+ +-----+
|
|
|
+10.1.20.55/32
if not see pic: http://ryry.foursquare.com/image/2y2I1q19432b
-basically, two edge routers, two core switches, full physical mesh.
-cs1 is default gateway for host.
-er{1,2} advertise default routes down to cs
-er{1,2} have different nat pools, and i attract traffic internally to the
correct router for the respective pool via iBGP.
-the host could either go to er1 or er2 via default route
-return traffic could either come in via peer1 or peer2. but, as per iBGP,
traffic to the nat block will always arrive back to the owning router. this
appears to be true, as the ms-mic is at least reporting the return packet
(but counts it as a new session).
-if i put a static route on cs1 for twitter's networks to point to er2, it
"fixes" the problem.
considering er2, on my interfaces facing the upstream peer, the link to
er1, and the two links to the downstream switches, i have the following in
place as part of the service set.
eg:
unit 0 {
description <snip>;
family inet {
filter {
input INTERNET-IN;
output INTERNET-OUT;
}
service {
input {
service-set SSET1 service-filter SFILTER-IN;
}
output {
service-set SSET1 service-filter SFILTER-OUT;
}
}
address <snip>/30;
}
}
service-filter SFILTER-IN {
term 1 {
from {
source-address {
10.1.20.55/32;
}
destination-address {
0.0.0.0/0;
10.0.0.0/8 except;
}
}
then service;
}
term 2 {
from {
destination-address {
$natpool-ip/28;
}
}
then service;
}
term 999 {
then skip;
}
}
service-filter SFILTER-OUT {
term 1 {
from {
destination-address {
$natpool-ip/28;
}
}
then service;
}
term 999 {
then skip;
}
service-set SSET1 {
nat-rules NAT-RULE1;
interface-service {
service-interface ms-0/2/0;
}
}
nat {
pool NP2 {
address $natpool-ip/28;
port {
range low 32768 high 65535;
}
}
rule NAT-RULE1 {
match-direction input;
term 1 {
from {
source-address {
10.1.20.55/32;
}
destination-address {
0.0.0.0/0;
10.0.0.0/8 except;
}
}
then {
translated {
source-pool NP2;
translation-type {
napt-44;
}
}
}
}
}
}
On Wed, Oct 8, 2014 at 12:29 PM, Alexander Arseniev <arseniev at btinternet.com
> wrote:
> The "Session: 1174405192" is a SYN-ACK being returned to Your router
> from 199.16.156.102, it cannot establish a session (only SYN can).
> Please post Your sanitized config ans ASCII diagram of traffic flow.
> Thanks
> Alex
>
> On 08/10/2014 19:44, ryanL wrote:
>
> thx again alex. i've found a clue, but i'm unclear why it's happening.
> my internal host is 10.1.20.55, trying to curl twitter.com, which
> hangs. i'm unclear why that return packet is counted as "Initiator"
> and is "Drop", and why there's two sessions for what is essentially
> the same flow.
>
> i'm opening a jtac case as well for some help, but maybe someone
> understands why a different session is getting created (i think that's
> what is happening?) and doesn't map back to the originating host
> properly.
>
> ry at iad1-er2# run show services sessions extensive
> ms-0/2/0
> Service Set: SSET1, Session: 1174405192, ALG: none, Flags: 0x0040, IP
> Action: no, Offload: no, Asymmetric: no
> TCP 199.16.156.102:443 -> <$natpool-ip>:32769 Drop I 3
> Byte count: 180
> Flow role: Initiator, Timeout: 4
> Service Set: SSET1, Session: 1442840643, ALG: none, Flags: 0x2000, IP
> Action: no, Offload: no, Asymmetric: no
> NAT PLugin Data:
> NAT Action: Translation Type - NAPT-44
> NAT source 10.1.20.55:40128 -> <$natpool-ip>:32769
> TCP 10.1.20.55:40128 -> 199.16.156.102:443 Forward I 2
> Byte count: 120
> Flow role: Initiator, Timeout: 4
> TCP 199.16.156.102:443 -> <$natpool-ip>:32769 Forward O 0
> Byte count: 0
> Flow role: Responder, Timeout: 4
>
> On Wed, Oct 8, 2014 at 1:55 AM, Alexander Arseniev<arseniev at btinternet.com> <arseniev at btinternet.com> wrote:
>
> Juniper MS-MIC NAPT44 is stateful and is based on sessions (internally in
> MS-MIC the "session" is basically 5-tuple packet info).
> It does deal with asymmetric traffic within the same router - when
> client->server packet exits interface1 but server->client packet returns on
> interface2, this is supported - just assign same service-set to both
> interface1 and interface2 identically.
> But in case of 2 separate physical routers, if there is no session info
> exchange between 2 routers, then asymmetric traffic does not work.
> You may need this featurehttp://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/nat-interchassis-high-availability-msmic-msmpc.html
> for the asymmetric traffic to work with NAPT44, but only for failures, not
> persistent trafic asymmetricity.
> If Your traffic is persistently asymmetric then MS-MIC is a wrong type of
> hardware to use, ScreenOS cluster or SRX cluster is the weapon of choice
> then.
> Thanks
> Alex
>
> On 08/10/2014 07:34, ryanL wrote:
>
> hi. i've got nat working now, much thanks to everyone's tips. a final
> question on this topic (i promise).
>
> how important is it for the ms-mic (in the mx80) to see the in/out
> traffic happen on the same interfaces? for example, i have multiple
> transit connections. the nat outbound packet could go out one transit,
> return via another mx80, and then cross an iBGP session back to the
> "originating" mx80 where the nat config lives.
>
> i've been able to confirm that if i move traffic in and out of the
> same router, it's no problem. but as soon as i introduce some
> asymmetry i tend to get into a bind where curl hangs. we can safely
> assume acl's are not the issue in this scenario, and i'm not using any
> of the stateful firewall features of the ms-mic.
>
> thx!
>
> On Wed, Sep 24, 2014 at 11:04 AM, ryanL <ryan.landry at gmail.com> <ryan.landry at gmail.com> wrote:
>
> very much appreciated, alex.
>
> On Wed, Sep 24, 2014 at 11:01 AM, Alexander Arseniev<arseniev at btinternet.com> <arseniev at btinternet.com> wrote:
>
> "service-filter" is a stateless firewall filter which has only 2 actions:
> either "then service" meaning "divert to Service PIC" (be it MS-PIC, MS-DPC
> NPU, MS-MIC etc) ; or "then skip" meaning "do NOT divert to Service PIC,
> route the usual way".
> "services stateful-firewall" stanza is for defining stateful-firewall
> (SFW) services on Service PIC itself. This SFW service is less sophisticated
> than SRX SFW (filters basic attacks like Teardrop/Land but cannot filter
> more complicated attacks like Winnuke) but has more throughput.
> There are cases when You have to use both. I.e. to offer granulated SFW
> service to different customer subnets on same interface and/or spread the
> load between >1 Service PIC, You have to use both "service-filter" and
> "services stateful-firewall" stanzas.
> I suggest You read "Junos Enterprise Routing" book which has excellent
> primer on Juniper router services (interface-style vs nexthop style, SFW,
> NAT, also IPSec) - either 1st or 2nd edition is fine since basics did not
> change between the two.
> HTH
> Thanks
> Alex
>
>
>
> On 24/09/2014 18:13, ryanL wrote:
>
> alex, thank you. very helpful. of course i particularly like your
> alternative, and that's what i thought i was accomplishing in the first
> place. guess not!
>
> can you explain the diff between `set firewall family inet service-filter`
> vs the documentation example which references `set services
> stateful-firewall` as part of the services set, and which is more
> appropriate to use here in an ms-mic situation?
>
> On Wed, Sep 24, 2014 at 10:00 AM, Alexander Arseniev<arseniev at btinternet.com> <arseniev at btinternet.com> wrote:
>
> I see You are using interface-style NAT - please exclude all control
> traffic in the service-filters from being diverted to MS-MIC, like below
> (rough cut, only BGP and BFD are excluded as an example):
>
> set firewall family inet service-filter sf-in term 1 from protocol tcp
> set firewall family inet service-filter sf-in term 1 from port 179
> set firewall family inet service-filter sf-in term 1 then skip
> set firewall family inet service-filter sf-in term 2 from protocol udp
> set firewall family inet service-filter sf-in term 2 from port [ 3784
> 4784 ]
> set firewall family inet service-filter sf-in term 2 then skip
> set firewall family inet service-filter sf-in term 3 then service
> set firewall family inet service-filter sf-out term 1 from protocol tcp
> set firewall family inet service-filter sf-out term 1 from port 179
> set firewall family inet service-filter sf-out term 1 then skip
> set firewall family inet service-filter sf-out term 2 from protocol udp
> set firewall family inet service-filter sf-out term 2 from port [ 3784
> 4784 ]
> set firewall family inet service-filter sf-out term 2 then skip
> set firewall family inet service-filter sf-out term 3 then service
> set interfaces ge-0/0/0.0 family inet service input service-set SSET1
> service-filter sf-in
> set interfaces ge-0/0/0.0 family inet service output service-set SSET1
> service-filter sf-out
>
> Alternatively, You can construct service-filters in such a way that only
> "interested" traffic is diverted to MS-MIC:
>
> set firewall family inet service-filter sf-in term 1 from source-address
> 10/8
> set firewall family inet service-filter sf-in term 1 from
> destination-address 0/0
> set firewall family inet service-filter sf-in term 1 from
> destination-address 10/8 except
> set firewall family inet service-filter sf-in term 1 then service
> set firewall family inet service-filter sf-in term 2 then skip
>
> set firewall family inet service-filter sf-out term 1 from
> destination-address <your nat pool route here>
> set firewall family inet service-filter sf-out term 1 then service
> set firewall family inet service-filter sf-out term 2 then skip
>
> set interfaces ge-0/0/0.0 family inet service input service-set SSET1
> service-filter sf-in
> set interfaces ge-0/0/0.0 family inet service output service-set SSET1
> service-filter sf-out
>
> HTH
> Thanks
> Alex
>
> On 24/09/2014 17:37, ryanL wrote:
>
> thanks for the replies, folks. indeed it was the no-translation thing
> that is hanging up the commit, and not the reported napt-44 statement. silly
> defect.
>
> i'm using this now:
>
> rule NAT-RULE1 {
> match-direction input;
> term term-2 {
> from {
> source-address {
> 10.0.0.0/8;
> }
> destination-address {
> 0.0.0.0/0;
> 10.0.0.0/8 except; #<---- (good suggestion)
> }
> }
> then {
> translated {
> source-pool NP2;
> translation-type {
> napt-44;
>
> and that seems to commit ok.
>
> however, implementing this on customer-facing interfaces broke the
> customer, dropped BGP sessions, etc. my goal is to only nat traffic if it is
> sourced from 10/8 and destined to anything other than 10/8. the NAT pool is
> a static discard route exported in iBGP to ensure that this router attracts
> return internet traffic in order to keep proper state.
>
> what am i doing wrong? the documentation is quite poor for this module's
> implementation, and sadly i don't have a lab to play with.
>
> On Wed, Sep 24, 2014 at 2:13 AM, Alexander Arseniev<arseniev at btinternet.com> <arseniev at btinternet.com> wrote:
>
> napt44 is most definitely is supported on MS-MIC
> http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/general/nat-implementations-feature-comparison.html
> What is not supported is "no-translation" knob.
> Please change Your config to (rough cut):
> 1/ delete term-1, and
> 2/ change term-2 to:
>
> + term term-2 {
> + from {
> + source-address {
> + 10.0.0.0/8;
> + }
> + destination-address {
> + 0.0.0.0/0;
> + 10.0.0.0/8 except;
> + }
> + }
> + then {
> + translated {
> + source-pool NP2;
> + translation-type {
> + napt-44;
> + }
>
> - then re-test and report back please.
> Thanks
> Alex
>
>
> On 24/09/2014 06:47, ryanL wrote:
>
> has anyone been successful here? i'm getting the following error, even
> though juniper's docs seem to indicate this is supported on the ms-mic
> with
> 13.2.
>
> my ref guides are:
> http://www.juniper.net/techpubs/en_US/junos13.2/information-products/topic-collections/config-guide-services/index.html?features-ms-mic.html
> http://www.juniper.net/techpubs/en_US/junos13.2/topics/example/nat-nat44-config-ms-mpc.html
>
> ry at iad1-er2# show | compare
> [edit]
> + services {
> + service-set SSET1 {
> + nat-rules NAT-RULE1;
> + interface-service {
> + service-interface ms-0/2/0;
> + }
> + }
> + nat {
> + pool NP2 {
> + address <pub_space>/28;
> + port {
> + automatic;
> + }
> + }
> + rule NAT-RULE1 {
> + match-direction input;
> + term term-1 {
> + from {
> + source-address {
> + 10.0.0.0/8;
> + }
> + destination-address {
> + 10.0.0.0/8;
> + }
> + }
> + then {
> + no-translation;
> + }
> + }
> + term term-2 {
> + from {
> + source-address {
> + 10.0.0.0/8;
> + }
> + }
> + then {
> + translated {
> + source-pool NP2;
> + translation-type {
> + napt-44;
> + }
> + }
> + }
> + }
> + }
> + }
> + }
> [edit interfaces]
> + ms-0/2/0 {
> + unit 0 {
> + family inet;
> + }
> + }
>
> [edit]
> ry at iad1-er2# commit check
> [edit services]
> 'service-set SSET1'
> translation type not supported on ms-interface
> error: configuration check-out failed
>
> [edit]
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.nethttps://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.nethttps://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
>
More information about the juniper-nsp
mailing list