[j-nsp] MX204 and copper SFP?

[Graham Brown]

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