[j-nsp] MX204 and copper SFP?

Niall Donaghy niall.donaghy at geant.org
Tue Apr 10 08:34:56 EDT 2018


Many thanks Graham. I see this works on 15.1F6 at least, and might in fact 
prove useful for us.



Br,

Niall



From: Graham Brown [mailto:juniper-nsp at grahambrown.info]
Sent: 09 April 2018 10:14
To: Niall Donaghy <niall.donaghy at geant.org>
Cc: Saku Ytti <saku at ytti.fi>; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] MX204 and copper SFP?



Quite timely, I saw a tweet around forcing the interface name via a CLI 
command.



https://twitter.com/mohsinulmalik/status/983190461513744385?s=21



Apologies but I have not tested this myself, but may be of interest to those 
of you on this list.



Cheers,

Graham



On Sat, 7 Apr 2018 at 07:49, Niall Donaghy <niall.donaghy at geant.org 
<mailto:niall.donaghy at geant.org> > wrote:

You're exactly right Saku, those are the questions to ask, the design 
decisions to be made. I posit that as Juniper break this up into 
type-fpc/pic/port, and there is some indication of speed in the type name, 
they would do well to standardise, or abandon the idea. Currently even the 
documentation states the type indicates speed, for some types, then lists 
exceptions to this. My only complaint is if you have to remember exceptions, 
best not to use it as an indicator at all.

I am certainly immersed in Ethernet interfaces more than any other, so 
accustomed to ge, xe, et denoting one speed, as per the deployment I work on 
every day. A little biased indeed. :)

I categorically wouldn't want a single 'type' prefix. Agree on the dynamic 
update on linerate OID being an ideal feature to have.

Get Outlook for Android<https://aka.ms/ghei36>



From: Saku Ytti
Sent: Friday, 6 April, 19:55
Subject: Re: [j-nsp] MX204 and copper SFP?
To: Niall Donaghy
Cc: Chuck Anderson, juniper-nsp at puck.nether.net 
<mailto:juniper-nsp at puck.nether.net>


Maybe you're right. Maybe you're suffering status quo bias. If interface name 
should give some indication, but provably unreliable indication of interface 
rate. Is that the idea amount of information encoded to interface name? Or 
should we code more information in the name? Or less? Should interface name 
include encapsulation type, why not? Why is rate special? We have field for 
bandwidth in SNMP MIB and interface CLI configuration, this could be 
automatically set to linerate of interface, so we would offer dynamic and 
accurate data about linerate, as opposed to interface name. Unless we want 
interface name to change once we change the speed?. On 6 April 2018 at 21:07, 
Niall Donaghy wrote: > Indeed, encapsulating a port speed in its name offers 
some convenience in > show commands, configuration groups, and 
interface-ranges; I would say the > value there is non-zero. > > Going beyond 
that, how about logical tunnels (lt-), GRE interfaces(gr- and > gre), loopback 
interfaces (lo), Multis
 ervices (ms-), SONET/SDH (so-) and the > various assortment? > Ref: > 
https://www.juniper.net/documentation/en_US/junos/topics/concept/interfaces- > 
interface-naming-overview.html > This page seems to say that aside from PTX 
routers, where et- can be > 10/40/100GE, et- == 100GE. > We know that's not 
the case as on MX204 and MX10k3, et- can be 40/100GE. I > guess they might 
update this page sometime.. > > Consider operators whose interface 
descriptions don't encapsulate the > relevant information, or worse still - 
whose operational interfaces may not > have interface descriptions at all. > 
In those cases it is *incredibly* useful to identify interface type by > 
interface name. > I would say identifying speed by name is an extension of 
that. > > I don't see that moving to a generic prefix such as inf- is for the 
greater > good. > > So now we have ge-, xe-, and et- meaning physical Ethernet 
interfaces - and > depending on your hardware, optics, and config - *likely* 
1GE/10GE/100GE, > r
 espectively ... but, maybe not. > Now with the speed variances, at least we 
can still say they're physical > interfaces. > > > Br, > Niall > > 
 > -----Original Message----- > From: juniper-nsp 
[mailto:juniper-nsp-bounces at puck.nether.net 
<mailto:juniper-nsp-bounces at puck.nether.net> ] On Behalf Of > Chuck Anderson > 
Sent: 05 April 2018 20:31 > To: juniper-nsp at puck.nether.net 
<mailto:juniper-nsp at puck.nether.net>  > Subject: Re: [j-nsp] MX204 and copper 
SFP? > > Back-in-the-day we had fe-x/x/x for 10/100 Mbps ports. Now we have 
ge-x/x/x > that can take a 100 Mbps SFP, but the name doesn't change to 
fe-x/x/x AFAIK. > So there is precedent for the names not changing when the 
speed changes. > > But I do like having the ability to match ports based on 
speed, e.g. find > all "uplink" ports by assuming ge-* are access ports and 
xe-* are uplinks. > Patterns can be used within configuration groups and 
interface-ranges. > > On Thu, Apr 05, 2018 at 01:38:46PM +0000, Nelson, Brian 
wrote: >> Port-foo is so archaic. >> It's an interface, inf-x/x/x would be 
more germane. >> >> Brian
 >> >> -----Original Message----- >> From: juniper-nsp 
[mailto:juniper-nsp-bounces at puck.nether.net 
<mailto:juniper-nsp-bounces at puck.nether.net> ] On >> Behalf Of Ola Thoresen >> 
Sent: Thursday, April 05, 2018 3:59 AM >> To: juniper-nsp at puck.nether.net 
<mailto:juniper-nsp at puck.nether.net>  >> Subject: Re: [j-nsp] MX204 and copper 
SFP? >> >> On 05. april 2018 10:44, Saku Ytti wrote: >> >> > Since of the 
fathers. >> > >> > 'Cisco did it'. >> > >> > I also see no value in it. >> >> 
Don't we all love that "linux" changed from eth0, eth1, eth2... to > beautiful 
stuff like wwp0s20u4 and enp0s25... >> >> Just call them port-x/x/x and be 
done with it. >> >> >> /Ola (T) > 
_______________________________________________ > juniper-nsp mailing list 
juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>  > 
https://puck.nether.net/mailman/listinfo/juniper-nsp > > 
_______________________________________________ > juniper-nsp mailing list 
juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>  > 
https://puck.nether.net/mailman/listinfo/juniper-nsp > -- ++ytti

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net 
<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 

-sent from my iPhone; please excuse spelling, grammar and brevity-



More information about the juniper-nsp mailing list