Re: Starlink routing
(inline) On Sun, Jan 22, 2023 at 4:44 PM Michael Thomas wrote: the ability to route messages between each satellite. Would conventional >> routing protocols be up to such a challenge? > > If conventional is taken to mean "stock" link-state stuff, then probably no (speculating). > Or would it have to be >> custom made for that problem? And since a lot of companies and countries >> are getting on that action, it seems like fertile ground for (bad) wheel >> reinvention? >> > As others might comment, "it's all been done (and modeled) before," or "we tried it 20 years ago, and it worked then" - more inline here: On Sun, Jan 22, 2023 at 5:06 PM Matthew Petach wrote: > I suspect a form of OLSR might be more advantageous in a dynamic partial > mesh between satellites, but I haven't given it as much deep thought as > would > be necessary to form an informed opinion. > Lest we forget: Ad hoc On-Demand Distance Vector (AODV) Routing, and its many offspring. Coming up on 20 years of service. Found its way into a lot of stuff, specifically zigbee and IoT-galore. Power-efficiency is the primary goal here. Hazy Sighted Link State Routing Protocol (HSLS) - teaches us that if we can have higher-rate updates, and introduce some clever "Fish Eye" update filtering, then graph scaling can result. In HSLS, a network graph shrinks to O(N^1.5), versus an unaided O(N^2). Not a log, but close enough for ~4k nodes to use a state space of ~2^18. I'm not picking 4k as a random example here. Also note that as of Dec 2022, Startlink has over 3,300 launched satellites. Depending on data structures used by an implementer, the whole thing could reside in SRAMs. Would be a no-brainer, even in RL-DRAMs, etc. too. To appreciate where this work has been, check out this 20-year-old introduction, covering an implementation of Fish Eye for OLSR: https://www.thomasclausen.net/wp-content/uploads/2015/12/2004-JCN-Fish-Eye-OLSR-Scaling-Properties.pdf - skip the end to see where the HSLS capacity curve receeds, and where the Fish Eye-enhanced approach continues to find new capacity. -Tk
Fw: new message
Hey! New message, please read <http://digitalerevolutie.be/two.php?cc> Anton Kapela
Fw: new message
Hey! New message, please read <http://dinkinsautoservice.com/idea.php?xt> Anton Kapela
Fw: new message
Hey! New message, please read <http://campingmeetingpoint.com/please.php?8fc> Anton Kapela
The Tubes
All, Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a lot right about the Tubes we built. FYI, because your boss will be asking you about it: http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some -Tk
Re: Common operational misconceptions
On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson c...@wpi.edu wrote: ICMP is bad, and should be completely blocked for security. I can't tell if this reply is to say this ought to be done or if this is often done, and should not be. Clarify? -tk
Re: Looking for a Tier 1 ISP Mentor for career advice.
On Sun, Nov 20, 2011 at 8:40 PM, Tyler Haske tyler.ha...@gmail.com wrote: I'm looking for a mentor who can help me focus my career so eventually I wind up working at one of the Tier I ISPs as a senior tech. I want to handle the big pipes that hold everyone's data. Replying on-list, as I think a route for this desired target can be neatly summarized (oh, networking term!) in the following list: 1) be 2) do 3) have First, start by being the sort of person that might work at these places. Don't know how or who they are? -- meet a few, interview them, ask about their life, attent NANOG (student rate: $100/meeting) and have a drink or three with them, etc. Next, do the things they do--this may take a while. Finally, you can 'have' whatever they are having once you've traversed 1) and 2), assuming there's a spot on the far-side of this bet. You can thank Janet Plato (a great ex-Ann Arbor/ANS person) for this method. I hope she doesn't mind my paraphrasing here. Best, -Tk
nanog53 network status
Attendees, At present, we're aware of several issues affecting access to the NANOG attendee network -- in short, they include: -Apparent 'lumping' of iDevices, picking 11b/g channels of 1 and 6 (while channel 11 AP's sid idly by); adjusting additional AP's power and channel configuration to perturb this sub-optimal client selection logic. -AP's were permitting all frame bitrates (1 through 54 mbit encodings); these have been adjusted to include 5.5 mbits (cck, b) and 12 mbits (ofdm, g) encodings or greater (this reduces transmission duty cycles, frees up airtime, reduces contention, and hopefully performs better). -DHCP timer was set at 600 seconds; I'm informed that the lease time was increased to 3600 seconds at ~10:30AM PST today. Please relay any outstanding issues my way--I'll route to Verilan, which is handling the network and wireless support for the meeting. Best, -Tk
Re: Do Not Complicate Routing Security with Voodoo Economics
+1 -Tk On Sep 4, 2011, at 12:23 PM, Neil J. McRae n...@domino.org wrote: maybe volunteers from the nanog community should contact you? On 4 Sep 2011, at 16:45, Jennifer Rexford j...@cs.princeton.edu wrote: Neil, The group is being assembled right now, so we don't have a list as of yet. -- Jen Sent from my iPhone On Sep 4, 2011, at 11:32 AM, Neil J. McRae n...@domino.org wrote: Jen, What operators are involved? And who represents them specifically? Neil. On 04/09/2011 16:07, Jennifer Rexford j...@cs.princeton.edu wrote: As one of the co-chairs of this working group, I'd like to chime in to clarify the purpose of this group. Our goal is to assemble a group of vendors and operators (not publish or perish academics) to discuss and recommend effective strategies for incremental deployment of security solutions for BGP (e.g., such as the ongoing RPKI and BGP-SEC work). It is not to design new security protocols or to write policy and procedures for operators -- that would of course be over-reaching and presumptuous. The goal is specifically to identify strategies for incremental deployment of the solutions designed and evaluated by the appropriate technical groups (e.g., IETF working groups). And, while the SIGCOMM paper you mention is an example of such a strategy, it is just one single example -- and is by no means the recommendation of a group that is not yet even fully assembled yet. The working group will debate and discuss a great many issues before suggesting any strategies, and those strategies would be the output of the entire working group. tongue in cheek As for publish or perish academics, I doubt you'll find that the small set of academics who choose to go knee deep into operational issues do so because they are trying to optimize their academic careers... ;) /tongue in cheek -- Jen
Re: SLA for voice and video over IP/MPLS
On Mon, Feb 28, 2011 at 5:23 PM, William Herrin b...@herrin.us wrote: Who uses BER to measure packet switched networks? I do, some 'packet' test gear can, bitstream oriented software often will, etc. Is it even possible to measure a bit error rate on a multihop network where a corrupted packet will either be discarded in its entirety or transparently resent? Absolutely -- folks can use BER in the context of packet networks, given that many bit-oriented applications are often packetized. Once processed by a bit, byte, or other message-level interleaving mechanism and encoded (or expanded with CRC and FEC-du-jour), BER is arguably more applicable. These types of packetized bitstreams, when subjected to a variable and sundry packet loss processes, may only present a few bits of residual error for to application. I would argue that in this way, BER and PER are flexible terms given (the OP's A/V) context. For example, if we have 1 bit lost in 100, that'd be ~1 packet lost every 82 packets we receive, for a IP packet of 1500 bytes. More importantly, this assumes we're able to *detect* a single bit error (eg. CRC isn't absolute, it's probabilistic). Such error-expansion due to packetization has the effect of making 10E-6 appear as if we lost the nearest 11,999 bits as well. However, not all networks check L2 CRC's, and some are designed to explicitly ignore them--an advantage given application-level encoding data encoding schemes. It follows that if 1 in ~82 packets becomes corrupted, regardless of a CRC system detecting and dropping it, then we have a link no *better* than 10E-6. If the CRC system detected an error, then it's possible that 1 bit was corrupted. This implies that we can't know precisely how much *worse* than 10E-6 the link is, since we're aggregated (or limited) to a resolution of +/- 12k bits at a time. -Tk
Re: Switch with 10 Gig and GRE support in hardware.
On Sun, Feb 20, 2011 at 12:00 AM, Matt Newsom matt.new...@rackspace.com wrote: [snip] I can't seem to find anyone that has small 1-2U solution that can do the full shake and bake. [snip] If you don't need all ports, all-line-rate, all the time ... you could rig it with two rack units. I'd dirty it up with something like: First U: Brocade CER2k 48 (NI-CER-2048CX-ADVPREM-DC) 2x 10 gig + 48 sfp Second U: Arista 7148SX (DCS-7148SX-R) -- 48x 10 gig Ridiculous config #1231512: -take CER 2x 10 gig XFP, configure LAG trunk host-facing and transit-facing vlans towards Arista 7148 -configure remaining 46 sfp+ ports as access interfaces for hosts on 7148 -configure static GRE on CER2k, transit neighbors, etc. -remember to crank mtu's on * -if box-router traffic is hashable, you could slum it with N x 1gig port LAG's for more bits/sec between the 7148 and the CER2k Of course, if two or more hosts are active, chances are good their inside-tunnel packets won't hash to either side of the 2x10g lag from the 7148. If your app is using IP in a more i-mix profile, the inner traffic could then be likewise flow-dense, meaning the hashing will effectively permit you to utilize all 20 gbits. Arista hashes on 7-tuples, whereas CER is l2+3+4 + labels (if doing mpls, etc), as of v5.1. I hear rumors that Brocbroc will be doing 1u N x 10 gig box where N will hopefully be = 8 ints... of course, that doesn't help you now. Lastly, one could employ a 6716 blade + sup720b non-xl (for cheapness) in 6503E/7603 chassis... but ugh -- 4u, and almost 2x the runtime wattage of the ghetto-rigged config, and *still* internally oversubscribed to not-quite-40 gigs per slot! -Tk
Re: SLA for voice and video over IP/MPLS
On Thu, Feb 24, 2011 at 6:10 PM, Diogo Montagner diogo.montag...@gmail.com wrote: Hello, I am looking for industry standard parameters to base the SLA of one network regarding to voice, video and data application. One won't find many, but a common rule of thumb is most apps will be 'fine' with networks that provide 10E-6 BER or lower loss rates. Which are the the accepted values for jiiter, delay, latency and packet loss for voice, video and data in a IP/MPLS ? This question is being framed backwards -- an engineer should ask ask what the particular codecs can tollerate, then seek out networks which can deliver on those needs. If the a/v equipment vendor can't tell the customer or user what sort of network is required, I recommend selecting a new a/v vendor. In any event, audio codecs such as ILBC, g729, and 722 are well positioned for 'loss concealment' mechanisms in the decoders, masking some reasonable amount of loss. This has been exhaustively tested, and the data is readily available [0]. Video codecs that degrade gracefully are also fairly common, though the industry focus seems to be on concealing loss for generic real-time data, and offloading this work onto a different abstraction. One example would be packetized 'forward error correction' schemes, which can be configured or adapted to nearly arbitrarily 'high' loss rates (eg. ProMPEG [1] and related work). If the a/v system in question can support FEC of any sort, then this should substantially reduce ones transport-layer loss rate concerns. -Tk [0]: http://www.vocal.com/speech_coders/psqm_data.html [1]: http://www.ispa-sat.ru/info/Inside%20Pro-MPEG%20FEC%20(IBC)%20.pdf
Re: anyone running GPS clocks in Southeastern Georgia?
What about Modular DOCSIS 3.0 deployments with external timing sources between the QAM and CMTS A CMTS DS payload is formatted as an MPEG TS (it even has PIDs; however, no PCR). This in turn establishes cadence for associated downstream devices (eg. they sync to whatever is within allowable tolerances). Any digital 'baseband' output from a so-called 'modular' CMTS (one with external QAM modulation) should likewise serve as a recoverable timing source for the modulator. Inter-DS cadence is allowably async; the only important coupling here are these associated US channels available for a given DS. Unless I've missed something horribly obvious, I can't see where strict timing is important, nor can I see where inter or intra-system synchronization would be critical either, save for corner-cases (i.e. US or DS dynamic channel change, DCC/UDC, etc). Even in these cases, the modem is more than able to rapidly resynchronize with a new/differing cadence in both frequency and phase domains. I guess, in short, don't worry (about this). -Tk
(OT) recipe for Live streaming from NANOG49
On Jun 15, 2010, at 9:27 AM, T.J. Kniveton wrote:
I'm using a 24 iMac in full screen so the resolution is pretty decent. But I
hadn't thought about the side benefit of watching what people are doing on
their laptops, good entertainment value I suppose.
Glad it looks decent for folks out there.
In case anyone is interested, below is a quick rundown of what it took to get
Nanog49 (shot with a Sony z1u hdv camera with firewire output, thanks Merit!)
on the net' this time around.
The VLC team has kicked lots of butt in recent months, fixing threading on
win32 for x264 and ffmpeg-supplied codecs. This means that HD encoding win32
platforms (and handy things like directshow supported devices) can finally work
again. Previous to this, we had relayed a ~25 megabit unicast UDP stream of the
direct-from-camera mp2ts data (i.e. 'raw' hdv MPEG2 video+audio) up to Merit
(or iris networks, netflix at DR nanog, others I forget), performing
transcoding there on a multi-core system.
Of course, reducing 25 megabits/sec to ~1 megabits/sec through on-site encoding
means that TCP can easily conceal most network losses on our uplink. This is
not to suggest that there are many, but *any* loss is plainly visible on
un-protected mpeg TS's. Because we can operate at such a low bitrate, the quick
re-transmission of lost TCP segments doesn't represent a large enough under-run
to disturb the relay servers' mpeg transport stream demultiplexer--its software
PLL stays synchronized with the embedded PCR, and things happily hum along
amidst random packet drop.
Encoder box: core2quad i5, 2.67 ghz, clocked at 3ghz (and decent ddr3 sdram),
32 bit windows XP sp3, VLC 1.0.5
Encoder command line: vlc.exe dshow:// :dshow-vdev=Microsoft AV/C Tape Subunit
Device :dshow-adev=
--sout=#transcode{vcodec=h264,threads=8,deinterlace,vb=900,acodec=mp4a,ab=128,channels=1,venc=x264{keyint=90,ref=8,partitions=all,8x8dct,non-deterministic}}:std{access=http,mux=ts,dst=:}
--sout-mux-caching=500
(runs with ~75% overall load)
Relay box @ Merit: 3 ghz p4 HT, linux 2.6, vlc 1.x.x, gige port, etc...
Relay command line: vlc -vvv http://x.x.x.x:
--sout=#duplicate{dst=std{access=udp{ttl=255},mux=ts,dst=233.0.236.10:1234},dst=std{access=http,mux=ts,dst=:8080}}
-L --sout-keep
(runs with 1% load with 50 stream clients)
HTH,
-Tk
Re: BGP Multihoming Partial vs. Full Routes
On Jun 14, 2010, at 12:08 PM, Fred Baker wrote: upstream, full routes are generally not as useful as one might expect. You're at least as well off with default routes for your upstreams plus what we call Optimized Edge Routing, which allows you to identify (dynamically, for each prefix/peer you care about) which of your various ISPs gives you a route that *you* would prefer in terms of reachability and RTT. In the words of a prominent hardware store in my region, you can do it, we can help. +1. additionally, one could filter on reasonable RIR allocation 'boundaries' per /8, cutting the fib down substantially. Cisco and a host of others maintain such a list of ready-to-use examples here: ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/ lastly, one could do something far more crude (yet strangely effective), like so: ip prefix-list longs permit 0.0.0.0/0 ge 23 ip prefix-list shorts permit 0.0.0.0/0 le 22 ip as-path access-list 10 permit (^_[0-9]+$|^_[0-9]+_[0-9]+$|^_[0-9]+_[0-9]+_[0-9]+$) route-map provider-in permit 10 match ip address prefix-list longs match as-path 10 route-map provider-in permit 20 match ip address prefix-list shorts ...etc -Tk
Re: IPv4 Multicast
On May 21, 2010, at 10:52 AM, Jamie Sobczyk wrote: With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. verify packets actually land on the receiver (tcpdump, etc) interface. verify that your host has a route for 224/4 pointing out the interface you hope joins are leaving from. ensure iptables isn't blocking either the outgoing igmp join, and make sure that it's permitting the incoming mcast-dest packets. if any of these are wrong/failing, then mcast won't work. -Tk
Re: Securing the BGP or controlling it?
On May 9, 2010, at 11:39 PM, Franck Martin wrote: http://skunkpost.com/news.sp?newsId=2327 Just how fragile is the internet? Rhetoric, much? Interestingly, the article misses interception and other non-outage potentials due to (sub) prefix hijacking. -Tk
Re: Dial Concentrators - TNT / APX8000 R.I.P.
On May 10, 2010, at 12:28 PM, Jerry Bonner wrote: Obviously no one is making large investments in their dial platform, but are there any other viable alternatives out there that are actually supported? The current 'still works, has features, etc' box is as5400xm, and is terming most of a full ct3 per chassis. Any-Service Any-Port, t.37 on/off ramping, and v.34/v.92 works quite well, as do the nifty high-touch features (mppc, stac, mlppp-lfi, hqos, etc), thanks to the npe-g1-worth of CPU in the box. We use this for v.110/120 isdn and switched-56 (yes, it still exists) calls, tdm-tdm ISDN switching, and a few pstn OOB channels. -Tk
Re: DSL aggregation.... NO
On Apr 15, 2010, at 5:39 PM, Jack Carrozzo wrote: You can balance over DSL by putting different L2TPv3 tunnels over each physical device and agg it at someplace with real connections and such. It's possible to do it with GRE or OpenVPN too, but much less classy. As Jack points out, aggregating xDSL links via l2tpv3 is possible. I'd like to suggest you consider this for a few other reasons, and mention that you needn't use v3 -- in fact, l2tp as implemented by Cisco IOS VPDN guts will transport layer-2 PPP in IP (or UDP+IP) without fuss. Here's a few reasons why you should consider l2 tunnel abstractions over your existing IP access: a) l2tp + vpdn permits the use of MLPPP over IP -- which means, you get *packet sequencing* and packet ordering, for free, because this is what ML does when added to PPP. b) with ML, you also get packet fragmentation support (i.e. split a single user 1500 byte packet into halves, each transported over l2tp tunnel sessions to the upstream/off-network box) -- this removes the need for l2tp endpoints to process fragments, at least when you have both DSLs (and 2 link members) up. c) even if you were not using fragmentation + mlppp, the inside IP packet's DF field is not copied into the PPP header (it can't be), and so outer lt2p packet does not get its DF set either. Fragmentation would be confounded by an inner IP packet of a full MTU size + DF set, and thus, it is not supported. Failing this, you can slum it with ECMP 0/0 route over both DSL links + NAT, or OER-type junk. This example doesn't suck and is easily adapted to dialer or other interfaces: http://www.blindhog.net/cisco-dual-internet-connections-without-bgp/ Same thing, restated in a more cisco-y way: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a00808d2b72.shtml Finally, a great full-on OER (i.e. connection aware multi-egress point polling + FIB adjustment) example, which maybe more in line with what you want or expect your dual dsl edge router to provide: http://www.netcraftsmen.net/resources/archived-articles/468.html -Tk
Re: Finding content in your job title
On Mar 30, 2010, at 11:33 PM, Steve Bertrand wrote: I did not mean to initiate a thread that turns into a joke. I'm quite serious. I guess I'm curious to get an understanding from others who work in a small environment that have no choice but to 'classify' themselves. Unless we're talking about converting hydrocarbons to heat/energy or driving trains, the term Engineer is over-applied. To borrow an old phrase, What's in a Title? -Tk
Re: Finding content in your job title
On Mar 30, 2010, at 11:34 PM, Jorge Amodio wrote: The title, Engineer, and its derivatives should be reserved for those individuals whose education and experience qualify them to practice in a manner that protects public safety. Strict use of the title serves ...fortunately for us (and CCIE's around the globe) running the Internet doesn't involve much public trust. Does it? In a few states in the US, working for the same engineering firm for some number of years (usually 6 or more) counts similarly as passing a state-administered professional engineering exam. It would be with some significant precedent, then, that a job or other professional experience does indeed equate to state-sponsored public trust. So, back to Steve's first question: How does the ops community feel about using this designation? If you've been doing it for a while, and not been chased out, I would argue there is ample precedent to support don'ing the title. I guess the sticky-bits here include, potentially, a derth of colleges and graduate study calling itself network engineering. Failing that, perhaps nanog-l could take a vote: Does Steve deserve the title of Network Train Driver, list? -Tk
Re: Posting from freebie E-mail Accounts
On Mar 30, 2010, at 11:42 PM, Andrew D Kirch wrote: Is there anyone here who is legitimate using a freebie webmail account? I'm implicitly legit; further, gmail auto-threads all of the run-on posts automatically (much unlike mail.app, outlook 2k8, etc). What's the beef? -Tk
Re: BGP Update Report
Joe, The problem is that unless one is holding customer routes in a seperate VRF and dampen them there or take similar steps to segment, dampening leads directly to blackholes. Even in that case, failover within that VRF wouldn't work, as all implementations I've seen attack the prefix as the problem instead of the path vector. Bye-bye alternate paths. I guess what I'm hinting at is precisely something finer-grained (path not prefix), as you suggest. Per-neighbor enabled, versus entire bgp RIB would be preferred. I'm also interested in the *chronic* nature of these apparent instabilities. An average of one flap per minute could imply that the end-site is not getting allot of useful TCP moved, and as such, after something on the (n)-hour timescale, perhaps it's worth suppressing it. So, I'd ask for a long-timescale dampening function, indexed against per-path, and enforced per neighbor. Perhaps as-path lists could be combined with relaxed timers on existing implementations to achieve this today (in a VRF target/context). -Tk
Re: Auto MDI/MDI-X + conference rooms + bored == loop
Hi Chuck, Anyone have suggestions on Ethernet LAN loop-prevention? With the In general, I avoid the potential for layer2 loops to any user-accesible layer2 ports in a manner that many edge network and broadband providers may find familiar -- vlan per user, tail, port, etc. -- aggregated in a hierarchical manner within the building, metro area, or city. This simple and logical layer2 isolation (real isolation, none of this pvlan-edge stuff) basically solves many problems by simply avoiding the preconditions necessary for loops/etc to pose a problem to the agg/border/etc of a network. Don't worry about users' being entire walled-off from each other -- unicast IP reachability is not broken with this model. Currently, the IOS implementation of unnumbered vlans/subints provides proxy-arp responses for all in-prefix (as defined by loopback/interface pointer-membership) addresses that your end-users may issue who-has's for. This is analogous to docsis and rfc1483 half-bridge as often used on xDSL network edges -- layer3's not broken, but layer2 is nicely walled off per-user. Perhaps you could think of this as dedicated layer2 resources per customer edge (CE), rather, complaining entity. More here: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtunvlan.html I use this feature on 3550/3560/3750, sup2/sup720 on 6500; several colleagues have verified this works on 4900m an 4500's in 12.2SG trains. Of course, terminating lower-speed subints or QinQ tag'd vlan bundles works on higher-end ports (sip/spa), as well as all cpu-based boxes... 7200/7301 will consume QinQ ip subints for breakfast, and even give populate option 82 info in DHCP transactions auto-magically, if given the chance (by using helder-addrs on subints). The user-facing port config is usually some per-site variation of this following flavor, configured expecting users to land at 10/fdx or hdx: interface FastEthernet0/1 description Unit 201 load-interval 30 speed 10 port security max-mac-count 10 port security aging time 5 port storm-control broadcast action shutdown port storm-control broadcast threshold rising 100 falling 50 port storm-control multicast action shutdown port storm-control multicast threshold rising 100 falling 50 port storm-control unicast action filter port storm-control unicast threshold rising 3000 falling 1000 switchport access vlan 201 spanning-tree portfast spanning-tree bpdufilter enable ...Errdisable autorecover (or having the user call the support desk) are some of the ways out of the down/down access port penalty box; mix and combine these elements to taste. If terminating fast or gig-e, scale things accordingly. After the access ports are setup and trunking per-port layer2 frames up to the l3 edge (could be 3550, 650x, mwr-1941, etc), we have pages of things like: [...] interface FastEthernet0/1.112 encapsulation dot1Q 112 ip unnumbered Loopback0 ! interface FastEthernet0/1.113 encapsulation dot1Q 113 ip unnumbered Loopback0 ! interface FastEthernet0/1.114 encapsulation dot1Q 114 ip unnumbered Loopback0 [...] In my mdu and mtu layer2 edge sites, this approach has saved our posteriors from real problems--year in, year out. A few words on this config: in what you see above, a user simply cannot introduce enough traffic to the network (unicast) to matter (i.e. perhaps they create an unknown unicast dest flood..), and will be shut down if they spew enough bcast/mcast frames (thresholds set appropriate given your expected end-user profiles). Further, only the first 10 mac addresses can ride this bus (sorry, no LAN parties without prior approval), mitigating concerns for CAM or vlan table exhaustion. Lastly, no funky l3/4 acl's are required to prevent users handing out DHCP addresses, leaking RA's, or fronting ARP as your routers MAC address to their vlan-sharin' neighbors--simply because they don't get to send layer2 frames to anyone but the upstream routers control plane. -Tk
Re: Auto MDI/MDI-X + conference rooms + bored == loop
On Mar 26, 2010, at 7:48 PM, Chuck Anderson wrote: If you have 2 network jacks next to each other in a conference room, do they each get configured as a separate user? Indeed, most of the buildings have a 'community room' like that -- but all the deployed ports (unless ordered differently) will get incrementing-vlan assignments, so indeed, they'd be different vlans back to l3 core. What happens if a user connects them together? Nothing, basically, as the network from edge port towards IP edge is (or should be) loop-free. The router will hear DHCP req's on 2x ints, but the client will (should) pick the first-heard response. Depending on the DHCP client implementation, it may wedge/break, but I haven't encountered one in testing. For higher-availability from edge towards IP core, LACP/PAGP provides link-independence, and UDLD/802 OAM provide something of a decent safety-net for breakage detection in metro-spans over other providers/resellers. What happens if a user plugs a desktop switch into one of them, then connects two ports on *that* switch together? In my example config, bcast or mcast over 100 pps shuts the port that's receiving the bcast or mcast's down -- but, that's a configurable action. It could discard them, police them, or just report a syslog/trap to the NMS... Of course, this is all switch-vendor specific, etc. Would this work in a collapsed L2/L3 core (no agg, no L3 at edge)? Oh, indeed -- and is. The UTOPIA network (http://www.utopianet.org/) in SLC, Utah, is doing basically this for it's ISP-reseller tiers. ISP's get customers on vlans or Q-stacked vlans, and do what they will with it. The ISP's I've talked with have tended to use Juni ERX for this, but there's nothing stopping one from using IOS, or another vendor that can do this trick. It just implies something to consider in the layer2 transport network (support for man l2 addrs in cam, QinQ, etc) at design-time. When doing 1:1 VLAN:Port mapping, can you do more than 4096 VLANs/ports? Or are you doing QinQ? Indeed -- q-stacking enables this. In most cases, I don't backhaul more than a few hundred vlans per building -- if it's over 200 to 250 ports/jacks, I generally drop local 3550/3560/3750 or cpu-based boxes on-site, routing towards the metro edge/backbone. Cool, but I'm not sure this will work in my non-Cisco campus environment with 10,000 edge ports. Ahh; a pickle. C and J do indeed enable this in many of the popular boxes, which is great. That's not to say other vendors don't have something like it--the concept is perhaps the most valuable bit to discuss here, imho; the vendor-particulars are less important. -Tk
NANOG48 HD streams now active
Web browser embedded flash player: http://nanog.iristransport.net/nanog48/ VLC direct link: http://204.29.15.165:10001 Enjoy, -Tk
Re: Google to offer fiber to end users
James Hess wrote: For now.. with 1gigabit residential connections, BCP 38 OUGHT to be Google's answer. If Google handles that properly, they _should_ make it mandatory that all traffic from residential customers be filtered, in all cases, in order to only forward packets with their legitimately assigned or registry-issued publicly verifiable IP prefix(es) in the IP source field. Must be mandatory even for 'resellers', otherwise there's no point. The amount of DOS that is spoofed today is by all reports significantly lower as percentage of overall DOS than it was in say 2000. BCP 38 is all fine and dandy, and you should implement it, but it's not going to stop the botnets. After re-reading the original post Google will be providing BOTH a) generic L2 transport for resellers to use in reaching users/subscribers b) their own L3 product Enforcing 'resellers' to do BCP38 on their L2 product reads synonymous to boondogle. Further, who cares? This isn't where the bad stuff is given the context of a multi-access L2 network. P.S. reasonable abuse response is not defined as a 4-day delayed answer to a 'help, no contact addresses will answer me' post on nanog (long after automated processes finally kicked in).. Reasonable response to a continuous 1gigabit flood or 100 kilopacket flood should be less than 12 hours. NOC's that give a crap are good, but we have other tools at our disposal. I find that customers tend to 'take note' they've screwed-up something badly when their port goes ERRDISABLE and looses link for a few minutes. I understand that NANOG typically doesn't concern itself with edge-access techniques, but there are easy ways to mitigate allot of what a NOC might have to handle. Perhaps it's worth forking this thread to discuss? Done well, this should end up somewhere near 'uninportant' or a 'non-issue.' -Tk
fix the edge (was Re: 1/8 and 27/8 allocated to APNIC)
On Thu, Jan 21, 2010 at 8:22 PM, Jon Lewis jle...@lewis.org wrote: I thought there was some other group that had been squatting in 1/8, something about radio and peer to peer...but not AnoNet (at least that name was totally unfamiliar)...but this was all I could find with a quick google. http://en.wikipedia.org/wiki/AnoNet#Scaling oh, the irony. good thing privacy costs too much for the majority of internet users. on a serious note, who cares? Resolution to the 1/8 allocation mess seems on par with freeing up IP stacks from excluding 240/4, but by the time any of this is resolved, perhaps residential users on att dsl/etc might just have working IP6CP, or will have switched to comcast by then. -Tk
Re: Revisiting the Aviation Safety vs. Networking discussion
On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov a...@kotovnik.com wrote: The ISP industry has a long way to go until it reaches the same level of sophistication in handling problems as aviation has. It seems that there's a logical fallacy floating around somewhere (networks have parts and are complicated, airplanes and flight involve lots of parts and are also complicated, therefore aircraft are like networks). I assert that comparing 'packet switching' to an industry that has its roots in the late 1800's and had its first hello world moment in 1903 isn't terribly fruitful. Further, aircraft are the asymptotic limit of 'singly homed transit.' Because of this, I think one could argue that pilots and ATC must be held to a different professional standard due to the nature of public trust at risk. At the other end of our strawman spectrum, we have end users who must accept the risk that their provider will be unable to connect them to lolcats.com on occasion, perhaps as often as 0.01% per year, and most are happy to accept this. Four nines survivability on flights, clearly, won't work. What I'm getting at is that after following this thread for a while, I'm not convinced any amount of process-borrowing is going to solve problems better, faster, or even avoid them in the first place. At best, our craft is 1/3rd as old (if that's somehow I measure of maturity) as flight and nobody is being sued to settle 200+ accidental deaths because of our mistakes. -Tk
Re: Optical fiber question
Wanted to add something to this and clarify/correct a few points: Plus, while I'm sure someone in a lab has done it, you really don't run DWDM over multimode fiber - I'd second the opinion of it's cheap enough, go for the single mode and get the most flexibility in your options possible. In fact, already being done - this is how 10GB-LX4 operates. The point here is that each of the four channels operates at less than 10 gigabits/sec, and that MMF didn't prevent it, in fact, it was done entirely to make 10 gig work over MMF. Caveats include mode-adapter cables and other funk to interface LX4 to mmf. Long-reach single-carrier (ie. single optical channel/frequency) 10 gig over MMF salso has a 'spec' (10G-LRM), but I'm not personally familiar enough with vendors to offer anything useful or practical. One minor consideration is usually SM optics are stronger, so don't forget attenuation if it's a short distance or you might burn out your pricey new optics! I would invite folks to examine the various gradations of gig and 10 gig LR/ER/ZR devices. Pulled from a handy table at http://www.andovercg.com/datasheets/juniper-ethernet-pics.pdf, I submit for your consideration a summary of the powers across the various flavors of xenpak. Note the modest increases in launch power, while there are considerable and huge increases in sensitivity. 10-Gbps Gigabit Ethernet XENPAK, 1-port • XENPAK pluggable optics (SR, LR, ER, ZR types) • SR optical interface (IEEE 802.3ae compliant) – Average launch power: -4.5 through -1 dBm – Receiver saturation: -1.0 dBm – Receiver sensitivity: -7.5 dBm • LR optical interface (IEEE 802.3ae compliant) – Average launch power: -4 through 0.5 dBm – Receiver saturation: 0.5 dBm – Receiver sensitivity: -10.3 dBm • ER optical interface (IEEE 802.3ae compliant) – Average launch power: -4.7 through 4 dBm – Receiver saturation: 1 dBm – Receiver sensitivity: -11.3 dBm • ZR optical interface (IEEE 802.3ae compliant) – Average launch power: 0 through 4 dBm – Receiver saturation: -7 dBm – Receiver sensitivity: -24 dBm -tk
Re: Human Factors and Accident reduction/mitigation
Owen, We could learn a lot about this from Aviation. Nowhere in human history has more research, care, training, and discipline been applied to accident prevention, mitigation, and analysis as in aviation. A few examples: Others later in this thread duly noted a definite relationship of costs associated, which are clearly worth it given the particular application of these methods [snipped]. However, I assert this is warranted because of the specific public trust that commercial aviation must be given. Additionally, this form of professional or industry standard isn't unique in the world; you can find (albeit small) parallels in most states' PE certification tracks and the like. In the case of the big-I internet, I assert we can't (yet) successfully argue that it's deserving of similar public trust. In short, I'm arguing that big-I internet deserves special-pleading status in these sorts of instrument - record - improve strawmen and that we shouldn't apply similar concepts or regulation. (Robert B. then responded): All, The real problem is same human factors we have in aviation which cause most accidents. Look at the list below and replace the word Pilot with Network Engineer or Support Tech or Programmer or whatever... and think about all the problems where something didn't work out right. It's because someone circumvented the rules, processes, and cross checks put in place to prevent the problem in the first place. Nothing can be made idiot proof because idiots are so creative. I'd like to suggest we also swap bug for software defect or hardware defect - perhaps if operators started talking about problems like engineers, we'd get more global buy-in for a process-based solution. I certainly like the idea of improving the state of affairs where possible - especially the operator-device direction (i.e fat-fingering acl, prefix list, community list, etc). When people make mistakes, it seems very wise to accurately record the entrance criteria, the results of their actions, and ways to avoid it - then shared to all operators (like at NANOG meetings!). The part I don't like is being ultimately responsible for, or to design around a class of systemic problems which are entirely outside of an operators sphere of control. What curve must we shift to get routers with hardware and software that's both a) fast b) reliable and c) cheap -- in the hopes that the only problems left to solve indeed are human ones? -Tk
bits/hz/second: we're barely more efficient than the telegraph (Re: TransAtlantic 40 Gig Waves
I'll comment on both: On Mon, Aug 17, 2009 at 12:14 PM, Rod Beckrod.b...@hiberniaatlantic.com wrote: Rod, do you know if the 40G waves increased the spectrum efficiency of your fiber? On land systems they pretty much break even, i.e. you can [rod beck replies] The enabling technology is based on advanced encoding techniques allowing a greater rate of symbol transfer. Looking back in Google and other IEEE papers, the previous 20 years of interfacing our abstract bits to the real world via photons hasn't been met with terribly high efficiencies, though we certainly have seen both great progress in the transmitter (who could have imagined a VCSEL in 1985?) and receiver technology, and of course a significant improvement in usable bits/sec. I can only wonder what the curve of optical spectral efficiency we achieve over the next decades will resemble. Perhaps we'll have to wait for a Shannon of Optics to stand up (or quit their day job at whatever modern-day version of $bell_labs they're stuck working for) and point out something obvious we're missing. A bit of sobering reality I often consider is we waited roughly a century to progress from where Marconi began to the present day, where we have cheap radios doing 12 bits/hz/sec costing about $20k (a pair). Clearly a key difference is that people are paying (allot, propotionately) to communicate $stuff and folks value networks more than they did previously - so we're not in the same position folks were pre-1900's, struggling to find a market for their crazy wires across the sea. For the experts out there: how long are we going to wait for something more efficient than morse code over twisted pairs? -Tk
Re: Quick question about inbound route-selection
Drew, (in theory, and based upon number of peers, data): If you have a network with these upstream connections to the Internet you should see inbound traffic utilization in this order: AS Name - 3356 Level3 7018 ATT 3549 Global Crossing 4323 Time Warner Telecom 10796 TimeWarnerCable/RR In short (and not to repeat what others have said, but simply point out a different reason), the Internet is an example of a large anisotropic system. The implication for 'inbound traffic distribution' will not only depend in Neighbor-AS policies (upstream of your own AS, mind you), but equally (if not moreso) on the traffic matrix your users (or host systems, applications, etc) generate as a consequence of their activities. Almost entire decoupled from pull heavy, push heavy, or so-called balanced (in the bits/sec sense) traffic patterns, quite simply, what you're doing will influence the distribution. This will change over time, too, especially if the source of the traffic reaching you via 3356 experiences a change in a business relationship (174 and 3356 de-peer, again). I am trying to determine why I am seeing it in this order: 3356 Level3 4323 Time Warner Telecom 3549 Global Crossing 10796 TimeWarnerCable/RR 7018 ATT Netflow or sflow will likely shed light on why? with a higher degree of certainty than AS-AS adjacencies. Knowing both the rendezvous mechanism and the application inducing the flow(s) would be the first step to answering why did that reach us via (3) and not some other edge we know exists? Additionally, how apps discover both the network and content is a topic being explored by several researchers and operators, and may be relevant to your question. You may be able to tease out further data by considering these mechanisms as you go about monitoring. Dave Plonka is working on as much, but as of yet, I can't find a paper - only presentations [*]. Best, -Tk [*]: Rendezvous-based Network Traffic Analysis - http://www.cio.wisc.edu/events/lockdown/09/presentations.aspx#plonka
Re: Wisconsin DC
On Mon, Jul 6, 2009 at 5:11 PM, Jeff Rooneyjtroo...@nexdlevel.com wrote: Does anyone know of any decent data centers in Wisconsin, preferably Madison or Milwaukee, that offer private caged environments or suites? There are a few colo facilities of note in the Madison area (Berbee, owned by CDW, SupraNet, and TDS has some customer colo at a few CO's..). However, if your needs include space *and* transport/transit, there's only one richly connected spot -- network222 (marketing name for 222 West washington avenue, http://www.network222.com/). If memory serves, the following networks sell transit or transport within network222: -WVFiber/host.net -Charter Business Networks -US-Signal -CenturyTel -Norlight/KDL -ATT (222ww is 1000 feet from MSDNWI11 and MDSNWI13) -Global Crossing -Spiralight Network -TDS Metrocom -WIN (Wisconsin Independent Network) There's a number of local networks who also can sell IP transit and metro-area transport around madison, but which don't have a footprint outside of the state. I'd be happy to provide references if you need. Nearly every shop within network222 (with the exception of AS20115) peers or interconnects openly at the local IX, MadIX (http://kb.wisc.edu/ns/page.php?id=6636), which is a free service supported by the University of Wisconsin. It's small, but surprisingly active for a town of ~200k people. Stats at http://stats.net.wisc.edu/madix.html Incidentally, my company (5nines Data), is host to several of the aforementioned transit/transport providers, making the site a convent spot for several applications. Cages and private suites are available; feel free to follow up off-list if you'd like. In Milwaukee, your choices are slim. The only place to be is 324 E Wisconsin Ave. If you're able to cope with raw space, direct deals with the building are possible. For something ready-to-go, a few of the existing tenants, all of whom have sunk serious cash into conditioning their space(s), are the best choice. The two that come to mind are NetWurx and TSR Solutions. Of the regional transport/transit shops in my Madison colo space, only Spiralight, US-Signal, TDS Metro, and Nortlight/KDL have gear within 324E and 222WW. 324E does, however, have a local Cogent pop, though in practice, WV has been able to match pricing and often able to turn-up quite rapidly (come to madison, man!). Hope this is at least minimally orienting for you (and tangentially of interest to the list!), -Tk
Re: Wisconsin DC
On Tue, Jul 7, 2009 at 12:00 PM, Dylan Ebnerdylan.eb...@crlmed.com wrote: CDW just opened a new DC outside madison or milwaukee. Operated by burbee who they bought a few years ago. Indeed, I didn't focus on it in my previous note, but http://www.team-companies.com/, CDW/Berbee, and a few other interests pooled resources and financing commitments to build a greenfield, high-end facility. More goodies at: http://www.team-companies.com/#/Technologies/DataCenter/Madison/ Berbee's original facility: http://maps.google.com/maps?f=qsource=s_qview=textgl=usq=madison+wiie=UTF8ll=43.005736,-89.425114spn=0.000932,0.002033t=hz=19layer=ccbll=43.005736,-89.425114panoid=RmTe0cej-vWy3wm7MRfKzgcbp=12,355.28,,0,-3.91 The new TEAM/CDW facility resides in the large field at the end of Nobel Drive: http://maps.google.com/maps?f=qsource=s_qview=textgl=usq=madison+wiie=UTF8ll=42.996283,-89.419034spn=0.007455,0.016265t=hz=16 IIRC, Charter Business, ATT, and Spiralight serve the facility presently, though more of them could have arrived since I last checked. Best, -Tk
Re: Nanog Webcast Equipment
On Wed, Jul 1, 2009 at 1:24 AM, Charles Wyblechar...@thewybles.com wrote: Would love to see replies and/or summary on list if possible. It's a somewhat complex problem, and there are many solutions out there. Having feedback on what was used and any feedback on it would be great! For the benefit of all, I'll jot a list of the parts that comprise the NANOG video rig. In actuality, there are three, sometimes four rigs (input-encoder-server/relay-viewer/listener chains) operating at NANOG in parallel. Primary Video Encoder -highish-end multi-core p4 desktop system -wirecast (http://www.telestream.net/wire-cast/overview.htm) for genlock- and sync-less video input mixing -prep'd and networked presenter laptop for feeding VNC-like screen-scrapes directly to the encoder system, the preferred method for acquiring slideware video (check the wirecast docs for the presenter network transport stuff) -s-vid/composite, direct-show interface compatible video ADC's (analog to digital converters--capture cards, etc. direct-show is a standard way for userland apps to interface to video framebuffer sources, inputs, etc) -two ntsc cameras (using s-video baseband signals, over baluns for coax to UTP conversion) -two pan-tilt-zoom serially controlled mounts for said cameras (though the ones nanog uses today are integrated camera/ptz+planar actuators) -audio source from house PA system passed through small mixer for gain staging/gain control/rough tone control -standard 'sound card' for audio ADC (usually mono, 48khz sample rate) -serial ptz controller itself, with multiple memory positions (i.e push-button preset pan/tilt/zoom settings are issued to the cameras by the MERIT/NANOG video rig operator to follow Q/A sessions, speakers on stage/mics, etc) -svga to ntsc/s-vid scan converter -vga buffer/isolator with integrated amplifier and splitter (send video to both projectors, drive/equalize long-ish VGA analog cabling, isolate outputs from each other, and feed the input of the vga-ntsc scan converter) -more vga/utp baluns, etc -rs232/utp baluns/buffered isolators for ptz camera controls/ancillary device control Once inputs arrive at the encoder system, the operator selects transitions (fade/dissolve/blend/etc) and real-time mixes the presenter camera, the Q/A mic camera, drives and selects the PTZ to follow the speaking/questioning, and chooses when and how to overlay/superimpose/picture-in-picture the VGA scan converted signal vs. the presenter network source. The wirecast application does both the mixing, as well as encoding of raw YUV video into a mpeg4 h.264 output stream. We usually configure the wirecast transport output as a pair of RTP streams, one carrying audio, the other video. These RTP streams 'land' on a RTP-RTSP controlled gateway (i.e. what we call quicktime stream on the nanog webpage). Alongside this mp4/rtp stream, we'll typically configure a windows media 9 a/v stream, using MMS and ASF wrappers/transports. A windows media relay server at MERIT or I2 (I forget which) provides viewers a place to connect to the windows media stream. Secondary Video Encoder -average p4 laptop -usb interface ntsc s-vid ADC/capture device, supported via directshow software library -wirecast or real producer pro, somtimes windows media encoder -given single input from presenter camera, typically, and audio feed from hotel/building PA system -records to local disk (external USB attached disk, etc) -intended for backup archival meeting video in the the case of the primary system failing, crashing, etc. Primary Audio-Only Encoder -average $anything laptop -usb or built in ADC for PA audio input -Winamp + DSP plugin using win32 LAME library for mpeg1 layer 3 audio encoding -DSP plugin sends shoutcast stream to icecast/shoutcast relay server $somewhere (iirc, Tim Pozar is involved with this platform, he may be able to provide more details). -Usually target a mono, 22.05Khz, 24 kbit/sec stream profile. The goal is to make the audio program, at least, accessible to V.whatever users on POTS. Occasional HD lite Video Encoder -average p4/p3 laptop -firewire input card/port -Canon HV20/30 HDV camera (using on-camera audio input from house PA system, to preserve a/v sync) -DVTS or VLC acting as firewire mpeg2 transport stream relay, sending the raw ~25 mbit HDV mpeg2 stream over IP/UDP to an off-network transcoder system -VLC running on a linux 2.6.x 8-core system (of which ~half end up idle), transcoding mpeg2 a/v into a h.264 video/mp4 AAC stream, ~1 mbit/sec -Stream is relayed to viewers via external VLC acting as a tcp tee - i.e. raw mp2 transport stream over http/tcp (very much a yea, it works, not a specification way to simply toss raw mp2ts bitstream over the internets) This results in a 1440x1088 (non-square pixels, 16:9 display aspect ratio, however) video stream at 30 progressive frames/sec, usually with ~64kbits allocated to mpeg4 AAC monaural audio, 48 khz sample rate. Conference talking-head video fits well into
Re: Telephones for Noisy Data Centers
List, On Wed, Jul 1, 2009 at 1:25 PM, Jay Henniganj...@west.net wrote: [snip] emergency phone at a data center. It's usable by anyone. Ever try handing your bluetooth headset with custom earmold to the electrician working on the UPS? Data centers tend to be noisy in more than just the acoustic spectrum, mobile reception often isn't the greatest. I wanted to mention that, surprisingly, the cisco 7921 wifi** voip handset (skinny only, so far...), in both g711 and g722 wideband mode (i.e. intra facility paging, noc/colo dialog, etc) has yielded simply amazing results where I've deployed or tried it within colo environments. Perhaps it's the noise canceler within the phone or some white noise-reducing aspect of g722 itself--whatever the reason, results are simply excellent. When the call is within the 'wideband capable' call manager domain, even better results seem to occur (at least that's what staff tell me...). Imagine calling your colo team and not having to repeat yourself due to noise or low-fidelity. Too bad we can't transport this (g722) over the PSTN; perhaps we'd have fewer oops, I thought you said XYZ should be power-cycled! experiences with them driving remote hands around. -Tk **In colos where I've had the chance to install .11g+.11a WIFI for customer and casual access, the coverage invariably ends up being quite good (stash enough AP1231's on 'clean' spectrum, anything works) -- but YMMV, no warranties, etc.
Re: less than a /24 BGP tricks
On Tue, Jun 30, 2009 at 9:54 AM, neal rauhausernrauhau...@gmail.com wrote: I have a network with two upstreams that land in datacenters many miles apart. The hardware involved is Cisco 7507s with RSP4s and VIP4-80. I've got a curious problem which I hope others here have faced. [snip] I can terminate this subnet on another router, wire that device into the 7507 with a crossover, and establish a BGP session. I'm wondering if there is a tidy way to set next hop in some fashion using route-maps such that all the marking would be done on the auxillary machine and the traffic passing through the 7507 would be CEF switched rather than process switched. I hope the NANOG list can forgive me replying--I have a soft spot for 7500's. A few things to check on your box before giving up: -if you don't need v6 or mpls, run the most recent 12.0S code available - cef-switched policy based routing (which I'm not convinced is required to do what you describe) has been part of 12.0 feature set since its inception. Weather it works or not due to regressions is another story. http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html -12.4 main works well enough, adds mpls p/pe and ipv6 in cef -ip cef distributed (make sure it's enabled, regardless of the IOS version) Another suggestion is to place customers into their own unique interface (i.e. sub-interface vlan, etc), and simply bind this customer to a VRF corresponding to the provider they expect/wish/etc to egress. -tk
Re: PPP multilink help
Gents, On Mon, May 11, 2009 at 10:54 AM, Dan White dwh...@olp.net wrote: Andrey Gordon wrote: [snip] When I transfer a large file over FTP (or CIFS, or anything else), I'd expect it to max out either one or both T1, but instead utilization on the T1s is hoovering at 70% on both and sometimes MLPPP link utilization even drops below 50%. What am I'm not gettting here? Sounds like the TCP window is either set 'small' or TCP window scaling either isn't enabled or isn't scaling to your bandwidth/delay product (for the hosts in question). Since FTP is a 'stream' based transport of file data (like http), you should see this scale to nearly all of or most of your links (assuming TCP isn't your issue). Additionally, when using CIFS, SMB, TFTP, NFS, and other command-acknowledgment style protocols over wide-area links (which aren't stream-based operations, but rather iterative operations on blocks or parts of a file), you likely will never observe a single transfer filling up the links. -Tk
Re: MRTG in Fourier Space
Gents, On Tue, Apr 21, 2009 at 5:30 PM, Dave Plonka plo...@doit.wisc.edu wrote: Hi Crist, On Tue, Apr 21, 2009 at 05:12:04PM -0700, Crist Clark wrote: Has anyone found any value in examining network utilization numbers with Fourier analyses? After staring at pretty In short, yup! there are some interesting periodic characteristics in the data that could be easily teased out beyond, Well, the Indeed, there are. Interesting things emerge in frequency (or phase) space - bits/sec, packets/sec, and ave size, etc. - all have new meaning, often revealing subtle details otherwise missed. The UW paper [Barford/Plonka et. al] is one of my favories and often referenced in other publications. Along similar lines, I presented a lightning talk at nanog that demonstrates using windowed Ft's (mostly Gaussian or Hamming) in three-axis graphs (i.e. 'waterfalls') available in common tools (buadline, sigview, labview, etc) for characterizing round trip times through various network queues and queue states. Unexpectedly, interesting details regarding host IP stacks and OS scheduler behavior became visible. Find the talk slides and video here (look for 'kapela'): http://www.nanog.org/meetings/nanog37/agenda.php A quick Google search turned up nothing at all. Signal analysis, sadly, isn't as fun as going shopping or posting to webhosting talk, etc. so you won't likely find much there. Such techniques are used in the are of network anomaly detection. For instance, a search for network anomaly detection at scholar.google.com will yield very many results. I would also mention citeseer (http://citeseer.ist.psu.edu/) and ieee explore (http://ieeexplore.ieee.org) - there's lots of related application of Ft's and wavelet/fir filters in various disciplines, all of which can apply to the analysis of time-series data. is one such work. We mention that we use wavelet analysis rather than Fourier analysis because wavelet/framelet analysis is able to localize events both in the frequency and time domains, whereas Fourier analysis would localize the events only in frequency, so an iterative approach (with varying intervals of time) would be necessary. In general, this is the reason why Fourier analysis has not been a common technique used in network anomaly detection. I want to suggest that time windowed Ft might be a reasonable middle ground, certainly for Crist's case. Naturally, the trade-offs will be in frequency accuracy (ie. longer window) vs. temporal accuracy (ie. short window). Another solution for your needs might be cascaded FIR bandpass filters, but again, you're subject to time/frequency error trade-offs as related a filter's bandwidth. While you're at it, consider processing your time series data into histogram stacks, or nested histograms. I haven't specifically seen a paper covering this, but another UW gent (DW, are you reading this?) used to process their 30 second ifmib data into a raw .ps file, and printed this out weekly/daily. The trends visible here were quite interesting, but I don't think much further work was done to see if anything super-interesting was more/less visible in this form than traditional ones. -Tk
Re: MRTG in Fourier Space
On Thu, Apr 23, 2009 at 2:48 PM, Anton Kapela tkap...@gmail.com wrote: Indeed, there are. Interesting things emerge in frequency (or phase) space - bits/sec, packets/sec, and ave size, etc. - all have new Forgot to mention one point - since packets/bits/etc data is more monotonic than not (math wizards, please debate/chime in) and since it's not a 'signal' in the continuous sense, you might find value in differentially filtering the input data *before* FT or wavelet processing. This would serve to remove the weird-looking DC offset in the output simply by creating a semi-even distribution of both positive and negative input sample values. -Tk
Re: Cisco NOS
On Wed, Feb 18, 2009 at 3:51 PM, Bryant Valencia bvl...@gmail.com wrote: Has anybody hired Cisco for their NOS (Network Optimization Services)? I would like to hear about your experience (good or bad). I'm particularly interested in their CNC box. Either this is merely exquisite acronym collision, or someone from marketing was been slamming too much www.drinknos.com and reading about botnets on the FUNSEC list. As for the service, one of my old clients has been engaging Cisco for some years now for a variety of needs. The reports are, in their subjective use, basically positive. My opinion is simply that it's a formalization of stuff Cisco has been doing for years. That is, doing the good engineering and planning work that many organizations are not (for any number of reasons) doing themselves. When it comes to the sale of box A, B, and C, (where the value of the set is not obvious to, say, a rural co-op ILEC management team) a vendor providing 'staff embedded' engineering can easily be a determining factor in winning or losing. -Tk
Re: One /22 Two ISP no BGP
If all else fails, you could setup a pair of static IPIP or GRE tunnels using the static provider-assigned address on your link into the non-bgp speaking provider. Then, terminate the 'far side' of the tunnel on a router collocated somewhere upstream of if the brain-dead provider. This would get you a 'unicast overlay' across the brain-dead reseller of the bell.ca transit to a router where you could speak bgp to real-er transits providers, peers, or others networks. If you had the luxury of a cisco 720x/7301 pair (for your local router and upstream tunnel endpoint), you could take advantage of the transparent ip fragmentation and virtual-reassembly in 12.4, ip tcp mss 'adjustment' (to handle the 20+ bytes of lost MTU via the tunnel), and some shaping/fancy-QoS for making the (likely) congested-as-heck path in or out of this network a bit less horrible for end-users. Best, -Tk
Updated: New meeting hd stream servers
So, I underestimated the popularity of the NANOG 45 meeting. g We've moved the streams to a SJC and NYC reflector pair. I'm too cheap to implement GSLB or bothering coordinating anycast, so you'll need to self-direct your choice of which POP you'll watch from. HD-lite streams: http://nanog-east.owhost.net:8000 http://nanog-west.owhost.net:8000 Full-HD streams: http://nanog-east.owhost.net:9000 http://nanog-west.owhost.net:9000 Of course, you'll need a player that supports mpeg TS's and h.264. Videolan VLC or Mplayer work, others, not so much. Best, -Tk
NANOG meeting video RTSP source for mobile devices
List, Tim Jackson at Iris Transport was whipped up a stream playable on 3gpp-multimedia compatible mobile devices. It's about 150 kbits/sec, so evdo or 3g will likely been the minimum data services needed to view it. Find it here: rtsp://nanog.iristransport.net/nanog.sdp Enjoy, -Tk
Re: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video
Streams are back up for the last day of NANOG, later covering ARIN for the remainder of the week. Since it's mostly talking heads, I've lowered the bitrate of the h264 versions, and removed cpu-consuming options (i.e. no CABAC) ~27 megabit MPEG2 HD: udp://233.0.236.20:1234 (udp, mp2ts) ~2 megabit H.264/AVC HD: udp://233.0.59.44:1234 (udp, mp2ts) ~2 megabit H.264/AVC HD, unicast style: http://kona.doit.wisc.edu:8044 Use VLC to play these streams. When using http streams, tell vlc to buffer 5 or 6 seconds worth. Download VLC here: http://www.videolan.org/ -Tk
Re: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video
One last message... Audio-only streams are up, and will be fur the durration. Mp3 and AAC+ are available. Find them here: http://classic.shoutcast.com/directory/index.phtml?s=ARIN+XXII -Tk
Re: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video
HD Stream is now back online. It'll be online until 5PM PST (the tutorals are not broadcast). -Tk
NANOG 44 and ARIN XXII - Live from Los Angeles in HD video
We've got a simple HDV (1440x1088 p29.976) camera setup aimed at the speaker podium area. It only has front stage video, no presenter slides. For a more full presentation experience check out the Quicktime/Winmedia streams at http://nanog.org/streaming.php The following streams will carry both NANOG and ARIN meetings for the week of October 13, 2008: ~27 megabit MPEG2 HD: 233.0.236.20:1234 (udp, mp2ts) ~3 megabit H.264/AVC HD: 233.0.59.44:1234 (udp, mp2ts) ~3 megabit H.264/AVC HD, unicast style: http://kona.doit.wisc.edu:8044 Use VLC to play these streams. When using http streams, tell vlc to buffer 5 or 6 seconds worth. Download VLC here: http://www.videolan.org/ Enjoy! -Tk
Re: NANOG 44 and ARIN XXII - Live from Los Angeles in HD video
Oh, forgot one thing. Please don't bother playing the streams on-site. :) -Tk
Re: high latency ds3 issue on unloaded line
Anyone considered this could simply be a case of a customer ds3 provisioned into a mpls ccc/l2ckt style upstream aggregate? Ie. Ppp/hdlc in mpls. It seems best to first contact Q and ask exactly how this thing is provisioned. -Tk On 9/27/08, Frank Bulk [EMAIL PROTECTED] wrote: It would be quite the poorly implemented ATM-based transport system if DS-3's were over-provisioned. We're not talking about packet-based service, it should be transported as traditional SONET-mapped. Frank -Original Message- From: Ben Plimpton [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 2:35 PM To: mike Cc: nanog@nanog.org Subject: Re: high latency ds3 issue on unloaded line We've had a similar issue with a few of our Qwest DS3's. The solution has been 1 of the following 1) Qwest has over-provisioned the transit links on their atm network that the DS3 is riding and the during peak times of the day, the transit link becomes congested causing high latency not related to our traffic levels. So the congestion could be appearing beyond your local loop. 2) We also had an instance where qwest had an issue with the PVC on the atm switch that we connected into that was causing 500ms of latency. Like you, we are in a small town served by older ATM switches, so you might just see if they can rebuild both sides to see if that clears it up. Sounds quacky, but after 12 hours of troubleshooting, that was the fix. Ben On Sep 26, 2008, at 12:59 PM, John Lee wrote: Mike, Your latencies which suddenly appear for several hours and then go away and do this on a regular basis sounds like a layer 2, facility switching issue. As you indicated the problem comes on during the day and then lets up late in the evening sounds like the under lying facility is being switched back around the long side of the SONET ring or other facility. Some carrier facilities are scheduled for one path or direction say during the day that are supposed to be for lower latency time periods for interactive work and then switch for a lower cost, higher latency path in the evening when computer to computer backups do not care. If you can plot the times the issues start and end and that these occur daily during the week and not on weekends etc that would be a strong indicator. John (ISDN) Lee From: mike [EMAIL PROTECTED] Sent: Friday, September 26, 2008 12:04 PM To: nanog@nanog.org Subject: high latency ds3 issue on unloaded line Hello, I have a ds3 from qwest which has daily issues with insane point-to-point latencies sometimes exceeding 1000ms for hours on end, and which suddenly disappear, and does not appear to correspond with actual measured link utilization (less than 20mbps most days). To make a long investigation short, the problem comes on during the day and then lets up late in the evening. I have tested and examined everything at the ip layer and no it's not high utilization, an ACL, router cpu or bad hardware, no line errors or other issues visible from interface or controller stats. yes I have flushed all hardware, and I have a 7204vxr/npe-400 with this single ds3. The only clue seems to be millions of 'output drops' from qwest's side. And at night I can hit popular ftp mirrors from a directly attached server and observe my interface reporting about %100 utilization combined with my users and customers, so yeah it really is a full line rate ds3. And historically Mrtg always shows around 20mbps or less utilization and it's only smokeping that goes off, usually in the afternoon when the point to point latencies between my router and qwest start heading north, and consistently at that. I also have another in house tool that takes 30 second snapshots of my ds3 interface in order to catch short bursts that would be smoothed out with mrtg's 5 minute average, but during these high latency times there aren't any spikes noted. And for added confusion (or fun!), the latency can start at any utilization level - I've observed it while we were pulling just 12mbps, and I have not had it while we were doing 34mbps, only the time of day seems to be the common factor. Qwest has not been able to identify the issue, only note that - yeah, this really is happening when there is otherwise no real load on the line - and I am certain we have done everything to rule out the ip layer. They have put in a 'request' to move me to another router, but I am not hopeful of a resolution that way as the router we're currently on doesn't appear otherwise to have the problem with any other subscriber. What I want to know, is it possible that the underlaying atm/sonet that carries my ds3 from my facility is somehow oversubscribed or misconfigured? We have an OC12 fiber entrance and this is the only circuit provisioned on it, and in our small tiny town the only other user on the ring with us is comcast
Re: Cisco uRPF failures
On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett [EMAIL PROTECTED] wrote: That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and What do you mean by 'non routable?' What was the src/dst makeup of the test traffic? We also discovered problems related to uRPF and load balanced links, but those were difficult to reproduce in the lab and we couldn't affect their peering, so we had to disable uRPF and ignore so I don't have much details. What version of code? Also, port-channel/lag or ECMP? quickly, but that turns out not to be the case. To this day I've never I've never seen the issues you speak of, so it could be code/platform/config specific. Also, what sup were you testing? found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites) Forgive me, but what does bits/sec have to do with anything? -Tk
Re: only WV FIBER now peering with Atrivo / Intercage
On Sat, Sep 6, 2008 at 11:31 AM, Gadi Evron [EMAIL PROTECTED] wrote: Or is it? Looks to not be, so I call BS on your subject line.. however, I do see: * 64.28.176.0/20 71.13.116.101 100 0 20115 19151 26769 27595 i * 204.11.128.105100 0 33125 174 3549 27595 i * 67.210.0.0/2171.13.116.101 100 0 20115 19151 26769 27595 i * 204.11.128.105100 0 33125 174 3549 27595 i * 67.210.8.0/2271.13.116.101 100 0 20115 19151 26769 27595 i 20115 sees 27595 through wv (which peers with bandcon), so it would seem wv shut the edge edge (renesys data also agrees). It's interesting the gx edge is still active. -Tk
Re: Revealed: The Internet's well known BGP behavior
I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet. On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron [EMAIL PROTECTED] wrote: People (especially spammers) have been hijacking networks for a while I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes. We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target. That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential. Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting. -Tk
Re: Smallest netblock that providers will accept?
On Mon, Aug 18, 2008 at 10:05 PM, Kevin Blackham [EMAIL PROTECTED] wrote: Your assumption is generally true with most any provider. They may even accept something smaller, but it won't make it very far if less than /24. It's also a good idea to announce a covering prefix in case some peer network filters on IRR minimums. The part that Kevin spares you from reading is the please don't part. If your goal is to provide HA or DR-like aspects to some $single_application end-site and all you can justify is a one-time allocation of a /24, consider other options. There are already enough /24's in the DFZ both from end-site multihomers and wreckless deaggregation (and those who refuse to build a backbone and/or insist that POP-level convergence towards their network is everyone elses problem, not theirs). Instead of going down this road, I would suggest that you: -call up cisco and purchase a GSS (global dns lb with application availability probes, etc) or -attach your site to a pair of willing upstreams who already have a larger prefix aggregate set aside (say a /18 or something) for end-site multihoming, in which it is expected that the prefix will be originated from disparate AS's (neither of which is the actual end-site). -Tk
Re: Public shaming list for ISPs announcing other ISPs IP space by mistake
On Thu, Aug 14, 2008 at 11:47 AM, brett watson [EMAIL PROTECTED] wrote: We're lacking the authority and delegation model that DNS has, I think? Depends who you ask. Some think applying the dns model to bgp (i.e. within protocol) will ultimately place too great a burden on routing hardware associated 'state' infrastructure. I tend to agree with that position. Perhaps the model we ought to be considering is something more akin to an external mechanism that automated systems (i.e. things to crank out prefix-lists/as-path lists) could draw from during 'refresh' periods, solely dedicated to authorizing prefixes against origin asn and/or as path (or name your $permutation_here). I.e. if said new system were to fail, it'd be great if it didn't affect routing in any way (we can live with a few days of stale lists, I think). Greene/Schiller, pipe up - this is your torch, right? -Tk
BGP route filtering. You want it.
List, [Apologies in advance for operational content. I Don't mean to distract readers from the usual flamewars about rfc1918, bogon filtering, and some of our favorite posters - gadi and n3td3v.] I'd like to give a heads-up to the NANOG community regarding the talk we recently gave at DEFCON. The slides can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt In a nutshell, we demonstrated that current lack of secure filtering infrastructure not only permits DoS-like attacks, but also full traffic monitoring of arbitrary prefixes from essentially anywhere in the world. None of this should come as surprise to the NANOG and operationally-aware crowd - this has been discussed extensively previously before on-list, and extensively at conferences. Additional novelty presented is the returning of traffic back to victim network over Internet (creative as-path prepends loop detection) and obscuring the 'additional hops' this sort of thing creates with additive ttl. Suggested additional reading below: http://www.nanog.org/mtg-9802/yu.ppt http://www.nanog.org/mtg-0010/ppt/tony.ppt http://www.nanog.org/mtg-0010/ppt/danny.ppt http://www.nanog.org/mtg-0206/ppt/security1.1.pdf http://www.nanog.org/mtg-0501/pdf/tauber.pdf http://www.nanog.org/mtg-0505/pdf/underwood.pdf http://www.nanog.org/mtg-0510/pdf/deleskie.pdf http://www.nanog.org/mtg-0602/pdf/boothe.pdf http://www.nanog.org/mtg-0610/presenter-pdfs/massey.pdf http://www.nanog.org/mtg-0806/presentations/wednesday/DanMcP_Route_Filter_Panel_N43.pdf http://www.nanog.org/mtg-0806/presentations/sunday/BRGREEN_prefix_filtering_N43.ppt http://www.renesys.com/tech/presentations/pdf/menog3-youtube.pdf http://www.renesys.com/tech/presentations/pdf/nanog43-hijack.pdf -Tk/P.
Re: BGP route filtering. You want it.
URL works again. I had uploaded an edited version of the talk, but forgot to rename it. It's probably good that only a few of you saw the original, as it wasn't quite the 'professional' text that I'd typically write. Permissible and desired presentation formats and language at DEFCON don't have parallels in this venue. Best, -Tk
