@Chrylis, can you join the chat?

@Chris, can you join this room?

Am I successfully in?

you're here :)

Keep in mind that this is a public room

Thanks, I still don't have privileges on NE!

people will be able to see everything you say...

I try to keep most online discussions that way. ;-)

np, glad to help any way I can

np... however, some people post contact info like email addresses

accidentally

Basically, it seems to me that networking (generally) is in a very similar position to server software c. 2000:

in what way?

Some open-source options, including ones that don't have contract support (AFAIK) and that run on commodity hardware, have become viable options for serious production work.

for the record, what is your job? Are you a full-time network engineer?

Around 2000, I remember hearing that Linux was interesting for learning about real Unix but that if you were going to be running an actual production server, you'd be using Solaris.

I am not a full-time network engineer. I'm a consultant whose job includes network design and troubleshooting in addition to software design. I hold CCNP and CCDP certifications (CSCO10699529).

ok, I'm a full time network engineer, who spends a large amount of time in linux... either writing software, or using it to accomplish my job

I know we've discussed quagga as a particular example before of the sort of edge case that I'm talking about.

so perhaps we can learn from each other

To my knowledge, there's no paid support for quagga (maybe if you go to Vyatta), and I've run it on commodity hardware, and in the overall "case study" I have in mind, on a VM.

But I think you agree that at least some questions regarding its usage (probably not installation) ought to be on-topic for NE.

ok, I was running RIP on solaris in 1998 to advertise loopbacks

Using ripd?

I can't remember the specific daemon

we used it as a way of multihoming servers and providing highly available addresses to connect to

Okay. Are you using that just as a frame of reference, or is there a particular significance to the example?

we bound an address to the loopback and always connected to those services via the loopback

my point is that routing protocols on a server are not new at all... since the beginning of the internet people have been running routing protocols on a unix server of some flavor

No, they're not, but I definitely encounter people (mostly from the all-networking side) who take the position that Real Networking happens on equipment from Cisco or Juniper and that running anything more complicated than perhaps an anycast endpoint on a general-purpose platform is a toy.

when you say "no they're not", I'm not sure what you're responding to

I meant that running routing protocols on hosts isn't a new thing.

And I don't remember saying that routing protocols on hosts are a toy. That's an assumption perhaps you have about me, but that's not why I suggest servers with routing should be off-topic

You didn't say that, and I didn't intend to attribute that to you; that's why I said that I encounter "people" who take that attitude.

so we agree... routing on servers has been around for over two decades

Here's a quick edge case that I'll toss out:

and BTW, people were using servers as infrastructure... because in some cases purpose-built routers were not available

CeroWrt is an instrumented OpenWRT variant specifically designed to help diagnose and combat bufferbloat. The designers chose to focus on one OpenWRT-friendly platform (Netgear WNDR3800) for a handful of reasons.

(They were, but my impression has been that by about 2000 the purpose-built hardware had achieved the "big-boy" status and that using GP hardware for the task was considered a low-budget hack.)

Now obviously questions about the WNDR3800 hardware don't belong on NE. Questions about installing CeroWrt probably don't. But the bufferbloat discussion is a very timely one that needs attention on a global scale, and from the close votes I've seen, the current standard would treat any questions regarding CeroWrt's instrumentation or capabilities in that area as "off-topic" because they weren't on a "professional" AP.

Rhetorical question: Where are buffers located?

"How do I configure the WiFi queue lengths in CeroWrt" should probably be OT (maybe Superuser). Questions about how WiFi AP queue lengths affect TCP windowing and unnecessary retransmission probably shouldn't be.

suspicious glance Everywhere!

Another rhetorical question: How can you have a meaningful discussion about buffering behavior that solves a real problem without being specific about the real hardware it is running on?

Because the relevant questions about the buffer aren't in fact hardware-specific. A TX queue is a TX queue whether it's in a Linux TCP/IP stack, a WiFi baseband's SRAM, or a Catalyst's port ring buffer.

because... buffer implementations are inside the interface drivers, inside some kernel

We disagree on that point

The hardware may impose limitations on how far you can modify its behavior, but the behavior is an algorithm that is to some degree separable from the implementation.

Can you elaborate on the distinction you're drawing?

specifically, it's overly simplistic to argue that if you're seen one TX queue, any other TX queue is no different... that argument highlights a basic ignorance of the work required to implement a TX queue...

have you written any interface drivers, or spent time reading the code from interface drivers?

if you want to discuss a theoretical queueing algorithm, that discussion is on-topic for either Stack Overflow, or Theoretical Computer Science... depending on the amount of code involved

however, this is a network engineering site... we're solving real deployment and architecture problems

Okay, I'll agree that I was overly simplistic there. TX queues can have significantly different behavior, but (as in the case of Cisco's software queues) they can be thoroughly specified still without tying it to the hardware.

I have not written drivers, but I've done some light reading in Linux for troubleshooting.

full disclosure: I worked for Cisco in a business unit, writing the requirements for new interface cards

thus, I have a little experience with what you're saying... and again, arguing that Cisco's software queues can be thoroughly specified without tying it to the hardware is quite simplistic as well

Would a question about RED parameters on an ISR be on-topic?

Okay, Cisco's materials claim that the behavior is thoroughly specified. Difference between theory and practice and all. O:-)

Please put more meat on your hypothetical RED on ISR question

in other words, pretend you're really asking it...

pulls out QoS book for an example he thinks he can translate

agreed about distinction between theory and practice... have you ever seen two different models of Catalyst switches that supported the same mappings between DSCP / MPLS EXP / IP Prec / dot1p bits?

and then think about pathological cases, like modifying DSCP before putting the payload in an IPSec tunnel...

I've been good this week. Don't make me cry on a Saturday night.

ok ok ok

This is as specific a question as I'm going to frame on this specific issue tonight, but:

back to the RED question... feel free to think on that one, but my wife might start demanding my time any minute now... she seems to think I should be watching movies with her instead of doing "computer things" on Saturdays

"I ran QoS instrumentation when we brought a major remote site online two years ago and configured the RED min/max thresholds to achieve smooth performance for our combined database and streaming-video feeds. We're now upgrading our WAN link to the site to double the capacity from 10Mbps to 20Mbps. How should we change the thresholds; should we double them, or is there another rule?"

It's a reasonable question as long as you specified the model of the router involved, and the interface cards

How do those variables affect how you should set the RED parameters?

what variables are you talking about? I don't see the specifics in your question

oh you mean the model?

yes, in fact they might...

Right. I'm not clear how the difference in router model changes how the thresholds ought to be set.

can your router actually handle an upgrade from X to Y bandwidth with the features you're asking for?

without being CPU limited? or running out of buffers on the tx-ring?

Presume the router and line cards can; the question wasn't about capacity planning.

Or scale the numbers down to 2Mbps and 4Mbps and make those issues moot; even a 1900 should be able to push at least that much process-switched without blinking.

I'm not talking about capacity planning... I'm talking about an ISR that might be at 40% interrupt CPU load at 10Mbps, and simply should not be used for an upgrade to 20Mbps

the point again... real problems happen on real hardware... you can pull out a case for RED on a 50Kbps circuit vs RED on 100Kbps circuit... we'd probably agree any Cisco these days should be able to handle it

Heh... I may pull that aphorism back out after I explain my other (real-world, working) example.

btw, you really do not want to process switch anything that involves qos... but that's a different discussion

please state your case, and allow me to take a break to consider and give my family some attention

Entirely true. Sorry, I've been focusing on software almost exclusively for the last year or so and am a bit slow on my networking reflexes.

There's no need for real-time at all for my example; I'm perfectly happy to post for consideration. I suggested chat just because it takes longer than 600 chars to explain.

fair, but I kindof like the format of this... let's come to a conclusion, the link will remain on the meta answer

Scenario: A client has work crews that travel all over the country into remote areas. Their command trucks are outfitted with VSAT dishes that provide connectivity into a private VLAN at the satellite provider's data center.

Due to restrictions by the hardware and/or satellite provider, the truck is limited to a single IP address attached to the VSAT endpoint. The current system just uses a consumer-level wireless router to NAT all the crew's traffic onto the uplink, and the telemetry is pushed from inside the truck back to the company's datacenter.

The client wants to be able to make connections from the corporate network to hosts in the field. Unfortunately, most of the devices speak only IPv4, have addresses assigned out of a flat address pool (most of the 192.168. block), and travel from crew to crew, so there's no programmatic way to know which satellite endpoint a particular device is accessible through on any given day.

The devices aren't intelligent enough to advertise their own presence, and it's cost-prohibitive for some intelligent device in the field to enumerate them and then push route advertisements across the uplink (bandwidth is metered and fairly expensive). It is feasible for field technicians to identify the IP address of a particular device and to tell the corporate support personnel the IP and which crew it's with.

The solution that I came up with was to run an IPv6-over-IPv4 tunnel between the truck and a terminator collocated with the satellite provider. A simple Web app had a list of the IPv6 prefixes assigned to each truck, and a troubleshooter could type an IPv4 address in, select the crew from a dropdown, and get redirected to an IPv6 address.

The wireless router, replaced with similar hardware running OpenWrt, ran TRT to unpack the embedded IPv4 address and run NAT between the IPv6 side and the IPv4-only devices.

There were a number of possible solutions for the VPN terminator, but we eventually decided to use a bare-bones Linux VM using static proto-41 tunnels on the satellite side and OSPFv3 (advertising the trucks' prefixes) on the corporate side.

(As a note, we looked at trying to run some of the IPv6 processing, beyond simple routing, on the main switch in each truck, which was a 3750, but the 3750 has really picky conditions about which tunnel setups it would handle. The docs say it's a hardware limitation, but I was never clear why a punt adjacency and CPU handling wouldn't work.)

I had a few questions during this development that I think would have been suitable for NE, such as:

- "I'm trying to run an IPv6-in-IPv4 tunnel over a link where bandwidth is expensive but changes in the endpoints and their associated prefixes are extremely uncommon. Are there serious disadvantages to using proto-41 tunneling that would be avoided with some heavier encapsulation like GRE?"

- "I have a remote site with 4 VLANs that's delegated an IPv6 /62 prefix. All upstream traffic has to be run over NAT or VPN through a single IP address. Is it better to send the IPv6 link advertisements from the 3750 or the OpenWrt router? Does this answer change depending on how frequently the prefixes are updated?"

- "I have VMs running as tunnel terminators, advertising small (/62) IPv6 prefixes to remote sites into the main corporate network. We have a main router sitting on the edge between the corporate WAN backbone and the datacenter where the terminators are. Is it clearly better to run the OSPFv3 process for the tunnels in its own area or in area 0?"

- "I have incoming IPv6 traffic that consists of both trusted and untrusted data. The addresses are structured in such a way that the last bit of the IPv6 prefix (bit 63) is an 'evil bit' (set indicates guest traffic, clear indicates corporate). Is there a clean way to set up an IPv6 access list to route the traffic differently based on the one bit in the middle of the address?"

that's a lot of question :)... let me parse all of this a bit later... need to spend time with my family for a while...

No problem, and I'm having trouble even explaining the question for working around the buggy IPv6 prefix-based address support in IOS 12.2. This was the example I had in mind to show that some questions related to non-contract-support networking infrastructure seem like they ought to be fair game for NE.

None of those questions are asking for information about the OpenWRT box... they sound good to me... Just don't ask us about troubleshooting OpenWRT, or how to implement the aforementioned services services on OpenWRT :)

That's fine; I've just gathered the impression that if I'd mentioned that I was using OpenWRT (or a home-grown Linux terminator image), I'd have been marked off-topic/consumer. This distinction is what I was trying to clarify.

First, the wording is very specific: "Questions about configuring or using consumer networking products"... your questions are not specifically about configuring or using OpenWRT. Second, very very few decisions to put questions on hold are final. The vast majority of cases can be appealed by asking a question in meta; exceptions come when there are quality issues in the question (such as the question is a poll). Finally, the community can vote to reopen questions that are put on hold.

room topic changed to Discussion about OpenWRT: Boundaries for asking questions involving OpenWRT and other non-commercial solutions [discussion]

Thus the current conversation. ;-)

I'm not sure I understand... thus refers to?

"Thus" meaning "the conversation about topicality went to meta".

yes, it's why we have meta :)... I hope more people will start using it to ask for clarification

I will note that in practice, due to the fact that NE is still new and few people have the rep to vote to close/reopen and that traffic is still light, an on-hold decision is likely to stick for the necessary threshold.

Additionally, meta is a confusing place to navigate. I've barely been able to find my way around when trying to resolve specific questions, and I haven't figured out how to make questions on-topic for it.

Maybe we need to get them to open a metameta.

even if nobody votes, the decisions can still be appealed on meta...

when you say "I haven't figured out how to make questions on-topic for it", tell me more... and we are getting off the open-wrt topic... I should create another room to keep this focused on OpenWRT discussion...

Of course. A final point of clarification regarding OpenWRT and similar topicality:

Given that configuring, say, IPv6 router advertisements on a 3750 is on-topic, it seems to me that configuring the same functionality on an OpenWRT router should be as well. "Network Engineering" is an activity, and while configuring an OpenWRT router for home use shouldn't qualify, it doesn't seem to me that performing tasks that would be considered "network engineering" from an implementation-agnostic POV should be off-topic because the tools used aren't sufficiently "professional".

(I'm having a hard time expressing myself on this point, but I think you understand the distinction I'm making now.)

room topic changed to Discussion about Consumer Networking Products: Boundaries for asking questions involving OpenWRT and other consumer solutions [discussion]

I'm afraid that's a relevant distinction

A Cisco 3750 goes through extensive testing, and was purpose-built for networking

OpenWRT is built by a community of volunteers who may or may not have tested the solution well; furthermore, it is not designed with support in mind. Finally, the reality of shareholders, fiduciarity duty, lawsuits and legal liability force large commercial networking vendors to (in general) do a much better job at testing these solutions.

[side note: need to run, daughter is crying]

This is why I made the Linux/Solaris analogy earlier. Your argument (1) does not offer any explanation for why a line of topicality should be drawn based on the product support model rather than the activity which is being undertaken and (2) is flawed on the facts.

I'm afraid we disagree on both points, but they are matters of opinion

In particular, if you look through your sales agreements, EULAs, and support contracts for your Cisco or Juniper products, you'll see that they disclaim all liability from bug reports. This same argument was brought up when Linux started entering the data center, and nobody's ever heard of a lawsuit against Sun or Microsoft for bugs in their software.

On the 3750 in particular, I recall running across massive bugs relating to IPv6 support, especially with prefixes, in production IOS versions.

This isn't to say categorically that one's better than the other, but your argument seems to boil down to the same argument that "proprietary is professional and open-source/commodity isn't".

Perhaps, but it's not intentionally one. You mentioned previously that you would consider quagga and its components to be on-topic. What's the difference there, since quagga isn't commercially supported?

I'm saying that as a rule, commercial products are signficantly easier to debug and troubleshoot...

Actually I was arguing that quagga is off-topic... read my answer closely :)

(IANAL, but this is a particular area I've read extensively in. What sort of tort are you suggesting provides some increased assurance of quality?)

the community voted otherwise... my reasoning is the same... open-source products are not built to the same standards for supportability

So to clarify, the line you think should be drawn is between products that have paid support options and those that don't?

My opinion of moderation activity:

So what about commercial quagga support available from Vyatta?

On your "purpose-built" requirement, are you meaning that some portion of it should be or that the entire stack must be?

e.g., a custom, commercial software distribution running on commodity x86 hardware?

I'm talking about the limits of what they support... that's what we should support

if the vendor only supports the software, then ok... we do the same

That's a reasonably clear distinction, though I still disagree that it's the most useful place to draw a line. A good bit of this is due to my having played with networking in an academic setting and my belief that the commoditization of much of the lower-end equipment that still clearly qualifies as "network engineering" is well underway (meaning, e.g., products that are performing forwarding, terminating tunnels, speaking routing protocols).

I would encourage you to see, especially as the site picks up momentum, whether drawing the line where it is now may be too restrictive in the same way that keeping Linux questions off of Server Fault would have been had SF been around a decade back.

When we see a movement among CIOs to embrace the aforementioned solutions on a regular basis, I think you'll find my agreement... however, at this point, we are nowhere close

need to run...

thank you for the interesting discussion :)

As my first networking mentor, prescient prophet and OpenFlow guru has been telling me, just wait for the first commodified OpenFlow forwarding devices to hit the datacenters. ;-)

@chrylis, I'm old enough to remember other networking "revolutions" like ATM LANE, IP over Glass, etc... all those ideas are sitting in garbage bins now... regarding the SDN / OpenFlow hype, well, we will see ;-)

He was spot-on about MPLS and virtualization generally. We'll see indeed!