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.dona...@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, email@example.com > > > 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-boun...@puck.nether.net] On Behalf Of > Chuck Anderson > > Sent: 05 April 2018 20:31 > To: firstname.lastname@example.org > 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-boun...@puck.nether.net] On >> Behalf Of Ola Thoresen >> > Sent: Thursday, April 05, 2018 3:59 AM >> To: email@example.com > >> 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 firstname.lastname@example.org > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > _______________________________________________ > juniper-nsp mailing list > email@example.com > > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- ++ytti > > _______________________________________________ > juniper-nsp mailing list firstname.lastname@example.org > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- -sent from my iPhone; please excuse spelling, grammar and brevity- _______________________________________________ juniper-nsp mailing list email@example.com https://puck.nether.net/mailman/listinfo/juniper-nsp