Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5
Hello!
We had tested napt44 half a year ago, and napt44 configuration was
commiting successfuly but not functioning at all.
JTAC reported that napt44 is not supported on MIC, and created PR993320 for
us.
Based on commit error, this PR is fixed on your junos :)
We also been told that napt44 will probably appear at middle of next year
or about so.
--
wbr,
Sergey Khalavchuk
On Wed, Sep 24, 2014 at 8:47 AM, ryanL ryan.lan...@gmail.com 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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
--
wbr
sergey khalavchuk
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5
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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] pfe-x/x/x and pfh-a/a/a
Hi Tom, Did you manage to get an answer for this. I am also looking for an explanation to interfaces that have been captured as part of a SNMP walk on our MX. Can anyone shed any light on what a pfe and pfh interface is ? Is there a doc with all interface types that describe what these are ? I have searched and couldn't find a satisfactory document. Thanks JFD On 21 November 2011 17:22, Thomas Eichhorn t...@te3networks.de wrote: Dear all, I just saw some interfaces named pfe- and pfh- on a trio based MX960: teichhorn@R10-et show interfaces pfh-7/0/0 Physical interface: pfh-7/0/0, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 549 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfh-7/0/0.16383 (Index 328) (SNMP ifIndex 552) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited teichhorn@R10-et show interfaces pfe-7/0/0 Physical interface: pfe-7/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 550 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfe-7/0/0.16383 (Index 327) (SNMP ifIndex 553) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited Protocol inet6, MTU: Unlimited My best guess would be that pfe-x/x/x has something to do with the pfe, but pfh is completely unclear... Has someone here a little bit more information about the purpose of these ifaces? Thanks, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] pfe-x/x/x and pfh-a/a/a
Take a look at http://kb.juniper.net/InfoCenter/index?page=contentid=KB23578 for a brief description of the pfh interfaces. Edward Dore Freethought Internet On 24 Sep 2014, at 10:48, junos fordummies junos.fordumm...@googlemail.com wrote: Hi Tom, Did you manage to get an answer for this. I am also looking for an explanation to interfaces that have been captured as part of a SNMP walk on our MX. Can anyone shed any light on what a pfe and pfh interface is ? Is there a doc with all interface types that describe what these are ? I have searched and couldn't find a satisfactory document. Thanks JFD On 21 November 2011 17:22, Thomas Eichhorn t...@te3networks.de wrote: Dear all, I just saw some interfaces named pfe- and pfh- on a trio based MX960: teichhorn@R10-et show interfaces pfh-7/0/0 Physical interface: pfh-7/0/0, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 549 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfh-7/0/0.16383 (Index 328) (SNMP ifIndex 552) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited teichhorn@R10-et show interfaces pfe-7/0/0 Physical interface: pfe-7/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 550 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfe-7/0/0.16383 (Index 327) (SNMP ifIndex 553) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited Protocol inet6, MTU: Unlimited My best guess would be that pfe-x/x/x has something to do with the pfe, but pfh is completely unclear... Has someone here a little bit more information about the purpose of these ifaces? Thanks, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] pfe-x/x/x and pfh-a/a/a
thanks Ed !! On 24 September 2014 10:59, Edward Dore edward.d...@freethought-internet.co.uk wrote: Take a look at http://kb.juniper.net/InfoCenter/index?page=contentid=KB23578 for a brief description of the pfh interfaces. Edward Dore Freethought Internet On 24 Sep 2014, at 10:48, junos fordummies junos.fordumm...@googlemail.com wrote: Hi Tom, Did you manage to get an answer for this. I am also looking for an explanation to interfaces that have been captured as part of a SNMP walk on our MX. Can anyone shed any light on what a pfe and pfh interface is ? Is there a doc with all interface types that describe what these are ? I have searched and couldn't find a satisfactory document. Thanks JFD On 21 November 2011 17:22, Thomas Eichhorn t...@te3networks.de wrote: Dear all, I just saw some interfaces named pfe- and pfh- on a trio based MX960: teichhorn@R10-et show interfaces pfh-7/0/0 Physical interface: pfh-7/0/0, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 549 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfh-7/0/0.16383 (Index 328) (SNMP ifIndex 552) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited teichhorn@R10-et show interfaces pfe-7/0/0 Physical interface: pfe-7/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 550 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfe-7/0/0.16383 (Index 327) (SNMP ifIndex 553) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited Protocol inet6, MTU: Unlimited My best guess would be that pfe-x/x/x has something to do with the pfe, but pfh is completely unclear... Has someone here a little bit more information about the purpose of these ifaces? Thanks, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] pfe-x/x/x and pfh-a/a/a
Hello Mates fpc/pic/port.16383 is an internally generated, nonconfigurable interface for router control traffic. -- Sent from myMail app for Android Wednesday, 24 September 2014, 00:48PM +03:00 from junos fordummies junos.fordumm...@googlemail.com: Hi Tom, Did you manage to get an answer for this. I am also looking for an explanation to interfaces that have been captured as part of a SNMP walk on our MX. Can anyone shed any light on what a pfe and pfh interface is ? Is there a doc with all interface types that describe what these are ? I have searched and couldn't find a satisfactory document. Thanks JFD On 21 November 2011 17:22, Thomas Eichhorn t...@te3networks.de wrote: Dear all, I just saw some interfaces named pfe- and pfh- on a trio based MX960: teichhorn@R10-et show interfaces pfh-7/0/0 Physical interface: pfh-7/0/0, Enabled, Physical link is Up Interface index: 135, SNMP ifIndex: 549 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfh-7/0/0.16383 (Index 328) (SNMP ifIndex 552) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited teichhorn@R10-et show interfaces pfe-7/0/0 Physical interface: pfe-7/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 550 Speed: 800mbps Device flags : Present Running Link flags : None Last flapped : Never Input packets : 0 Output packets: 0 Logical interface pfe-7/0/0.16383 (Index 327) (SNMP ifIndex 553) Flags: SNMP-Traps Encapsulation: ENET2 Bandwidth: 0 Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited Protocol inet6, MTU: Unlimited My best guess would be that pfe-x/x/x has something to do with the pfe, but pfh is completely unclear... Has someone here a little bit more information about the purpose of these ifaces? Thanks, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Sampling - High CPU
+1 here, definitely awaiting these releases.
On Sep 23, 2014, at 4:28 PM, Graham Brown juniper-...@grahambrown.info wrote:
12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I think
there are many people waiting for these two releases...
Cheers,
Graham Brown
Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer
LinkedIn http://www.linkedin.com/in/grahamcbrown
On 24 September 2014 03:18, Justin M. Streiner strei...@cluebyfour.org
wrote:
Sounds like you are running into bugs PR963060 or PR671136.
This is supposed to be fixed in 12.3R8 which is supposed to be released
very soon.
We ran into this behavior on a pair of MX480s and had to disable sampling
for the time being.
jms
On Tue, 23 Sep 2014, Ritz Rojas wrote:
We have a few MX80s (MX80-48T) that we're looking to deploy in certain
applications where they'll be taking full Internet tables (v4 and v6). We
also have a need to gather flow data on our routers, and have noticed an
interesting trend in the lab.
We are not using an MS-MIC currently.
This test box is running 12.3R7.7 at the moment, but we've seen this same
thing in 11.4 too.
When set up with full Internet routes and sampling is enabled, each time a
commit is made for any change at all, RPD and sampled take turns grinding
the CPU up to 100%, for up to 5-10 minutes or more post-commit, and we see
changes to BGP policy sometimes stall and take a decent amount of time (on
the order of several minutes or more) to actually take effect.
First RPD will climb up to almost 100% CPU utilization, chew it for a few
minutes, then it'll go down and sampled will climb up to almost 100% for
it's couple minutes turn and chew a bit. Then sampled goes back down and
RPD takes back over to 100% for a few more minutes. Eventually it all
finally calms back down and normalizes back to expected levels.
Turn off sampling, and any CPU spikes post-commit are only on the order of
seconds, not minutes, and any policy changes take effect pretty much
immediately.
We've seen this regardless of how flow is configured; we've configured
flow
with a simple config, as well as inline jflow, pretty much with the same
results. We're curious if anyone's had any of these same problems with
jflow killing the CPU on MX80s (yeah, I know these PPC boxes are pretty
weak sisters), and if there's any fix beyond the usual Doctor, it hurts
when I do this, what should I do?. Don't do that!.
It's a nice feature, shame that using it seems to come with this heavy a
price.
As an aside, we also see a bit of a slowdown in the RIB/FIB
learning/purging on BGP session turnup/reset, which we're well aware is a
known issue with sampling enabled, so I won't be shocked if this is just
how it is. I'd love to be wrong.
Here's our sampling config, quick and dirty, regular and inline jflow, in
case we're missing something.
Normal Sampling:
router show configuration forwarding-options
sampling {
input {
rate 8192;
run-length 0;
max-packets-per-second 2;
}
family inet {
output {
flow-server x.x.x.x {
port x;
version 5;
}
}
}
}
router show configuration interfaces xe-0/0/0
unit xxx {
vlan-id xxx;
family inet {
sampling {
input;
output;
}
}
Inline Jflow Sampling:
router show configuration forwarding-options
sampling {
instance {
BLAH-INSTANCE {
input {
rate 5000;
}
family inet {
output {
flow-server x.x.x.x {
port ;
autonomous-system-type origin;
no-local-dump;
version-ipfix {
template {
BLAH-TEMPLATE;
}
}
}
inline-jflow {
source-address x.x.x.x;
}
}
}
}
}
}
router show configuration chassis
tfeb {
slot 0 {
sampling-instance BLAH-INSTANCE;
}
}
router show configuration services
flow-monitoring {
version-ipfix {
template BLAH-TEMPLATE {
flow-active-timeout 10;
flow-inactive-timeout 10;
template-refresh-rate {
packets 1;
seconds 10;
}
option-refresh-rate {
packets 1;
seconds 10;
}
ipv4-template;
}
}
}
router show configuration interfaces xe-0/0/0
unit xxx {
vlan-id xxx;
family inet {
sampling {
input;
output;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5
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 arsen...@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5
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 http://10.0.0.0/8;
}
destination-address {
0.0.0.0/0 http://0.0.0.0/0;
10.0.0.0/8 http://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
arsen...@btinternet.com mailto:arsen...@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 http://10.0.0.0/8;
+ }
+ destination-address {
+ 0.0.0.0/0 http://0.0.0.0/0;
+ 10.0.0.0/8 http://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:
Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5
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
arsen...@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
arsen...@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 {
+
Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU
Okay so we traced this down to BGP Replication for NSR. Looks like a bad attribute kills the replication process. Other than blocking the received prefix is there a way to fix this: Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received malformed update from x Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Family inet-unicast, prefix 5.56.168.0/21 Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Malformed Attribute AGGREGATOR4(18) flag 0xc0 length 8. Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Total incoming malformed attributes from xx since last logging Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received 1 malformed attribute AGGREGATOR4(18) Mind you, the primary session with the peer stays up, this only kills the replication process... Scott H. On 9/18/14, 11:38 AM, Scott Harvanek wrote: Has anyone had a issue with MX units in a VC where BGP rsync was consuming a boatload of CPU? Master chassis shows: Task StartedUser Time System Time Longest Run BGP rsync 9650 10. 0.8 0.0 ( BGP rsync is the only task with any user time during high user CPU for rpd ) now, that's only like 20% CPU on the master but on the slave it's 90% This seems to have happened when our total paths exceeded 2MM but does not seem to be a memory issue: Dynamically allocated memory: 411009024 Maximum: 808517632 Program data+BSS memory:5537792 Maximum: 5537792 Page data overhead:1196032 Maximum: 1196032 Page directory size: 212992 Maximum: 212992 -- Total bytes in use: 417955840 (12% of available memory) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 BNG licensing
Correct, unless you use other features that requires S-MX80-SSM-FP. Regards, Wojciech ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU
Have You tried drop-path-attributes http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10491 ? You can drop any attribute, not only 128 as in the KB. Thanks Alex On 24/09/2014 18:38, Scott Harvanek wrote: Okay so we traced this down to BGP Replication for NSR. Looks like a bad attribute kills the replication process. Other than blocking the received prefix is there a way to fix this: Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received malformed update from x Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Family inet-unicast, prefix 5.56.168.0/21 Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Malformed Attribute AGGREGATOR4(18) flag 0xc0 length 8. Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Total incoming malformed attributes from xx since last logging Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received 1 malformed attribute AGGREGATOR4(18) Mind you, the primary session with the peer stays up, this only kills the replication process... Scott H. On 9/18/14, 11:38 AM, Scott Harvanek wrote: Has anyone had a issue with MX units in a VC where BGP rsync was consuming a boatload of CPU? Master chassis shows: Task StartedUser Time System Time Longest Run BGP rsync 9650 10. 0.8 0.0 ( BGP rsync is the only task with any user time during high user CPU for rpd ) now, that's only like 20% CPU on the master but on the slave it's 90% This seems to have happened when our total paths exceeded 2MM but does not seem to be a memory issue: Dynamically allocated memory: 411009024 Maximum: 808517632 Program data+BSS memory:5537792 Maximum: 5537792 Page data overhead:1196032 Maximum: 1196032 Page directory size: 212992 Maximum: 212992 -- Total bytes in use: 417955840 (12% of available memory) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5
very much appreciated, alex.
On Wed, Sep 24, 2014 at 11:01 AM, Alexander Arseniev
arsen...@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
arsen...@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
Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU
Well shoot, that's a great idea, looks like this command is hidden so I didn't even see it. I assume AGGREGATOR4 is type code 18? I can't find anything official confirming that though? Scott H. On 9/24/14, 3:39 PM, Alexander Arseniev wrote: Have You tried drop-path-attributes http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10491 ? You can drop any attribute, not only 128 as in the KB. Thanks Alex On 24/09/2014 18:38, Scott Harvanek wrote: Okay so we traced this down to BGP Replication for NSR. Looks like a bad attribute kills the replication process. Other than blocking the received prefix is there a way to fix this: Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received malformed update from x Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Family inet-unicast, prefix 5.56.168.0/21 Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Malformed Attribute AGGREGATOR4(18) flag 0xc0 length 8. Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Total incoming malformed attributes from xx since last logging Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received 1 malformed attribute AGGREGATOR4(18) Mind you, the primary session with the peer stays up, this only kills the replication process... Scott H. On 9/18/14, 11:38 AM, Scott Harvanek wrote: Has anyone had a issue with MX units in a VC where BGP rsync was consuming a boatload of CPU? Master chassis shows: Task StartedUser Time System Time Longest Run BGP rsync 9650 10. 0.8 0.0 ( BGP rsync is the only task with any user time during high user CPU for rpd ) now, that's only like 20% CPU on the master but on the slave it's 90% This seems to have happened when our total paths exceeded 2MM but does not seem to be a memory issue: Dynamically allocated memory: 411009024 Maximum: 808517632 Program data+BSS memory:5537792 Maximum: 5537792 Page data overhead:1196032 Maximum: 1196032 Page directory size: 212992 Maximum: 212992 -- Total bytes in use: 417955840 (12% of available memory) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Virtual Chassis RPD/BGP Rsync high CPU
Disregard, 18 is correct, looks like IETF/RFC4893 has this as AS4_AGGREGATOR not AGGREGATOR4. Scott H. Login Inc. On 9/24/14, 5:11 PM, Scott Harvanek wrote: Well shoot, that's a great idea, looks like this command is hidden so I didn't even see it. I assume AGGREGATOR4 is type code 18? I can't find anything official confirming that though? Scott H. On 9/24/14, 3:39 PM, Alexander Arseniev wrote: Have You tried drop-path-attributes http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10491 ? You can drop any attribute, not only 128 as in the KB. Thanks Alex On 24/09/2014 18:38, Scott Harvanek wrote: Okay so we traced this down to BGP Replication for NSR. Looks like a bad attribute kills the replication process. Other than blocking the received prefix is there a way to fix this: Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received malformed update from x Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Family inet-unicast, prefix 5.56.168.0/21 Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Malformed Attribute AGGREGATOR4(18) flag 0xc0 length 8. Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Total incoming malformed attributes from xx since last logging Sep 24 17:31:06 TUS-2-VC-1 rpd[48424]: Received 1 malformed attribute AGGREGATOR4(18) Mind you, the primary session with the peer stays up, this only kills the replication process... Scott H. On 9/18/14, 11:38 AM, Scott Harvanek wrote: Has anyone had a issue with MX units in a VC where BGP rsync was consuming a boatload of CPU? Master chassis shows: Task StartedUser Time System Time Longest Run BGP rsync 9650 10. 0.8 0.0 ( BGP rsync is the only task with any user time during high user CPU for rpd ) now, that's only like 20% CPU on the master but on the slave it's 90% This seems to have happened when our total paths exceeded 2MM but does not seem to be a memory issue: Dynamically allocated memory: 411009024 Maximum: 808517632 Program data+BSS memory:5537792 Maximum: 5537792 Page data overhead:1196032 Maximum: 1196032 Page directory size: 212992 Maximum: 212992 -- Total bytes in use: 417955840 (12% of available memory) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] T4000 power architecture
Hi Fred, Thanks for the reply. Your suggestions from step 1 - 3.2 makes sense. Having said that, rather than swapping the PEMs in step 4, I can just swap PEM1 with a replacement (we have support on the chassis). The difficulty for me is we have to get electricians onsite out of hours to do this - which I'm trying to avoid if it's unlikely the PEM is actually at fault. This would be the case if the PEM output is carried to the FPCs via a common bus arrangement, at which point I would suggest there is no way the PEM can be at fault considering all the other FPCs DO show power being received from PEM1. If I can confirm (via JTAC or otherwise) what the power architecture is, then we can save this step, bite the bullet and move on with getting the chassis replaced without wasting time on replacing the PEM, then having to get a second window booked with electricians etc to swap out the whole chassis. I suppose ultimately part of the problem here has been that my coworkers and myself would have assumed back in July when we first lodged this issue to JTAC that asking a relatively straightforward question (how is the power distributed from the PEMs to the FPCs in a T4000?) that we would have actually had a fairly clear answer without too much fuss. To date, that hasn't happened - we can't work out why this is; is it that nobody runs T4000s? Is it that nobody in Juniper has this information? Is it 'commercially sensitive' enough that nobody wants to tell us? The response from JTAC so far has basically been hand-waving and avoiding the question. That doesn't give me much confidence in either the platform or JTAC. Cheers, Sam On Thu, Sep 25, 2014 at 2:33 AM, Fred Quan fq...@juniper.net wrote: Hi Sam, Maybe you can try the below steps to isolate the problem. 1. run show chassis environment pem to check which FPC has 0 Voltage and Current on PEM. ( Here, I assume that, FPC 0 has 0 Voltage and Current on PEM 1 ) 2. check FPC 0 is Online state with Dual PEM power on. 3. power off PEM #0 in slot 0, then check FPC 0 state. 3.1 if FPC 0 is still Online state with single PEM #1 power on, then PEM #1 in slot 1 can provide power to FPC 0, it is a display problem in STEP 1. 3.2 if FPC 0 is Offline state with single PEM #1 power on, then PEM #1 in slot 1 cannot provide power to FPC 0, then continue STEP 4. 4. power off both PEMs and swap PEM #0 and PEM #1, so PEM #0 in slot 1 and PEM #1 in slot 0. 5. power on PEM #1 in slot 0 only. It looks like the PEM #1 problem if FPC 0 is Offline state. 6. power on PEM #0 in slot 1 only. It looks like the Mid plane problem if FPC 0 is Offline state. Regards, -Fred From: juniper-nsp juniper-nsp-boun...@puck.nether.net on behalf of Sam Silvester sam.silves...@gmail.com Sent: Tuesday, September 23, 2014 9:40 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] T4000 power architecture Bumping for good measure... So JTAC are suggesting it's either the PEM or the midplane, but I was hoping to get some more information so I can validate what I'm being told - which, currently, is very little. Basically the suggestion is replace the PEM, if that doesn't work replace the chassis. I'd like to avoid whack-a-mole if possible; for example, if I knew that all of the FPCs were fed via the PEM via a central bus on the midplane, then we don't have to worry about replacing the PEM and can go straight ahead with organising a chassis swap. I don't suppose somebody happens to have a spare T4000 chassis or PEM lying around and could take a photo of the connectors between the PEM and the midplane? I'm still trying to get an idea of how power is distributed from the PEM to the actual FPC slots. The exact same questions has been posed to JTAC multiple times, but no answer has been forthcoming. I really hope the nagging suspicion I have that nobody in Juniper knows this information is incorrect but in the meantime I'm posting here in the hope I can figure it out from some pictures. Google image search isn't helping me find any clear photos of the rear of the PEM or the midplane :/ Sam On Thu, Sep 11, 2014 at 8:06 AM, Sam Silvester sam.silves...@gmail.com wrote: Hi Aqeel - thanks for the reply. Agree 100% - the problem is, we only seem to be getting power to FPC0 from one PEM... have a look below (and also note that FPC1 is fine, as are the rest of the FPCs). The question is - are we looking at a PEM fault here, or a midplane fault? As per previous discussion, the FPC itself seems fine, as moving it to another slot resolves the issue. Putting another card into slot 0 yields the same result as below. PEM 0 status: State Online Temperature32 degrees C / 89 degrees F DC Input: OK Voltage(V) Current(A) Power(W) Load(%) INPUT 0 54.750 4.312 236
