Re: [j-nsp] Junos Fusion Provider Edge

[magno]

Ciao William,

Today VC as Aggregation Device is not suported, so the AD must be a single
MX. The license model is on both AD (one single license) + 1 license for
each satellite.

HTH

Max.

On Mon, Jun 6, 2016 at 4:05 PM, Jackson, William <
william.jack...@gibtele.com> wrote:

> Hi all
>
> Any one used Junos Fusion Provider Edge?
>
> I was wondering if the aggregation device can be an MX virtual Chassis
> rather than a single standalone MX?
>
> And if using qfx units as satellites, do you need any fancy licenses on
> them if the smarts are on the MX?
>
> Many thanks
>
> William Jackson
> NGN Engineering
>
> Gibtelecom
> Tel: +350 58007229
> Fax: +350 2004
>
>
>
> ___
> 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 no more hash-key option in 12.2?

[magno]

Hi Paul,

 with MX TRIO you don't need to configure anything to achieve almost the
behaviour you need (almost = not per packet, read below).

 TCP and UDP ports are taken into account on TRIO by default for both IPv6
and IPv4. Please be aware of some more info:

- TRIO doesn't support per-packet LB, per session only is supported as per
Juniper tradition (only the origina IPv1 asic supported per packet, and
still we have this legacy thing in our CLI ;-));
- you need to apply the export policy to the routing-options
forwarding-table stanza;
- TRIO load balances symmetrically, this means that if you have back to
back TRIO, both devices will chose the same link because the parameters are
ordered in lower/higher way;
- It's not possible to selectivly disable layer-4 port for UDP or TCP, just
for L3 protocol (for instance, you consider L4 ports for IPv4 and not for
IPv6...);

HTH

Max.

On Tue, Oct 23, 2012 at 5:56 PM, Paul Vlaar  wrote:

> Hi Magno,
>
> that clarifies things a bit more for me, thank you.
>
> However, am I right to conclude that I still need the hash-key stanza
> for our 11.2 MX80s to make IPv6 source/destination hashing work for load
> balancing?
>
> As for what I am trying to do, well, that is pretty simple. We have ECMP
> for a number of IPv4 /32 and IPv6 /128 addresses setup via BGP within
> our own network, to 32 servers. We want to have load balancing across
> these servers for these addresses, and the hashing algorithm should
> cause UDP to be distributed per packet, but TCP to be distributed
> according to a src_ip:src_port:dst_ip:dst_port hash.
>
> Thank you,
>
> ~paul
>
> On 23/10/12 5:12 PM, magno wrote:
> > Hi Paul!
> >
> >  Leaving the hash-key stanza enabled for MX80 leaves room to unexpected
> > behaviours as you could observe yourself.
> >
> >  the only supported way to tweak load balancing input paramters for TRIO
> > based devices (I mean MPCs and MX80 for instance) is to use the
> > enhanced-hash-key stanza.
> >
> >  The culprit for the new 12.2 behavior is me, I asked for this
> > modification in the code. The reasons why I asked are:
> >
> > 1) hash-key is not the right config stanza for TRIO as per design, so
> > the enhanced-hash-key stanza was created;
> > 2) Our docs is not, let me say, so precise ... to say it in a fair way;
> > 3) the hash-key, on MX80, produced unpredictable results as some
> > commands led to wrong configurations on the TRIO chipset (for instance,
> > I tried personally with a 10.4 release to configure source/destination
> > ports which are on by default and I found in the PFE this command
> > activated the input interface);
> >
> > Please take into consideration that the engineers that designed TRIO LB
> > decided to simplify the LB options traditionally available on other
> > chipsets, so you may find missing ones under the enhanced-hash-key. TRIO
> > LB algorithm is already pretty much sophisticated by default.
> >
> > Of course, if you explain what you want to do, maybe we may find the
> > best way to satisfy your needs.
> >
> > Hope this  helps tp clarify the subject a little bit more.
> >
> > Massimo.
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 no more hash-key option in 12.2?

[magno]

Hi Paul!

 Leaving the hash-key stanza enabled for MX80 leaves room to unexpected
behaviours as you could observe yourself.

 the only supported way to tweak load balancing input paramters for TRIO
based devices (I mean MPCs and MX80 for instance) is to use the
enhanced-hash-key stanza.

 The culprit for the new 12.2 behavior is me, I asked for this modification
in the code. The reasons why I asked are:

1) hash-key is not the right config stanza for TRIO as per design, so the
enhanced-hash-key stanza was created;
2) Our docs is not, let me say, so precise ... to say it in a fair way;
3) the hash-key, on MX80, produced unpredictable results as some commands
led to wrong configurations on the TRIO chipset (for instance, I tried
personally with a 10.4 release to configure source/destination ports which
are on by default and I found in the PFE this command activated the input
interface);

Please take into consideration that the engineers that designed TRIO LB
decided to simplify the LB options traditionally available on other
chipsets, so you may find missing ones under the enhanced-hash-key. TRIO LB
algorithm is already pretty much sophisticated by default.

Of course, if you explain what you want to do, maybe we may find the best
way to satisfy your needs.

Hope this  helps tp clarify the subject a little bit more.

Massimo.

On Tue, Oct 23, 2012 at 4:14 PM, Paul Vlaar  wrote:

> Doug,
>
> On 23/10/12 9:52 AM, Doug Hanks wrote:
> > Pretty much. enhanced-hash-hey does a lot by default. Harry can
> elaborate.
>
> So on 11.2 at least, enhanced-hash-key doesn't offer me any options to
> set, as the defaults should already enable port based hashing:
>
> mx80# set forwarding-options enhanced-hash-key family inet ?
> Possible completions:
> + apply-groups Groups from which to inherit configuration data
> + apply-groups-except  Don't inherit configuration dta from these groups
>   incoming-interface-index  Include incoming interface index in the hash
> key
>   no-destination-port  Omit IP destination port in the hash key
>   no-source-port   Omit IP source port in the hash key
>   type-of-service  Include TOS byte in the hash key
> [edit]
>
> So I'm left with no options to set. And when I deactivate/remove the
> hash-key setting from forwarding-options, I get:
>
> mx80# request pfe execute command "show jnh lb" target tfeb0
> SENT: Ukern command: show jnh lb
> GOT:
> GOT: Unilist Seed Configured 0x8bce4c39 System Mac address
> 00:00:00:00:00:00
> GOT: Hash Key Configuration: 0x00e8ff00 0x
> GOT:IIF-V4: Yes
> GOT:  SPORT-V4: Yes
> GOT:  DPORT-V4: Yes
> GOT:   TOS: Yes
> GOT:
> GOT:IIF-V6: No
> GOT:  SPORT-V6: No
> GOT:  DPORT-V6: No
> GOT: TRAFFIC_CLASS: No
> GOT:
> GOT:  IIF-MPLS: No
> GOT:  MPLS_PAYLOAD: Yes
> GOT:  MPLS_EXP: No
> GOT:
> GOT:   IIF-BRIDGED: No
> GOT: MAC ADDRESSES: Yes
> GOT: ETHER_PAYLOAD: Yes
> GOT:  802.1P OUTER: No
> GOT:
> GOT: Services Hash Key Configuration:
> GOT:  SADDR-V4: No
> GOT:IIF-V4: No
> GOT:
> LOCAL: End of file
>
> So that shows there is no port based hashing done for ECMP IPv6 traffic.
>
> Bringing back:
>
> forwarding-options hash-key family inet6 { layer3; layer4; }
>
> Yields:
>
> pvlaar@r1.iad1> request pfe execute command "show jnh lb" target tfeb0
> SENT: Ukern command: show jnh lb
> GOT:
> GOT: Unilist Seed Configured 0x8bce4c39 System Mac address
> 00:00:00:00:00:00
> GOT: Hash Key Configuration: 0x00ec 0x
> GOT:IIF-V4: Yes
> GOT:  SPORT-V4: Yes
> GOT:  DPORT-V4: Yes
> GOT:   TOS: Yes
> GOT:
> GOT:IIF-V6: Yes
> GOT:  SPORT-V6: Yes
> GOT:  DPORT-V6: Yes
> GOT: TRAFFIC_CLASS: Yes
> GOT:
> GOT:  IIF-MPLS: No
> GOT:  MPLS_PAYLOAD: Yes
> GOT:  MPLS_EXP: No
> GOT:
> GOT:   IIF-BRIDGED: No
> GOT: MAC ADDRESSES: Yes
> GOT: ETHER_PAYLOAD: Yes
> GOT:  802.1P OUTER: No
> GOT:
> GOT: Services Hash Key Configuration:
> GOT:  SADDR-V4: No
> GOT:IIF-V4: No
> GOT:
> LOCAL: End of file
>
>
> So the hash-key option definitely does *something*, and is in fact
> necessary on 11.2 to get port hashing working for IPv6.
>
> ~paul
>
>
>
> ___
> 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] Upgrading MX5/10/40 to a higher model

[magno]

Hi Skeeve,

 it just works immediately, no reboot is needed.

HTH

Massimo.

On Wed, Oct 10, 2012 at 1:32 PM, Skeeve Stevens <
skeeve+juniper...@eintellego.net> wrote:

> Hey all,
>
> Can someone who has done it, tell me if upgrading an MX5 (or 10, 40) to a
> higher model is something that you have to reboot for or once the license
> is entered, it 'just works' immediately.
>
> Thanks.
>
> *
>
> *
> *Skeeve Stevens, CEO - *eintellego Pty Ltd
> ske...@eintellego.net ; www.eintellego.net
>
> Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellego ;  
> linkedin.com/in/skeeve
>
> twitter.com/networkceoau ; blog: www.network-ceo.net
>
> The Experts Who The Experts Call
> Juniper - Cisco – IBM - Cloud
> ___
> 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] CGN ob MX5?

[magno]

Hi Pavel, some corrections inline.

Ciao
Magno

On Sat, Apr 14, 2012 at 2:09 PM, Pavel Lunin  wrote:

> Hi,
>
> Until Juniper realizes MS-MIC (I have no idea when it will happen) MX5–80
> boxes really supports no NAT at all.
>
[MAGNO] Not dynamic NAT (or PBA), just static 1:1 nat

>
> What they call Inline NAT on Trio (recently realized) is by now… umm… sort
> of a patch for a particular customer or something like. It only supports
> 1:1 bidirectional static mapping, which in no way has any relation to CGN.
> If you take the license price into account, you'll understand what my
> "umm…"  really means.
>
> AFAIK, the idea behind real inline NAT (not just static mapping) on Trio is
> using the embedded TCAM memory. Something like what NetScreen/ISG firewalls
> did. This approach processes first packets though the 'long cycle' in
> software and than offloads the session state to TCAM, though which the
> subsequent packets are switched.
>
[MAGNO] Not really. 1:1 static nat is not using TCAM, basically it is a
very basic form of NAT which won't require the maintenance of any
connection table.
Handling a connection table to support dynamic form of NAT is not suitable
for TRIO (or for any other forwarding asic) for both memory constraints and
processing time.

>
> Two challenges arise here:
>
> 1. The need for a flexible and powerful CPU for 'long cycle' processing.
> I'm afraid, the LU-chip inside Trio is not the best thing here.
> 2. TCAM update speed bottleneck.
>
> [MAGNO] LU may even be able to do NAT, it is really very flexible indeed,
but it can't maintain any session / connection table, for sure not at a
scale. MS-DPC has for instance 4 Gigabytes of RAM and a dedicated multicore
processor to do it. TCAM is not used in inline nat.


> If you take a look at the new session per second rate of any TCAM-based
> flow-device, you'll see it's quite not much in the context of CGN.
>
> However, as of what I know, Juniper mobile team, which develops GGSN from
> MX, is going this way and they even have special MPCs with extended TCAM.
> In mobile world, though, where session lengths are usually longer on
> account of the lower access rates and, consequently, the new sps rates a
> also lower, theoretically, this can be a solution.
>
> [MAGNO] the TCAM won't be enlarged on the new Enhanced MPCs, just a region
of LU memory will be doubled. TCAM is physicall present inside MPCs but it
is not used by any software as per today. TCAMs are not the most suitable
solution to scale and maintaining low power consumption for instance.

> --
> Pavel
>  ___
> 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] VPLS Lab

[magno]

Hi Robert,

  if you put SRX in packet mode, you'll be able to implement VPLS.

 All your hardware is VPLS capable (J/SRX in packet mode, MX80 with some
more features related to the VPLS integration with layer 2 features like
bridge domain, virtual switch and so on).

HTH

Max

On Wed, Dec 28, 2011 at 10:14 AM, Robert Hass  wrote:

> Hi
> I just want to build VPLS lab (carry couple of VLANs between 4
> routers) for test some solutions. Is VPLS supported on software
> routers (J-Series or SRX) ? Performance is not important here - as
> it's for LAB few mbps is enough.
>
> BTW. I've got couple of J2320 with extended RAM and one MX80 in LAB.
>
> Robert
> ___
> 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] MX VPLS Trunk with VLAN rewriting

[magno]

hi Sebastian,

 did you try to remove the vlan-id statement at all (I mean, no vlan-id
none but no vlan-id at all)?

Massimo.

On Thu, Dec 22, 2011 at 10:20 PM, Sebastian Wiesinger <
juniper-...@ml.karotte.org> wrote:

> * Serge Vautour  [2011-12-22 17:28]:
> > Hello,
> >
> > Have you tried building this up from a very simple setup that works
> > and adding complexity as you go? I've done something like this with
> > the "vlan-id all" before but not with the VLAN tag manipulations at
> > the same time.
>
> Hi,
>
> yes I begun with a simple setup where I just connected two sites with
> one vlan on each site and "vlan-id none". The VLAN manipulation is the
> only thing that doesn't seem to work.
>
>
> > The first thing that looks odd to me is the input-vlan map. Why do
> > you need it? Swap on egress should be enough. Another thing I'm not
> > sure about is both sub-interfaces in the same site. I'd put them in
> > separate sites.
>
> I need the input-vlan-map to rewrite the vlan tag so that it is the
> same in the vpls instance on both sites.
>
> The subinterfaces are on the same L2 switch, why should I put them in
> different sites? What if I have 100 subinterfaces, I can't (or don't
> want to) make 100 sites for that on every PE.
>
> > Try making this work by using the same VLAN on both ends, then add
> > the VLAN manipulation. I've got something that looks almost exactly
> > the same as this in my lab and it works:
>
> If I have the same VLAN on both sites it works, but I don't have that
> in the production setup so that's not an option. :(
>
> Regards
>
> Sebastian
>
> --
> New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0
> B9CE)
> Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
>-- Terry Pratchett, The Fifth Elephant
> ___
> 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] VLAN / IRB config on MX Trio

[magno]

Old style will be there , no problem about that.

New style is supported on TRIO starting with JUNOS 11.1

HTH

Max

On Fri, Dec 16, 2011 at 4:07 AM, Chuck Anderson  wrote:

> On Thu, Dec 15, 2011 at 08:54:11PM -0500, Brendan Mannella wrote:
> > www.mail-archive.com/juniper-nsp@puck.nether.net/msg11424.html
> >
> > My fear is if i reconfig to the old style, eventually when code
> > catches up, i will then have to reconfigure everything to the new
> > style.
>
> I don't think the old style will ever stop being supported.
> ___
> 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-DC vs MX80-5G-DC-B

[magno]

Quote:
That is not true. The ports are configurable and usable. But you need a
license to be allowed to use them. The license is just paperwork and you
dont need to activate it somewhere. However this policy will change in
the future, all MX5/10/40 bundles and line cards are EEPROM coded and a
later JunOS will activate these limitations (ask your channel partner
about this...).

Magno: True for today Junos, but as Juniper has the rights to lock these
ports it is not safe to use them for production. Of course, today all the
licenses (but the Subscriber management) are honor based but this will
change in the future for sure, so my advice is not to rely too much on this
approach because as soon as you upgrade the box to a future release you may
lose these ports. The license enforcer software is already in Junos, just
not used today.

Quote: 'No, we have multiple MX5/MX10 boxes and none of them have any visual
difference to a "real" MX80. If they changed this in the last 2 months,
then this must be new."

Magno: Yes, correct just because you have vanilla MX80s which were sold
just using a commercial bundle (basically the ones sold using the part
number MX80-5*/MX80-10*/MX80-40*) . MX5/10/40 chassis will ship starting
with JUNOS 11.4R1, so end of 2011/beginning of 2012. Of course, as I stated
before, there are no practical differences between the current chassis and
the new ones.

Quote: "MPCx and MPCxE difference also should be same, better oscillator for
PPT. (and supposedly 256M->512M FIB, i.e. 2M -> 4M routes or so)."

Magno: This is not 100% correct. It's correct about the oscillator, but not
about the memory. The only actual benefit coming from the memory upgrade
(256 mbytes to 512 mbytes) is about mobile users for the MobileNext
platform. Prefixes/nexthops are stored elsewhere; nevertheless the current
2.4M FIB IPv4 prefixes supported today will be increased by new features
such as FIB localization, to name just one.

Hope this helps.

Magno.

On Sat, Nov 19, 2011 at 5:52 PM, Jonas Frey (Probe Networks) <
j...@probe-networks.de> wrote:

> Hello,
>
>
> > Hi all,
> >
> >these codes are basically the same, both are MX80 based devices with a
> > MIC 1x20GE (all mics are commercially called 3D, no difference here)
> > already installed in one of the two available slots. On MX5 (and in the
> > commercial bundle MX80-5) the 20x1G MIC is the only card available to
> > connect the MX to the network, as the on board 10GE ports are software
> > restricted and not configurable.
>
> That is not true. The ports are configurable and usable. But you need a
> license to be allowed to use them. The license is just paperwork and you
> dont need to activate it somewhere. However this policy will change in
> the future, all MX5/10/40 bundles and line cards are EEPROM coded and a
> later JunOS will activate these limitations (ask your channel partner
> about this...).
>
> >
> > So, the two differences are:
> >
> > 1) the MX5 is a chassis which is phisically grey and you can read MX5 on
> > the front panel, whereas MX80-5-DC-B is a commercial bundle based on a
> MX80
> > chassis; the commercial bundle was needed to have a faster go to market
> > time schedule, that's it; of course, MX5 chassis (and MX10 & MX40) are
> > exactly an MX80, just the color and the label on the front panel change;
> > 2) the "T" versions (all the T versions, MX5, 10,40 and also MX80-T)
> > supports Sync-E according with G.8261 / G.8262 standards;
>
> No, we have multiple MX5/MX10 boxes and none of them have any visual
> difference to a "real" MX80. If they changed this in the last 2 months,
> then this must be new.
>
> >
> > 1) is just commercial, whereas 2) is a technical difference.
> >
> > Both models are field upgradable to MX10, MX40 and MX80 using the same
> > licensing scheme. If you need MX5 now, my advice is to go with the bundle
> > as the real MX5 will ship end of this year (11.2R4/11.4R1 time frame).
> > Hope this helps!
> >
> > Magno.
> >
> > On Fri, Nov 18, 2011 at 10:12 PM, Paul Stewart 
> wrote:
> >
> > > There are bundles and then there are "base units".  The bundles
> typically
> > > include the MIC-3D-20GE-SFP - there were no MIC's that I'm aware of
> that
> > > weren't 3D ... definitely not on the MX80 platform.  Yes, MX5 is
> > > modular
> > > it's physically the same as an MX80 box, just with software based
> > > restrictions in place (which unless it's changed are honor system based
> > > still) as noted by "4x10G fixed ports and 1x front empty MIC slot
> > > restricted" .. restricted = not u

Re: [j-nsp] MX5-T-DC vs MX80-5G-DC-B

[magno]

Hi all,

   these codes are basically the same, both are MX80 based devices with a
MIC 1x20GE (all mics are commercially called 3D, no difference here)
already installed in one of the two available slots. On MX5 (and in the
commercial bundle MX80-5) the 20x1G MIC is the only card available to
connect the MX to the network, as the on board 10GE ports are software
restricted and not configurable.

So, the two differences are:

1) the MX5 is a chassis which is phisically grey and you can read MX5 on
the front panel, whereas MX80-5-DC-B is a commercial bundle based on a MX80
chassis; the commercial bundle was needed to have a faster go to market
time schedule, that's it; of course, MX5 chassis (and MX10 & MX40) are
exactly an MX80, just the color and the label on the front panel change;
2) the "T" versions (all the T versions, MX5, 10,40 and also MX80-T)
supports Sync-E according with G.8261 / G.8262 standards;

1) is just commercial, whereas 2) is a technical difference.

Both models are field upgradable to MX10, MX40 and MX80 using the same
licensing scheme. If you need MX5 now, my advice is to go with the bundle
as the real MX5 will ship end of this year (11.2R4/11.4R1 time frame).

Hope this helps!

Magno.

On Fri, Nov 18, 2011 at 10:12 PM, Paul Stewart  wrote:

> There are bundles and then there are "base units".  The bundles typically
> include the MIC-3D-20GE-SFP - there were no MIC's that I'm aware of that
> weren't 3D ... definitely not on the MX80 platform.  Yes, MX5 is
> modular
> it's physically the same as an MX80 box, just with software based
> restrictions in place (which unless it's changed are honor system based
> still) as noted by "4x10G fixed ports and 1x front empty MIC slot
> restricted" .. restricted = not usable without software upgrade.
>
> Paul
>
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Kevin Wormington
> Sent: Friday, November 18, 2011 3:22 PM
> To: sth...@nethelp.no
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MX5-T-DC vs MX80-5G-DC-B
>
> I agree the specs look to be the same, the only difference I can see is the
> MX5 says it includes a MIC-3D-20GE-SFP and the MX80 a 20x1G MIC.
> Did they make a MIC that wasn't 3D?
>
> I'm pretty sure the MX5 is modular as well since it has the open MIC slot
> that you can get an upgrade license to be able to use.
>
> On 11/18/2011 01:37 PM, sth...@nethelp.no wrote:
> >> The T version is copper only. The DC version is modular.
> >
> > Certain about this? In my price list (from August), these bundles are
> > listed with exactly the same price.
> >
> > MX80-5G-DC-B:
> > MX80 Promotional 5G Bundle, Includes MX80 Modular DC, spare DC Power
> > supply, 20x1G MIC including L3-ADV license, Queuing, Inline Jflow,
> > Junos WW. (4x10G fixed ports and 1x front empty MIC slot restricted)
> >
> >
> > MX5-T-DC:
> > MX5 DC chassis with timing support - includes dual power supplies,
> > MIC-3D-20GE-SFP, Junos, S-MX80-ADV-R, S-MX80-Q&  S-ACCT-JFLOW-IN-5G
> > licenses. Power-supply cable to be ordered separately
> >
> > Sure looks to me like the specifications are the same too.
> >
> > Steinar Haug, Nethelp consulting, sth...@nethelp.no
> >
> >
> >> On Nov 18, 2011, at 11:06 AM, Kevin Wormington wrote:
> >>
> >> I'm looking at the above two MX bundles and other than timing support on
> the MX5 they seem to have the same specs.  Is there something that I'm
> missing?  Does anyone on the list know why one might want the MX80-5G-DC-B
> vs the MX5-T-DC?
> >>
> >> Thanks
> >>
> >> Kevin
> >> ___
> >> 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VPLS Hardware Not present

[magno]

Hi Keegan,

  Keep in mind that you can only configure the tunnel bandwidth according
with the actual port speed on the DPC. If you have a 10ge dpc you must use a
10g tunnel bandwidth config  (and as Harry mentioned you lose a port) and in
case you have a 1g DPC you must use a 1g tunnel bandwith config and you
won't lose anything.

After committing this config, look for a 'vt' interface... moreover check
you are using the correct encapsulation for VPLS (either ethernet-vpls or
vlan-vpls).

Have you just tried with no-tunnel-service just to see if the instance comes
up? This test would confirm encapsulation on the access facing interface.

Cheers

Magno
Il giorno 30/set/2011 23:07, "Harry Reynolds"  ha
scritto:
> So the fpc restart fixed the issue?
>
> AFAIK, the 1g tunnel is free, 10g burns a port.
>
> Regards
>
>
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:
juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley
> Sent: Friday, September 30, 2011 1:56 PM
> To: juniper-nsp
> Subject: Re: [j-nsp] VPLS Hardware Not present
>
> We are using the following to dedicate fpc bandwidth instead of disabling
> tunnel services. I've been told it's faster but disables a gig interface
to
> cannibalize the asics. It however requires a fpc restart. I suppose a RTM
> is in order. Thanks all for the input.
>
>
> set chassis fpc 0 pic 0 tunnel-services bandwidth 1g
>
>
> 2011/9/30 Keegan Holley 
>
>> Ok, I'm stumped. Configuring vpls and everything seems to be working but
>> the local router interfaces. They come up as NP or hardware not present.
>> The DPC and pic are up and working fine and I've tried it with "tunnel
>> bandwidth 1g" configured under the chassis stanza as well as no tunnel
>> services under vpls protocols. I have a pretty good grasp of vpls
>> configuration, but I'm sensing a juniper nuance that I don't remember.
Does
>> this ring any bells for anyone?
>>
>> Thanks,
>>
>> Keegan
>>
>> root@mx480> show vpls connections
>> Layer-2 VPN connections:
>>
>> Legend for connection status (St)
>> EI -- encapsulation invalid NC -- interface encapsulation not
>> CCC/TCC/VPLS
>> EM -- encapsulation mismatch WE -- interface and instance encaps not
>> same
>> VC-Dn -- Virtual circuit down NP -- interface hardware not present
>> CM -- control-word mismatch -> -- only outbound connection is up
>> CN -- circuit not provisioned <- -- only inbound connection is up
>> OR -- out of range Up -- operational
>> OL -- no outgoing label Dn -- down
>> LD -- local site signaled down CF -- call admission control failure
>> RD -- remote site signaled down SC -- local and remote site ID collision
>> LN -- local site not designated LM -- local site ID not minimum
designated
>> RN -- remote site not designated RM -- remote site ID not minimum
>> designated
>> XX -- unknown connection status IL -- no incoming label
>> MM -- MTU mismatch
>>
>> Legend for interface status
>> Up -- operational
>> Dn -- down
>>
>> Instance: vplsA
>> Local site: mx480-vplsA (6)
>> connection-site Type St Time last up # Up trans
>> 5 rmt NP
>> 9 rmt NP
>> 10 rmt NP
>>
>> {master}
>> root@mx480>
>>
>>
> ___
> 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] 10.0 or 10.4?

[magno]

Hi Nathan and all,

  I can confirm, 10.4 is the first JUNOS release developed with a new
methodology.

  This would allow Juniper to catch much more bugs before releasing the code
than in the past.

  Hope this helps

  Magno.

On Tue, Mar 15, 2011 at 11:03 PM, Nathan Sipes wrote:

> Funny My SE assures me that they have made significant changes to the way
> that the JUNOS code is being developed. Which will result in me finally
> after four years getting a stable code image. 10.4 is supposed to fix all
> my
> issues with the R3 release.
>
> Any one taking odds on this?
>
>
>
> On Tue, Mar 15, 2011 at 12:34 PM, Chris Morrow  >wrote:
>
> >
> >
> > On 03/15/11 13:57, Steve Feldman wrote:
> > > On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote:
> > >
> > >> ...
> > >> We recently spent a fair bit of time trying to decide between 10.3R3
> and
> > >> 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the
> > >> conclusion that 10.4R2 was significantly buggier.
> > >
> > > What sorts of bugs did you see in 10.4R2?
> > >
> > > JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in
> > > 10.1R4) where some of our firewall filter rules were being silently
> > > ignored.
> >
> > ex + firewall ... 'silently ignored' is the norm no? ;(
> >
> > here's a fav of mine. Loopback filters drop traceroute THROUGH the
> > device (unless you permit all traceroute of course) because, you know..
> > separating the 'control plane' traffic from the 'data plane' traffic is
> > something we all figured out 10 years ago. :(
> >
> > (to be fair, this 'bug' is fixed in 11.X... 'please load this daily code
> > image on your production network, kthxbi!')
> >
> > -grumpy-in-north-america
> > ___
> > 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] DS-lite support on Junos

[magno]

Hi all,

 Have you tried on 10.4 beta doc?

Cheers

Magno


On 27/10/2010, Daniel Roesen  wrote:
> On Tue, Oct 26, 2010 at 10:00:07PM +0200, Daniel Roesen wrote:
>> On Tue, Oct 26, 2010 at 01:15:57PM -0500, Jay Hanke wrote:
>> > Has anyone tried using Junos to implement the LSN for a DS-lite
>> > deployment? I've seen slided indicating it is supported (or coming).
>>
>> It's mentioned in 10.2 release notes, but I'm unable to find
>> documentation, or something in the CLI. I've yet to get an answer about
>> that from Juniper.
>
> Meanwhile, JNPR has removed DS-Lite support statement from the 10.2
> release notes completely. It's configurable, but hidden and unsupported.
>
> Looks like someone jumped the gun in the 10.2 release notes...
> "forward looking statement". :-)
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0
> ___
> 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 ADV-R License

[magno]

Hi all,  no need to install anything,  risate the adv license on MX80 is
just honored and not enforced.

HTH

Magno
> Hi,
>
> We have two of these boxes with the Advanced L3 Licenses, there is no need
to install the license apparently, nor is there a way to generate the key on
the juniper site. The boxes work fine holding 2 full tables with vrf's
without us installing the licenses, so I suspect that it is either installed
when the box is shipped, or it is currently an honesty based license.
>
> Cheers,
>
> Callum Barr
> Network Engineer
> WorldxChange Communications
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:
juniper-nsp-boun...@puck.nether.net] On Behalf Of Giuliano Cardozo Medalha
> Sent: Thursday, September 23, 2010 12:55 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] MX80 ADV-R License
>
> People,
>
> Does anyone know how to install the following license into the box:
>
> 1 x S-MX80-ADV-R License to support full scale L3 route and L3 VPN on
> MX80
>
> We have received a paper describing the license and a pen drive.
>
> Does anyone bought a MX80-48T and have the license to install ?
>
> How can we check if the license is correctly installed ?
>
> Thanks a lot,
>
> Giuliano
> ___
> 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] Juniper MX80 IRB

[magno]

Hi Chuck,

  I agree with you about the way Juniper handled this, it was simply
painful. My advice is to check with your SE which features are actually
supported or not. By the way, in the JunOS 10.1 Release notes (10.1 is the
first release supporting new TRIO MPCs) you can read "*Layer 2 VPLS, IRB,
and mesh group feature parity (MX Series routers with Trio MPC/MIC
interfaces)*—Support for Layer 2 feature parity with JUNOS Release  9.1 on
MX Series routers that include Trio Modular Port Concentrators (MPCs) and
Modular Interface Cards (MICs).". I agree this is not the best way to
advertise what is supported and what is not... Moreover this statement
should be included in all the release notes, and while all the features are
ported release after release, the release note should clearly advertising
what has been ported from old DPCs to new MPCs.

 Of course JUNOS should warn you it's not supported, I fully agree with you,
and, overall in my opinion, the unsupported commands should be hidden in the
CLI.

 About why we have to jump 2 years back in time, you must consider that the
new MPCs have a completely new PFE, and this PFE is way way better than the
old but it's also very different, so Juniper has to rewrite a lot of
forwarding plane ucode to port all the features MX has been accumulating
since 2006 to the new TRIO chipset. I was told there is an internal feature
parity catch up program which spans throughout JUNOS releases from 10.1 to
11.4 (new numbering convention) and again you should check in with your SE
to have more details.

 I hope this could clarify a bit more the scenario, regards.

   Massimo.

On Tue, Jul 27, 2010 at 4:31 PM, Chuck Anderson  wrote:

> On Tue, Jul 27, 2010 at 03:46:41PM +0200, magno wrote:
> > Today Trio only supports the old style config. in the near future, the
> > new style config will be supported as well.
>
> I have several problems with the way Juniper handled this:
>
> 1. The configuration commits without any warnings or errors.  There is
> no indication that what you have configured is unsupported.  No logs,
> no alarms, no nothing.
>
> 2. I've seen MPCs crash/go into a reboot loop when configuring them
> the new VLAN Bundle way.  (For the OP: do your MPC's go into a reboot
> loop, alternately showing offline/online under show chassis fpc
> pic-status?)  They should gracefully fail to work when doing something
> unsupported and make loud noises when you do.
>
> 3. Documentation is severely lacking.  In the 10.2 Release Notes, no
> where does it say "today Trio only supports JUNOS 9.2 features"
> (except when talking about the MX80 specifically, and some other
> specific features--nothing about the other Trio cards or about
> bridging/VLAN Bundles specifically).  I've only heard that from
> statements made by my Juniper reps.  Even then, you have to really dig
> deep in the Network Interfaces guide and Layer 2 Configuration Guide
> to find references to "9.5+ required" on VLAN Bundles and other
> configuration statements and features.  The 10.x Release Notes really
> ought to say "In this release, Trio only supports JUNOS 9.2 features
> and configurations on the following cards and platforms" and then list
> out *exactly* which hardware and configuration statements this applies
> to.  The rest of the configuration guides ought to have warnings
> sprinkled throughout saying "Not supported on Trio!" with pointers to
> the old way that works on Trio.  These warnings should stay in the
> documentation and Release Notes until the limitations no longer apply.
>
> The current situation is a horrible landmine for customers wishing to
> migrate/upgrade from DPC to Trio, as well as brand new customers like
> myself who haven't read the 9.2 documentation and earlier Release
> Notes.  Why should I have to go back 7 releases worth of documentation
> to configure my brand new hardware that is only supported at all under
> 10.0/10.1 and only supported under 10.2 when mixed with DPC cards?
>
> Finally, JTAC/ATAC can't even figure out the above!!!  I have a case
> open and they *still* haven't come to the solution because they
> haven't realized that "Today Trio only supports the old style config"
> and what that really means.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX80 IRB

[magno]

Today Trio only supports the old style config. in the near future, the
new style config will be supported as well.

Cheers

Max


On 27/07/2010, Chuck Anderson  wrote:
> On Tue, Jul 27, 2010 at 10:40:54AM +0200, Tim Vollebregt wrote:
>> I'm getting errors when changing to this configuration. It is only
>> possible to use encapsulation vlan-bridge on unit 0. And when I
>> change it to unit 0:
>>
>> VLAN Encapsulation: Not allowed on untagged interfaces
>> 
>
> This following commits for me.  The point of the exercise is to see if
> MPC Trio cards *require* 9.2-style configurations: using separate
> logical units for each VLAN, encapsulation vlan-bridge, refer to all
> the logical unit interfaces in bridge-domain in order to actually
> function.  I.e. do they not work with 9.5+ style VLAN Bundles: family
> bridge, interface-mode access/trunk, vlan-id-list?  In my experience
> with testing some new MPC Trio cards, this conclusion is true.  A
> perfectly working VLAN Bundle bridging configuration on DPC cards
> failed miserably when copied over to MPC cards until it was
> reconfigured the 9.2 non-VLAN Bundled way.
>
> ge-2/0/1 {
> flexible-vlan-tagging;
> native-vlan-id 200;
> encapsulation flexible-ethernet-services;
> unit 200 {
> encapsulation vlan-bridge;
> vlan-id 200;
> }
> }
> irb {
> unit 200 {
> family inet {
> address 10.11.12.13/24;
> }
> }
> }
> VLAN200 {
> domain-type bridge;
> vlan-id 200;
> interface ge-2/0/1.200;
> routing-interface irb.200;
> }
>
>> This issue seems to be really strange as we have it working the 10.x
>> way on another router. When I configure Ge-1/0/0 as a routed
>> interface it works fine.
>
> Does the other router where this works have the new MPC Trio cards?
> Or is it using the older DPC cards?
> ___
> 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] Local Proxy Arp

[magno]

Have a look at the 'unrestricetd' proxy arp feature. It might work...

HTH

Max


On 10/07/2010, Jay Hanke  wrote:
> Does Juniper have support for Local Proxy ARP on any platforms? By local I'm
> meaning within an interface not regular proxy arp that spans more than one
> interface.
>
>
>
> Thanks,
>
>
>
> Jay
>
>
>
>
>
> ___
> 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

[j-nsp] Loop Free Alternates for OSPF

[magno]

Hi List!

  I have read and tested LFA for OSPF in LAB and I really like it. I am
aware of the drawbacks on certain topologies (it doesn't work very well on
square topology for instance) but the feature looks cool!

  so  I am looking for any real world implementation because I am very
tempted to deploy it on one of my customer network.

  Is there anyone who could share experiences ?

  Thanks a lot!

  Massimo.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 L2TP Functions

[magno]

Q3 2010 on JCS, Q4 2010 on MX (not MX80), M (high-end) and T Series
with the new REs (dual core 8gb ram and 16gb ram mx,m and t series,
quad core 16 Gb ram Mx only).

Cheers

Magno


On 13/06/2010, Richard A Steenbergen  wrote:
> On Sun, Jun 13, 2010 at 08:28:01AM +0300, Nahrux M wrote:
>> Greetings,
>>
>> Does JUNOS on Intel platform supports SMP (symmetrical multi processing)?
>
> Not the official public builds, yet. :)
>
> --
> Richard A Steenbergenhttp://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> ___
> 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] What is the XRE200?

[magno]

This is the external control plane device needed to run the virtual chassis
configuration on EX8200.

Max

On Wed, May 26, 2010 at 6:00 PM, Mark Tinka wrote:

> On Wednesday 26 May 2010 11:38:09 pm matthew zeier wrote:
>
> > I noticed this
> > http://www.juniper.net/us/en/products-services/switching/
> > ex-series/options/xre200/
> >
> > on Juniper's site.  Looks new but I'm having a hard time
> >  understanding what it does.  It mentions "EX8200-based
> >  Virtual Chassis configurations" - does that mean I can
> >  finally get VC on the 8200 platform?
> >
> > As usual Juniper's website is short on details.
>
> Too far from home to ask for details, but from the basic
> literature online, it looks like the JCS1200 equivalent for
> the EX8200 switch.
>
> Cheers,
>
> Mark.
>
> ___
> 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

[j-nsp] R: Re: MX 80

[magno]

Correct, 32 k without the R licenze.

Max

Il giorno 12 mag, 2010 5:49 p., "Jay Hanke"  ha
scritto:

With the license it is 1 M in the FIB and 4 M in the RIB.

I believe without the license it is 32k total, but I don't have a
conformation on that.

-Original Message- From: juniper-nsp-boun...@puck.nether.net[mailto:
juniper-nsp-boun...@pu...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 802.3ad Question

[magno]

Juniper's hash algorithm is not affected by the number of links, so there is
no problem in having 3 links bundled together.

Moreover, starting with JunOS 9.6, on MX platform, also symmetrical load
balancing is available.

Max.

On Thu, Jan 14, 2010 at 7:33 AM, Bit Gossip  wrote:

> I had 2x T320 configured each with a bundle of 3x 10GE and traffic was
> split correctly 33% 33% 33%
>
> These has been in place for several years and across several Junos
> releases.
>
> On Thu, 2010-01-14 at 02:57 -0300, alexi wrote:
> > Hello Stefan:
> >
> > Thanks for your answer, this was a costumer question that i think camed
> from
> > the way how load balancing in Cisco using Ether Channel was done , in
> that
> > case you had a fixed number of 8 values so the hashing algorithm (using
> the
> > source ip , mac ... etc) gives you one of those fixed values. So each one
> of
> > the links in a bundle was identified with one or several of those values
> ...
> > so in this case you can only have perfect load balance if you are using
> 2, 4
> > or 8 links ... any other combination gives you a not even distribution
> ...
> >
> > this is explained here :
> >
> http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml
> >
> > I don´t know how this goes in 802.3ad  in Juniper ...what do you think ?
> ,
> >
> > have you ever seen examples of good load balancing using 3 , 5 or 6 links
> in
> > a bundle ?
> >
> > BR
> > Alexi
> >
> >
> > On Thu, Jan 14, 2010 at 2:04 AM, Stefan Fouant <
> > sfou...@shortestpathfirst.net> wrote:
> >
> > > > -Original Message-
> > > > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
> > > > boun...@puck.nether.net] On Behalf Of alexi
> > > > Sent: Wednesday, January 13, 2010 11:45 PM
> > > > To: mti...@globaltransit.net
> > > > Cc: juniper-nsp@puck.nether.net
> > > > Subject: Re: [j-nsp] 802.3ad Question
> > > >
> > > > Hello Mark:
> > > >
> > > > I am coming back to this question , i would apreciate your help again
> > > > ...
> > > >
> > > > in the example you mention you said that your bundle is using 3xGE
> and
> > > > you
> > > > have a pretty fair load balance 1:1:1
> > > > do you know if there is any requirement about having pair numbers or
> > > > power
> > > > of 2 amount of links in a bundle to get a good load balance ?
> > > >
> > > > I guess that should depend on the hashing algorithm but of course
> there
> > > > is
> > > > no much info about how it works  we are interested to have 6xGE
> in
> > > > a
> > > > bundle ... so , will we get 6Gbps of real throuhput  ...?
> > >
> > > The hashing algorithm Juniper uses is proprietary so there isn't much
> > > useable information out that, but in my experience I've never seen
> anything
> > > along the lines which would require a LAG to be comprised of multiples
> of 2
> > > links to get an even load balance.  The load balancing tends to get a
> more
> > > even distribution when you've got a large number of flows.  Assuming a
> > > large
> > > number of flows, you should be able to get an even balance across the
> > > component links within the 802.3ad LAG bundle.  You might also want to
> > > consider enabling Layer 4 hashing to get even more granular
> distribution,
> > > if
> > > the source and destinations are sparse, but you're using a large number
> of
> > > source and destination ports.
> > >
> > > HTHs.
> > >
> > > Stefan Fouant, CISSP, JNCIE-M/T
> > > www.shortestpathfirst.net
> > > GPG Key ID: 0xB5E3803D
> > >
> > >
> > ___
> > 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] juniper trinity

[magno]

I agree, and I am pretty sure the new chipset will encompass and
largely extend all the qos functionalities provided today by ez-chip
chip.

Cheers.

Max


On 24/10/2009, Richard A Steenbergen  wrote:
> On Sat, Oct 24, 2009 at 06:38:53PM +0200, magno wrote:
>> I repeat, Trinity has nothing to do with ez-chip. My advice is to stop
>> elucubrating around any ez-chip whatever.
>>
>> Ez-chip proved to be quite limited for some qos functions, so I really
>> don't think juniper wants to be qos feature limited by a third-party
>> chip anymore.
>
> I believe the original question was "do the new asics integrate the
> functionality of ezchip, thus eliminating the need for it", and from
> what I've heard I believe the answer is yes. That is why we're talking
> about the ezchip in the first place.
>
> --
> Richard A Steenbergenhttp://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] juniper trinity

[magno]

I repeat, Trinity has nothing to do with ez-chip. My advice is to stop
elucubrating around any ez-chip whatever.

Ez-chip proved to be quite limited for some qos functions, so I really
don't think juniper wants to be qos feature limited by a third-party
chip anymore.

My 2 cents.

 Max


On 24/10/2009, Richard A Steenbergen  wrote:
> On Sat, Oct 24, 2009 at 11:56:18AM +0200, Roger Gabarit wrote:
>> >
>> I'm sorry not to agree on this one. Unless you can prove me that I'm wrong
>> :)
>> - Juniper uses the chips on the MX series only in -Q- Line Cards. So when
>> you use something only in advanced QoS line cards, there's something
>> related
>> to QoS, definitely.
>>
>> - Check the description of EZChip NPs on their website (
>> http://www.ezchip.com), they are built to provide the Ethernet framing and
>> MAC lookup AND traffic management). Neither Cisco nor Juniper would buy a
>> chip to have it do only 20% of what it could do. Cisco uses the chip in
>> the
>> ES+/ES40 and in ASR 9k cards.
>
> Juniper uses EZChips on all MX series line cards, not just -Q. In fact,
> the distinction between the original MX DPCs and the -E models is the
> rev of EZChip, with the -E's having support for larger microcode (1.5KB
> vs 6KB). On regular switching/routing cards the EZChip is used only for
> framing and MAC lookup, all of the IP routing and QoS is handled by the
> I-Chip. I think you're actually right about the -Q cards, there is some
> EZChip QoS functionality used there to implement the per-VLAN features,
> but I (and one would assume most sane people with a budget :P) don't
> touch the -Q cards. :)
>
>> All that stuff makes me think that the 2 vendors will not release any 100G
>> ports (*with advanced QoS*) on MX or ASR until the EZChip NP4 is produced
>> (not only prototypes). That gives by the way > 2 years advance to
>> Alcatel-Lucent from that point of view, because their 100G NP has been
>> ready
>> since last year. Funny market :)
>>
>> But well, let's wait for Juniper's next week announcement.
>
> I don't think the Trinity announcement has anything to do with 100G, but
> I could be wrong.
>
> --
> Richard A Steenbergenhttp://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> ___
> 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] juniper trinity

[magno]

Guys, forbes or not forbes, maybe this time could be even better...

Stay tuned...

M.

On 23/10/2009, Richard A Steenbergen  wrote:
> On Fri, Oct 23, 2009 at 08:53:17AM -0700, Marlon Duksa wrote:
>> Keep in mind that this is from the Forbes magazine - these guys have no
>> clue
>> what a router is.
>> But the point is that something is coming out next week, and it gives me
>> kind of clue what...
>>
>> I gather they will have 40G (full duplex chipset), have three of them on a
>> line card which will give them 120G of throughput???  Of course this will
>> go
>> on MX...With no fabric redundancy. Only 10GE ports, no 100GE?? Will find
>> out
>> soon...
>
> Remember the articles that came out before the MX's release, about how
> Juniper had outsourced the entire thing and it was an EZChip based
> platform? Makes you wonder exactly how full of shit they are on every
> other article that isn't about something you actually know well, doesn't
> it? :)
>
> --
> Richard A Steenbergenhttp://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> ___
> 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] OSPF NBMA

[magno]

I couldn't understand if this issue is resolved... If not, try to
configure ospf using 'set protocol ospf area 0.0.0.0 interface
a.b.c.d' (basically using ip address configured on the interface
instead of interface name)... I faced a similar issue and that
configuration fixed the problem.

  Hope this helps.

  Massimo


On 28/03/2009, Harry Reynolds  wrote:
> Sorry I missed that. I believe its needed.
>
>
>
> -Original Message-
> From: Aamir Saleem [mailto:aamirw...@gmail.com]
> Sent: Friday, March 27, 2009 9:11 PM
> To: Harry Reynolds
> Cc: Sean Clarke; Juniper Puck
> Subject: Re: [j-nsp] OSPF NBMA
>
> Dear Harry,
>
> Thanks for your response. As already mentioned in my emal that NBMA mdoe
> is working perfectly with multipoint interface configuration. without
> multipoint will this not work?
>
> Regards.
> Aamir
>
>
> ___
> 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] not defining no-cspf

[magno]

Hello Amid.

1) CSPF is a modified flavour of the normal spf algorithm which is the core
of the ospf & isis protocol. If you set up an lsp with RSVP, and you are
using TE extension with isis (on by default) and OSPF (you must turn on the
use of opaque LSA type 10 (area scope) with the knob "traffic-engineering",
these IGPs will populate the "TED" (Traffic Engineering Database) and when
the RSVP will use the IGP to setup your LSP (without ERO for instance), the
RSVP will take a look at the TED and a modified SPF will run.
All the links which won't satisfied some requirements will be taken out of
the calculation. At the end of the calculation, the CSPF process will give
to RSVP an ERO list (not setup manually by you, but calculated by CSPF
itself) and this ERO list will be used to setup the LSP. If you want to use
link administrative groups (link coloring) or FastReroute you will have to
use the CSPF.
Specifically, the CSPF Algorithm states that:
 1) Prune links with insufficient bandwidth;
 2) Prune links that don't include the administrative-groups
 3) Prune links that contain excluded administrative-groups
 4) Calculate shortest path from ingress to egress consistent with manually
configured ERO
 5) If equal cost paths exist, choose the one whose last hop is the LSP end
point
 6) Select among equal-cost paths (least hop then fill related criteria
(most fill, least fill)
 7) Pass EROs to RSVP

2) OSPF traffic-engineering is the knob you need to enable
traffic-engineering using OSPF (with ISIS it's up by default).So, you'll
find in the ospf database a new 'section' populated by LSA type 10, and
these LSAs will contain link information such as bandwidth constranint, link
administrative group, TE metrics, (for each setup priority 0-7). These
information will be used to populate the TED.

Hope this helps

Massimo

On 5/20/07, Amos Rosenboim <[EMAIL PROTECTED]> wrote:
>
> Hello Hamid,
>
> As far as I  know if you configure no-cspf then the router will not
> run cspf to set up the LSP. This means that no administrative factors
> will be taken into account and the LSP will follow the IGP path.
> I used it (thanks to a tip from this list) to establish rsvp lsp
> across ospf areas.
>
> I'm not a big expert on this, so you might want to hear a second
> opinion.
>
> As for ospf traffic engineering, it is meant to enable ospf to carry
> the additional  information required for TE (mainly link bandwidth).
>
> Regards
>
> Amos
>
> On May 19, 2007, at 6:38 PM, Hamid Ahmed wrote:
>
> > Hi all,
> >   Can anyone explain me the following  please :
> >
> >   1) what are consequences of if i donot define no-cspf command
> > while i configure a explicit LSP configuration with ERO consttraints ?
> >   2) what is the purpose of ospf traffic engineering ?
> >
> >   Best regards,
> >   HA
> >
> >
> > -
> > You snooze, you lose. Get messages ASAP with AutoCheck
> >  in the all-new Yahoo! Mail Beta.
> > ___
> > 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] Estabilishing TE's tunnels between juniper and CISCO

[magno]

Hi Marcio.

If you want to hide your topology behind MPLS, you should use the
"no-propagate-ttl" you should enable this knob under the protocol mpls
hierarchy and on Cisco box you should enter the command "Cisco(Config)# no
mpls ip propagate-ttl forwarded"...

As this technology is not signaled by any object in RSVP (so it's
interoperable), you should configure it on all your router. You can't enable
it on a per LSP base as well.

Hope this helps.

Massimo.

On 5/3/07, Marcio Pereira <[EMAIL PROTECTED]> wrote:
>
>   Hi guys,
>
> I am trying estabilish TE tunnels between juniper ( M20 ) and cisco (
> 76xx), but TE goes up just when i disable "no-decrement-ttl" knob ( That´s
> not good ...). Otherwise the tunnel keeps down showing the message :"Unknown
> Object type:label_request with no-decrement-tt"
> Have someone experienced this issue ? Any ideas how can i fix ?
> I am using junos 7.1 and IOS 12.2(18)SXF7
>
> Mp.
>
>  [EMAIL PROTECTED] show protocols mpls
> label-switched-path teste
> to 201.X.X.X;
> no-decrement-ttl;
>
>
> [EMAIL PROTECTED] run show mpls lsp ingress name teste extensive
> Ingress LSP: 17 sessions
>
> 201.X.X.X
>   From: 200.X.X.X, State: Dn, ActiveRoute: 0, LSPname: teste
>   ActivePath: (none)
>   LoadBalance: Random
>   Encoding type: Packet, Switching type: Packet, GPID: IPv4
>   PrimaryState: Dn, No-decrement-ttl
> SmartOptimizeTimer: 180
> Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 10)
> 201.X.X.X S
> 3 May  3 09:25:17 201.47.0.6: Unknown Object type:label_request with
> no-decrement-ttl[3 times]
> 2 May  3 09:25:08 Originate Call
> 1 May  3 09:25:08 CSPF: computation result accepted
>   Created: Thu May  3 09:25:06 2007
> Total 1 displayed, Up 0, Down 1
>
> Mp.
> ___
> 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