Re: [j-nsp] Thanks for all the fish

[Forrest Christian (List Account) via juniper-nsp]

On Tue, Jan 9, 2024, 4:22 AM Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> There is no shortage of cheap ports. The issue is how useful those ports
> are beyond just "speed".
>

I find it frustrating that things one would expect to be included in any
layer 3 switch has become additional revenue opportunities.

"The switch hardware is $x.  Oh you want the software too?  Oh,  that's an
additional cost.   L3 switching?  Oh,  that's an extra feature.  OSPF? Oh
that's not included with the L3 license so that will be extra too. Oh and
by the way,  you aren't buying a perpetual license anymore so be sure to
pay us the fees for all the software functionality every year".

Yes I know the above isn't completely 100% accurate but it definitely is
how it seems anymore.

I get charging extra for advanced features,  but when basic features that
pretty much everyone wants and uses becomes an add-on and not perpetual,
it tends to make me start looking for a different vendor.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5110 / EVPN-VXLAN with IPv6 underlay

[Christian Scholz via juniper-nsp]

Also might be worth mentioning that the Router-ID - although it might look like 
one and you would usually use one you already have on your loopback - is 
technically not an IP(v4)-Address. 


See: 
https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/ref/statement/router-id-edit-routing-options.html

Even if you run only OSPF3 or IPv6 BGP peering in a routing instance, a 32-bit 
router-id must be configured in the instance. This is because IPv6 routing 
protocols use the router-id for handshaking. The router ID must be configured 
as a 4 octet (32 bit) unsigned non-zero integer value. 
It's often convenient to use an IPv4 address as the router ID. However, a valid 
IPv4 address is not required. The RID does not have to be a routable IPv4 
address. You can configure any 32-bit value that is unique within the routing 
domain. If you do not configure the router-id in an IPv6 OSPF or BGP routing 
instance the IPv6 protocols will use an invalid value for the router ID 
(0.0.0.0) and the adjacency and connections will fail

CHS



> Am 28.11.2023 um 16:14 schrieb Roger Wiklund via juniper-nsp 
> :
> 
> For the QFX5110 specifically, MAC-VRF is supported:
> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=9788=MAC+VRF+with+EVPN-VXLAN
> 
> But IPv6 underlay is not:
> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=11165=EVPN-VXLAN+fabric+with+an+IPv6+underlay
> 
> So maybe it's an ASIC limitation as QFX5110 is using Trident 2+ and
> QFX5120/EX4400 is using Trident 3.
> 
> Regards
> Roger
> 
> 
> 
>> On Tue, Nov 28, 2023 at 3:48 PM Roger Wiklund 
>> wrote:
>> 
>> Hey
>> 
>> You're interpreting the default switch limitation incorrectly.
>> 
>> It doesn't mean the QFX5120 can't support MAC-VRFs, it means even if you
>> implement MAC-VRFs you still only have a single switch domain and can't
>> have overlapping VLANs in the different MAC-VRFs. (MX does not have this
>> limitation. It supports 32k VLANs)
>> 
>> IPv6 underlay is supported on QFX5120 in MAC-VRF from Junos 21.2R2:
>> Explore Features by Product | Juniper Networks Pathfinder Feature Explorer
>> 
>> 
>> You can configure an EVPN-VXLAN fabric with an IPv6 underlay. You can use
>> this feature only with MAC-VRF routing instances (all service types). You
>> must configure either an IPv4 or an IPv6 underlay across the EVPN instances
>> in the fabric; you can’t mix IPv4 and IPv6 underlays in the same fabric.
>> To enable this feature, include these steps when you configure the EVPN
>> underlay:
>> • Configure the underlay VXLAN tunnel endpoint (VTEP) source interface as
>> an IPv6 address:
>> • Even though the underlay uses the IPv6 address family, for BGP
>> handshaking to work in the underlay, you must configure the router ID in
>> the routing instance with an IPv4 address:
>> • Enable the Broadcom VXLAN flexible flow feature, release where the
>> feature is not enabled by default:
>> We support the following EVPN-VXLAN features with an IPv6 underlay:
>> • EVPN Type 1, Type 2, Type 3, Type 4, and Type 5 routes(excluding EX9200
>> for type 5).
>> • Shared VTEP tunnels (required with MAC-VRF instances).
>> • All-active multihoming, including Ethernet segment ID (ESI)
>> auto-generation and preferencebased DF (DF) election.
>> • EVPN core isolation.
>> • Bridged overlays.
>> • Layer 3 gateway functions in ERB and CRB overlays with IPv4 or IPv6
>> traffic.
>> • Underlay and overlay load balancing.
>> • Layer 3 protocols over IRB interfaces—BFD, BGP, OSPF.
>> • Data center interconnect (DCI)—over-the-top (OTT) full mesh only.
>> • EVPN proxy ARP and ARP suppression, and proxy NDP and NDP suppression.
>> 
>> Regards
>> Roger
>> 
>> On Mon, Nov 27, 2023 at 11:31 AM Denis Fondras via juniper-nsp <
>> juniper-nsp@puck.nether.net> wrote:
>> 
>>> Hello,
>>> 
>>> Thank you very much everyone for the help.
>>> 
>>> It seems that `netraven` nailed it.
>>> I missed the part where QFX5110 could not support multiple forwarding
>>> instances.
>>> 
>>> I will have to go back to the legacy protocol then :/
>>> Replacing IPv6 addresses with IPv4 addresses, keeping the same config,
>>> worked on
>>> first try.
>>> 
>>> Thank you again !
>>> Denis
>>> 
>>> 
>>> Le Mon, Nov 27, 2023 at 10:52:52AM +0100, netravnen+nspl...@gmail.com a
>>> écrit :
 Dennis,
 
 On Sat, 25 Nov 2023 at 15:26, Denis Fondras via juniper-nsp
  wrote:
> Can you give a clue ? I haven't found any information on wether it
>>> could work on
> QFX5110.
 
 Looking at the two pages below.
 1. The QFX5120 (assuming this also applies to the QFX5120-32C model)
 *only* supports the default-switch forwarding instance.
 2. And IPv6 underlays seem to be *exactly not* supported for the
 default-switch forwarding instance.
 
 If I take this from what it reads. It looks like you 

Re: [j-nsp] How to pick JUNOS Version

[Christian Scholz via juniper-nsp]

--- Begin Message ---
If you face issues, you have JTAC, ATAC, and Engineering - and also a local SE.
I would never wait and "hope" that a fix will be out there because it has been 
reported, "by someone else."
Observe, Pinpoint, Report and if needed Escalate - works very good with Juniper 
and they help you; unlike other vendors who "build bridges" and tell you to 
deploy your software while Saturn is in line with Mars and while offering a 
goat as a token of appreciation at the same time 
If there is a nasty issue that is not fixed in any release, Engineering 
provides "Special Customer Releases" to have a fix for your particular 
environment and issue to help you.
Therefore if you report the Bug, you might not have a fix tomorrow, but in the 
next 2-3 months.
And if it takes longer, there's an "escalate this case" button that works very 
well - I never had to wait longer than six weeks for a particular fix after it 
had been confirmed. Your local SE can also assist you if you have trouble.


Back to the topic:
If you start fresh, follow the "JTAC versions to consider" (as stated earlier, 
it's no longer called recommended for various reasons) and ask your local SE - 
that's the "official" way. 
In 9/10 Cases, this is an excellent version to start with if you have no idea 
where to start at all.
If you need a specific feature that's not yet in the "version to consider," or 
there's a bug in this version affecting you, your local SE can tell you what to 
do and what version to try.
This way, you get a working version or the correct pointers on what to do to 
get the right version.

Tom's approach is also an excellent idea - the important part is that you test 
everything for your environment yourself before deploying it to prod. Most of 
the time, "shit hits the fan" because folks don't check appropriately for 
themselves or have no testing environment at all because "it's expensive."
In my personal opinion, it's not the vendor's responsibility to test every 
customer topology in existence with every tiny feature.
It's your job at the end of the day to make sure that you deploy code that 
works. 
The vendor can assist you as best as possible, but it's simply not possible for 
them to test EVERY scenario out there.
Again: Observe, Pinpoint, Report.

Yes - there are often multiple bugs involved, and yes it can be a "Minesweeper 
Game" to find the one that has "everything" fixed (however, such thing does not 
exist per definition because humans are not perfect) - but it's not as 
complicated as with other vendors with 27.000 Releases and Sub-Releases out 
there that have to be "qualified" in order to get support 

Just my 2ct

-- Christian






-Ursprüngliche Nachricht-
Von: juniper-nsp  Im Auftrag von Alexandre 
Guimaraes
Gesendet: Donnerstag, 20. August 2020 15:34
An: Tom Beecher ; Colton Conor 
Cc: Juniper List 
Betreff: Re: [j-nsp] How to pick JUNOS Version

The best answer ever!

Go to Vegas, in a Cassino, play some roulette.  Wait for a number between 10 
and 20, if black, normal Junos, if red, SR Junos...  if you lose all money 
before get a code similar a release, follow Tom Beecher schemas.

IT'S A LOTTERY to pick a junos release. 

One of my case
I have deployed some QFX5120 32C and 48Y units a year ago, exactly Aug/2019, 
until today, those units are offline and waiting a code that’s fix 
RSVP/ISIS/MPLS signalization until there, wasted money, etc



Em 19/08/2020 13:32, "juniper-nsp em nome de Tom Beecher" 
 escreveu:

Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.

On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__colton.conor-40gmail.com=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=vCQMfrWksdsBnD7JU0aeeHZARhmdT9KC6Caf59B_xgc=>
wrote:

> How do you plan which JUNOS version to deploy on your network? Do you 
stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a 
different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.juniper.net_InfoCenter_index-3Fpage-3Dcontent-26id-3DKB21476-26actp-3DMETADATA=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=CQxemDO4grDS8J_BXAGPC3akSwvKhy2DBPt6JlKN3nI=
>
> Just wondering if JUNOS will ever go to a unified code model

Re: [j-nsp] Juniper support offline?

[Christian Scholz]

Looks like a Maintenance Window - a bit early here but this was planned.



Best Regards
 
Christian Scholz





-Ursprüngliche Nachricht-
Von: juniper-nsp  Im Auftrag von Nathan 
Ward
Gesendet: Donnerstag, 13. Februar 2020 22:42
An: Juniper NSP 
Betreff: Re: [j-nsp] Juniper support offline?

And again.. this time the whole my.juniper.net <http://my.juniper.net/> is 
down, not just the login system. Downloads are also not working, and 
www.juniper.net <http://www.juniper.net/> is really slow to load.. Weirdly, 
support.juniper.net <http://support.juniper.net/> seems to work.

This is not wildly confidence inspiring, eh?

Don’t get me wrong, this is one of those “I’m complaining because I like your 
gear and it pains me to see you mess up so bad” situations.

> On 26/01/2020, at 8:16 PM, Nathan Ward  wrote:
> 
> Hi,
> 
> Looks to me and colleagues of mine like Juniper support is offline.
> 
> Last night, I was able to log in but trying to download an image got to some 
> stage of the redirect process and hung, then a please try again later 
> message. It persisted for the next few hours of me trying every now and then.
> 
> Today, I can’t log in at all - Invalid user/password.
> Password reset process works, but, still doesn’t let me in. Different 
> browsers, cleared cache, all the usual “is it on at the wall sir” debugging.
> 
> Hearing the same story for others.
> 
> I’ve called both the NZ 00800 (international 800) and the US +1888 number. 
> The former says “call cannot be completed”. The US number says “high volume 
> of calls please leave a message”.
> 
> We’re in New Zealand - unsure if that’s relevant.
> 
> 
> Are others having these same issues?
> 
> Any insight in to what’s going on? 
> It’s a long weekend here, so the local sales/SE/etc. folks I usually deal 
> with are likely not anywhere near their phones.
> 
> --
> Nathan Ward
> 

___
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 support offline?

[Christian Scholz]

Everything works here again - without resetting.
Looks like it’s recovering



Von meinem iPhone gesendet

> Am 26.01.2020 um 17:08 schrieb Ross Halliday 
> :
> 
> Seems to be back albeit a bit rocky - I could not get in with my previous 
> password and had to reset. SRM and Downloads appear to be functioning
> 
> Ross
> 
> 
> -Original Message-
> From: juniper-nsp  On Behalf Of Thomas 
> Scott
> Sent: January 26, 2020 6:14 AM
> To: Nathan Ward 
> Cc: Juniper NSP 
> Subject: Re: [j-nsp] Juniper support offline?
> 
> Just got off the phone with JTAC and was informed the website was down for
> "maintenance". We managed to open a case last night, but were unable to
> this morning... I'm hoping that the "issue" doesn't last too long..
> 
> Phone number I called was 1-888-314-5822.
> 
> - Thomas Scott | mr.thomas.sc...@gmail.com  
> 
> 
 On Sun, Jan 26, 2020 at 5:28 AM Nathan Ward  wrote:
>> Hi,
>> The published number on the Juniper website - 0080025864737 doesn’t work,
>> and the +1888 US number went to Juniper, but to voicemail.
>> I’ve called the number Liam has posted here (same as above but with +
>> rather than 00), which worked - the agent had told me that there was
>> maintenance yesterday and now there is no way to get copies of images
>> apparently, even JTAC.
>> I was told that there is no ETA for login being restored. All they can do
>> is open a case so I get notified if and when it’s fixed. (Yeah, the agent
>> really said “if and when”).
>> Prsearch disappeared what, Jan 2019.. this year will it be case management
>> and download access we lose for almost a year?
>> On the off chance someone has them and is able to share, I need packages
>> for 18.2R3-S1 for MX204 (so, VMHost), and 18.4R2-S2 for QFX5120.
>> Those are the JTAC recommended versions, so I imagine they’ll be knocking
>> about on plenty of hard drives..
>> Luckily, checksums are still visible on the public site :-)
 On 26/01/2020, at 8:22 PM, Liam Farr  wrote:
>>> I just messaged some local at Juniper NZ and they advised that
>> +80025864737 is working for support.
>>> Seems to work from my 2D mobile here too.
>>> Cheers
>>> Liam
>>> On Sun, 26 Jan 2020 at 8:16 PM, Nathan Ward > > wrote:
>>> Hi,
>>> Looks to me and colleagues of mine like Juniper support is offline.
>>> Last night, I was able to log in but trying to download an image got to
>> some stage of the redirect process and hung, then a please try again later
>> message. It persisted for the next few hours of me trying every now and
>> then.
>>> Today, I can’t log in at all - Invalid user/password.
>>> Password reset process works, but, still doesn’t let me in. Different
>> browsers, cleared cache, all the usual “is it on at the wall sir” debugging.
>>> Hearing the same story for others.
>>> I’ve called both the NZ 00800 (international 800) and the US +1888
>> number. The former says “call cannot be completed”. The US number says
>> “high volume of calls please leave a message”.
>>> We’re in New Zealand - unsure if that’s relevant.
>>> Are others having these same issues?
>>> Any insight in to what’s going on?
>>> It’s a long weekend here, so the local sales/SE/etc. folks I usually
>> deal with are likely not anywhere near their phones.
>>> --
>>> Nathan Ward
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net > juniper-nsp@puck.nether.net>
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp <
>> https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>> --
>>> Kind Regards
>>> Liam Farr
>>> Maxum Data
>>> +64-9-950-5302
>> ___
>> 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] EX4300-AFO to AFI

[Christian Scholz]

Make sure to involve JTAC because if you have to RMA this and the Database has 
not been updated you might get the wrong switch back. 

BR
Christian



Von meinem iPhone gesendet

> Am 12.12.2019 um 17:48 schrieb Dovid Bender :
> 
> Just swapping them out seemed to do the trick for us.
> 
>>> On Thu, Dec 12, 2019 at 11:19 AM Colin  wrote:
>> Hi
>> Is it possible, or has anybody successfully tried, to convert an
>> EX4300-AFO to an AFI by just replacing the fan and power supply which
>> are both FRU items  (EX4300-FAN-AFI, JPSU-350-AC-AFI-A) or would changes
>> need to be made to the firmware?  Thanks.
>> Colin McIntyre
>> ___
>> 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] DNS Flag Day

[Christian Scholz]

What they told you sounds like bullshit to me. From 10.2 on there are no 
special settings required. Maybe they don’t know how to do it?

So I guess they are just very lazy or don’t know better and blame the 
firewall... I pray for you that they don’t run Code below 10.2...

https://kb.juniper.net/InfoCenter/index?page=content=KB23569=SRX_5600_1=LIST


CHS








Von meinem iPhone gesendet

Am 25.01.2019 um 12:53 schrieb sth...@nethelp.no:

>> When doing some investigation for the upcoming DNS Flag Day 
>> (https://dnsflagday.net: February 1st 2019) I got some bad news from one of 
>> the service providers: they use Juniper SRX firewalls, and claim that they 
>> can't properly support EDNS because of a bug in their SRX firewalls. This 
>> seems outrageous to me. Is this just because they haven't upgraded their 
>> JunOS for years, they're running ancient DNS server software, or is there 
>> really a problem?
> 
> See
> 
> https://mailman.nanog.org/pipermail/nanog/2019-January/099180.html
> 
> "Juniper and Checkpoint have newer code that doesn't do this."
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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] MACsec interoperability between MX10003 and Cisco ASR 9k?

[Christian Seitz]

Hello,

Am 24.09.18 um 23:29 schrieb Christian Seitz:

> I'm currently trying to find out if somebody has already tested if MACsec can
> be used on a 100G port between MX10003 and Cisco ASR 9k (required licenses
> will be installed on both routers). Yes, MACsec is a standard, but... ;-)
> 
> Unfortunately Juniper currently has no MX10003 available in the loaner pool.
> They have an MX10003 in their lab in Amsterdam, but no ASR 9k. Therefore I
> cannot test is by myself and hope somebody else already made some experience.

nobody answered this email yet so I would like to answer it myself in case
somebody else is interested in this information.

Juniper was now able to deliver a loaner so we could test MACsec between the
MX10003 and an ASR 9910. As long as your JunOS is recent enough that PR1336834
("MACSec AES-GCM-256 hashing algorithm is not compatible with other vendors")
is fixed and your IOS XR has fixed CSCvg91792 ("STARLORD MACSEC - ARP is not
resolved in Octane starlord interop") MACsec just works. I have tested AES-256
between both boxes on a 100G interconnect and unicast and multicast traffic
pass the link.

Thanks and regards,

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

[j-nsp] MACsec interoperability between MX10003 and Cisco ASR 9k?

[Christian Seitz]

Hello,

I'm currently trying to find out if somebody has already tested if MACsec can
be used on a 100G port between MX10003 and Cisco ASR 9k (required licenses
will be installed on both routers). Yes, MACsec is a standard, but... ;-)

Unfortunately Juniper currently has no MX10003 available in the loaner pool.
They have an MX10003 in their lab in Amsterdam, but no ASR 9k. Therefore I
cannot test is by myself and hope somebody else already made some experience.

Thanks in advance and regards,

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

Re: [j-nsp] eve-ng - lab environment

[Christian Scholz]

Welcome to the world of EVE.
I prepped my JNCIE purely with EVE ;)




> Am 16.07.2018 um 14:16 schrieb Aaron Gould :
> 
> Oh my gosh, Eve-ng is awesome!  If you didn't know about it, you gotta try
> it.  It's so cool in its ability to run vSRX and vMX so far in my testing.
> In only a short couple days I've been able to test the following.
> 
> - mpls martini l2circuits using ldp
> - mpls vpls bgp ad/ldp sig (rfc4762)
> - mpls vpls bgp ad/bgp sig (rfc4761)
> - mpls evpn (my first look ever!)
> - mplsogre (my first look ever in junos!)
> 
> I wanted to see it run L2 bridging technologies since I had so much
> unsuccess in my previous GNS3 attempts over the last few years (I may have
> never set up the virtual l2 fwd'ing plane in gns3 like I should have)
> 
> incase you want to take a look.
> 
> http://eve-ng.com 
> 
> 
> 
> I had to take a moment and share about this.  It's so clean and elegant in
> how it runs and works.
> 
> 
> 
> -Aaron 
> 
> ___
> 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 login down ?

[Christian Scholz]

Yes - they had planned maintenance today...




 Ursprüngliche Nachricht Von: Aaron Gould  
Datum: 09.02.18  00:32  (GMT+01:00) An: juniper-nsp@puck.nether.net Betreff: 
[j-nsp] juniper login down ? 
iam-sso.juniper.net - is this down ?

 

- Aaron

___
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 your experience with the EX2200

[Christian Scholz]

Unfortunately no pattern yet - all areas have problems - but if I have to
name one that has very "hard" Problems it will be dot1x...
Thing is, that we installed a lot of them in production, they were just fine
but after a while we noticed, that whenever we changed the config (even
changing a single VLAN) the Device crashes - no pattern - no Clue. 
Core-Dump does not tell anything good.
JTAC is on this but didn't come up with a Solution yet - we replaced all of
them with the good old EX2200 and now the Production Network runs fine again
(Version 12.3R12-S6 I think).
We will test 17.4 or maybe even better 18.1 or 18.2 - the EX2300 needs to
become more mature before we trust it again.

By the way:
My earlier Mail was not meant to "bully" anyone - it was just my Opinion. I
love Juniper but the Software 15.1 is only a Joke - but enough said ;)



-Ursprüngliche Nachricht-
Von: Dan White [mailto:dwh...@olp.net] 
Gesendet: Montag, 11. Dezember 2017 16:53
An: Christian Scholz <c...@ip4.de>
Cc: juniper-nsp@puck.nether.net
Betreff: Re: What is your experience with the EX2200

Thank you all for your feedback. This is invaluable advice as we don't have
much operational experience with Juniper switches to work with.

Christian,

Is there a common theme among the issues you've encountered? Are they
aligned with a particularly feature set?

On 12/09/17 20:29 +0100, Christian Scholz wrote:
>I would only buy the EX2300 if somebody points a Gun in my Face -
seriously!
>Anyone recommending a Device that purely relies on 15.1 Software does 
>not even closely know what he is talking about...
>
>The 2300 is a Joke so far - We have 7 PR's open and weekly Core-Dumps...
>Stick with the EX2200 since the EX2200 is not EOL and the EX2300 is 
>unusable until a fine Release (17.3 onwards) is available, fixing all 
>the critical things.
>15.1 is the new Windows Vista - unstable, unreliable and just a big 
>joke - never ever ever ever use a 15.X in Production until you want to 
>watch the World burn...
>
>Just my 2 cents...

--
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@olp.net
http://www.btcbroadband.com


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

Re: [j-nsp] What is your experience with the EX2200

[Christian Scholz]

I would only buy the EX2300 if somebody points a Gun in my Face - seriously!
Anyone recommending a Device that purely relies on 15.1 Software does not
even closely know what he is talking about...

The 2300 is a Joke so far - We have 7 PR's open and weekly Core-Dumps...
Stick with the EX2200 since the EX2200 is not EOL and the EX2300 is unusable
until a fine Release (17.3 onwards) is available, fixing all the critical
things.
15.1 is the new Windows Vista - unstable, unreliable and just a big joke -
never ever ever ever use a 15.X in Production until you want to watch the
World burn...

Just my 2 cents...


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

Re: [j-nsp] It is about cisco command

[Christian Scholz]

There is no such way to "test before apply " in Cisco. Thats one reason to 
choose Juniper ;)
You could Create a Lab-Environment to test such things or test this virtually 
with Cisco VIRL. Besides that there is no way because as you wrote - Cisco will 
take everything and fires it live...
RegardsChris


 Ursprüngliche Nachricht Von: Brijesh Patel 
 Datum: 21.03.17  22:13  (GMT+01:00) An: Saku Ytti 
 Cc: juniper-nsp@puck.nether.net Betreff: Re: [j-nsp] It is about 
cisco command 
Hi Saku,

Thanks for your response.

In juniper* test *command will test before apply to neighbour

Where in cisco , once you implement command go into nvram so bit not give
answer.

Regards,

Brijesh Patel


On Tue, Mar 21, 2017 at 8:00 PM, Saku Ytti  wrote:

> Hey,
>
> > *Juniper>test policy CUSTOMER-BGP-ABC-Consultancy-V4 192.168.x.y/24 *
> >
> > *Is there any command in cisco to test roue-map and prefix-list. *
>
> Pretty sure best you get is 'show ip bgp route-map XYZ'
>
> --
>   ++ytti
>
___
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] SRX Is 12.3X48 already mature?

[Christian Beyerlein]

Hi!

Does anyone already use 12.3X48 on datacenter SRX (SRX3600 HA)?

We are currently on 12.1X44 and would like to skip 12.1X46 and 12.1X47, 
but 12.3X48 is not yet "JTAC recommended".


Any stability issues observed? Will ISSU work from 12.1X44?

We use only basic features, FW/NAT and ALG for RTSP/SUNRPC, no IDP or 
sth like that.


BR
  Christian
--
Christian Beyerlein
Senior System Engineer

net mobile AG
Fritz-Vomfelde-Str. 26-30
DE 40547 Düsseldorf

Tel. +49 (0) 211 97020-950

Registergericht: Amtsgericht Düsseldorf, HRB 48022
Vorstand:Edgar Schnorpfeil (Vorsitzender),
 Simone Wittstruck,
 Imran Khan

Vorsitzender des
Aufsichtsrates:  Hiroyuki Sato
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] unsubscrive

[Christian Malo]

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

Re: [j-nsp] JUNIPER L3VPN MPLS LAB - MTU (Giuliano Medalha)

[Christian V Petersen]

Hello :)

To me it sounds like a routing issue - if you remove an IP-interface and
then it works, then check the connectivity over this interface. Can you
ping the host you want to SSH to?

Could it be that the IP-interface it not configured correctly but you are
routing the traffic over this interface? (static?)

As far as I know its the IP-layer that re-assembles all fragments and
presents this to higher layers. But with MTU around 1500 I dont suspect
your SSH-traffic will be fragmented - just forwarded.

Hope this helps! :)
BR
CVP

On Mon, Jun 9, 2014 at 6:00 PM, juniper-nsp-requ...@puck.nether.net wrote:

 Send juniper-nsp mailing list submissions to
 juniper-nsp@puck.nether.net

 To subscribe or unsubscribe via the World Wide Web, visit
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 or, via email, send a message with subject or body 'help' to
 juniper-nsp-requ...@puck.nether.net

 You can reach the person managing the list at
 juniper-nsp-ow...@puck.nether.net

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of juniper-nsp digest...


 Today's Topics:

1. JUNIPER L3VPN MPLS LAB - MTU (Giuliano Medalha)


 --

 Message: 1
 Date: Sun, 8 Jun 2014 14:48:58 -0300
 From: Giuliano Medalha giuli...@wztech.com.br
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Subject: [j-nsp] JUNIPER L3VPN MPLS LAB - MTU
 Message-ID:
 CAMw=
 8hq3e5tu-tewhgg3zvk3qwkhdl2icwzzq+5nq-9fdnt...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8

 ?Hello everyone,

 Doing some lab tests with JUNIPER SRX100H2 equipments (packet-mode).

 Basically we have:

   --- P3 --- P4 ---
- -
  PE-1 - - PE-2
- -
   --- P1 --- P3 ---


 All fast interfaces are configured like:

 set interfaces fe-0/0/0 mtu 1534
 set interfaces fe-0/0/0 unit 0 family inet mtu 1500
 set interfaces fe-0/0/0 unit 0 family inet6 mtu 1500
 set interfaces fe-0/0/0 unit 0 family mpls mtu 1520


 MPLS MTU = IP MTU + 20 byte

 After commit the system asks to configure Interface MTU with 1534 bytes
 (MPLS MTU + MTU overhead = 14 bytes)

 The VRF can converge and everything works fine.

 The questions about this configuration are:

 - When we access P1 ... it cannot run ssh to P3 directly.  SSH do not work.

 - If we remove fe-0/0/0 unit 0  family inet mtu it works fine.


 This configuration is correct for fast ethernet using RSX ?

 We do not test VRF with applications (FTP, HTTP, etc) ... it will work ?

 Inside VRF we have another interfaces (PE routers) ... Do we need to
 configure interface MTU for VRF too ?



 Anyone knows why SSH is not working  between boxes ?   Could be
 fragmentation ?

 Thanks a lot,

 Giuliano


 --

 Subject: Digest Footer

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

 --

 End of juniper-nsp Digest, Vol 139, Issue 7
 ***




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

Re: [j-nsp] Juniper Product against DDoS

[Andre Christian]

Another option - 
http://www.juniper.net/us/en/products-services/security/ddos/

Depends on the use case.

On 2/18/14, 4:08 PM, Dobbins, Roland rdobb...@arbor.net wrote:


On Feb 18, 2014, at 9:46 PM, Samol molas...@gmail.com wrote:

 Does Juniper provide any DDoS solution ?

They have this:

http://www.juniper.net/as/en/products-services/security/junos-webapp-secu
re/ddos/

I've never run into anyone using it, so I've no idea as to its
capabilities.  Perhaps someone else on the list has experience with it
and can comment . . .

They also have flowspec capabilities on many (all?) of their routers;
flowspec can be utilized to leverage the routers to mitigate DDoS attacks
using layer-4 classification.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

 Luck is the residue of opportunity and design.

  -- John Milton


___
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] Outbound collision errors ?

[Christian de Balorre]

Hello,
Before anything, make sure both ends have identical autoneg or 
duplex/speed settings.

Also you can run a tdr test (request diagnostic tdr) from the EX.

Christian.

Le 15/10/2013 15:33, Ben a écrit :

Hi,


This issue appears to be beyond the collective intellect of JTAC (I'm 
getting the usual wall of silence you get when the poor engineer is 
stumped !).   So before I complain to Juniper and escalate to someone 
who knows their * from their elbow, I thought I would ask here first !


Mr Google is also not being particularly useful, apart from one 
potential hit saying its a hardware fault.


Under show int stat detail on an EX4200, I'm seeing the following 
for a copper gige interface :


  Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 33174940,
Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU 
errors: 0,

Resource errors: 0

I have swapped cables and ports on our side and it makes no 
difference, the outbound collisions are still rising.


The carrier partner on the other side says they are seeing no errors 
whatsoever on their kit.


We have tried  both hard coding and autoneg, same result in both 
instances.


Help !



___
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] Advice on a 100Gbps+ environment

[Christian de Balorre]

Slow control-plane. No RE redundancy. More limited rib  fib than 
regular MX. Cryptic licensing scheme.

Otherwise nothing really wrong.

Christian

Le 02/07/2013 15:55, Drew Weaver a écrit :

And what is wrong with the MX80 as a peering/transit router for up to 80Gbps of 
traffic?

Thanks,
-Drew


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Dobbins, Roland
Sent: Tuesday, July 02, 2013 9:01 AM
To: juniper-nsp Puck
Subject: Re: [j-nsp] Advice on a 100Gbps+ environment


On Jul 2, 2013, at 7:19 PM, Mark Tinka wrote:


Says who?

Doh - MX*480*, not MX*80*.  My mistake.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton


___
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] ISSU timeouts on MX upgrades due to large routing tables?

[Christian]

Hello Clarke,
You can use a Linux box with an hexabgp to easely inject as many routes 
you want in your lab routers.

Rgds,

Christian

Le 22/05/2013 03:01, Clarke Morledge a écrit :
I was curious to know if anyone has run into any issues with large 
routing tables on an MX causing ISSU upgrades to fail?


On several occasions, I have been able to successfully do an 
In-Software-Service-Upgrade (ISSU) in a lab environment but then it 
fails to work in production.


I find it difficult to replicate the issue in a lab, since in 
production I am dealing with lots of routes as compared to a small 
lab.  Does anyone have any experience when the backup RE gets its new 
software, then reboots, but since it takes a long time to populate the 
routing kernel database on the newly upgraded RE that it appears to 
timeout?


I have seen behavior like this with upgrades moving from 10.x to a 
newer 10.y and from 10.x to 11.y.


Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
___
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] next-hop driving me crazy

[Christian]

Hello,
Use a ttl on the bgp session with the customer -
Rgds,

C.

Le 26/04/2013 16:26, Alex Arseniev a écrit :
Works fine for me in the lab on MX80+JUNOS 12.3 ( I use BGP-LU though, 
too busy to change to regular inet unicast:-)


[edit logical-systems MX2-RR]
aarseniev@mx80# run show route logical-system MX2-RR protocol bgp 
extensive


inet.0: 29 destinations, 30 routes (27 active, 0 holddown, 2 hidden)
198.18.0.6/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 198.18.0.6/32 - {indirect(1048668)}
   *BGPPreference: 170/-101
   Next hop type: Indirect
   Address: 0x26e8010
   Next-hop reference count: 6
   Source: 198.18.0.11
   Next hop type: Discard
   Protocol next hop: 192.0.2.1
   Push 299904
   Indirect next hop: 29941d8 1048668 INH Session ID: 
0x280008

   State: Active Int Ext
   Local AS: 50928 Peer AS: 50928
   Age: 5:14   Metric2: 0
   Validation State: unverified
   Task: BGP_50928.198.18.0.11+179
   Announcement bits (2): 3-KRT 5-Resolve tree 2
   AS path: 31133 50928 I (Looped: 50928)
   Communities: 5:5
   Accepted
   Route Label: 299904
   Localpref: 100
   Router ID: 198.18.0.11
   Secondary Tables: inet.3
   Indirect next hops: 1
   Protocol next hop: 192.0.2.1 Metric: 0
   Push 299904
   Indirect next hop: 29941d8 1048668 INH Session 
ID: 0x280008


[edit logical-systems MX2-RR]
aarseniev@mx80# show policy-options policy-statement set-nh
term 1 {
   from {
   protocol bgp;
   community 5:5;
   }
   then {
   next-hop 192.0.2.1;
   accept;
   }
}
[edit logical-systems MX2-RR]
aarseniev@sadok# show routing-options
static {
   route 192.0.2.1/32 discard;
}


- Original Message - From: Eric Krichbaum e...@telic.us
To: juniper-nsp@puck.nether.net
Sent: Friday, April 26, 2013 2:36 PM
Subject: [j-nsp] next-hop driving me crazy



This should be simple but I can't get the behavior I want.

Blackhole scenario.  Customer set community, I want to see that 
community

and set next-hop to an address I have with a discard.  I've tried both a
discard interface and a basic static route.  Those seem ok either way.

set routing-options static route 192.0.2.1/32 discard

Route comes in and is accepted by policy.  With no next-hop 192.0.2.1
action, I see it as a valid route so I know the policy is happening.  
When I
add the next-hop action, the route becomes Next hop type: Unusable 
with
Inactive reason: Unusable path.  I don't see anything special about 
this
and what I translated from my cisco versions doesn't look all that 
different

from various black hole presentations I find.

Anyone have a magic answer?

Thanks,
Eric



___
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] Redundancy with MX

[Andre Christian]

Marcus - I am building about 10 PoPs and opted for the dual mx-80 design. Also 
looked at making the PoPs all layer 2 with a pair of exs. 

Plan to use MC-LAG where applicable.

On Jan 21, 2013, at 3:43 PM, Markus H hauschild.mar...@gmail.com wrote:

 Hi,
 
 I wonder what kind of redundancy the community would prefer for
 small-medium sized PoPs.
 This is what I have come up with so far:
 
 a) 2xMX80
 Pro: Two seperate devices so less prone to config errors and chassis failure
 Con: Using redundant uplinks is more complicated (LB would need to be
 done via routing protocol)
 
 b) 1xMX240/480 with redundant SCB and RE
 Pro: Easier to use redundant uplinks (LACP)
 Con: Config error as well as chassis failure brings the whole PoP down
 
 Any further arguments? Best practices? What did you deploy?
 
 
 Best regards,
 Markus
 ___
 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] DDOS and MX-240's

[Christian]

I confirm Alcatel has also implemented flowspec on their device.
On our side we also use it moderately on our backbone ; it is very easy 
to implement and much more powerful than rtbh.


Christian

Le 08/01/2013 05:10, Eric Cables a écrit :

It's interesting that Flowspec was one of the presentations at the Bay Area
Juniper User's Group in October, and heavily used by CloudFlare.

http://www.slideshare.net/junipernetworks/flowspec-bay-area-juniper-user-group-bajug

-- Eric Cables


On Mon, Jan 7, 2013 at 12:41 PM, Darius Jahandarie djahanda...@gmail.comwrote:


On Mon, Jan 7, 2013 at 2:48 PM, Richard A Steenbergen r...@e-gerbil.net
wrote:

On Mon, Jan 07, 2013 at 05:41:06AM +, Dobbins, Roland wrote:

On Jan 6, 2013, at 11:14 PM, Richard Gross wrote:


I am seeking advise.  If you wanted to block 800K /32's from your

inbound pipes, how would you do it?

You don't need nor want to do this.  Flowspec and S/RTBH are very
useful tools for blocking, as Chris indicated, but nobody needs to
block 800K /32s.

http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html

Still has the same issue. Juniper has basically let Flowspec bit-rot
into complete uselessness since Pedro left.

It really sucks to hear that the performance didn't improve on Trio.
Flowspec is /the/ way to make DoS mitigation possible for companies
not big enough to buy a boatload of edge capacity, it's too bad that
it's not implemented by anyone but Juniper, and Juniper is letting it
rot. (It's also too bad that, AFAIK, nLayer is the only transit
provider that actually offers it to customers.)

I think this is one of the things that the people building on top of
OpenFlow can use to wipe the floor with classical vendors (a good
MPLS-TE implementation being the other thing).

--
Darius Jahandarie
___
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 issues

[Christian]

Hello,
Any luck with the strict option at the install-nexthop ?
Rgds,

Christian

Le 30/11/2012 17:41, Richard A Steenbergen a écrit :

Does anybody have any experience with forced LSP path selection for VPLS
circuits? Long story short, when we fire up traffic on one particular
VPLS instance, we're seeing SOME of the traffic it's carrying being
blackholed. The pattern is one of certain IP or even TCP port pairs
being blocked, and it seems to rotate over time, which screams hashing
across multiple LSPs where one of them is doing something bad, and it
changes as the LSPs resignal over time to me. To try and lock this
down, I'm trying to force the VPLS traffic to route over a single LSP,
in the usual manner with a forwarding-table export policy, and a very
simple extended community regexp against the vrf-target community.

term VPLS {
 from community MATCH_VPLS;
 then {
 install-nexthop lsp-regex .*-SILVER.*;
 load-balance per-packet;
 accept;
 }
}

But it sure as hell doesn't look like it's narrowing the LSP selection:

ras@re0.router show route forwarding-table family vpls table blah
Routing table: blah.vpls
VPLS:
DestinationType RtRef Next hop   Type Index NhRef Netif
...
00:xx:xx:xx:xx:xx/48 user 0  indr 1050634 5
  idxd  3223 2
idx:1  xx.xx.142.132 Push 262153, Push 655412(top)  
4543 1 xe-7/3/0.0
idx:1  xx.xx.142.62  Push 262153, Push 752660, Push 
691439(top)  1315 1 xe-4/1/0.0
idx:2  xx.xx.142.132 Push 262153, Push 758372(top)  
1923 1 xe-7/3/0.0
idx:2  xx.xx.142.62  Push 262153, Push 382341, Push 
691439(top)  2541 1 xe-4/1/0.0
idx:3  xx.xx.142.132 Push 262153, Push 758372(top)  
1923 1 xe-7/3/0.0
idx:3  xx.xx.142.62  Push 262153, Push 382341, Push 
691439(top)  2541 1 xe-4/1/0.0
idx:4  xx.xx.142.30  Push 262153, Push 714676(top)  
1500 1 xe-4/1/1.0
idx:4  xx.xx.142.62  Push 262153, Push 619458, Push 
378636(top)  3864 1 xe-4/1/0.0
idx:xx xx.xx.142.82  Push 262153, Push 601828(top)  
 989 1 xe-5/0/0.0
idx:xx xx.xx.142.132 Push 262153, Push 684644(top)  
3516 1 xe-7/3/0.0
idx:xx xx.xx.142.62  Push 262153, Push 528898, Push 
760875(top)  4766 1 xe-4/1/0.0
idx:xx xx.xx.142.62  Push 262153, Push 792036, Push 
691439(top)  3473 1 xe-4/1/0.0

Any ideas, about this or about troubleshooting the forwarding plane for
VPLS in general? Other than that VPLS just sucks... :)



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

Re: [j-nsp] GRE between EX3200

[Christian]

Hello,
The only trick is the need to sacrifice a physical gig-e port :

http://www.juniper.net/techpubs/en_US/junos12.1/topics/task/configuration/gre-tunnel-services-cli.html

Christian

Le 27/11/2012 10:46, Emil Katzarski a écrit :

Hello,

Did anybody actually manage to bring a GRE tunnel up with EX4200? I 
couldn't.


Regards: Emil

On Wed, Apr 25, 2012 at 5:20 PM, Christian cdebalo...@neotelecoms.com 
mailto:cdebalo...@neotelecoms.com wrote:


Hello,
GRE support in EX in 12.1,
Rgds,

Christian

Le 25/04/2012 16:15, paul.ma...@agencyport.com
mailto:paul.ma...@agencyport.com a écrit :

Hi all,



Has anyone had any luck with GRE tunnels on the EX3200? I've
found an
old thread from 2010 that seems to suggest that the
functionality has
drifted in and out of support on various versions of JunOS,
and was
roadmapped for permanent inclusion...



Thanks,



Paul







_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.

If you have received this email in error please notify the
originator of the message. This footer also confirms that this
email message has been scanned for the presence of computer
viruses.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Agencyport Software Ltd.

Scanning of this message and addition of this footer is performed
by Websense Email Security software in conjunction with
virus detection software.

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

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
mailto: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] GRE between EX3200

[Christian]

Hello,
GRE support in EX in 12.1,
Rgds,

Christian

Le 25/04/2012 16:15, paul.ma...@agencyport.com a écrit :

Hi all,



Has anyone had any luck with GRE tunnels on the EX3200? I've found an
old thread from 2010 that seems to suggest that the functionality has
drifted in and out of support on various versions of JunOS, and was
roadmapped for permanent inclusion...



Thanks,



Paul







_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.

If you have received this email in error please notify the
originator of the message. This footer also confirms that this
email message has been scanned for the presence of computer viruses.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Agencyport Software Ltd.

Scanning of this message and addition of this footer is performed
by Websense Email Security software in conjunction with
virus detection software.

___
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] junos 10 - send syslog to non standard port

[Loos, Christian]

Hi Artur,
checked it with SRX100 (JUNOS 11.4R1.6) and it is not a hidden command:
[edit system syslog host 1.1.1.1]
root@host# set ?
Possible completions:
  allow-duplicates Do not suppress the repeated message
  any  All facilities
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  authorizationAuthorization system
  change-log   Configuration change log
  conflict-log Configuration conflict log
  daemon   Various system processes
  dfc  Dynamic flow capture
  explicit-priorityInclude priority and facility in messages
  external Local external applications
  facility-overrideAlternate facility for logging to remote host
  firewall Firewall filtering system
  ftp  FTP process
  interactive-commands  Commands executed by the UI
  kernel   Kernel
  log-prefix   Prefix for all logging to this host
  matchRegular expression for lines to be logged
  ntp  NTP process
  pfe  Packet Forwarding Engine
  port Port number  --- here!
  security Security related
  source-address   Use specified address as source address
 structured-data  Log system message in structured format
  user User processes

Viele Grüße / Kind regards,
Christian Loos


Sitz der NK Networks  Services GmbH: Von-der-Wettern-Straße 15, 51149 Köln
Registergericht: Amtsgericht Köln, Registernummer HRB 30805
Geschäftsführer: Markus Buschmann, Frank Kammer, Bernard Latour 



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

Re: [j-nsp] strange packet loss without impact

[Christian]

Hi,
Try to monitor the fwdd process - when running high it causes packet to 
drop on these pc's.


Christian


Le 04/07/2011 13:11, Adam Leff a écrit :

I realize this will sound silly, but have you checked for half-duplex
on your interfaces?

Those onboard J6350 interfaces are actually 10/100/1000, so if you
don't have the speed and link-mode hardcoded,  do a show interfaces
extensive ge-0/0/# and check the link partner section to ensure you're
running full-duplex.

Adam

On Jul 4, 2011, at 7:01, Matthias Brummmatth...@brumm.net  wrote:


Hello!

Since some weeks now, we have a strange packet loss on one of our edge
locations.

A few days ago an IX informed us about packet loss on our router. The router
in place is a J6350. We have a 1 Gig line to us and two 1 Gig lines to some
uplinks. Every communication goes through a 1 Gig copper link to a ProCurve
2810-24G. So the external links are connected to the switch and the switch
via one cable with the router.

The packet loss is strange, because:

1. In smokeping during the busy hours of the day, there are losses of about
5%
2. From my workstation I get packet loss of about 10 up to 50%
3. There are no errors on the switch or router interface (except i.e. VLAN
errors)
4. no customers have reported any problems. But there are many customers
relying on real time communication (VoIP/RDP)
5. The switch port with the router is showing maximum 200 Mbit
6. The router is showing 20% real-time threads

According to the datasheet the J-Series should be able to deliver this
performance easily. Or are the onboard Gig-Interfaces the problem? Of course
I know, that this physical configuration is a bad idea, and I will change is
very soon to ease the load on this particular port.

Any other ideas?

Regards,

Matthias
___
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] strange packet loss without impact

[Christian]

If in doubt run show system processes summary to check for busy process 
during your peak time.

Also you can have some interesting stats with a show pfe statistics traffic

Christian


Le 04/07/2011 15:33, Matthias Brumm a écrit :

Hello!

At the moment I am monitoring it with top on UNIX shell, do you have 
another suggestion? In top this process is idleing.


Regards,

Matthias

2011/7/4 Christian cdebalo...@neotelecoms.com 
mailto:cdebalo...@neotelecoms.com


Hi,
Try to monitor the fwdd process - when running high it causes
packet to drop on these pc's.

Christian


Le 04/07/2011 13:11, Adam Leff a écrit :

I realize this will sound silly, but have you checked for
half-duplex
on your interfaces?

Those onboard J6350 interfaces are actually 10/100/1000, so if you
don't have the speed and link-mode hardcoded,  do a show
interfaces
extensive ge-0/0/# and check the link partner section to
ensure you're
running full-duplex.

Adam

On Jul 4, 2011, at 7:01, Matthias Brummmatth...@brumm.net
mailto:matth...@brumm.net  wrote:

Hello!

Since some weeks now, we have a strange packet loss on one
of our edge
locations.

A few days ago an IX informed us about packet loss on our
router. The router
in place is a J6350. We have a 1 Gig line to us and two 1
Gig lines to some
uplinks. Every communication goes through a 1 Gig copper
link to a ProCurve
2810-24G. So the external links are connected to the
switch and the switch
via one cable with the router.

The packet loss is strange, because:

1. In smokeping during the busy hours of the day, there
are losses of about
5%
2. From my workstation I get packet loss of about 10 up to 50%
3. There are no errors on the switch or router interface
(except i.e. VLAN
errors)
4. no customers have reported any problems. But there are
many customers
relying on real time communication (VoIP/RDP)
5. The switch port with the router is showing maximum 200 Mbit
6. The router is showing 20% real-time threads

According to the datasheet the J-Series should be able to
deliver this
performance easily. Or are the onboard Gig-Interfaces the
problem? Of course
I know, that this physical configuration is a bad idea,
and I will change is
very soon to ease the load on this particular port.

Any other ideas?

Regards,

Matthias
__ _
juniper-nsp mailing list juniper-nsp@puck.nether.net
mailto:juniper-nsp@puck.nether.net
https://puck.nether.net/ mailman/listinfo/juniper-nsp
https://puck.nether.net/mailman/listinfo/juniper-nsp

__ _
juniper-nsp mailing list juniper-nsp@puck.nether.net
mailto:juniper-nsp@puck.nether.net
https://puck.nether.net/ mailman/listinfo/juniper-nsp
https://puck.nether.net/mailman/listinfo/juniper-nsp

__ _
juniper-nsp mailing list juniper-nsp@puck.nether.net
mailto:juniper-nsp@puck.nether.net
https://puck.nether.net/ mailman/listinfo/juniper-nsp
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] SUSPECT : Re: ISIS between ERX 1440 and MX960

[Christian]

Sniffing the ISIS packets should give some more clues.

Le 19/05/2011 20:37, Kaliraj a écrit :

hi david,

1. is the erx interface configured with an ip-address?
 
http://www.juniper.net/techpubs/software/erx/junose72/swconfig-ip-ipv6-igp/html/isis-config6.html#89040
says erx should have atleast one ip-addres/router-id configured.

2. if yes, then pls try if adjusting hello-padding attributes on both
ends. it does look like mtu and padding issue. perhaps try
adaptive/strict padding on junos side to see if there are mtu issues.

kaliraj

On Thu, May 19, 2011 at 10:24 AM,david@orange-ftgroup.com  wrote:

Hi all,

I'm trying to establish an ISIS L2 adjacency between an ERX (Junose is new for 
me) and 1 MX without success :  I double checked the mtu, subnet, Area (not 
checked for L2), authentication key (I tried simple and MD5 types)

The problem seems to be at the ERX side. Indeed, the MX receives well the IIH 
of the ERX and put its state to Init, then it sends an IIH to the ERX. At the 
ERX level, IIH is discarded (at the Interface level : Input Discard counter). I 
don't understand why. I guess there is a MTU issue with the hello padding 
process but I'm not sure.

Config at the MX side
---

ge-2/2/2.0
{
family iso;
faimly inet address 10.1.1.1/30
}

lo0
{
family iso address 49.0001.xxx
}

protocol isis
{
level 2 {
authentication-key sdjskdjskd;
authentication-type md5;
}
interface ge-2/2/2.0 {
level 1 disable;
level 2 {
  hello-authetication-key FOO;
  hello-authetication-type md5;
}
}


Config at the ERX side :

router isis 1234
is-type level-2-only
net 49.0001.xxx
domain-message-digest-key 1 hmac-md5 FOO
passive-interface loopback50


int gi 12/0
ip router isis 1234
isis circuit-type level-2-only
isis message-digest-key 1 hmac-md5 FOO level-2


I tried to monitor ISIS packet at the MX side. I noticed that the PDU length of 
the MX IIH is equal to 1492 and the ERX one is equal to 1497. Moreover, the 
protocol capabilities of the MX are IPv4 and IPv6 and for the ERX that are CLNP 
and IPv4.

Any help would be most welcome.

thanks
Regards,
David




IMPORTANT.Les informations contenues dans ce message electronique y compris les 
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) 
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, 
veuillez immediatement le signaler  a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce 
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s 
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and 
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), 
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be 
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.



___
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] Strange behavior of BGP policy

[Christian]

I guess you want a  reject instead of the last accept,
rgds,

Christian


Le 09/11/2010 11:18, Alexander Shikoff a écrit :

Hello,

On MX80-48T with JunOS 10.2R1.8 I have a BGP session with downstream
configured as follows:

minot...@br1-gdr.ki# show routing-instances World protocols bgp group 
Downstreams
neighbor 178.214.196.6
description MHost: World;
import [ Local-Pref-400 from-MHost Deny-Rest ];
export to-MHost;
peer-as 21098;


Filtering of outgoing prefixes is performed via to-MHost policy:
minot...@br1-gdr.ki# show policy-options policy-statement to-MHost
term Default {
 from {
 route-filter 0.0.0.0/0 exact;
 }
 then reject;
}
term Itself {
 from {
 protocol static;
 route-filter 178.214.192.0/19 exact;
 }
 then accept;
}
then accept;


As you can see only route 178.214.192.0/19 from static routes should be
redistributed into BGP, but I see another routes (direct, static, OSPF)
also being redistributed:
minot...@br1-gdr.ki# run show route 178.214.192.0/19 advertising-protocol bgp
178.214.196.6

World.inet.0: 337026 destinations, 668447 routes (60 active, 10 holddown, 
3675
hidden)
   Prefix  Nexthop  MED LclprefAS path
* 178.214.192.0/19SelfI
* 178.214.192.0/27Self 2  I
* 178.214.192.64/32   SelfI
* 178.214.192.65/32   Self 2  I
* 178.214.192.68/32   Self 2  I
* 178.214.192.69/32   SelfI
* 178.214.192.96/28   SelfI
* 178.214.192.128/29  SelfI
* 178.214.192.136/30  SelfI
* 178.214.192.140/30  Self 2  I
* 178.214.192.144/30  SelfI
* 178.214.193.0/30Self 2  I
* 178.214.193.4/30Self 2  I
* 178.214.194.0/30Self 2  I
* 178.214.194.4/30Self 2  I
* 178.214.195.0/24Self 2  I
* 178.214.196.4/30SelfI

Why does policy accepts another direct/static/OSPF routes?

Thanks.



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

Re: [j-nsp] Weird Port Problem

[Christian]

Just to be sure, if you want the port to be forced also disable auto-neg 
on the combo interface.

Looks like a duplex mismatch at first sight.

Christian


Le 21/10/2010 18:26, Paul Stewart a écrit :

Hi there..



We have a customer we migrated off a Cisco 7600 over to an MX480.



Long story short we're having performance issues and have isolated it down
to some questions ;)



This is a 20GE+2X10GE linecard - customer port is using a copper 10/100/1000
SFP.  Port is hard coded to 100/full on both sides.



   MAC statistics:  Receive Transmit

 Total octets 586682576135778876

 Total packets   616114   506951

 Unicast packets 616114   506616

 Broadcast packets0  335

 Multicast packets00

 CRC/Align errors  98950

 FIFO errors  104900

 MAC control frames   00

 MAC pause frames 00

 Oversized frames 0

 Jabber frames0

 Fragment frames682

 VLAN tagged frames   0

 Code violations  0

   Filter statistics:

 Input packet count  616114

 Input packet rejects  9895

 Input DA rejects 0

 Input SA rejects 0

 Output packet count  506951

 Output packet pad count   0

 Output packet error count 0

 CAM destination filters: 0, CAM source filters: 0





Opened ticket with JTAC and so far not getting anywhere despite requesting
an escalation - they have been analyzing this for over 24 hours now with
no idea.



According to some docs, FIFO errors mean replace the PIC immediately which
I find hard to believe - this could be a classic cat5 issue or an SFP issue
but before knocking the customer down would rather get some feedback
please..



Customer side is a watchguard firewall unfortunately



Thanks,


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] Strange BGP behaviour on 10.0R3

[Christian]

 Hello,
Checking for bgp msgs stuck  in the outgoing queue is also a good clue 
for mtu issues :-)

Rgds,

Christian


Le 12/10/2010 13:42, Diogo Montagner a écrit :

Hi William,

Have you tried enable pmtud in this session ?

Tks

On 10/12/10, William Jacksonwjack...@sapphire.gi  wrote:

Hi



We are seeing some strange behavior on an MX with 10.0R3.



We have an Ethernet link to a switch where we have multiple eBGP peers.

We and the peer are seeing the session come up and then expiring with
hold-time received messages, other peers on the same segment work 100%.



When doing a pcap we are seeing the following happen:



Setup and establish session BGP session.

Once established our router then starts to send the updates to the
correct IP address but a different MAC.  The pcap doesn't show any
strange ARP behaviour, the MAC address that is suddenly used belongs to
another peer.



The session then obviously times out, we haven't seen messages or
indicators as to why this is happening.  JTAC are looking at it but
don't seem to know why either.

Anyone else seen this type of behavior?



___
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] destination nat, 8 rule limit

[christian koch]

he said he did that already..

unfortunately i don't think the limits were upped for source/destination nat
rules, i think it is still 8 on 9.6r1

On Tue, Nov 3, 2009 at 8:39 AM, Derick Winkworth dwinkwo...@att.net wrote:

 Upgrade to 9.6.  You can have many more rules per rule-set...




 
 From: Christopher M. Hobbs ch...@altbit.org
 To: juniper-nsp@puck.nether.net
 Sent: Tue, November 3, 2009 10:08:13 AM
 Subject: [j-nsp] destination nat, 8 rule limit

 If I try to set up more than 8 rules per rule-set on our
 SRX240 boxes, Junos gets cranky.  Here's the error I
 receive:

 ---
 cho...@ss0101# commit check
 [edit security nat destination rule-set mail]
  'rule'
number of elements exceeds limit of 8
 error: configuration check-out failed: (number of elements exceeds limit)
 ---

 I can't break our rules out into different rule sets because
 it complains of context at that point (which I believe is
 tied to the destination address?):

 ---
 cho...@ss0101# commit check
 error: Destination NAT rule-set mail and test have same
 context.
 [edit security nat destination]
  'rule-set test'
Destination NAT rule-set(test) sanity check failed.
 error: configuration check-out failed
 ---

 All of our incoming addresses exist on the same subnet and
 the majority of our destination addresses are on the same
 subnet as well, so I clearly can't split up our rules to
 work around this issue if the context is based on either the
 incoming or destination addresses.

 I've read a couple of threads concerning a similar issue and
 the fix was to upgrade to 9.6, which I did.  The upgrade
 didn't appear to solve anything at all.

 Does anyone know why this restriction is here other than
 just poor programming?  How can I get past this limitation?

 Thanks for your time!
 --
 C.M. Hobbs, http://altbit.org
 ___
 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] [c-nsp] Network Liberation Movement???

[christian koch]

On Sun, Nov 1, 2009 at 9:54 PM, Omachonu Ogali oog...@gmail.com wrote:

 How much is buzz worth? About the same as YouTube views. (In South Park
 speak, theoretical dollars).

 If you can't convert *positive* buzz into revenue, your marketing efforts
 will serve as nothing more than brand awareness campaigns.

 By this point in the conversation, it should be obvious the buzz is turning
 negative:
 a) overtones of disinterest due to dubious marketing,
 b) people biting the bait on what seems to be a month long viral campaign
 that *still* has 15 more days to go before phase 2,
 c) conversation shift from the mystery product, to debating whether the
 marketing works -- and we still don't know what's being marketed other than
 common sense (You hate vendor lock-in, I hate vendor lock-in, let's be
 friends)


well said, and agreed

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

Re: [j-nsp] [c-nsp] Network Liberation Movement???

[christian koch]

looks as if its working based on the activity in this thread...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Problem M10

[christian]

memory errors, obviously - open a jtac case or you can try replacing
feb card, if you have a spare

On Sat, Oct 10, 2009 at 7:36 PM, wolfz l...@netadm.com.br wrote:
 Hello!

 Anybody already sow this messages?

 Oct 9 05:17:57 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 05:17:57 Ebstjkj feb Bogus Cell incremented since last reported.
 6863444

 Oct 9 05:18:27 Ebstjkj feb Bogus Cell incremented since last reported.
 6863448

 Oct 9 05:18:30 Ebstjkj feb BCHIP 0: multiple uncorrectable ECC error

 Oct 9 05:18:30 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit -1 was
 bypassed

 Oct 9 05:18:30 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 05:19:09 Ebstjkj feb Bogus Cell incremented since last reported.
 6864053

 Oct 9 05:19:09 Ebstjkj feb Bogus Cell incremented since last reported.
 1361645

 Oct 9 05:19:13 Ebstjkj feb BCHIP 0: multiple correctable ECC errors

 Oct 9 05:19:13 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit 48 was
 corrected

 Oct 9 05:19:13 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 ECC errors

 Oct 9 05:19:19 Ebstjkj feb Bogus Cell incremented since last reported.
 6864093

 Oct 9 05:19:19 Ebstjkj feb Bogus Cell incremented since last reported.
 1361663

 Oct 9 05:41:23 Ebstjkj feb Bogus Cell incremented since last reported.
 6864136

 Oct 9 05:41:23 Ebstjkj feb Bogus Cell incremented since last reported.
 1361665

 Oct 9 23:15:09 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 23:15:20 Ebstjkj feb Bogus Cell incremented since last reported.
 13592167

 Oct 9 23:15:20 Ebstjkj feb Bogus Cell incremented since last reported.
 2913515

 Oct 9 23:15:24 Ebstjkj feb BCHIP 0: multiple correctable ECC errors

 Oct 9 23:15:24 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit 25 was
 corrected

 Oct 9 23:15:24 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 ECC errors

 Oct 9 23:18:00 Ebstjkj feb BCHIP 0: multiple uncorrectable ECC error

 Oct 9 23:18:00 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit -1 was
 bypassed

 Oct 9 23:18:00 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 23:18:01 Ebstjkj feb Bogus Cell incremented since last reported.
 13592231

 Oct 9 23:18:01 Ebstjkj feb Bogus Cell incremented since last reported.
 2913525

 Oct 9 23:18:33 Ebstjkj feb Bogus Cell incremented since last reported.
 13592245

 Oct 9 23:18:33 Ebstjkj feb Bogus Cell incremented since last reported.
 2913529

 Oct 9 23:18:33 Ebstjkj feb BCHIP 0: multiple uncorrectable ECC error

 Oct 9 23:18:33 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit -1 was
 bypassed

 Oct 9 23:18:33 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 23:19:11 Ebstjkj feb Bogus Cell incremented since last reported.
 13592668

 Oct 9 23:19:11 Ebstjkj feb Bogus Cell incremented since last reported.
 2913597

 Oct 9 23:19:12 Ebstjkj feb BCHIP 0: multiple uncorrectable ECC error

 Oct 9 23:19:12 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit -1 was
 bypassed

 Oct 9 23:19:12 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 23:19:37 Ebstjkj feb Bogus Cell incremented since last reported.
 13592893

 Oct 9 23:19:37 Ebstjkj feb Bogus Cell incremented since last reported.
 2913613

 Oct 9 23:19:39 Ebstjkj feb BCHIP 0: multiple uncorrectable ECC error

 Oct 9 23:19:39 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit -1 was
 bypassed

 Oct 9 23:19:39 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 uncorrectable ECC errors

 Oct 9 23:19:47 Ebstjkj feb Bogus Cell incremented since last reported.
 13592971

 Oct 9 23:19:47 Ebstjkj feb Bogus Cell incremented since last reported.
 2913626

 Oct 9 23:20:01 Ebstjkj feb Bogus Cell incremented since last reported.
 13592986

 Oct 9 23:20:01 Ebstjkj feb Bogus Cell incremented since last reported.
 2913628

 Oct 9 23:20:01 Ebstjkj feb BCHIP 0: multiple correctable ECC errors

 Oct 9 23:20:01 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit 39 was
 corrected

 Oct 9 23:20:01 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 ECC errors

 Oct 9 23:20:03 Ebstjkj feb Bogus Cell incremented since last reported.
 13600213

 Oct 9 23:20:03 Ebstjkj feb Bogus Cell incremented since last reported.
 2914965

 Oct 9 23:20:05 Ebstjkj feb Bogus Cell incremented since last reported.
 13600620

 Oct 9 23:20:07 Ebstjkj feb BCHIP 0: multiple correctable ECC errors

 Oct 9 23:20:07 Ebstjkj feb BCHIP 0: ECC from SDRAM bank 1, at bit 48 was
 corrected

 Oct 9 23:20:07 Ebstjkj feb CM: Slot 0: Recoverable error detected; multiple
 ECC errors

 Oct 9 23:20:13 Ebstjkj feb Bogus Cell incremented since last reported.
 2915061

 Oct 9 23:21:59 Ebstjkj feb Bogus Cell incremented since last reported.
 13600672

 Oct 9 23:22:01 Ebstjkj feb BCHIP 0: multiple uncorrectable ECC error

 

[j-nsp] Refurbished Hardware

[Christian Koch]

anyone know of a reputable reseller where I may be able to find an SCB
for an old M40 chassis?

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

Re: [j-nsp] MPLS VPN Load-balancing

[Christian Martin]

Thanks, Harry.

I just checked our routing and noticed that the traffic was entering  
the Juniper via a transit MPLS link to another PE, so the VPN label is  
the only label on the stack due to PHP.  As such, if what Steven  
mentions is true re: ABC-chip hardware, then there is no entropy as  
the VPN label is the same.  We are shifting the traffic to allow it to  
ingress as IPv4 to see if that changes anything.


There are several VRFs that transit the link, each with a few source  
subnets and a single destination subnet.  In these cases, the traffic  
rates are low and periodic ( 500kbps every 10 minutes or so, spread  
around).  The meaningful traffic is exchanged between 5 IPs on two  
subnets (subnet A.1,.2,.3,.4,.5 to subnet B.1,.2.,3,.4,.5).  Each  
stream is around 6Mbps.


Do you know if there is a CFEB upgrade that uses a new chip  
architecture that would support a deeper hash key?


Cheers,
Chris


On Aug 11, 2009, at 5:27 PM, Harry Reynolds wrote:

 but one particular subnet pair is exchanging quite a bit of  
traffic).  All of

the addresses are unique within our domain


Can you clarify the nature of you test traffic to the busy subnet in  
question?


1. Number of vrf ingress interfaces?
2. Number of source-Ips
3. Number of destination ips w/in that subnet

Basically, how many flows do you have heading to that busy subnet?

IIRC, as an ingress node we would do an IP hash, and this should use  
the incoming interface and IP S/D addresses by default. On some  
platforms when you start adding additional hashes, such as a L4  
port, you may start eating into the number of IP address bits that  
are actually hashed. Meaning, you gain port entropy but loose some  
granularity at the IP address level. Hence these knobs have a bit of  
variance for each person that test them, as their flow specifics may  
or may not benefit from some combination.


As always, the more variance and the larger the number of streams  
the better the expected results. If there is a single pair of busy  
speakers on that subnet that would explain things. If you had 10 (or  
more) more or less equally active streams, and still had the results  
below, then that would seem broken IMO. I may be wrong, but if you  
only have 3 such streams, then each stream is independently hashed,  
and there is a 12 % chance  (.50 x .50 x.50) you will get unlucky  
and find all three on the same link.


HTHs.






-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net 
] On Behalf Of Christian Martin

Sent: Tuesday, August 11, 2009 1:58 PM
To: Steven Brenchley
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPLS VPN Load-balancing

Steven,

Thanks for the response.  I was unaware of this limitation in the  
ABC- chip, but I am still curious as to why the incoming traffic to  
the PE, which should be hashed at IP only, is not properly balanced  
across the outbound (MPLS) links.  The lookup is done on the IP  
header only, which should have enough entropy to create a reasonably  
balanced modulus.  Unless the outbound FIB entries play a role  
somehow?  I could see if this were a P and MPLS was coming in and  
out, but it is

IP---push--push---forward...

Also note that the outer label is of course different on the two  
links (learned via LDP).


Cheers,
Chris





On Aug 11, 2009, at 4:08 PM, Steven Brenchley wrote:


Hi Christian,
The problem your hitting is a limitation of the M10i chip set.
It can only look at the top two labels and since both top labels are
the same for all this traffic it's going to look like the same flow
and send it all across the same link.  The only way I've been able to
get a simulance of load balancing is by creating multiple LSP's
between the same end points and manually push different traffic  
across

the different LSP's.  It's really clunky but there are no switches
that will work around this limitation on the current M10i CFEB.
 If you where using a T-series, M320,M120, or MX router you don't
have this limitation.  They can all go deeper into the packet to
determine load balance.
 On the a semi brighter side, on the horizon there are some new
Ichip based CFEB's which will not have this limitation.  I don't
recall when those will be available but you could probably get a hold
of your SE and get a time table from them.

Steven Brenchley

===

On Tue, Aug 11, 2009 at 3:16 PM, Christian Martin
christian.mar...@teliris.com

wrote:

NSP-ers,

I have a Cisco---Juniper pair connected over a pair of T3 links.
The Juniper acts as a PE and is pushing two labels for a specific
route learned on the PE destined to a single remote PE well beyond  
the
Cisco P.  The traffic is destined to several IP addresses clustered  
in

this subnet (sort of like 10, 11, 12, 13) and the forwarding table
shows that there are two correctly installed next- hops - same VPN
label, different LDP label (we have applied several

Re: [j-nsp] MPLS VPN Load-balancing

[Christian Martin]

We made the traffic change and now the balancing is even.  I am going  
to change the config to label-1 payload ip (only) and then shift it  
back and see if we can in fact hash on the single label and the iP  
header.  Hopefully this will suffice!


Cheers,
Chris




On Aug 12, 2009, at 12:50 PM, Harry Reynolds wrote:

I think the issue is that on ABC/M-series we can either do a MPLS  
hash (up to two labels), or an IP/L4 hash. It does not seems that  
you can do both, but I read somewhere if you only do a 1 label hash  
then abc/m series can hash on the IP. Its so hard to keep this  
straight. Good thing there is only one junos else all hope would be  
lost. ;)


T-series platforms with e-fpcs and MX can hash on multiple MPLS  
labels while *also* hashing on L3 and l4.


This seems to jive with the docs at:

http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-policy/policy-configuring-load-balancing-based-on-mpls-labels.html

Regards







-Original Message-
From: Christian Martin [mailto:christian.mar...@teliris.com]
Sent: Wednesday, August 12, 2009 9:25 AM
To: Harry Reynolds
Cc: Steven Brenchley; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPLS VPN Load-balancing

Thanks, Harry.

I just checked our routing and noticed that the traffic was entering  
the Juniper via a transit MPLS link to another PE, so the VPN label  
is the only label on the stack due to PHP.  As such, if what Steven  
mentions is true re: ABC-chip hardware, then there is no entropy as  
the VPN label is the same.  We are shifting the traffic to allow it  
to ingress as IPv4 to see if that changes anything.


There are several VRFs that transit the link, each with a few source  
subnets and a single destination subnet.  In these cases, the  
traffic rates are low and periodic ( 500kbps every 10 minutes or  
so, spread around).  The meaningful traffic is exchanged between 5  
IPs on two subnets (subnet A.1,.2,.3,.4,.5 to subnet B. 
1,.2.,3,.4,.5).  Each stream is around 6Mbps.


Do you know if there is a CFEB upgrade that uses a new chip  
architecture that would support a deeper hash key?


Cheers,
Chris


On Aug 11, 2009, at 5:27 PM, Harry Reynolds wrote:


but one particular subnet pair is exchanging quite a bit of
traffic).  All of

the addresses are unique within our domain


Can you clarify the nature of you test traffic to the busy subnet in
question?

1. Number of vrf ingress interfaces?
2. Number of source-Ips
3. Number of destination ips w/in that subnet

Basically, how many flows do you have heading to that busy subnet?

IIRC, as an ingress node we would do an IP hash, and this should use
the incoming interface and IP S/D addresses by default. On some
platforms when you start adding additional hashes, such as a L4 port,
you may start eating into the number of IP address bits that are
actually hashed. Meaning, you gain port entropy but loose some
granularity at the IP address level. Hence these knobs have a bit of
variance for each person that test them, as their flow specifics may
or may not benefit from some combination.

As always, the more variance and the larger the number of streams the
better the expected results. If there is a single pair of busy
speakers on that subnet that would explain things. If you had 10 (or
more) more or less equally active streams, and still had the results
below, then that would seem broken IMO. I may be wrong, but if you
only have 3 such streams, then each stream is independently hashed,
and there is a 12 % chance  (.50 x .50 x.50) you will get unlucky and
find all three on the same link.

HTHs.






-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net
] On Behalf Of Christian Martin
Sent: Tuesday, August 11, 2009 1:58 PM
To: Steven Brenchley
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPLS VPN Load-balancing

Steven,

Thanks for the response.  I was unaware of this limitation in the
ABC- chip, but I am still curious as to why the incoming traffic to
the PE, which should be hashed at IP only, is not properly balanced
across the outbound (MPLS) links.  The lookup is done on the IP
header only, which should have enough entropy to create a reasonably
balanced modulus.  Unless the outbound FIB entries play a role
somehow?  I could see if this were a P and MPLS was coming in and
out, but it is
IP---push--push---forward...

Also note that the outer label is of course different on the two
links (learned via LDP).

Cheers,
Chris





On Aug 11, 2009, at 4:08 PM, Steven Brenchley wrote:


Hi Christian,
   The problem your hitting is a limitation of the M10i chip set.
It can only look at the top two labels and since both top labels are
the same for all this traffic it's going to look like the same flow
and send it all across the same link.  The only way I've been able  
to

get a simulance of load balancing is by creating multiple LSP's
between the same end points

[j-nsp] MPLS VPN Load-balancing

[Christian Martin]

NSP-ers,

I have a Cisco---Juniper pair connected over a pair of T3 links.  The  
Juniper acts as a PE and is pushing two labels for a specific route  
learned on the PE destined to a single remote PE well beyond the Cisco  
P.  The traffic is destined to several IP addresses clustered in this  
subnet (sort of like 10, 11, 12, 13) and the forwarding table shows  
that there are two correctly installed next-hops - same VPN label,  
different LDP label (we have applied several different types of  
hashings and of course have our forwarding table export policy in  
place).  Nevertheless, the Juniper is doing a very poor job load- 
balancing the traffic, and the Cisco is splitting it almost evenly.   
There is in fact a larger number of routes being shared across this  
link (about 20 or so VPN routes in different VRFs and thus different  
VPN labels – all sharing the same 2 LDP labels, but one particular  
subnet pair is exchanging quite a bit of traffic).  All of the  
addresses are unique within our domain.


Has anyone had issues with load-balancing a single subnet across an  
MPLS VPN link pair?  Note again that this is a PE-P (J--C) problem and  
that the IP addresses are all arranged locally.  I know Juniper are  
secretive about their hashing algorithm (can't lose any hero tests,  
can we?), but we are getting like 5:1 load share if we are lucky and  
are bumping up against the T3's capacity.  The box is an M10i.


As always, any help would be appreciated.

Cheers,
C

show route forwarding-table destination 10.160.2.0/24

Routing table: foo.inet
Internet:
DestinationType RtRef Next hop   Type Index NhRef Netif
10.160.2.0/24  user 0indr 262175 2
 ulst 262196 2
Push 74   600 1  
t3-0/0/0.1000
Push 74   632 1  
t3-0/0/1.1000



PE-P next-hop count (all showing load-balancing in effect)

show route next-hop 172.16.255.11 terse | match  | count
Count: 106 lines


monitor interface traffic

InterfaceLink Input bytes(bps)  Output  
bytes(bps)
 t3-0/0/0  Up541252651233   (25667208)  691166913860
(35611752)
 t3-0/0/1  Up279149587856(8737568)   24893605598   
(20112)



Note that the Cisco is doing 25/9 Mbps and the Juniper 35/.02.






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

Re: [j-nsp] MPLS VPN Load-balancing

[Christian Martin]

Steven,

Thanks for the response.  I was unaware of this limitation in the ABC- 
chip, but I am still curious as to why the incoming traffic to the PE,  
which should be hashed at IP only, is not properly balanced across the  
outbound (MPLS) links.  The lookup is done on the IP header only,  
which should have enough entropy to create a reasonably balanced  
modulus.  Unless the outbound FIB entries play a role somehow?  I  
could see if this were a P and MPLS was coming in and out, but it is  
IP---push--push---forward...


Also note that the outer label is of course different on the two links  
(learned via LDP).


Cheers,
Chris





On Aug 11, 2009, at 4:08 PM, Steven Brenchley wrote:


Hi Christian,
 The problem your hitting is a limitation of the M10i chip set.   
It can only look at the top two labels and since both top labels are  
the same for all this traffic it's going to look like the same flow  
and send it all across the same link.  The only way I've been able  
to get a simulance of load balancing is by creating multiple LSP's  
between the same end points and manually push different traffic  
across the different LSP's.  It's really clunky but there are no  
switches that will work around this limitation on the current M10i  
CFEB.
  If you where using a T-series, M320,M120, or MX router you  
don't have this limitation.  They can all go deeper into the packet  
to determine load balance.
  On the a semi brighter side, on the horizon there are some new  
Ichip based CFEB's which will not have this limitation.  I don't  
recall when those will be available but you could probably get a  
hold of your SE and get a time table from them.


Steven Brenchley

===

On Tue, Aug 11, 2009 at 3:16 PM, Christian Martin christian.mar...@teliris.com 
 wrote:

NSP-ers,

I have a Cisco---Juniper pair connected over a pair of T3 links.   
The Juniper acts as a PE and is pushing two labels for a specific  
route learned on the PE destined to a single remote PE well beyond  
the Cisco P.  The traffic is destined to several IP addresses  
clustered in this subnet (sort of like 10, 11, 12, 13) and the  
forwarding table shows that there are two correctly installed next- 
hops - same VPN label, different LDP label (we have applied several  
different types of hashings and of course have our forwarding table  
export policy in place).  Nevertheless, the Juniper is doing a very  
poor job load-balancing the traffic, and the Cisco is splitting it  
almost evenly.  There is in fact a larger number of routes being  
shared across this link (about 20 or so VPN routes in different VRFs  
and thus different VPN labels – all sharing the same 2 LDP labels,  
but one particular subnet pair is exchanging quite a bit of  
traffic).  All of the addresses are unique within our domain.


Has anyone had issues with load-balancing a single subnet across an  
MPLS VPN link pair?  Note again that this is a PE-P (J--C) problem  
and that the IP addresses are all arranged locally.  I know Juniper  
are secretive about their hashing algorithm (can't lose any hero  
tests, can we?), but we are getting like 5:1 load share if we are  
lucky and are bumping up against the T3's capacity.  The box is an  
M10i.


As always, any help would be appreciated.

Cheers,
C

show route forwarding-table destination 10.160.2.0/24

Routing table: foo.inet
Internet:
DestinationType RtRef Next hop   Type Index NhRef  
Netif

10.160.2.0/24  user 0indr 262175 2
ulst 262196 2
   Push 74   600 1  
t3-0/0/0.1000
   Push 74   632 1  
t3-0/0/1.1000



PE-P next-hop count (all showing load-balancing in effect)

show route next-hop 172.16.255.11 terse | match  | count
Count: 106 lines


monitor interface traffic

InterfaceLink Input bytes(bps)  Output  
bytes(bps)
 t3-0/0/0  Up541252651233   (25667208)  691166913860
(35611752)
 t3-0/0/1  Up279149587856(8737568)
24893605598  (20112)



Note that the Cisco is doing 25/9 Mbps and the Juniper 35/.02.






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



--
Steven Brenchley
-
There are 10 types of people in the world those who understand  
binary and those who don't.


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

Re: [j-nsp] MPLS EXP bit marking question

[Christian Martin]

One reason to do this is to use a different egress PE classification  
scheme and rewrite ruleset than what is used in the core.  This  
allows for setting different core EXP values than what would be  
preserved at egress and then, potentially, used for egress marking,  
thus maintaining TOS transparency end-to-end.  I believe this is  
called the short-pipe model.


C

On Jun 8, 2009, at 8:26 AM, Lynch, Tomas wrote:

Why would you want to do that? Labels are used only inside your  
backbone
where you have the same QoS policy in all the routers. It's going  
to be

a burden to configure QoS policies on interfaces because you will have
to think is this router doing the PHP or not?

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Li Zhu
Sent: Sunday, June 07, 2009 7:46 PM
To: mas...@nexlinx.net.pk
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPLS EXP bit marking question

Masood, Nugroho

Thank you for the reply. I agree with both of you that rewrite takes
effect
on both inner and outer mpls label. My next question is:
what if I want to mark inner and outer MPLS label differently? Say I
want
mark the inner exp with 5 and outer exp with 6? Is it possible to
achieve
this?

Thanks,

Li

On Sun, Jun 7, 2009 at 4:10 PM, mas...@nexlinx.net.pk wrote:


the rewrite-rule will take effect on both tags and all the labels in

label

stack.

Regards,
Masood


All,

There is a network like CE --- PE --- P. The PE is M320. Traffic is

from

CE
to P. The traffic out of CE is native IP, after it reaches and gets

out

PE

(then to P), it is double-tagged with MPLS lable. There is a exp
rewrite-rule applied on PE link to P router. My questions is
will the rewrite-rule take effect on both tags or only the outer

tag?


Thanks,

Li
___
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] MPLS EXP bit marking question

[Christian Martin]

One possibility would be to manually set the MPLS exp bit on your  
RSVP tunnel under edit protocols mpls label-switched-path.  This  
overrides the CoS setting for rewrite (but not the scheduler  
config).  If you are using LDP, you use the set protocols mpls  
interface name label-map label-val command.  Note that this is a  
crude method and not exactly what you are probably looking for.


C



On Jun 8, 2009, at 8:26 AM, Lynch, Tomas wrote:

Why would you want to do that? Labels are used only inside your  
backbone
where you have the same QoS policy in all the routers. It's going  
to be

a burden to configure QoS policies on interfaces because you will have
to think is this router doing the PHP or not?

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Li Zhu
Sent: Sunday, June 07, 2009 7:46 PM
To: mas...@nexlinx.net.pk
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPLS EXP bit marking question

Masood, Nugroho

Thank you for the reply. I agree with both of you that rewrite takes
effect
on both inner and outer mpls label. My next question is:
what if I want to mark inner and outer MPLS label differently? Say I
want
mark the inner exp with 5 and outer exp with 6? Is it possible to
achieve
this?

Thanks,

Li

On Sun, Jun 7, 2009 at 4:10 PM, mas...@nexlinx.net.pk wrote:


the rewrite-rule will take effect on both tags and all the labels in

label

stack.

Regards,
Masood


All,

There is a network like CE --- PE --- P. The PE is M320. Traffic is

from

CE
to P. The traffic out of CE is native IP, after it reaches and gets

out

PE

(then to P), it is double-tagged with MPLS lable. There is a exp
rewrite-rule applied on PE link to P router. My questions is
will the rewrite-rule take effect on both tags or only the outer

tag?


Thanks,

Li
___
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] Inactive/Disabled Interface Reporting Link Down via SNMP

[Christian Koch]

thanks to all that replied

activating the interface, deleting the disable, then re-adding the
disable, seemed to fix my issue

christian



On Wed, Sep 10, 2008 at 11:31 PM, Christian Koch
[EMAIL PROTECTED] wrote:
 Hi  -

 I have an interface on an old M40, which i have 'deactivated', 'set
 disable' on that is still alarming Link Down via SNMP polling, and
 showing up/down on a show int terse and Enabled on show interface
 outputs...

 There is nothing connected on this interface

 Am I missing something?

 Software is  JUNOS 7.0R2.7

 [edit interfaces ge-6/1/0]
 # show
 ##
 ## inactive: interfaces ge-6/1/0
 ##
 inactive: disable;
 no-traps;

 [edit interfaces ge-6/1/0]
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] show interfaces terse | match ge-6/1/0
 ge-6/1/0updown

 [EMAIL PROTECTED] show interfaces ge-6/1/0 | match Enabled | last
 Physical interface: ge-6/1/0, Enabled, Physical link is Down


 Thanks!

 Christian

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

Re: [j-nsp] vpls ping control-plane-response

[Christian Koch]

read the following kompella draft, i am pretty sure vpls ping
operation is covered

http://tools.ietf.org/html/draft-stokes-vkompella-l2vpn-vpls-oam-01



On Wed, Aug 13, 2008 at 2:24 PM, Marlon Duksa [EMAIL PROTECTED] wrote:
 Does anyone know what control-plane-response in vpls ping cmd mean?
 VPLS ping in my scenario without that keyword works, but with it, it
 doesn't.

 [EMAIL PROTECTED] run ping vpls instance vpls destination-mac 
 00:00:07:00:00:01
 source-ip 1.1.1.1
 ! - re-0:vpls:ge-5/0/4.0
 ! - re-0:vpls:ge-5/0/4.0


 [EMAIL PROTECTED] run ping vpls instance vpls destination-mac 
 00:00:07:00:00:01
 source-ip 1.1.1.1 control-plane-response
 .

 Thanks,
 Marlon
 ___
 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] J-web installation-j6300 router

[Christian Koch]

request system software delete jweb
request system software add /var/tmp/blahblah
system services web-management http

On Tue, Aug 5, 2008 at 5:02 PM, Mohd Arshad [EMAIL PROTECTED] wrote:
 I have juniper j6300 router
 i want to install j web graphic interface on it
 previsly it was installed on it but i have disabled it from jweb
 now i want to do again\
 can any bodey help me for giving the commands and process for jweb 
 installation of jweb in J6300 router
 software version is 7.3R1.5
 thanks
 arshad


  From Chandigarh to Chennai - find friends all over India. Go to 
 http://in.promos.yahoo.com/groups/citygroups/
 ___
 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] Supporting Audit Requirements in JUNOS

[Christian Koch]

i think a combination of things like this is fine, in most case, auditors
just want to verify you are actually doing what you say you are...how you do
it, whether  ideal, complicated or simple, doesn't really matter to them for
the most part.

like i said if you have some type of change control procedure or policy, you
can associate the changes and the requester of the change with actual proof
of the change (logs/rancid/tftp/etc)






On Wed, Jul 23, 2008 at 9:32 AM, Jose Madrid [EMAIL PROTECTED] wrote:

 Going back to Christian's point, Rancid doesn't know who made the
 changes and if there are multiple changes between rancid run-times, it
 will pick up various changes and not just the one in particular.  I
 currently use a mixture of rancid and logs from devices to see who
 logged in at a time nearest when the change was picked up.  This is
 less than ideal solution, but all we currently have.

 On Tue, Jul 22, 2008 at 5:17 PM, Stefan Fouant [EMAIL PROTECTED] wrote:
  Yes, we have a change management process in place, but my job is to
  enforce it.  Normally, we get the change request submitted, approved,
  then we push the change to the firewall.  However, there is no simple
  way to correlate the committed change to the actual change request.
  My idea was to enforce the use of comments on commits along the lines
  of:
 
  commit comment This is for Change Request Ticket # 123
 
  As I alluded and Ben Bird confirmed, it seems that the most reasonable
  way to accomplish this goal is through the use of deny-commands to
  force the use of any commit which does not contain the string
  'comment' in it.  This is easier said than done, and I'll need to
  brush up on my RegEx skills:
 
  I wanted to do something along the lines of :
 
  set system login class engineering deny-commands ^commit.*!comment.*$
 
  but the damn * is being greedy and matching everything... so, I just
  need to play around with it a bit.
 
  On Tue, Jul 22, 2008 at 5:06 PM, Christian Koch
  [EMAIL PROTECTED] wrote:
  Hello Stefan -
 
  I have been going through multiple SAS70's for the past year now...
 
  however, we have a change management process, which changes need to go
  through in order for a change to be allowed. so everything is all
  documented..
 
  submit change request - review - approve - push change -
 archive/document
 
  i realize this may not be feasible for everyone and being in different
  situations, environments, etc.. but its not too much of a hassle, also
 if
  you are using something like rancid, or some script or
  other network management product to fetch and save configs when changes
 are
  made, i think you are in the clear.
 
 
  on a side note, if the commit script thing works well, i think that's an
  awesome idea
 
 
  christian
 
 
 
 
  On Tue, Jul 22, 2008 at 3:38 PM, Stefan Fouant [EMAIL PROTECTED]
 wrote:
 
  Hi folks,
 
  As part of SAS 70 Audit requirements, I need to ensure that anytime a
  firewall change is made on my routers a description of that change is
  recorded.  I suppose I could force this by using commit scripts and
  forcing the use of annotate on anything in the firewall-filters
  stanza, although this could be rather unwieldy in it's implementation.
   My preference would be to ensure that anytime the configuration is
  committed a 'commit comment comment' is used, but doesn't seem that
  I can use commit-scripts to force that since a commit is not a
  configuration variable.  I wonder if I could use allow-commands or
  deny-commands to accomplish something along these lines...
 
  Has anyone attempted anything similar?  What have you folks done to
  support SAS 70 Audit requirements?
 
  Thanks,
 
  --
  Stefan Fouant
  Principal Network Engineer
  NeuStar, Inc. - http://www.neustar.biz
  GPG Key ID: 0xB5E3803D
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 
 
 
  --
  Stefan Fouant
  Principal Network Engineer
  NeuStar, Inc. - http://www.neustar.biz
  GPG Key ID: 0xB5E3803D
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 



 --
 It has to start somewhere, it has to start sometime. What better place
 than here? What better time than now?

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

Re: [j-nsp] Supporting Audit Requirements in JUNOS

[Christian Koch]

Hello Stefan -

I have been going through multiple SAS70's for the past year now...

however, we have a change management process, which changes need to go
through in order for a change to be allowed. so everything is all
documented..

submit change request - review - approve - push change - archive/document

i realize this may not be feasible for everyone and being in different
situations, environments, etc.. but its not too much of a hassle, also if
you are using something like rancid, or some script or
other network management product to fetch and save configs when changes are
made, i think you are in the clear.


on a side note, if the commit script thing works well, i think that's an
awesome idea


christian




On Tue, Jul 22, 2008 at 3:38 PM, Stefan Fouant [EMAIL PROTECTED] wrote:

 Hi folks,

 As part of SAS 70 Audit requirements, I need to ensure that anytime a
 firewall change is made on my routers a description of that change is
 recorded.  I suppose I could force this by using commit scripts and
 forcing the use of annotate on anything in the firewall-filters
 stanza, although this could be rather unwieldy in it's implementation.
  My preference would be to ensure that anytime the configuration is
 committed a 'commit comment comment' is used, but doesn't seem that
 I can use commit-scripts to force that since a commit is not a
 configuration variable.  I wonder if I could use allow-commands or
 deny-commands to accomplish something along these lines...

 Has anyone attempted anything similar?  What have you folks done to
 support SAS 70 Audit requirements?

 Thanks,

 --
 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz
 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

Re: [j-nsp] Enforcing CLI Idle-Timeouts

[Christian Koch]

i tried this a while back and came across the same issue, i've yet to be
able to find a 'hack' since..

christian



On Mon, Jul 21, 2008 at 4:56 PM, Stefan Fouant [EMAIL PROTECTED] wrote:

 Hey Folks,

 Wondering if anyone knows how to enforce CLI Idle-Timeouts on Juniper
 using default login classes such as Super-User.  I see that there is a
 command 'idle-timeout' which can be configured under a login class,
 but I want to modify the default class 'super-user' which has a
 default of idle-timeout 0/disabled.  It does not appear that I can
 modify the default login classes.

 Anyone here ever attempt anything similar?

 --
 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz
 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

Re: [j-nsp] RD usage in BGP based VPLS

[Christian Koch]

if you're using bgp signaling for auto discovery then you need RD, if you
are using LDP, you do not

if you still dont know why you need an RD when using bgp, i suggest you read
the following RFC's



http://tools.ietf.org/html/rfc4761
http://tools.ietf.org/html/rfc4762












On Tue, Jun 17, 2008 at 8:07 AM, narasimha murthy [EMAIL PROTECTED]
wrote:

 Hi can any one tell me why RD is required for BGP based VPLS configaration.
 in case of L3 vpn RD is used to make customer ipv4 address globally unique
 in MPLS domain.
   But i dont understand the usage of RD in case of VPLS.

 Murthy

 ___
 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] /31 subnet mask

[Christian Koch]

/31 is useless/unuseable

/31 = 255.255.255.254 - 2 addresses network address and broadcas, there is
no room for host addresses



On Sat, Mar 22, 2008 at 8:49 AM, sunnyday [EMAIL PROTECTED] wrote:

 hello can any one explain the use of a /31 subnet mask i know its for
 saving ip addresses etc etc but i need to know how it works,limitations
 and how to implement it.
 thank you
 ___
 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] JunOS cookbook thoughts?

[christian]

Definitely worth it, I constantly use the book as well as 2 other resources

http://www.juniperforum.com/
and this wiki i recently found which has the potential to be an excelent
Juniper resource
 http://juniper.cluepon.net/index.php/Main_Page


On 7/28/07, Stephen Fulton [EMAIL PROTECTED] wrote:

 Gordon Ewasiuk wrote:

  It's a no-nonsense guide too.  Assumes a level of expertise regarding
  protocols and standards.  You don't get chapters and chapters of
  theory and background.  Just lots of practical, hands-on JunOS
  commands and recipes.  Best book I've purchased this year.

 I concur, it's well worth it.  The only part I've really missed is info
 on certain L2 functions of JunOS, but that's easily found on the Juniper
 site.

 -- Stephen.

 ___
 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-ldp signaling

[Peder Christian Bach]

Hi.

This is ordinary martini vpn. P2P.

Marini use LDP ( target LDP)


So this is not VPLS.. 

For example VPLS - BGP is configured like this:


routing-instances {
Cust {
description VPLS;
instance-type vpls;
interface ge-0/0/0.2001;
interface ge-0/0/0.2002;
route-distinguisher 211:300;
vrf-target target:211:300;
protocols {
vpls {
site A {
site-identifier 2;
}
}
}
}

-Peder


-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Muhammad Teguh 
Pribadi
Sendt: 28. februar 2007 09:17
Til: Junos Guy
Kopi: Juniper Milis
Emne: Re: [j-nsp] Vpls-ldp signaling

Hi,
   
  Maybe you can use my configuration testing, i used it in my office lab, and 
it works, even in other router using Junos 8.0
   
  Hope it will help you.
   
  Regards,
  -Teguh-

Junos Guy [EMAIL PROTECTED] wrote:
  Thanks Jake.
Hope someone from Juniper can confirm this.

Regards,
Aditya.



On 2/27/07, Bourgeois, Jacob (Jake)** CTR ** 
wrote:

 This seems like a doc bug, AKAIK, and per 7.6 docs, BGP is still used to
 signal VPLS on juniper platforms.


 http://www.juniper.net/techpubs/software/junos/junos76/swref76-hierarchy/htm
 l/rfc-list2.html#1213459

 draft-ietf-l2vpn-vpls-bgp is listed.
 draft-ietf-l2vpn-vpls-ldp is not listed.


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Junos Guy
 Sent: Monday, February 26, 2007 8:41 PM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Vpls-ldp signaling

 Hello ,

 How do we configure vpls with ldp signaling ?



 As per JunOS 7.6 Feature Release.

 LDP Signaling for VPLS
 Uses Label Distribution Protocol (LDP) instead of Border Gateway Protocol
 (BGP) as the signaling protocol for VPLS
 Implemented per draft-ietf-l2vpn-ldp-05
 ___
 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


 
-
Any questions?  Get answers on any topic at Yahoo! Answers. Try it now.

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

Re: [j-nsp] LDP issues

[Christian Malo]

I do get the routes in the ldp database and to Reply to Sergio's email:

[EMAIL PROTECTED] show ldp database | match Input|L2CKT 
Input label database, x.x.x.109:0--x.x.x.110:0
Input label database, x.x.x.109:0--x.x.x.124:0
Input label database, x.x.x.109:0--x.x.x.125:0

Neighbor: x.x.x.124
Interface Type  St Time last up  # Up trans
fe-0/0/3.0(vc 500)rmt   VC-Dn  -  0
  Local interface: fe-0/0/3.0, Status: Up, Encapsulation: ETHERNET
  Remote PE: x.x.x.124, Negotiated control-word: No
  Incoming label: 310240, Outgoing label: 195

-chris


-Original Message-
From: Doug Marschke [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 24, 2007 5:35 PM
To: 'Christian Malo'; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] LDP issues

Are the routes also installed as IGP routes?
Due to ordered control, the L2circuit neighbor must be an IGP route.

Do you see labels advertised with show ldp database?

Doug


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian Malo
Sent: Wednesday, January 24, 2007 2:12 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] LDP issues

That's the simple setup I have


 6500-sup720
|
|
|
m5  m20-- bunch of other routers



I have ldp enabled on every router and the m20 has no problems setting up 
l2circuits to every router except the m5 and 6500.

I noticed on the m5 that it doesn't have any LDP routes from the m20 but 
has 1 from the 6509.

The configuration for both interfaces are the same and the mpls/ldp 
configs are similar.


[EMAIL PROTECTED] run show route protocol ldp

inet.0: 206261 destinations, 411236 routes (206240 active, 0 holddown, 21 
hidden)
+ = Active Route, - = Last Active, * = Both

x.x.x.x125/32   [LDP/9] 00:20:08, metric 1
  to x.x.x.78 via ge-0/2/0.0

inet.1: 163 destinations, 163 routes (163 active, 0 holddown, 0 hidden)

inet.3: 4 destinations, 5 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

x.x.x.125/32   [LDP/9] 00:20:09, metric 1
  to x.x.x.78 via ge-0/2/0.0

inet.4: 163 destinations, 163 routes (163 active, 0 holddown, 0 hidden)

mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

310464 *[LDP/9] 00:20:09, metric 1
  to x.x.x.78 via ge-0/2/0.0, Pop
310464(S=0)*[LDP/9] 00:20:09, metric 1
  to x.x.x.78 via ge-0/2/0.0, Pop

inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

__juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 
holddown, 0 hidden)

l2circuit.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

---


125 is the loopback address of the 6509
110 is the loopback address of the m20
124 is the loopback address of a router being the m20

[EMAIL PROTECTED] run show ldp neighbor
AddressInterface  Label space ID Hold time
x.x.x.124 lo0.0  x.x.x.124:0 89
x.x.x.74  ge-0/3/0.0 x.x.x.110:0 10
x.x.x.78  ge-0/2/0.0 x.x.x.125:0 12


[EMAIL PROTECTED] run show ldp session
   Address   StateConnection Hold time
x.x.x.110  Operational  Open 22
x.x.x.124  Operational  Open 172
x.x.x.125  Operational  Open 174


m5 is running 6.3
m20 is running 7.4r1.7


Do you guys have any idea?


-chris
___
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] Encrypted LSP

[Peder Christian Bach]

Hi.



Take a look at this.


http://www.juniper.net/products/modules/100089.pdf





-Peder

-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Leigh Porter
Sendt: 5. januar 2007 12:52
Til: juniper-nsp@puck.nether.net
Emne: [j-nsp] Encrypted LSP

Hiya,

Does anybody know if you can encrypt traffic on a LSP?

i.e. have encrypted LSPs ?

Thanks,
Leigh Porter

___
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