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 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
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
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 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
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"
> > 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"
> On Mar 1, 2016, at 21:44 , William Herrinwrote: > > 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
On Thu, Mar 3, 2016 at 9:16 AM, Nick Hilliardwrote: > 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
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
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 Hilliardwrote: > 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
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