Re: [j-nsp] mx80 napt-44 with ms-mic on 13.2R5

2014-09-24 Thread Sergey Khalavchuk 
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] Juniper EX4550

2013-05-12 Thread Sergey Khalavchuk 
Hello,

Take a look at SFP compatibility list:
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/optical-interface-ex4550-support.html

There is cleary stated that all ports (base and uplink module) do support
both 1G and 10G.

--
wbr
sergey khalavchuk


On Mon, May 13, 2013 at 6:19 AM, Suginto Hung suginto.h...@gmail.comwrote:

 Hi everyone,

 I have experience on EX4200, For EX4200, we can only use either 4 1g or 2
 10g.
 For juniper EX4550-32F, Does it support mix port between 1g and 10g?
 Or we must choose 10g or 1g?

 I have difficulty to find about this information.

 Hope someone can help me.

 Thank you.

 br
 Suginto
 ___
 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] MX5-T VPLS fowarding problem

2013-03-31 Thread Sergey Khalavchuk 
Hello,

On Fri, Mar 29, 2013 at 11:27 PM, Mathias Sundman math...@nilings.se wrote:
 On 03/29/2013 12:40 PM, Caillin Bathern wrote:

 Can someone explain the benefits of using tunnel-services vs
 no-tunnel-services on the MX80 platform for VPLS services?

tunnel-services are just a hack to allow two lookups per one frame
received from mpls backbone using frame re-circulation:
1) label lookup to map frame to vpls instance,
2) mac lookup to forward frame to correct interface.

Recirculation means that every frame must be processed TWICE. And it
is possible that frame will cross fabric twice.
For this reason, when you enable tunnel-services for fpc, you must put
bandwidth limit (1g or 10g), and recirculated traffic will be policed.

On older fpc it is mandatory for VPLS.
On newer fpcs, it is possible to perform 1st lookup with IO manager on
ingress linecard, and avoid recirculation.

So, with vrf-table-label or with no-tunnel-services, there is single
lookup, no performance penalty, only profit.

Why tunnel-services may be needed?
1) older fpc (not mx).
2) SDH/ATM/local tunnels on ingress line-card doesn't allow IO manager
to perform 1st lookup, so tunnel services will be required.

 With a 10G backbone using 3-4 of the built-in 10G interfaces, and an
 expected VPLS use of 1-4G of bandwidth, what would be the recommended
 config?

use vrf-table-label of no-tunnel-services.

--
wbr,
Sergey Khalavchuk
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp