Re: [j-nsp] ex4500 snmp temperature zero
You see zero because it is NOT supported on EX4500 platform. regards, Phuong On Tue, Nov 12, 2013 at 6:09 AM, ryanL ryan.lan...@gmail.com wrote: heya list, anyone know if this is a bug? i've tried restarting snmp and shm-rtsdbd but no success. i can't access juniper.net at the moment to research. service unavailable Hostname: fs-cs2 Model: ex4500-40f JUNOS Base OS boot [12.3R2.5] JUNOS Base OS Software Suite [12.3R2.5] JUNOS Kernel Software Suite [12.3R2.5] JUNOS Crypto Software Suite [12.3R2.5] JUNOS Online Documentation [12.3R2.5] JUNOS Enterprise Software Suite [12.3R2.5] JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R2.5] JUNOS Routing Software Suite [12.3R2.5] JUNOS Web Management [12.3R2.5] JUNOS FIPS mode utilities [12.3R2.5] # snmpwalk -v 2c -c blah fs-cs2 JUNIPER-MIB::jnxOperatingTemp JUNIPER-MIB::jnxOperatingTemp.1.1.0.0 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.2.1.1.0 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.2.1.2.0 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.4.1.1.1 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.4.1.1.2 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.4.1.1.3 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.4.1.1.4 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.4.1.1.5 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.7.1.0.0 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.8.1.1.0 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.8.1.4.0 = Gauge32: 0 JUNIPER-MIB::jnxOperatingTemp.9.1.0.0 = Gauge32: 0 ___ 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] RIB - FIB filtering.
Hi, I think no one made an argument for not doing it that way.. I will deploy the RIB-FIB filtering tomorrow morning during our maintenance window, i hope everything goes well. Thank you all for your input. Kind regards, Peter Krüpl ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M-series IPSEC / SP interface and VRF
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where the
local gateway is NOT in the same routing-instance as the service
interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around this?
The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M-series IPSEC / SP interface and VRF
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where the
local gateway is NOT in the same routing-instance as the service
interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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] M-series IPSEC / SP interface and VRF
Alex,
Yea, tried this but it looks like you can't set it to the default inet.0
instance, only to things different... the local gw in my case is in the
default instance and I want the service interface in another so unless
I'm mistaken it's in default by default and this fails?
Scott H.
On 11/12/13, 11:22 AM, Alex Arseniev wrote:
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where the
local gateway is NOT in the same routing-instance as the service
interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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] M-series IPSEC / SP interface and VRF
So, if I understand Your requirement, You want sp-0/0/0.unit in VRF,
correct?
And outgoing GE interface in inet.0?
And where the decrypted packets should be placed, inet.0 or VRF?
And where from the to-be-ecrypted packets should arrive, from inet.0 or VRF?
If the answer is correct/inet.0/VRF/VRF then migrate to next-hop-style
IPSec and place inside sp-* unit into the VRF leaving outside sp-* unit
in inet.0.
HTH
Thanks
Alex
On 12/11/2013 16:35, Scott Harvanek wrote:
Alex,
Yea, tried this but it looks like you can't set it to the default
inet.0 instance, only to things different... the local gw in my case
is in the default instance and I want the service interface in another
so unless I'm mistaken it's in default by default and this fails?
Scott H.
On 11/12/13, 11:22 AM, Alex Arseniev wrote:
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where
the local gateway is NOT in the same routing-instance as the
service interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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] M-series IPSEC / SP interface and VRF
Yep excellent, I'll give it a whirl, thanks!
Scott H.
On 11/12/13, 1:24 PM, Alex Arseniev wrote:
So, if I understand Your requirement, You want sp-0/0/0.unit in VRF,
correct?
And outgoing GE interface in inet.0?
And where the decrypted packets should be placed, inet.0 or VRF?
And where from the to-be-ecrypted packets should arrive, from inet.0
or VRF?
If the answer is correct/inet.0/VRF/VRF then migrate to
next-hop-style IPSec and place inside sp-* unit into the VRF leaving
outside sp-* unit in inet.0.
HTH
Thanks
Alex
On 12/11/2013 16:35, Scott Harvanek wrote:
Alex,
Yea, tried this but it looks like you can't set it to the default
inet.0 instance, only to things different... the local gw in my case
is in the default instance and I want the service interface in
another so unless I'm mistaken it's in default by default and this
fails?
Scott H.
On 11/12/13, 11:22 AM, Alex Arseniev wrote:
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where
the local gateway is NOT in the same routing-instance as the
service interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. On 8 November 2013 16:46, Paul Nazario naza...@doit.wisc.edu wrote: That is what we've heard and they have the following two items in their $USD list pricing: S-MX104-UPG-2X10GE Upgrade License to activate 2 x 10GE fixed ports on MX104 MX104 $10,000 S-MX104-UPG-4X10GE Upgrade License to activate 4 x 10GE fixed ports on MX104 MX104 $18,000 On Nov 5, 2013, at 1:16 PM, Nicolaj Kamensek n...@accelerated.de wrote: Hi everybody, anybody had a chance yet to put their hands on the new MX104? According to Juniper the 4 10G ports on-board are software locked this time but I'd like to have a confirmation for that from an actual experience. 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It’s one of those things where you work with account team. if the commercial terms don’t work out for most potential buyers, then the product won’t be successful and either things will change or they won’t. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp signature.asc Description: Message signed with OpenPGP using GPGMail ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Procedure to add a NPC to SRX HA cluster
can anyone recommend a procedure to add an NPC card to an SRX HA (active/standby) cluster? In this case it's a pair of SRX3400s, running 12.1X44-D10.4 I've only got two redundancy groups, RG0(control) and RG1(data). Currently the only NPC in each SRX is the integrated NPC-IOC 10GbE card in each chassis Node0 is primary for both RG0 and RG1. I'm not currently running any dynamic routing protocols. There are some Policy based VPNs, ALGs and NATs in place. Can I do something like the following? * power down node 1, install the NPC, boot up and verify status * manually fail RG1 to node1 via request chassis cluster failover * manually fail RG0 to node1 via request chassis cluster failover (is the best way to do this?) * power down node 1, install NPC, boot up and verify status * fail both RG1 and RG0 back to node0 JTAC's first response was to follow this guide: http://kb.juniper.net/InfoCenter/index?page=contentid=KB26674 which seems overly complicated and possibly not applicable. It seems to deal with the case of wanting to move a live SPC from one slot to another. They say it applies to an NPC- but I'm not moving a live NPC, I'm inserting a new one. thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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] Juniper MX104
My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ 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 MX104
Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
Anyone have have a ball park figure of what the MS-MIC will cost? On Wed, Nov 13, 2013 at 4:04 PM, Ben Dale bd...@comlinx.com.au wrote: MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX104
Isn't that using the front MIC slot though? The rear 'Services Slot' is an MPC slot isn't it? Based on the following: MS-MIC 16G - MS-MIC with 16 GB of memory provides 9GB of service throughput, occupies single MIC slot on MX5, MX10, MX40, and MX80 3D Universal Edge Routers, as well as on the MPC1, MPC2, and MPC3 cards for the MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Router. MS-MPC-128 - MS-MPC with 128 GB of memory (32 GB per NPU), provides 60Gbps of service throughput, occupies a single slot in MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Routers The rear picture of the MX80 at http://www.juniper.net/shared/img/products/mx-series/mx80/mx80-rear-high.jpg Says MPC 0 and MIC 1 in smaller writing under it. From front right slot is also called 1/MIC 1 I think we need further clarification. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 4:04 PM, Ben Dale bd...@comlinx.com.au wrote: MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where
Re: [j-nsp] Juniper MX104
Yeah, my take on that is that MPC0 is pretty much anything built-in on the MX5/80 - eg: the front 10G ports are xe-0/0/0 My guess is that the rear slot is just another MIC slot (slot 1) MPC 0 so something like sp-0/1/0 or whatever designation gets used. The front MIC slots are ge-1/0/0-19 and ge-1/1/0-19 etc. On 13 Nov 2013, at 3:33 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Isn't that using the front MIC slot though? The rear 'Services Slot' is an MPC slot isn't it? Based on the following: MS-MIC 16G - MS-MIC with 16 GB of memory provides 9GB of service throughput, occupies single MIC slot on MX5, MX10, MX40, and MX80 3D Universal Edge Routers, as well as on the MPC1, MPC2, and MPC3 cards for the MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Router. MS-MPC-128 - MS-MPC with 128 GB of memory (32 GB per NPU), provides 60Gbps of service throughput, occupies a single slot in MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Routers The rear picture of the MX80 at http://www.juniper.net/shared/img/products/mx-series/mx80/mx80-rear-high.jpg Says MPC 0 and MIC 1 in smaller writing under it. From front right slot is also called 1/MIC 1 I think we need further clarification. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 4:04 PM, Ben Dale bd...@comlinx.com.au wrote: MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would
Re: [j-nsp] Juniper MX104
The datasheet for the MX-104 ( http://www.juniper.net/us/en/local/pdf/datasheets/1000446-en.pdf ) has the MIC listed: MS-MIC-16G Multiservices MIC with 16GB of memory for the MX5, MX10, MX40, MX80 and MX104 as well as Type 1, Type 2, Type 3 and Type 4 MPCs for the MX240, MX480, MX960, MX2010 and MX2020. supports separately licensed Junos Address Aware (CGNAT); Junos Traffic vision (flow monitoring) Junos vPN Site Secure (IPsec) and Junos Network Secure (Stateful Firewall) No mention of MPC anywhere. On 13.11.2013 16:33, Skeeve Stevens wrote: Isn't that using the front MIC slot though? The rear 'Services Slot' is an MPC slot isn't it? Based on the following: MS-MIC 16G - MS-MIC with 16 GB of memory provides 9GB of service throughput, occupies single MIC slot on MX5, MX10, MX40, and MX80 3D Universal Edge Routers, as well as on the MPC1, MPC2, and MPC3 cards for the MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Router. MS-MPC-128 - MS-MPC with 128 GB of memory (32 GB per NPU), provides 60Gbps of service throughput, occupies a single slot in MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Routers The rear picture of the MX80 at http://www.juniper.net/shared/img/products/mx-series/mx80/mx80-rear-high.jpg Says MPC 0 and MIC 1 in smaller writing under it. From front right slot is also called 1/MIC 1 I think we need further clarification. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 4:04 PM, Ben Dale bd...@comlinx.com.au wrote: MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive.
Re: [j-nsp] Juniper MX104
Scaling on the MX80 is supposed to be 16,000 per chassis, 8,000 per MIC and 4,000 per PIC and a 8,000 limit on PPPoE sessions. In order to max out you need 2 MICs loaded with at least 1 port per PIC active for subscriber term at up to 4k per. Also, vlan units and PPPoE units both count as a sub... So if doing uniq stacked tag combo per sub w/ PPPoE you are using a unit at both the vlan and pppoe level per sub and when you hit the 8k limit you are also out of interfaces. I have not personally seen a MX80 with that many active subs yet, will have to see if things run out of juice before the hard limits are reached. On 11/12/13 7:52 PM, Skeeve Stevens wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp --
Re: [j-nsp] Juniper MX104
On (2013-11-12 20:25 -0500), Eric Van Tol wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. It is annoying. As far as I know there is absolutely no technical reason why the chassis ports couldn't use QX. Only reason I can think of why they did that was to avoid grossly oversubscribing QX chip. QX was dimensioned for MPC use-case, where you have 40G WAN and 40G fabric, so 40G was absolute maximum you'd need. With MX80 and MX104, ports sit where fabric should be, so you have doubled your demand for QX capacity. QX performance is somewhere between 20Gbps (small packets) to 38Gbps (large packets). And as far as I know this gets halved if you enable ingress and egress shaping, so you might be looking as poor performance as 10Gbps. So maybe some PM thought it would be giving too much rope to customers to allow enabling it on 8x10GE ports? -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
