Re: [j-nsp] potential bug in SNMP engine on JunOS 13.3R6.5

[Drew Weaver]

Here is a little bit of additional information.

I figured out that it doesn't actually have anything to do with the pfxcnt 
being 0.

If I do this locally in junos it works fine:

show snmp mib walk decimal 1.3.6.1.2.1.15.3.1

but if I do snmpwalk -v2c -c {community} {ip} 1.3.6.1.2.1.15.3.1 it times out 
halfway through (only with the third peer established, though}.

-Drew

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Drew Weaver
Sent: Monday, November 30, 2015 11:33 AM
To: 'juniper-nsp@puck.nether.net' 
Subject: [j-nsp] potential bug in SNMP engine on JunOS 13.3R6.5

Howdy,

I am trying to monitor the status of a BGP session that has no prefixes using 
SNMP:

admin@MX80> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table  Tot Paths  Act Paths SuppressedHistory Damp StatePending
inet.0
   2  2  0  0  0  0
Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped...
169.254.255.1    81677  87593   0  11 3w6d11h 
1/1/1/0  0/0/0/0
169.254.255.57   81677  87595   0  10 3w6d11h 
1/1/1/0  0/0/0/0
172.16.0.10   65003  3  6   0   1  59 
0/0/0/0  0/0/0/0

if I snmpwalk 1.3.6.1.2.1.15.3 (notice the timeout at the end)

[root@linuxweb html]# snmpwalk -v2c -c   1.3.6.1.2.1.15.3
SNMPv2-SMI::mib-2.15.3.1.1.169.254.255.1 = IpAddress: 169.254.255.1
SNMPv2-SMI::mib-2.15.3.1.1.169.254.255.57 = IpAddress: 169.254.255.57
SNMPv2-SMI::mib-2.15.3.1.1.172.16.0.10 = IpAddress: 209.190.5.162
SNMPv2-SMI::mib-2.15.3.1.2.169.254.255.1 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.2.169.254.255.57 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.2.172.16.0.10 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.3.169.254.255.1 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.3.169.254.255.57 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.3.172.16.0.10 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.4.169.254.255.1 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.4.169.254.255.57 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.4.172.16.0.10 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.5.169.254.255.1 = IpAddress: 169.254.255.2
SNMPv2-SMI::mib-2.15.3.1.5.169.254.255.57 = IpAddress: 169.254.255.58
Timeout: No Response from 

if I snmpwalk the specific OID I need:

[root@linuxweb html]# snmpwalk -v2c -c   1.3.6.1.2.1.15.3.1.7
SNMPv2-SMI::mib-2.15.3.1.7.169.254.255.1 = IpAddress: 169.254.255.1
SNMPv2-SMI::mib-2.15.3.1.7.169.254.255.57 = IpAddress: 169.254.255.57
Timeout: No Response from 

Anyone know a way around this? the BGP session with no prefixes is a backup 
tunnel and the prefixes will only activate when the primary goes offline. I 
would still like to monitor the bgp session between the two devices however.

Thanks.

___
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] potential bug in SNMP engine on JunOS 13.3R6.5

[Drew Weaver]

Howdy,

I am trying to monitor the status of a BGP session that has no prefixes using 
SNMP:

admin@MX80> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table  Tot Paths  Act Paths SuppressedHistory Damp StatePending
inet.0
   2  2  0  0  0  0
Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped...
169.254.255.1    81677  87593   0  11 3w6d11h 
1/1/1/0  0/0/0/0
169.254.255.57   81677  87595   0  10 3w6d11h 
1/1/1/0  0/0/0/0
172.16.0.10   65003  3  6   0   1  59 
0/0/0/0  0/0/0/0

if I snmpwalk 1.3.6.1.2.1.15.3 (notice the timeout at the end)

[root@linuxweb html]# snmpwalk -v2c -c   1.3.6.1.2.1.15.3
SNMPv2-SMI::mib-2.15.3.1.1.169.254.255.1 = IpAddress: 169.254.255.1
SNMPv2-SMI::mib-2.15.3.1.1.169.254.255.57 = IpAddress: 169.254.255.57
SNMPv2-SMI::mib-2.15.3.1.1.172.16.0.10 = IpAddress: 209.190.5.162
SNMPv2-SMI::mib-2.15.3.1.2.169.254.255.1 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.2.169.254.255.57 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.2.172.16.0.10 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.3.169.254.255.1 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.3.169.254.255.57 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.3.172.16.0.10 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.4.169.254.255.1 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.4.169.254.255.57 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.4.172.16.0.10 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.5.169.254.255.1 = IpAddress: 169.254.255.2
SNMPv2-SMI::mib-2.15.3.1.5.169.254.255.57 = IpAddress: 169.254.255.58
Timeout: No Response from 

if I snmpwalk the specific OID I need:

[root@linuxweb html]# snmpwalk -v2c -c   1.3.6.1.2.1.15.3.1.7
SNMPv2-SMI::mib-2.15.3.1.7.169.254.255.1 = IpAddress: 169.254.255.1
SNMPv2-SMI::mib-2.15.3.1.7.169.254.255.57 = IpAddress: 169.254.255.57
Timeout: No Response from 

Anyone know a way around this? the BGP session with no prefixes is a backup 
tunnel and the prefixes will only activate when the primary goes offline. I 
would still like to monitor the bgp session between the two devices however.

Thanks.

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

Re: [j-nsp] potential bug in SNMP engine on JunOS 13.3R6.5

[Drew Weaver]

Ah, turns out that there is something doing NAT between the NMS and the router 
that appears to be mangling the UDP packet.

-Original Message-
From: Drew Weaver 
Sent: Monday, November 30, 2015 12:03 PM
To: Drew Weaver ; 'juniper-nsp@puck.nether.net' 

Subject: RE: potential bug in SNMP engine on JunOS 13.3R6.5

Here is a little bit of additional information.

I figured out that it doesn't actually have anything to do with the pfxcnt 
being 0.

If I do this locally in junos it works fine:

show snmp mib walk decimal 1.3.6.1.2.1.15.3.1

but if I do snmpwalk -v2c -c {community} {ip} 1.3.6.1.2.1.15.3.1 it times out 
halfway through (only with the third peer established, though}.

-Drew

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Drew Weaver
Sent: Monday, November 30, 2015 11:33 AM
To: 'juniper-nsp@puck.nether.net' 
Subject: [j-nsp] potential bug in SNMP engine on JunOS 13.3R6.5

Howdy,

I am trying to monitor the status of a BGP session that has no prefixes using 
SNMP:

admin@MX80> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table  Tot Paths  Act Paths SuppressedHistory Damp StatePending
inet.0
   2  2  0  0  0  0
Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped...
169.254.255.1    81677  87593   0  11 3w6d11h 
1/1/1/0  0/0/0/0
169.254.255.57   81677  87595   0  10 3w6d11h 
1/1/1/0  0/0/0/0
172.16.0.10   65003  3  6   0   1  59 
0/0/0/0  0/0/0/0

if I snmpwalk 1.3.6.1.2.1.15.3 (notice the timeout at the end)

[root@linuxweb html]# snmpwalk -v2c -c   1.3.6.1.2.1.15.3
SNMPv2-SMI::mib-2.15.3.1.1.169.254.255.1 = IpAddress: 169.254.255.1
SNMPv2-SMI::mib-2.15.3.1.1.169.254.255.57 = IpAddress: 169.254.255.57
SNMPv2-SMI::mib-2.15.3.1.1.172.16.0.10 = IpAddress: 209.190.5.162
SNMPv2-SMI::mib-2.15.3.1.2.169.254.255.1 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.2.169.254.255.57 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.2.172.16.0.10 = INTEGER: 6
SNMPv2-SMI::mib-2.15.3.1.3.169.254.255.1 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.3.169.254.255.57 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.3.172.16.0.10 = INTEGER: 2
SNMPv2-SMI::mib-2.15.3.1.4.169.254.255.1 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.4.169.254.255.57 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.4.172.16.0.10 = INTEGER: 4
SNMPv2-SMI::mib-2.15.3.1.5.169.254.255.1 = IpAddress: 169.254.255.2
SNMPv2-SMI::mib-2.15.3.1.5.169.254.255.57 = IpAddress: 169.254.255.58
Timeout: No Response from 

if I snmpwalk the specific OID I need:

[root@linuxweb html]# snmpwalk -v2c -c   1.3.6.1.2.1.15.3.1.7
SNMPv2-SMI::mib-2.15.3.1.7.169.254.255.1 = IpAddress: 169.254.255.1
SNMPv2-SMI::mib-2.15.3.1.7.169.254.255.57 = IpAddress: 169.254.255.57
Timeout: No Response from 

Anyone know a way around this? the BGP session with no prefixes is a backup 
tunnel and the prefixes will only activate when the primary goes offline. I 
would still like to monitor the bgp session between the two devices however.

Thanks.

___
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] Cisco ASR 9001 vs Juniper MX104

[Nitzan Tzelniker]

Regarding CGNAT the MX104 can have MS-MIC that can do all of the
PBA/NAPT/ALG/EIM features for near 10G

Nitzan


On Mon, Nov 30, 2015 at 4:06 PM, Payam Chychi  wrote:

> Asr1000 line are solid if needed for nat
>
> --
> Payam Chychi
> Solution Architect
>
>
> On Monday, November 30, 2015 at 5:57 AM, Saku Ytti wrote:
>
> > On 30 November 2015 at 15:39, Adam Vitkovsky 
> wrote:
> >
> > Hey Adam,
> >
> > > I think this can be alleviated with BGP provider edge link
> protection(Cisco BGP PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
> > > However in Junos this is available only for VRFs.
> > >
> >
> >
> > You'll be happy to hear it got into 15.1 for INET \o/
> >
> > > That's right Trio's LU is just better, it can cope with any
> combination of features enabled with only small performance hit compared to
> A9k's NPU.
> > > However if QX chip is used the whole LU performance advantage is
> jeopardized (but at least the degradation is deterministic).
> > >
> >
> >
> > My main woe is not feature parity or inherent capability of
> > Trio/EZ/nPower, it's more that once JNPR ships something, it'll work
> > on all Trio kit. Cisco is coming up _really_ good troubleshooting
> > tooling for ASR9k, but they'll arrive at different pace (or maybe not
> > at all) at different engines, which is completely understandable for
> > this low-level stuff.
> >
> > > Also the basic Junos documentation is incomplete and getting some deep
> level information is next to impossible.
> >
> > ACK. This is not mentioned often enough, Cisco is doing pretty good
> > job in documents.
> >
> > > And what about ASR903 it's very similar product to MX104.
> >
> > Dunno, I'd say it's more similar to ACX1k, both are running BRCM
> > Enduro? Looking forward to Waris' webinar.
> >
> > --
> > ++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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 21:18, Nitzan Tzelniker wrote:

> Regarding CGNAT the MX104 can have MS-MIC that can do all of the
> PBA/NAPT/ALG/EIM features for near 10G

I've never been keen on adding more expensive hardware to existing
expensive hardware to do something that ought to be supported inline.

This is why the ASR1000 is a better option, IMHO.

Mark.

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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Amos Rosenboim]

I don't think ASR1K is comparable to MX.
The Juniper platform we position against ASR1K is the Juniper SRX.

Amos

Sent from my iPhone

On 30 Nov 2015, at 22:05, Mark Tinka 
> wrote:



On 30/Nov/15 21:18, Nitzan Tzelniker wrote:

Regarding CGNAT the MX104 can have MS-MIC that can do all of the
PBA/NAPT/ALG/EIM features for near 10G

I've never been keen on adding more expensive hardware to existing
expensive hardware to do something that ought to be supported inline.

This is why the ASR1000 is a better option, IMHO.

Mark.

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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 06:00, Colton Conor wrote:

> I have looked and priced both platforms from Juniper and Cisco. Both would
> require two routers for true redundancy as expected. Cisco said instead of
> getting two 9001s, why not look at the ASR9010. They had a promo for free
> RSPs if you buy two cards. The price of the ASR9010 with two cards was just
> about the same price as two 9001s. And a much better deal than the MX104
> fully licensed with two REs and similar cards.
>
> So is looking at something like the ASR9010 worth it even if you only need
> 30Gbps northbound for now? I know for the OP space is a concern so
> the ASR9010, but for those of you with plenty of space what is your overall
> thoughts?

The ASR9010 isn't bad (although you probably want to be looking at the
ASR99xx line moving forward), but if the OP is still looking at NAT,
then not an ideal platform because he'll have to buy another service
line card to do the NAT offload. This takes up even more space and adds
cost.

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

[j-nsp] SNMP OID for CPU temperature

[Rajendra Maharjan]

Dear All,

Is there any SNMP oid that can return value of CPU temperature rather than RE 
temperature. I know there is an oid for RE temperature but it would be very 
beneficial if I could get CPU temperature value too. Searching through juniper 
docs didn't help me either. We may workout with script too but getting direct 
OID would be gorgeous.

Routing Engine status:
  Slot 0:
Current state  Master
Election priority  Master (default)
Temperature 47 degrees C / 116 degrees F
CPU temperature 62 degrees C / 143 degrees F


Regards,
Rajendra Maharjan


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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Colton Conor]

I have looked and priced both platforms from Juniper and Cisco. Both would
require two routers for true redundancy as expected. Cisco said instead of
getting two 9001s, why not look at the ASR9010. They had a promo for free
RSPs if you buy two cards. The price of the ASR9010 with two cards was just
about the same price as two 9001s. And a much better deal than the MX104
fully licensed with two REs and similar cards.

So is looking at something like the ASR9010 worth it even if you only need
30Gbps northbound for now? I know for the OP space is a concern so
the ASR9010, but for those of you with plenty of space what is your overall
thoughts?

Other options might be a used MX240 with older RE's and DPC cards.




On Mon, Nov 30, 2015 at 4:34 AM, john doe  wrote:

> Hey guys,
>
> Working on a project here and it's more or less SP focused,
>
> Which is not a muscle I've worked on lately, mostly been doing campus
> stuff.
>
>
>
> Looking at MX104 vs ASR 9001 as a potential solution.
>
> Requirements are fairly straightforward  - 1GE to collect customers and
> 10GE going northbound (up to 30 Gbps), full MPLS and IP stack, possibly
> Carrier NAT.
>
> Customer wants a box that will give them most room to grown in terms of
> scale/features. And we can't go full modular since rack space is big pain
> for these guys. Price is also an issue (as usual)
>
> I heard good stuff about Juniper SP gear, while not so complimentary
> things of ASR. But that was when platform was introduced and they had all
> sorts of IOS-XR adventures.
>
> Would love to hear some input from here as vendor claims are conflicting
> (nothing new here I guess)
>
>
>
> Cheers
>
>
>
> p.s.
>
> Anyone with experience on ISSU on these platforms?
>
> I've done some googling and it seems like on both platforms it's dependent
> upon line cards you use.
>
> Plus most of the stuff I found was covering big chassis systems, not the
> low range.
>
>
>
>
>
> Sent using Zoho Mail
>
>
>
>
>
>
> ___
> 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] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 22:56, Amos Rosenboim wrote:

> I don't think ASR1K is comparable to MX.

I think the ASR1000 is comparable to the MX104 specifically.

Both are platforms that are suited to a mix of Ethernet and non-Ethernet
ports in a cost-effective manner.

Where the ASR1000 edges our the MX104 is that there are various variants
of the chassis, supporting low-, mid- and high-end forwarding
capacities, native additional services such as IPSec, NAT, e.t.c.

> The Juniper platform we position against ASR1K is the Juniper SRX.

That is not really the ideal comparison, if you ask me. If you want to
pit something against the SRX, for better or worse, I'd do the ASA.

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

Re: [j-nsp] SNMP OID for CPU temperature

[Rajendra Maharjan]

Hi Dale,

I am on MX router and temperature value given by snmp walk is of RE which we 
are already using. But there is no any oid that points out CPU Temperature
run show snmp mib walk jnxOperatingTemp
jnxOperatingTemp.1.1.0.0 = 0
jnxOperatingTemp.2.1.0.0 = 58
jnxOperatingTemp.2.2.0.0 = 48
jnxOperatingTemp.4.1.0.0 = 0
jnxOperatingTemp.4.1.1.0 = 0
jnxOperatingTemp.4.1.2.0 = 0
jnxOperatingTemp.4.1.3.0 = 0
jnxOperatingTemp.4.1.4.0 = 0
jnxOperatingTemp.4.1.5.0 = 0
jnxOperatingTemp.6.1.0.0 = 72
jnxOperatingTemp.6.1.1.0 = 55
jnxOperatingTemp.6.1.2.0 = 70
jnxOperatingTemp.6.1.3.0 = 73
jnxOperatingTemp.7.1.0.0 = 72
jnxOperatingTemp.7.2.0.0 = 72
jnxOperatingTemp.7.3.0.0 = 72
jnxOperatingTemp.8.1.1.0 = 0
jnxOperatingTemp.8.1.2.0 = 0
jnxOperatingTemp.8.2.1.0 = 0
jnxOperatingTemp.8.2.2.0 = 0
jnxOperatingTemp.8.3.1.0 = 0
jnxOperatingTemp.9.1.0.0 = 56
jnxOperatingTemp.20.1.1.0 = 0
jnxOperatingTemp.20.2.1.0 = 0
jnxOperatingTemp.20.2.2.0 = 0
jnxOperatingTemp.20.3.1.0 = 0

#run show chassis routing-engine
Routing Engine status:
  Slot 0:
Current state  Master
Election priority  Master (default)
Temperature 56 degrees C / 132 degrees F
CPU temperature 67 degrees C / 152 degrees F


Regards,
Rajendra Maharjan


On Dec 1, 2015, at 12:26 PM, Dale Shaw  wrote:

> show snmp mib walk jnxOperatingTemp

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

Re: [j-nsp] SNMP OID for CPU temperature

[Dale Shaw]

Hi Rajendra,

On Tue, Dec 1, 2015 at 5:20 PM, Rajendra Maharjan <
rajendra.mahar...@subisu.net.np> wrote:
>
> Is there any SNMP oid that can return value of CPU temperature rather
than RE temperature. I know there is an oid for RE temperature but it would
be very beneficial if I could get CPU temperature value too. Searching
through juniper docs didn't help me either. We may workout with script too
but getting direct OID would be gorgeous.
[...]

I don't have an EX Virtual Chassis handy to test these commands on but
maybe this helps?

dale@ex2200> show snmp mib walk jnxOperatingDescr
jnxOperatingDescr.1.1.0.0
jnxOperatingDescr.2.1.1.0 = Power Supply: Power Supply 0 @ 0/0/*
jnxOperatingDescr.4.1.1.1 = FAN: Fan 1 @ 0/0/0
jnxOperatingDescr.4.1.1.2 = FAN: Fan 2 @ 0/0/1
jnxOperatingDescr.7.1.0.0 = FPC: EX2200-24T-4G @ 0/*/*
jnxOperatingDescr.8.1.1.0 = PIC: 24x 10/100/1000 Base-T @ 0/0/*
jnxOperatingDescr.8.1.2.0 = PIC: 4x GE SFP @ 0/1/*
jnxOperatingDescr.9.1.0.0 = Routing Engine 0

{master:0}
dale@ex2200> show snmp mib walk jnxOperatingTemp
jnxOperatingTemp.1.1.0.0 = 0
jnxOperatingTemp.2.1.1.0 = 0
jnxOperatingTemp.4.1.1.1 = 0
jnxOperatingTemp.4.1.1.2 = 0
jnxOperatingTemp.7.1.0.0 = 31 <-- temperature of FPC
jnxOperatingTemp.8.1.1.0 = 0
jnxOperatingTemp.8.1.2.0 = 0
jnxOperatingTemp.9.1.0.0 = 31 <-- temperature of RE

jnxOperatingTemp.7.1.0.0 == .1.3.6.1.4.1.2636.3.1.13.1.7.7.1.0.0

In a VC, you should see jnxOperatingTemp.7..0.0 being populated
with the per-FPC temperature value.

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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 12:34, john doe wrote:

> Hey guys,
>
> Working on a project here and it's more or less SP focused,
>
> Which is not a muscle I've worked on lately, mostly been doing campus stuff.
>
>
>
> Looking at MX104 vs ASR 9001 as a potential solution.
>
> Requirements are fairly straightforward  - 1GE to collect customers and 10GE 
> going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier 
> NAT.
>
> Customer wants a box that will give them most room to grown in terms of 
> scale/features. And we can't go full modular since rack space is big pain for 
> these guys. Price is also an issue (as usual)
>
> I heard good stuff about Juniper SP gear, while not so complimentary things 
> of ASR. But that was when platform was introduced and they had all sorts of 
> IOS-XR adventures.
>
> Would love to hear some input from here as vendor claims are conflicting 
> (nothing new here I guess)

The MX104 has dual RE's, while the ASR9001 only one RP.

The current MX104 RE's are quite slow, but since they are modular, the
unit could get a quicker one in the future.

The ASR9001 has more capacity (120Gbps) vs. the MX104 which is only 80Gbps.

The MX104 has 4x modular slots while the ASR9001 has only 2x.

The ASR9001 is physically smaller than the MX104, so if rack space is
tight, the Cisco is a better option.

Feature-wise, Junos and IOS XR won't let you down. Your decision factors
are most likely going to be price.

Personally, if you're going to be running policers on LAG's, Junos on
the Trio chipset is better than what Cisco currently have.

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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 13:27, Saku Ytti wrote:

> For either of these NAT is bit awkward, as it's going to have to go
> via separate service card anyhow. Unless you could live with 1:1 NAT,
> but I believe CarrierNAT implies NAPT.
> If all traffic is NAPTed traffic, you might want  to go with ASR1k instead.

Agree - if you want NAT, the ASR1000 is the ideal platform for this.

The ASR1000 line has just got a refresh as well, so from a scaling
perspective, you've got both the low- and high-end options.

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

[j-nsp] Cisco ASR 9001 vs Juniper MX104

[john doe]

Hey guys,

Working on a project here and it's more or less SP focused,

Which is not a muscle I've worked on lately, mostly been doing campus stuff.



Looking at MX104 vs ASR 9001 as a potential solution.

Requirements are fairly straightforward  - 1GE to collect customers and 10GE 
going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier NAT.

Customer wants a box that will give them most room to grown in terms of 
scale/features. And we can't go full modular since rack space is big pain for 
these guys. Price is also an issue (as usual)

I heard good stuff about Juniper SP gear, while not so complimentary things of 
ASR. But that was when platform was introduced and they had all sorts of IOS-XR 
adventures.

Would love to hear some input from here as vendor claims are conflicting 
(nothing new here I guess)



Cheers



p.s.

Anyone with experience on ISSU on these platforms?

I've done some googling and it seems like on both platforms it's dependent upon 
line cards you use.

Plus most of the stuff I found was covering big chassis systems, not the low 
range.





Sent using Zoho Mail






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

Re: [j-nsp] Multi Core on JUNOS?

[Mohan Nanduri]

It's been a while but if my memory serves me correct, we opened ER
(17039) while back to assign tags to interfaces similar to static
routes.

Cheers,
-Mohan


On Wed, Oct 21, 2015 at 5:44 PM, Chad Myers  wrote:
> On Oct 21, 2015, at 3:58 PM, Tarko Tikan  wrote:
>
>> hey,
>>
>>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
>>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K
>>
>> Thats what I had in mind as well.
>
> I'm for that method as well.
>
>
> 
>
> This message may contain confidential information and is intended for 
> specific recipients unless explicitly noted otherwise. If you have reason to 
> believe you are not an intended recipient of this message, please delete it 
> and notify the sender. This message may not represent the opinion of 
> Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and 
> does not constitute a contract or guarantee. Unencrypted electronic mail is 
> not secure and the recipient of this message is expected to provide 
> safeguards from viruses and pursue alternate means of communication where 
> privacy or a binding message is desired.
> ___
> 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] Cisco ASR 9001 vs Juniper MX104

[Saku Ytti]

On 30 November 2015 at 12:34, john doe  wrote:

Hey,

> Looking at MX104 vs ASR 9001 as a potential solution.
>
> Requirements are fairly straightforward  - 1GE to collect customers and 10GE 
> going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier 
> NAT.

For either of these NAT is bit awkward, as it's going to have to go
via separate service card anyhow. Unless you could live with 1:1 NAT,
but I believe CarrierNAT implies NAPT.
If all traffic is NAPTed traffic, you might want  to go with ASR1k instead.

> Customer wants a box that will give them most room to grown in terms of 
> scale/features. And we can't go full modular since rack space is big pain for 
> these guys. Price is also an issue (as usual)
>
> I heard good stuff about Juniper SP gear, while not so complimentary things 
> of ASR. But that was when platform was introduced and they had all sorts of 
> IOS-XR adventures.
>
> Would love to hear some input from here as vendor claims are conflicting 
> (nothing new here I guess)

For ASR9001 and MX104 I would definitely choose MX104. Both boxes have
serious problems, but MX maybe less so. Largest problem MX has is that
it's decoupling route HW insertion and readvertisement in SW+HW, so in
scaled BGP environment you're going to do some blackholing during
convergence. This may be minor inconvenience or major headeache.
HW in MX104 is simpler, as it's fabricless, which I think is very good
thing as long as you can get away with it, distributed architecture is
just harmful.

I think Trio is better story than ASR9k engine story, it's still same
microcode and fundamentally same design from oldest MPC1 to newest
MPC, unlike ASR9k which is making jump to entirely new engine, and
even Trio to EZChip, I think Trio wins.

JunOS and IOS-XR are both terrible in their own way. I have more faith
in JunOS today than in IOS-XR.

JunOS is very conservative, run-to-completion single threaded RPD
(much same design as IOS XE), which in theory requires very very good
code quality to pull it off, and in JunOS the code quality issues
related to run-to-completion flat model manifests as 'RPD slips',
where you might lose your IGP because commit took too long.
IOS-XR is architecturally more modern, but they likely made some
architectural design flaws, as the platform seems to have quite large
amount of state errors. Perhaps Barney was wrong, perhaps newer isn't
always better.

 I think most innovation is to be made in control-plane software.
Everything today is basically awfully fragile hacks.

> Anyone with experience on ISSU on these platforms?

Yes. Don't.

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

Re: [j-nsp] Multi Core on JUNOS?

[Mike Williams]

On Saturday 03 October 2015 02:41:09 Olivier Benghozi wrote:
> I have heard that:
> 1) forget it about PowerPC CPUs (MX 80/104).

As we've got a couple MX104s on the bench waiting for some testing I decided 
to give this a try.
15.1F3, no SMP.

% sysctl hw.ncpu
hw.ncpu: 1
% 


It's also clear you really shouldn't be using this release, so who knows.

--- JUNOS 15.1F3.11 built 2015-10-27 19:44:29 UTC
At least one package installed on this device has limited support.
Run 'file show /etc/notices/unsupported.txt' for details.


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

Re: [j-nsp] Policy Based Routing

[Mattias Gyllenvarg]

Not sure about Juniper but on Cisco PBR does not apply to CPU punted
packets.

So, in most PBR environments you will not be able to reach interfaces
routed in via PBR.
PBR is often counter-intuitive to trouble shoot because it (locally) breaks
most ICMP features.

This may be the expected behavior or not. I can not tell as I don't
understand the purpose of your topology.

mån 23 nov. 2015 kl 22:39 skrev Cahit Eyigünlü :

> Our network Topology as this :
>
>
>
> http://forums.juniper.net/t5/image/serverpage/image-id/12913i3A1C52D8896D0604/image-size/original?v=mpbl-1=-1
> ​
>
>
>
>
> We have an MX80 router which has connection on ae0 to our isp
>
>
>
> root@mx80-core# show interfaces ae0
> aggregated-ether-options {
>  minimum-links 1;
>  lacp {
>  active;
>  periodic fast;
>  }
> }
> unit 0 {
>  family inet {
>  filter {
>  input FWDirect;
>  }
>  address 10.32.35.14/30;
>  }
> }
>
>
> [edit]
> root@mx80-core# show firewall
> filter FWDirect {
> term UDPFW {
> from {
> destination-address {
> 185.9.159.86/32;
> }
> protocol udp;
> }
> then {
> log;
> routing-instance UDP-Routes;
> }
> }
> term TCPFW {
> from {
> destination-address {
> 185.9.159.86/32;
> }
> }
> then {
> count TCPFWTR;
> log;
> routing-instance TCP-Routes;
> }
> }
> term Default {
> then accept;
> }
> }
>
> [edit]
> root@mx80-core# show routing-instances
> Normal-Routes {
> instance-type virtual-router;
> }
> TCP-Routes {
> instance-type forwarding;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 37.123.100.122;
> }
> }
> }
> UDP-Routes {
> instance-type forwarding;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 37.123.100.98;
> }
> }
> }
>
> [edit]
> root@mx80-core# show protocols ospf
> rib-group SPD-Route;
> area 0.0.0.0 {
> interface all;
> interface ae0.0 {
> disable;
> }
> }
>
> [edit]
>
> root@mx80-core# show routing-options rib-groups
> SPD-Route {
> import-rib [ inet.0 UDP-Routes.inet.0 TCP-Routes.inet.0 ];
> }
>
> [edit]
> root@mx80-core#
>
>
>
> The router has connection to routing instance ip addresses and logging the
> connections :
>
>
> root@mx80-core# run ping 37.123.100.122
> PING 37.123.100.122 (37.123.100.122): 56 data bytes
> 64 bytes from 37.123.100.122: icmp_seq=0 ttl=64 time=1.194 ms
> 64 bytes from 37.123.100.122: icmp_seq=1 ttl=64 time=0.956 ms
> ^C
> --- 37.123.100.122 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 0.956/1.075/1.194/0.119 ms
>
> [edit]
> root@mx80-core# run ping 37.123.100.98
> PING 37.123.100.98 (37.123.100.98): 56 data bytes
> 64 bytes from 37.123.100.98: icmp_seq=0 ttl=64 time=0.490 ms
> 64 bytes from 37.123.100.98: icmp_seq=1 ttl=64 time=8.739 ms
> 64 bytes from 37.123.100.98: icmp_seq=2 ttl=64 time=0.422 ms
> ^C
> --- 37.123.100.98 ping statistics ---
> 3 packets transmitted, 3 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 0.422/3.217/8.739/3.905 ms
>
> [edit]
> root@mx80-core# run show firewall log
> Log :
> Time  FilterAction Interface ProtocolSrc Addr
>Dest Addr
> 08:44:20  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:19  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:18  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:17  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:16  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:15  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:14  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:13  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:12  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:11  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:10  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:09  pfe   A  ae0.0 ICMP212.174.232.182
> 185.9.159.86
>
>
>
> but we can not access from outside the network :
>
>
>
> Request timeout for icmp_seq 14714
> 36 bytes from 10.32.35.14: Destination Net Unreachable
> Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
>  4  5  00 5400 938d   0   38  01 d3ad 

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 15:39, Adam Vitkovsky wrote:

> Yes XR is more modern and as a consequence there are a lot of things/features 
> that makes your life easier that I miss in Junos.

If only IOS XR was as easy to upgrade as Junos. All that modularity is
still a pain, even in 2015.

> Technology wise Junos is trailing XR, so any feature introduced into XR is 
> going to be available in Junos only on releases that are more towards the 
> bleeding edge.

This is one of my biggest issues with Junos, particularly in the days of
Junos 10.x.

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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Saku Ytti]

On 30 November 2015 at 15:39, Adam Vitkovsky  wrote:

Hey Adam,

> I think this can be alleviated with BGP provider edge link protection(Cisco 
> BGP PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
> However in Junos this is available only for VRFs.

You'll be happy to hear it got into 15.1 for INET \o/

> That's right Trio's LU is just better, it can cope with any combination of 
> features enabled with only small performance hit compared to A9k's NPU.
> However if QX chip is used the whole LU performance advantage is jeopardized 
> (but at least the degradation is deterministic).

My main woe is not feature parity or inherent capability of
Trio/EZ/nPower, it's more that once JNPR ships something, it'll work
on all Trio kit. Cisco is coming up _really_ good troubleshooting
tooling for ASR9k, but they'll arrive at different pace (or maybe not
at all) at different engines, which is completely understandable for
this low-level stuff.

> Also the basic Junos documentation is incomplete and getting some deep level 
> information is next to impossible.

ACK. This is not mentioned often enough, Cisco is doing pretty good
job in documents.

> And what about ASR903 it's very similar product to MX104.

Dunno, I'd say it's more similar to ACX1k, both are running BRCM
Enduro? Looking forward to Waris' webinar.

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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Payam Chychi]

Asr1000 line are solid if needed for nat 

-- 
Payam Chychi
Solution Architect 


On Monday, November 30, 2015 at 5:57 AM, Saku Ytti wrote:

> On 30 November 2015 at 15:39, Adam Vitkovsky  
> wrote:
> 
> Hey Adam,
> 
> > I think this can be alleviated with BGP provider edge link protection(Cisco 
> > BGP PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
> > However in Junos this is available only for VRFs.
> > 
> 
> 
> You'll be happy to hear it got into 15.1 for INET \o/
> 
> > That's right Trio's LU is just better, it can cope with any combination of 
> > features enabled with only small performance hit compared to A9k's NPU.
> > However if QX chip is used the whole LU performance advantage is 
> > jeopardized (but at least the degradation is deterministic).
> > 
> 
> 
> My main woe is not feature parity or inherent capability of
> Trio/EZ/nPower, it's more that once JNPR ships something, it'll work
> on all Trio kit. Cisco is coming up _really_ good troubleshooting
> tooling for ASR9k, but they'll arrive at different pace (or maybe not
> at all) at different engines, which is completely understandable for
> this low-level stuff.
> 
> > Also the basic Junos documentation is incomplete and getting some deep 
> > level information is next to impossible.
> 
> ACK. This is not mentioned often enough, Cisco is doing pretty good
> job in documents.
> 
> > And what about ASR903 it's very similar product to MX104.
> 
> Dunno, I'd say it's more similar to ACX1k, both are running BRCM
> Enduro? Looking forward to Waris' webinar.
> 
> -- 
> ++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

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Adam Vitkovsky]

Hi,

> Saku Ytti
> Sent: Monday, November 30, 2015 11:28 AM
> For ASR9001 and MX104 I would definitely choose MX104. Both boxes have
> serious problems, but MX maybe less so. Largest problem MX has is that it's
> decoupling route HW insertion and readvertisement in SW+HW, so in scaled
> BGP environment you're going to do some blackholing during convergence.
> This may be minor inconvenience or major headeache.
I think this can be alleviated with BGP provider edge link protection(Cisco BGP 
PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
However in Junos this is available only for VRFs.

> HW in MX104 is simpler, as it's fabricless, which I think is very good thing 
> as
> long as you can get away with it, distributed architecture is just harmful.
>
> I think Trio is better story than ASR9k engine story, it's still same 
> microcode
> and fundamentally same design from oldest MPC1 to newest MPC, unlike
> ASR9k which is making jump to entirely new engine, and even Trio to EZChip,
> I think Trio wins.
That's right Trio's LU is just better, it can cope with any combination of 
features enabled with only small performance hit compared to A9k's NPU.
However if QX chip is used the whole LU performance advantage is jeopardized 
(but at least the degradation is deterministic).

> JunOS and IOS-XR are both terrible in their own way. I have more faith in
> JunOS today than in IOS-XR.
>
> JunOS is very conservative, run-to-completion single threaded RPD (much
> same design as IOS XE), which in theory requires very very good code quality
> to pull it off, and in JunOS the code quality issues related to run-to-
> completion flat model manifests as 'RPD slips', where you might lose your
> IGP because commit took too long.
Or you get random convergence times when adding links to bundle.

> IOS-XR is architecturally more modern, but they likely made some
> architectural design flaws, as the platform seems to have quite large amount
> of state errors. Perhaps Barney was wrong, perhaps newer isn't always
> better.
>
>  I think most innovation is to be made in control-plane software.
> Everything today is basically awfully fragile hacks.
>
Yes XR is more modern and as a consequence there are a lot of things/features 
that makes your life easier that I miss in Junos.
Technology wise Junos is trailing XR, so any feature introduced into XR is 
going to be available in Junos only on releases that are more towards the 
bleeding edge.
Also the basic Junos documentation is incomplete and getting some deep level 
information is next to impossible.

> > Anyone with experience on ISSU on these platforms?
>
> Yes. Don't.
>
Yeah the only platform out there that promises working ISSU are the NCS series 
from Cisco, but would love to hear the real world stories.


And what about ASR903 it's very similar product to MX104.

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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