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

[Stanislaw Datskevich]

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 saying that you are using a feature that is
licensable and that you do not possess a license for the feature. If
you try to commit configuration changes for a feature that is not
licensed, you will receive a commit warning saying that you have
exceeded the allowed license limit for the feature."


> 
> 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 think his use of the word "trick" is what triggered your firewall
> :-).
> 
> He could easily re-phrase the question as "Is there any risk with
> running BGP on the QFX5200 with the license warning"?
> 
> Juniper already know that a lot of operators run their kit this way.
> Their only recourse is to enforce license limits in software, and we
> are
> seeing that with later releases + newer platforms.
> 
> Mark.

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

[Mark Tinka]

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 think his use of the word "trick" is what triggered your firewall :-).

He could easily re-phrase the question as "Is there any risk with
running BGP on the QFX5200 with the license warning"?

Juniper already know that a lot of operators run their kit this way.
Their only recourse is to enforce license limits in software, and we are
seeing that with later releases + newer platforms.

Mark.

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

[Kenneth McRae]

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

[Tony Wicks]

>
>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 works in QFX5200..
>

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 ?

Juniper QFX5200-32C junos base services license and BGP

[Stanislaw]

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 works in QFX5200..

Re: About inetnum "ownership"

[Owen DeLong]

> 
> 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 of time. ;-)

What we are discussing here, however, is some theoretical right to prevent the 
spammer
from doing so.

Owen

Re: About inetnum "ownership"

[Owen DeLong]

> 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 recorded.
> 
> The U.S. Supreme Court talks about property this way: "The right to
> exclude others [is] one of the most essential sticks in the bundle of
> rights that are commonly characterized as property." (Kaiser Aetna v.
> United States)

And you get no such right in IP addresses.

> Do I have the legal right to exclude others from announcing my block
> of IP addresses to the public Internet routing tables? It's not well
> tested in court but the odds are exceptionally strong that I do.
> Indeed, the whole point of registration is to facilitate determination
> of -who- has the exclusive right over -which- blocks of addresses.

Not so much, no.

First, there’s no good definition of “the public Internet” and there’s
no single definition of “public routing tables”.

There is, instead, the set of individually run networks who cooperate in
the exchange of traffic by sharing routes.

Any right to exclude would be a right to control how each and every one
of those networks operates. Since many of those networks are outside of
the jurisdiction of any court to which you would likely have access and
to the best of my knowledge there is no international court of competent
jurisdiction to compel ISPs around the world to obey any such order,
no, you have no right to exclude.

> The right to exclude is not the only one in the bundle of rights that
> is property but it is the primary and it is argued sufficient
> condition of property.
> http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1492=nlr
> 
> Which brings us back around to what I said earlier: IP addresses are
> property but the legal precedent isn't as strong as might be nice.

I think I have shown that you do not have the right to exclude, so if you
have some other basis by which you think you can define these property
rights, let’s have it.

I argue that because what you actually mean by “the public Internet” is
a combination of so many different legal entities in so many not-necessarily-
overlapping jurisdictions and because there is no single jurisdiction to
which they are all subject, nor even necessarily any particular agreed
upon complete shared definition or enumeration of all of them, the ability
to enforce any sort of right to exclusion is nothing but a myth, making
any such alleged right also mythical.

>> IP addresses are so abstract and ephemeral in their nature
>> as to be impossible to treat as property
> 
> Computers don't do abstraction. There's nothing abstract or
> particularly ephemeral about the use of IP addresses on the public
> Internet.

Please in a legal way define this single entity that you refer to as
“the public Internet” such that some court would have jurisdiction over
the entirety of its operations.

Then please define the venue of jurisdiction to which you would avail
yourself in order to compel said entity to obey such an order.

Indeed, the reason there aren’t any court precedents to support your
position is because when hijackings have occurred, the solution has
been to contact the provider and/or upstream providers of the one
engaged in hijacking. Case in point, the incident between YouTube
and AS17557 over 208.65.153.0/24. Do you really think that the
Pakistani government would have ever punished Pakistan Telecom or
that YouTube could have obtained any useful injunctive relief in
that jurisdiction?

No, instead, they contacted PCCW and got voluntary cooperation in
no longer forwarding the announcement. This isn’t a sign of a right
of exclusion, but of a gentlemen’s agreement amongst service providers.

https://www.ripe.net/publications/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study

It would have been quite difficult for YouTube to get any sort of
injunctive relief against Pakistan Telecom. It might have been possible
for them to get injunctive relief against PCCW, but even that is iffy.

What if hundreds of other service providers had also forwarded the route?

YouTube would have needed injunctions against each and every one of them.

It’s not at all clear what happens with the ones that do operate in the US
where YouTube has the greatest likelihood of getting injunctive relief.

It’s even less clear what happens with any that are not subject to US
courts.

Owen

Re: sFlow vs netFlow/IPFIX

[Peter Phaal]

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 your collector code which you've now diverged from the
> mainstream distribution, thereby creating a requirement for future
> maintenance, with associated costs.

I completely agree that you don't want to maintain two sets of
configurations (switch and collector) that need to be updated.
However, it's much better to focus on minimizing switch configuration
complexity than it is to focus on reducing analyzer software
configuration complexity.

If you push the problem of de-duplication to the switch configurations
then you end up with VxT sets of switch configuration in a
multi-vendor network (where T is the number of topologically different
wiring configurations used for the switches and V is the number of
vendors - actually it can be even worse, since each vendor product
line might have different configuration options, CatOS vs NX-OS for
example). Adopting a standard sFlow agent configuration in which
monitoring is enabled on all switch ports with policy based default
sampling rates (a good default sampling rate = port speed in gigabits
per second x 1000. e.g. 1-in-10,000 on a 10G port) greatly simplifies
large scale sFlow deployments. Now instead of maintaining and updating
VxT configurations in thousands of switches, there are only V switch
configurations that are installed when the switches are initially
provisioned and remain static over the lifetime of the network.

Updating the single, central configuration of the sFlow analyzer
software is much simpler and easily automated. It also makes it much
easier to roll out new analytics capabilities since they are simply
configuration and software updates to the central collector and don't
require building, testing and deploying configurations to all the
devices.

Re: sFlow vs netFlow/IPFIX

[Nick Hilliard]

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 all flow samples with a destination
port of one of the entries on the list is excluded from the flow
processing.  Alternatively, you can set up a full accounting perimeter
and lop off 50% of the packet and byte counts.

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 your collector code which you've now diverged from the
mainstream distribution, thereby creating a requirement for future
maintenance, with associated costs.

Cisco could just fix the problem rather than lalala-ing about how it's
now a feature because it's been documented.  Broadcom's SDK makes it
simple to implement this and there is no technical reason for Cisco to
continue to decline to fix the problem.

Nick

Re: sFlow vs netFlow/IPFIX

[Peter Phaal]

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 --
sampleType_tag 0:1
sampleType FLOWSAMPLE
sampleSequenceNo 1022129
sourceId 0:7
meanSkipCount 128
samplePool 130832512
dropEvents 0
inputPort 7
outputPort 10

The two fields of interest are the sourceId (0:7) indicating that this
measurement came from a data source of type ifIndex (0) and that the
ifIndex of the data sources is 7. The inputPort is the ifIndex of the
port that received the packet. In this case because the dataSource
ifIndex and the inputPort ifIndex are the same, this is an ingress
sampled packet. A simple filter along the lines:

if ( sourceId.split(':')[1] != inputPort) return;

would allow your sFlow analyzer to eliminate the unwanted samples. You
could also enable / disable ports on your switches to ensure that each
path is sampled once, but that does limit the types of analysis you
can do with the data. A better approach is to simply add additional
input filters to specify which edge data sources you want to include /
exclude in your traffic accounting application since this would allow
the full sFlow feed to be used for other purposes as well (identifying
traffic on busy links, etc.)

The overhead of enabling sFlow on all ports and all devices is
generally quite small since packets are sampled in hardware and
production sampling rates tend to be in range (1,000 - 50,000) so very
little traffic measurement traffic is actually generated. A more
important consideration is operational complexity. If you have
thousands of switches, designing customized configurations for each
one doesn't make a lot of sense. It's much better if the intelligence
is applied at the collecting end. Taking this approach and including
sensible defaults in the agents can get the sFlow agent configuration
down to something as simple as:

sflow {
  DNSSD = off
  collector {
ip = 10.0.0.162
  }
}

And you could go even simpler if you use DNS SRV records to identify
the sFlow collector(s)

sflow {
  DNSSD=on
}

These configurations are from Cumulus Linux.

One of the trends in merchant silicon based platforms is inclusions of
the ONIE boot loader. If you don't like the network operating system,
you can install a different operating system to better suite your
requirements without ripping and replacing hardware. There are many
virtually identical switches built around the Broadcom ASICs, giving a
lot of choice in hardware and network operating system vendor.

On Thu, Mar 3, 2016 at 3:53 AM, Nick Hilliard  wrote:
> 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
>> common and easiest to deal with, but a decent sFlow analyzer should be
>> able to handle all three cases without over / under counting.
>
> Bidirectional sampling doesn't allow you to define an sampling perimeter
> on your switch topology.  This means that if you if you have anything
> other than a trivial topology, you will end up double-counting your
> traffic.  The only way to work around this is to get the collector to
> discard 50% of the samples or otherwise write down the amount of traffic
> by 50%, assuming a standard accounting perimeter configuration.  This is
> broken.
>
> The thing is, this is ridiculously easy to fix in code.  The hooks are
> already there.
>
> Nick

Re: sFlow vs netFlow/IPFIX

[Nick Hilliard]

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
> common and easiest to deal with, but a decent sFlow analyzer should be
> able to handle all three cases without over / under counting.

Bidirectional sampling doesn't allow you to define an sampling perimeter
on your switch topology.  This means that if you if you have anything
other than a trivial topology, you will end up double-counting your
traffic.  The only way to work around this is to get the collector to
discard 50% of the samples or otherwise write down the amount of traffic
by 50%, assuming a standard accounting perimeter configuration.  This is
broken.

The thing is, this is ridiculously easy to fix in code.  The hooks are
already there.

Nick