Re: Juniper QFX5200-32C junos base services license and BGP

And the question is: is the QFX5200 platform that newer platform which has license limits enforced? It seems limits currently are "soft" as in previous platforms according to vendor's documentation: "Note: If you try to configure a feature that is not licensed, you will receive syslog messages

Re: Juniper QFX5200-32C junos base services license and BGP

On 3/Mar/16 22:38, Tony Wicks wrote: > Um, you do realise that all the major vendors (including that well Known > vendor) have people on this list ? Sending a question about taking advantage > of said vendors light handed approach to licencing to this list is somewhat > less than subtle ? I

Re: Juniper QFX5200-32C junos base services license and BGP

RE: Juniper QFX5200-32C junos base services license and BGP

> >Hi, >Does anyone has a QFX5200-32C gear with a "Junos Base Services" license? >Does that license technically allow running BGP? > >Currently I have a QFX5100 which only gives me warning "This feature requires a license" during commit but BGP routing works fine. So I'm wandering if that trick

Juniper QFX5200-32C junos base services license and BGP

Hi, Does anyone has a QFX5200-32C gear with a "Junos Base Services" license? Does that license technically allow running BGP? Currently I have a QFX5100 which only gives me warning "This feature requires a license" during commit but BGP routing works fine. So I'm wandering if that trick

Re: About inetnum "ownership"

> > Interesting demonstration of why retreat to analogies does not help in a > discussion. > > A question: If you stop announcing your routes, where will the world get > them from? > In most cases, the first spammer to notice that the space is no longer announced, at least for some period

Re: About inetnum "ownership"

> On Mar 1, 2016, at 21:44 , William Herrin wrote: > > On Tue, Mar 1, 2016 at 6:55 PM, Owen DeLong wrote: >> Unique registrations in the RIR databases may well be property. > > Hi Owen, > > Registration records property. Registrations are not the property

Re: sFlow vs netFlow/IPFIX

On Thu, Mar 3, 2016 at 9:16 AM, Nick Hilliard wrote: > The beauty of sflow is that you can do anything in the collector, but > most people aren't going to do this because it means maintaining two > sets of data about your flow configuration: one set on the switch and > one set in

Re: sFlow vs netFlow/IPFIX

Peter Phaal wrote: > sampled packet. A simple filter along the lines: > > if ( sourceId.split(':')[1] != inputPort) return; It's not a one-liner in practice. It involves maintaining an array of source ip + egressPorts with sflow enabled and (depending on how you implement it) e.g. ensuring that

Re: sFlow vs netFlow/IPFIX

While it would be nice if the Nexus switches supported ingress sampling, you can get exactly the same result at the receiving end by dropping the egress samples. The following sflowtool output shows some of the metadata contained in the packet sample: startSample --

Re: sFlow vs netFlow/IPFIX

Peter Phaal wrote: > I think "pathologically broken" somewhat overstates the case. > Bidirectional sampling is allowed by the sFlow spec and other vendors > have made that choice. Another vendor used to implement egress only > sampling (also allowed) but unusual. I agree that ingress is the most >