Mailing List Archive

MX204 vs. MX240??
I wanted to resurrect an old thread about the MX204, from a year and a
half ago:

https://lists.gt.net/nsp/juniper/64290

My understanding is that the MX204 is a 1 RU MPC7, but with a few
modifications. I understand that the eight 10Gig ports have been modified
to allow for 1 Gig transceivers as well, and perhaps that the QSFP ports
can accommodate a pigtail for providing a bunch of 1 Gig connections, if
necessary.

The 10/40/100 capabilities of the MPC7 look great, but there are few
isolated cases where I need to support legacy 1 gig, and the MX204 can now
handle that. Is this true?

Also, I understand that the MX204 CPU and other resources are a vast
improvement over the MX80, and that the MX204 can handle multiple full
Internet route BGP feeds, just as well as the MX240 REs can, without
compromise in performance.

The newer VM support inside the RE makes the requirements for an
additional RE less important now, according to my understanding.

So, if you do not need a lot of speeds and feeds, and can live without a
physical backup RE, the MX204 would be a good alternative to a MX240.

Have I made accurate assumptions??


Clarke Morledge
Network Engineering
Information Technology
Jones Hall (Room 18)
200 Ukrop Way
Williamsburg VA 23187
William & Mary
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Yes

MX204 is a super router !!!

Very impressive about its performance


* Forwarding plane and control plane performance

A lot of memory for rib and fib and bng too

It is the best router from the last years from Juniper.

Hope that they create a new release ( sane success ) using MPC10 pizza box with 8 and 16 x 100G pretty soon

Att

Giuliano


Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> on behalf of Clarke Morledge <chmorl@wm.edu>
Sent: Friday, November 8, 2019 1:39:26 PM
To: juniper-nsp@puck.nether.net <juniper-nsp@puck.nether.net>
Subject: [j-nsp] MX204 vs. MX240??

I wanted to resurrect an old thread about the MX204, from a year and a
half ago:

https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gt.net%2Fnsp%2Fjuniper%2F64290&amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7C5851804d4a6b4bf67b4008d7646a5aaa%7C584787b077bd4312bf8815412b8ae504%7C1%7C1%7C637088280276647570&amp;sdata=wjPk9CFlTh1y1h0FaOLThm658jgEnjd7kBIc9qQ3Sps%3D&amp;reserved=0

My understanding is that the MX204 is a 1 RU MPC7, but with a few
modifications. I understand that the eight 10Gig ports have been modified
to allow for 1 Gig transceivers as well, and perhaps that the QSFP ports
can accommodate a pigtail for providing a bunch of 1 Gig connections, if
necessary.

The 10/40/100 capabilities of the MPC7 look great, but there are few
isolated cases where I need to support legacy 1 gig, and the MX204 can now
handle that. Is this true?

Also, I understand that the MX204 CPU and other resources are a vast
improvement over the MX80, and that the MX204 can handle multiple full
Internet route BGP feeds, just as well as the MX240 REs can, without
compromise in performance.

The newer VM support inside the RE makes the requirements for an
additional RE less important now, according to my understanding.

So, if you do not need a lot of speeds and feeds, and can live without a
physical backup RE, the MX204 would be a good alternative to a MX240.

Have I made accurate assumptions??


Clarke Morledge
Network Engineering
Information Technology
Jones Hall (Room 18)
200 Ukrop Way
Williamsburg VA 23187
William & Mary
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&amp;data=02%7C01%7Cgiuliano%40wztech.com.br%7C5851804d4a6b4bf67b4008d7646a5aaa%7C584787b077bd4312bf8815412b8ae504%7C1%7C1%7C637088280276657565&amp;sdata=OSwj4%2FSOHmXpeUyM8csMQ4kOs0aG5eRxplvovdzdhLg%3D&amp;reserved=0

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Yes, since 18.1 the MX204 can be configured to support 1G:
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html

IMHO its hard to compare MX204 vs MX240, they are made for different markets. MX240 can be redundant, MX204 cant.

As for the RE it can keep up with current line modular RE's for the MX240.

-Jonas
Am Freitag, den 08.11.2019, 11:39 -0500 schrieb Clarke Morledge:
> I wanted to resurrect an old thread about the MX204, from a year and a?
> half ago:
>
> https://lists.gt.net/nsp/juniper/64290
>
> My understanding is that the MX204 is a 1 RU MPC7, but with a few?
> modifications. I understand that the eight 10Gig ports have been modified?
> to allow for 1 Gig transceivers as well, and perhaps that the QSFP ports?
> can accommodate a pigtail for providing a bunch of 1 Gig connections, if?
> necessary.
>
> The 10/40/100 capabilities of the MPC7 look great, but there are few?
> isolated cases where I need to support legacy 1 gig, and the MX204 can now?
> handle that. Is this true?
>
> Also, I understand that the MX204 CPU and other resources are a vast?
> improvement over the MX80, and that the MX204 can handle multiple full?
> Internet route BGP feeds, just as well as the MX240 REs can, without?
> compromise in performance.
>
> The newer VM support inside the RE makes the requirements for an?
> additional RE less important now, according to my understanding.
>
> So, if you do not need a lot of speeds and feeds, and can live without a?
> physical backup RE, the MX204 would be a good alternative to a MX240.
>
> Have I made accurate assumptions??
>
>
> Clarke Morledge
> Network Engineering
> Information Technology
> Jones Hall (Room 18)
> 200 Ukrop Way
> Williamsburg VA 23187
> William & Mary
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On 8/Nov/19 18:39, Clarke Morledge wrote:

>  
>
> So, if you do not need a lot of speeds and feeds, and can live without
> a physical backup RE, the MX204 would be a good alternative to a MX240.

Our use-case for the MX204 is:

    - 10Gbps capability in the Metro. Hardware redundancy not necessary,
as revenues don't justify it.
    - Peering and transit routers. Multiple entry/exit points, so
hardware redundancy is not necessary.

Our use-case for the MX480 (MX204 is too small):

    - High-touch edge services for customers.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
> Clarke Morledge
> Sent: Friday, November 8, 2019 4:39 PM
>
> I wanted to resurrect an old thread about the MX204, from a year and a
half
> ago:
>
> https://lists.gt.net/nsp/juniper/64290
>
> My understanding is that the MX204 is a 1 RU MPC7, but with a few
> modifications.
Yup, so be aware of the reboot requirements if you change the layout of the
card/mx204

> I understand that the eight 10Gig ports have been modified to
> allow for 1 Gig transceivers as well,
Yup

> and perhaps that the QSFP ports can
> accommodate a pigtail for providing a bunch of 1 Gig connections, if
> necessary.
>
Haven't looked so don't know

> The 10/40/100 capabilities of the MPC7 look great, but there are few
isolated
> cases where I need to support legacy 1 gig, and the MX204 can now handle
> that. Is this true?
>
Yup on the 10g for sure, but if you need 1G in volume you can pair it with a
simple 1RU switch.

> Also, I understand that the MX204 CPU and other resources are a vast
> improvement over the MX80,
Anything is better than those old CPUs.

> and that the MX204 can handle multiple full
> Internet route BGP feeds, just as well as the MX240 REs can, without
> compromise in performance.
>
Yup

> The newer VM support inside the RE makes the requirements for an
> additional RE less important now, according to my understanding.
>
The short answer is it's complicated.
You got to compare the probabilities of different failure scenarios,
probabilities of brown failures and see if it's worth spending a significant
extra for a resilient RE, ideally you'd just use 204s in pairs if necessary.


> So, if you do not need a lot of speeds and feeds, and can live without a
> physical backup RE, the MX204 would be a good alternative to a MX240.
>
If you run the numbers you'll see that the mx240 even with half licensed
mpc7 cards has a significantly higher CAPEX&OPEX per revenue port.


adam


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
> > The 10/40/100 capabilities of the MPC7 look great, but there are few
> isolated
> > cases where I need to support legacy 1 gig, and the MX204 can now handle
> > that. Is this true?
> >
> Yup on the 10g for sure, but if you need 1G in volume you can pair it with a
> simple 1RU switch.

Yep, we pair 2 x MX204s with 2 x EX4300s for 1G optics and higher.

Just migrating from a pair of MX5's to this set up.

> The short answer is it's complicated.
> You got to compare the probabilities of different failure scenarios,
> probabilities of brown failures and see if it's worth spending a significant
> extra for a resilient RE, ideally you'd just use 204s in pairs if necessary.

As above. Recommended.

For pricing, a license to light up a 10GB port on an MX5 was the same
price as buying a MX204....
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
> Giuliano C. Medalha
> Sent: Friday, November 8, 2019 4:48 PM
>
> Yes
>
> MX204 is a super router !!!
>
> Very impressive about its performance
>
>
> * Forwarding plane and control plane performance
>
We didn't have it on our testbench yet but we did have MPC7 on there and
were not impressed at all.
Don't get me wrong MPC7 will forward packets alright, it's just if you get a
bit harsh with he packet size or filters (pick your poison) it will start to
crumble, but so does the was majority of cards that offer 100G ports out
there.
Now MPC3-NG that's a very impressive performance (overpowered even) a true
workhorse!

adam


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Hello,

this is really interesting.

We have a MX204 (Fusion AD, running Junos 18.4R1) + EX4300 (Fusion SD)
running and found out you cannot set the port speed on the RJ45 ports of
the EX4300 in that combination.
We discussed this 3 months because Juniper wanted to tell us that this is
by design because MX204 has no ports with variable speed and therefore
disabled the "speed" knob in Junos 17.4 for MX204.
They still did not provide a solution.

If you do not use Fusion and you do not want to change the port speed of
the QSFP ports (this requires a restart of the pic, not a full reload, so
the 10GBit stay online) the MX204 is great (really fast, commits nearly
instant).

If you really need RJ45 copper ports that are not switched and have that
one or 2 customers that only work with 100MBit fdx w/o autoneg, think
about buying MX204 + MPC1 + RJ45 MIC.

kind regards
Rolf

> Yes, since 18.1 the MX204 can be configured to support 1G:
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html
>


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Re: MX204 vs. MX240?? [ In reply to ]
Hello Gavin,

no, you cannot configured Fusion fpcs that way.

regards
Rolf

> Can't you do:
>
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-on-mx204-to-enable-different-port-speeds
>


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
We evaluated the 204. It met our current needs for port density, but not future. A sweet upgrade path from an 80 or 104 though!

Pay close attention to the port allocations. They’re a slight puzzle:

https://apps.juniper.net/home/port-checker/index.html

-b


> On Nov 8, 2019, at 08:40, Clarke Morledge <chmorl@wm.edu> wrote:
>
> ?I wanted to resurrect an old thread about the MX204, from a year and a half ago:
>
> https://lists.gt.net/nsp/juniper/64290
>
> My understanding is that the MX204 is a 1 RU MPC7, but with a few modifications. I understand that the eight 10Gig ports have been modified to allow for 1 Gig transceivers as well, and perhaps that the QSFP ports can accommodate a pigtail for providing a bunch of 1 Gig connections, if necessary.
>
> The 10/40/100 capabilities of the MPC7 look great, but there are few isolated cases where I need to support legacy 1 gig, and the MX204 can now handle that. Is this true?
>
> Also, I understand that the MX204 CPU and other resources are a vast improvement over the MX80, and that the MX204 can handle multiple full Internet route BGP feeds, just as well as the MX240 REs can, without compromise in performance.
>
> The newer VM support inside the RE makes the requirements for an additional RE less important now, according to my understanding.
>
> So, if you do not need a lot of speeds and feeds, and can live without a physical backup RE, the MX204 would be a good alternative to a MX240.
>
> Have I made accurate assumptions??
>
>
> Clarke Morledge
> Network Engineering
> Information Technology
> Jones Hall (Room 18)
> 200 Ukrop Way
> Williamsburg VA 23187
> William & Mary
> _______________________________________________
> 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: MX204 vs. MX240?? [ In reply to ]
I'll preface this by saying that the MX204 is a great box, and fits many a
niche quite well... However:

On Fri, 8 Nov 2019, Clarke Morledge wrote:

> My understanding is that the MX204 is a 1 RU MPC7, but with a few
> modifications.

More or less -- it's an RE glued to the non-fabric-facing parts of the
MPC7, which tends to tickle some "interesting" corner cases in code that
assumes there's a fabric chip present.

> I understand that the eight 10Gig ports have been modified to
> allow for 1 Gig transceivers as well, and perhaps that the QSFP ports can
> accommodate a pigtail for providing a bunch of 1 Gig connections, if
> necessary.

You can run 1G optical transceivers in the 8x SFP+ slots, if necessary...

Don't.

Seriously, don't. The initial code in 17.4 refused to light them at all,
and seems to have been haphazardly gutted of all config/op statements
related to 1G optics. 18.1R3 is necessary to support them at all, and
they show up as xe- interfaces only, half the config is hidden and the
other half refuses to commit, they have a lot of weird problems with rate
negotiation, and they don't work in bundles unless you really beat on the
other end to convince it to bring up the aggregate.

Just pair the 204 up with a cheap switch... Whether you want to get crazy
and run Fusion is another matter.

> Also, I understand that the MX204 CPU and other resources are a vast
> improvement over the MX80, and that the MX204 can handle multiple full
> Internet route BGP feeds, just as well as the MX240 REs can, without
> compromise in performance.

Yup, plenty of memory and CPU to play with, it'll do 10M routes without
batting an eye.

> The newer VM support inside the RE makes the requirements for an additional
> RE less important now, according to my understanding.

Again more or less -- ISSU between VMs works reasonably well, but Juniper
has walked back the original claims of "never needing to upgrade the
hypervisor" quite a bit since these were released. I've been doing full
vmhost upgrades every time to minimize surprises. Need a pair for real
redundancy, anyway...

> So, if you do not need a lot of speeds and feeds, and can live without a
> physical backup RE, the MX204 would be a good alternative to a MX240.

You'll also need to be willing to run relatively recent software if you
want to do anything beyond basic layer 3. I had 3 MX204-specific PRs on
18.1R3 that led to running 18.4R1-S4 now -- and have 5 new SRs open
against that code. Your mileage may vary...

-Rob




_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Hey,

> More or less -- it's an RE glued to the non-fabric-facing parts of the
> MPC7, which tends to tickle some "interesting" corner cases in code that
> assumes there's a fabric chip present.

I don't think RE connects atypically in MX204. RE is ETH+PCI
connected, not fabric.

Can you elaborate on the corner cases?

It is true that MX204 is fabricless, like MX80 was. Which ostensibly
is a good thing,
as you could use both fab+wan serdes purely for wan, doubling the wan
density while
halving the average lookup and buffer delay performance

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Funny thing about the (8) sfp+ ports which do 1/10 gig... when you config a
port for 1 gig, it still is referenced as "xe" ! ... not "ge" as you would
expect. :|

agould@site1-204-1> show system information
Model: mx204
Family: junos
Junos: 18.4R1-S3.1
Hostname: site1-204-1

agould@site1-204-1> show configuration interfaces xe-0/1/4 | display set
set interfaces xe-0/1/4 description site1-nid-1
set interfaces xe-0/1/4 flexible-vlan-tagging
set interfaces xe-0/1/4 mtu 9216
set interfaces xe-0/1/4 encapsulation flexible-ethernet-services
set interfaces xe-0/1/4 gigether-options speed 1g
<---------------- this is how to switch it to 1 gig
set interfaces xe-0/1/4 unit 100 encapsulation vlan-vpls
set interfaces xe-0/1/4 unit 100 vlan-id 100

...look how funny, speed says 10gbps (not, ha).... but speed config says
1G.....

agould@site1-204-1> show interfaces xe-0/1/4 media | grep speed
Link-level type: Flexible-Ethernet, MTU: 9216, MRU: 9224, LAN-PHY mode,
Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None, MAC-REWRITE
Error: None, Loopback: None, Source filtering: Disabled, Flow control:
Enabled,
Speed Configuration: 1G

....It's linked up to a device which only does 1 gig, so, it's working...

agould@dallas-204-1> show interfaces terse xe-0/1/4
Interface Admin Link Proto Local Remote
xe-0/1/4 up up
xe-0/1/4.100 up up vpls
xe-0/1/4.32767 up up multiservice

agould@dallas-204-1> show chassis fpc pic-status
Slot 0 Online MPC
PIC 0 Online 4XQSFP28 PIC
PIC 1 Online 8XSFPP PIC



- Aaron


-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
Clarke Morledge
Sent: Friday, November 8, 2019 8:39 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX204 vs. MX240??

I wanted to resurrect an old thread about the MX204, from a year and a
half ago:

https://lists.gt.net/nsp/juniper/64290

My understanding is that the MX204 is a 1 RU MPC7, but with a few
modifications. I understand that the eight 10Gig ports have been modified
to allow for 1 Gig transceivers as well, and perhaps that the QSFP ports
can accommodate a pigtail for providing a bunch of 1 Gig connections, if
necessary.

The 10/40/100 capabilities of the MPC7 look great, but there are few
isolated cases where I need to support legacy 1 gig, and the MX204 can now
handle that. Is this true?

Also, I understand that the MX204 CPU and other resources are a vast
improvement over the MX80, and that the MX204 can handle multiple full
Internet route BGP feeds, just as well as the MX240 REs can, without
compromise in performance.

The newer VM support inside the RE makes the requirements for an
additional RE less important now, according to my understanding.

So, if you do not need a lot of speeds and feeds, and can live without a
physical backup RE, the MX204 would be a good alternative to a MX240.

Have I made accurate assumptions??


Clarke Morledge
Network Engineering
Information Technology
Jones Hall (Room 18)
200 Ukrop Way
Williamsburg VA 23187
William & Mary
_______________________________________________
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: MX204 vs. MX240?? [ In reply to ]
We deployed the MX204 in pairs in 2 new markets that we entered into
recently... Houston and Dallas... the MX204 presents itself as a small and
relatively inexpensive but with nice port and feature versatility with its
MX capabilities.

We decided to roll them out with (2) 100g, (2) 40g, (4) 10g and (4) 1g...and
link them together with a 100g DAC cable

Btw, the MX204 defaults as a all-10gig interface box.. in its default
state...

[edit]
root# run show interfaces terse | grep "^et|^xe|^ge"
xe-0/0/0:0 up down
xe-0/0/0:1 up down
xe-0/0/0:2 up down
xe-0/0/0:3 up down
xe-0/0/1:0 up down
xe-0/0/1:1 up down
xe-0/0/1:2 up down
xe-0/0/1:3 up down
xe-0/0/2:0 up down
xe-0/0/2:1 up down
xe-0/0/2:2 up down
xe-0/0/2:3 up down
xe-0/0/3:0 up down
xe-0/0/3:1 up down
xe-0/0/3:2 up down
xe-0/0/3:3 up down
xe-0/1/0 up down
xe-0/1/1 up down
xe-0/1/2 up down
xe-0/1/3 up down
xe-0/1/4 up down
xe-0/1/5 up down
xe-0/1/6 up down
xe-0/1/7 up down

[edit]
root# run show interfaces terse | grep "^et|^xe|^ge" | count
Count: 24 lines


....so to achieve port speed that you want, this is what we did.


set chassis fpc 0 pic 0 port 0 speed 100g
set chassis fpc 0 pic 0 port 1 speed 100g
set chassis fpc 0 pic 0 port 2 speed 40g
set chassis fpc 0 pic 0 port 3 speed 40g

set chassis fpc 0 pic 1 port 0 speed 10g
set chassis fpc 0 pic 1 port 1 speed 10g
set chassis fpc 0 pic 1 port 2 speed 10g
set chassis fpc 0 pic 1 port 3 speed 10g
set chassis fpc 0 pic 1 port 4 speed 10g
set chassis fpc 0 pic 1 port 5 speed 10g
set chassis fpc 0 pic 1 port 6 speed 10g
set chassis fpc 0 pic 1 port 7 speed 10g

Verify. after.


root> show interfaces terse | grep "^et|^xe|^ge" | count
Count: 12 lines

root> show interfaces terse | grep "^et|^xe|^ge"
et-0/0/0 up down
et-0/0/1 up down
et-0/0/2 up down
et-0/0/3 up down
xe-0/1/0 up down
xe-0/1/1 up down
xe-0/1/2 up down
xe-0/1/3 up down
xe-0/1/4 up down
xe-0/1/5 up down
xe-0/1/6 up down
xe-0/1/7 up down

...then to get the (4) 1g that we wanted...

set interfaces xe-0/1/4 gigether-options speed 1g
set interfaces xe-0/1/5 gigether-options speed 1g
set interfaces xe-0/1/6 gigether-options speed 1g
set interfaces xe-0/1/7 gigether-options speed 1g


- Aaron

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On Sun, 10 Nov 2019, Saku Ytti wrote:

>> More or less -- it's an RE glued to the non-fabric-facing parts of the
>> MPC7, which tends to tickle some "interesting" corner cases in code that
>> assumes there's a fabric chip present.
>
> I don't think RE connects atypically in MX204. RE is ETH+PCI
> connected, not fabric.

Atypical only in that there's no chassis switch involved on the Ethernet
link... The comment above was about software catching up to what's
(functionally) missing from the line card, in this case.

PR1444186 -- GRE packets which are larger than MTU get dropped on MX204
platforms when sampling is enabled on the egress interface -- was a fun
one, and as it happens an MX80 was used to demonstrate that the issue was
specific to MX204. There's a not-yet-public follow up for that, and I've
also got a half dozen 204s sporadically timing out BFD sessions, with
platform as the only commonality.

New platform, new bugs... My only real complaint is how long it takes to
get fixes turned around these days.

-Rob




_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On 12/Nov/19 06:55, Rob Foehl wrote:

>  
>
>  
>
> New platform, new bugs...  My only real complaint is how long it takes
> to get fixes turned around these days.

Yep, pretty standard.

Per usual, it will settle down.

Unlike the MX80 and MX104, the MX204 looks to have the stones to stick
around for quite some time, even if it gets a successor.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On Tue, 12 Nov 2019 at 06:55, Rob Foehl <rwf@loonybin.net> wrote:

> Atypical only in that there's no chassis switch involved on the Ethernet
> link... The comment above was about software catching up to what's
> (functionally) missing from the line card, in this case.

I can't parse this, sorry.

> PR1444186 -- GRE packets which are larger than MTU get dropped on MX204
> platforms when sampling is enabled on the egress interface -- was a fun
> one, and as it happens an MX80 was used to demonstrate that the issue was

This is interesting, but not enough information on the PR to make
heads or tails.

MX204 has all the bits and bobs linecard boxes have, just FAB side
serdes is not used for FAB, forwarding in MX204 is no different to
forwarding in linecard box when both ingress and egress port are on
same Trio. So that PR is surprising to me, being MX204 specific.

> specific to MX204. There's a not-yet-public follow up for that, and I've
> also got a half dozen 204s sporadically timing out BFD sessions, with
> platform as the only commonality.

When this happens, does it affect many BFD sessions at the same time?
There is PR1401507 which causes disruption between the RE PPMd and the
LC CPU PPMd causing all LC PPMd distributed keepalives to be torn
down.
Do you run BFD keepalives from LC CPU or NPU? I don't know if MX204
has real linecard CPU, or if it is like PTX1k where due to cost saving
there is no separate linecard CPU. If that is the case, and you don't
want NPU/inline BFD disabling distributed BFD is actually CPU cheaper
than doing LC CPU and less risky.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On 12/Nov/19 12:02, Saku Ytti wrote:


> Do you run BFD keepalives from LC CPU or NPU? I don't know if MX204
> has real linecard CPU, or if it is like PTX1k where due to cost saving
> there is no separate linecard CPU. If that is the case, and you don't
> want NPU/inline BFD disabling distributed BFD is actually CPU cheaper
> than doing LC CPU and less risky.

On our MX480's, we've known for a very long time that IPv4 BFD is
supported in the PFE. However, IPv6 BFD runs on the RE.

Last year, we got an ER submitted with Juniper to fix this as we believe
IPv4 and IPv6 parity is crucial to IPv6's success. I sent a a reminder a
month ago, haven't heard back. Let me ping my SE.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On Tue, 12 Nov 2019 at 12:34, Mark Tinka <mark.tinka@seacom.mu> wrote:

> On our MX480's, we've known for a very long time that IPv4 BFD is
> supported in the PFE. However, IPv6 BFD runs on the RE.

PFE is an ambiguous term, it variably means NPU or LC CPU inside JNPR.

There are several places where you can run your keepalieve

a) RPD
b) RE PPMd
c) LC CPU PPMd
d) NPU (dispatch block in the LU/XL)

And it depends on config where you run it. Not every protocol can
register to all of these. But yes, BFD v4 can run as RE PPMd, LC CPU
PPMd and NPU.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
Does any body know if the LC CPU on the MX204 has less power than the one
in MPC7 or in MX10003 LC
I saw some scaling numbers for subscriber management and it looks like some
numbers are very low on the MX204 compared to MX10003 LC
These are control plane tasks that are distributed to the PFE so I suspect
this could be a bottleneck for some applications

Nitzan

On Tue, Nov 12, 2019 at 1:29 PM Saku Ytti <saku@ytti.fi> wrote:

> On Tue, 12 Nov 2019 at 12:34, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
> > On our MX480's, we've known for a very long time that IPv4 BFD is
> > supported in the PFE. However, IPv6 BFD runs on the RE.
>
> PFE is an ambiguous term, it variably means NPU or LC CPU inside JNPR.
>
> There are several places where you can run your keepalieve
>
> a) RPD
> b) RE PPMd
> c) LC CPU PPMd
> d) NPU (dispatch block in the LU/XL)
>
> And it depends on config where you run it. Not every protocol can
> register to all of these. But yes, BFD v4 can run as RE PPMd, LC CPU
> PPMd and NPU.
>
> --
> ++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: MX204 vs. MX240?? [ In reply to ]
On Tue, 12 Nov 2019 at 14:28, Nitzan Tzelniker
<nitzan.tzelniker@gmail.com> wrote:

> Does any body know if the LC CPU on the MX204 has less power than the one in MPC7 or in MX10003 LC
> I saw some scaling numbers for subscriber management and it looks like some numbers are very low on the MX204 compared to MX10003 LC
> These are control plane tasks that are distributed to the PFE so I suspect this could be a bottleneck for some applications

Looks like it has real LC CPU:

MX204: SMPC platform (1601Mhz Intel(R) Atom(TM) CPU processor, 3136MB
memory, 8192KB flash)
JNP10K-LC2101: IMPC platform (2417Mhz Intel(R) Atom(TM) CPU processor,
3136MB memory, 8192KB flash)
MPC7: SMPC platform (1750Mhz Intel(R) Atom(TM) CPU processor, 3136MB
memory, 8192KB flash)


--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On 12/Nov/19 13:28, Saku Ytti wrote:

> PFE is an ambiguous term, it variably means NPU or LC CPU inside JNPR.
>
> There are several places where you can run your keepalieve
>
> a) RPD
> b) RE PPMd
> c) LC CPU PPMd
> d) NPU (dispatch block in the LU/XL)
>
> And it depends on config where you run it. Not every protocol can
> register to all of these. But yes, BFD v4 can run as RE PPMd, LC CPU
> PPMd and NPU.

If I'm honest, I haven't gone deep into where it's running. What I know
is that it's not on the RE.

IPv6 BFD is on the RE, hence all the issues we had with it and had to
turn it off.

We've never had any issues with IPv4 BFD stability. Solid!

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
> Saku Ytti
> Sent: Tuesday, November 12, 2019 11:28 AM
>
> On Tue, 12 Nov 2019 at 12:34, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
> > On our MX480's, we've known for a very long time that IPv4 BFD is
> > supported in the PFE. However, IPv6 BFD runs on the RE.
>
> PFE is an ambiguous term, it variably means NPU or LC CPU inside JNPR.
>
> There are several places where you can run your keepalieve
>
> a) RPD
> b) RE PPMd
> c) LC CPU PPMd
> d) NPU (dispatch block in the LU/XL)
>
> And it depends on config where you run it. Not every protocol can register
to
> all of these. But yes, BFD v4 can run as RE PPMd, LC CPU PPMd and NPU.
>
Hey Saku,

Would need some more insight from you to process the above
I must admit I got confused by the above since I was only familiar with
this:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB31595&pmv=print&ac
tp=LIST&searchid=&type=currentpaging
Right so RPD or whoever offloads the periodic packet management to PPMD that
part is fine.
Then PPMD can run on RE obviously or can be distributed onto LC -now this is
where my confusion comes in.

That's because I was under the impression that it's the LC CPU hosting the
PPMD in distributed mode,
But reading the KB article linked above again and other sources on PPMD also
specifically mentions PFE as the entity running PPMD
And in in my book PFE is solely the Trio complex (MQ,LU,QX -or whatever
version and quantity combinations of thee 3 blocks), but not the LC CPU.
-hence my confusion,
And yes I didn't do a test of running say 3k BFD sessions in PPMD
distributed mode to see if LC CPU utilization or PFE utilization rises.

But still I don't see how the LU microcode has the ability to actually
generate packets, let alone to host a complete daemon.
Alright the PPEs inside LU are pretty much generic cores (probably some
streamlined instruction set) but could potentially run any type of app, but
the microcode I find it hard to believe it has enough code to run a daemon
or generate packets -what about hyper-mode (streamlining of that microcode)
-would that have any effect on the ability of the microcode to run PPMD?
In my head I find it much more plausible for the LC CPU just tx/rx packets
to/from trio complex and the trio just doing the simple
forwarding/filtering/queuing/counting..

Also is there a cmd I can use to switch between LC CPU and LU?

Thanks,

adam


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: MX204 vs. MX240?? [ In reply to ]
On Thu, 14 Nov 2019 at 15:18, <adamv0025@netconsultings.com> wrote:


> But still I don't see how the LU microcode has the ability to actually
> generate packets, let alone to host a complete daemon.

It does, there is dispatch block in LU, in this callout block you
generate parcel in timed manner, which will be given to some PPE,
which causes the PPE to execute the correct microcode.

PPM on LC CPU:
IMPC0(r33.labxtx01.us.bb-re1 vty)# show ppm adjacencies


PPM on NPU:
IMPC0(r33.labxtx01.us.bb-re1 vty)# show ppm inline sessions
bfd show PPM inline sessions for BFD
cfm show PPM inline sessions for CFM
lacp show PPM inline sessions for LACP
lfm show PPM inline sessions for LFM
vrrp show PPM inline sessions for VRRP

> or generate packets -what about hyper-mode (streamlining of that microcode)
> -would that have any effect on the ability of the microcode to run PPMD?

I've not tested, but I'd be shocked if this wasn't part of ucode
rewrite goal. So I'd be ready to bet money hypermode has support for
this.

> Also is there a cmd I can use to switch between LC CPU and LU?

As far as I know there isn't shell to the LU complex, just commands in
the LC CPU to query about its state.


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

1 2  View All