馬嘶的網路大道

看來是自找苦吃, 不過也只能前行了 不學新的 , 被丟在後頭, 學新的 , 也只能把自己當菜鳥 LTE, SAN, CDN , DPI , SDN, 1588, APM, ADC, virtualization.....還有多少

http://opencontrail.org/why-mplsbgp-vpn/ 對特定特大號的運營商而言, 也許是真的 但對data center/enterprise,  也許還是票房毒藥 這讓我想起了, 有榔頭的人, 看見什麼東西都想敲敲看

http://demo.ipspace.net/get/NSX%20Architecture.pdf

Novel Applications for a. SDN- enabled Internet Exchange Point

" Network engineers should know by now that hardware load balancers are not a long term career option." from  http://etherealmind.com/response-getting-the-most-out-of-haproxy/ 也許這也是 Cisco exit的原因

SDN: Software Defined Networks，Thomas Nadeau D.，O'Reilly Media 雖說是 J的人寫的, 但是非常全面, 還是佛心來的, 在這個連 SDN的定義都吵翻 天的階段, 有人願意花時間寫一本專書, 不過, 不太好讀

http://www.ietf.org/proceedings/85/slides/slides-85-sdnrg-2

http://opencontrail.org/opencontrail-architecture-documentation/ 這可能是目前SDN(或overlay)廠商最完整的文件, 還要搞open source呢 很有趣的是, Juniper就不玩openflow, 搞BGP/MPLS/XMPP/IF-MAP的combo, 但是MPLS對data center應該是票房毒藥, BGP 也好像是(可能電信公司吧,  參draft-fang-l3vpn-virtual-pe-01） , 不玩ovs, 要搞自己的vrouter, 能放入VMware裡嗎? services chaining倒是一個好賣點, vCPE也是

http://www.joyent.com/blog/linux-performance-analysis-and-tools-brendan-gregg-s-talk-at-scale-11x

Making Middleboxes Someone Else’s Problem: Network Processing as a Cloud Service 有可能嗎? Middelbox真的很煩人, 如果在電信公司的服務來說, 那更是數不完了, 更可怕的是, 流量去回都需經同一設備, openflow真有好解法嗎?

http://allthingsd.com/20130902/microsoft-to-buy-nokias-device-business-for-7-17-billion-euros/

Network Virtualization is Different than Server Virtualization http://www.sdncentral.com/technology/network-virtualization-different-from-server-virtualization/2012/08/ http://blogs.cisco.com/news/three-truths-about-networking-the-next-chapter/

http://www.vmware.com/files/pdf/vsphere/VMware-vSphere-Platform-Whats-New.pdf

http://www.networkworld.com/news/2013/082813-juniper-mobilenext-273299.html?page=2

大話無線通信 大話移動通信 大話通信--通信基礎知識讀本 願意花時間寫如此深入淺出的書 , 真的佛心來的, 非常感恩

Global Networks: Engineering, Operations and Design 很好的框架,  而且是來自AT&T的

http://conferences.sigcomm.org/sigcomm/2013/hotsdn.php

TCP 和 HTTP會是未來最重要的protocol,花再多時間也不夠 back to basics/theory awesome! need to  plug into socket  *Effective TCP/IP Programming: 44 Tips to Improve Your Network Programs: 44 Tips to Improve Your Network Programs*

http://www.sdnap.com/

http://fasterdata.es.net/ Internet Explorer and TCP RST - a reason to dislike http://www.extrahop.com/post/blog/good-reads/tcp-application-monitoring/ http://www.extrahop.com/post/blog/good-reads/tcp-application-monitoring-part2/ http://en.wikipedia.org/wiki/TCP_tuning

http://blog.ioshints.info/2010/08/storage-networking-is-different.html http://www.nanog.org/meetings/nanog55/presentations/Sunday/Hudson_Storage.pdf 其實就是loseless, 不過, 對我這種networking 老賊 , 就還是有笨問題 , 掉就掉, 重傳就好, HD Video這種real time, 都搞得定, IP萬歲! FC到16Gbps到頂 (和SDH到40G一樣), L1/L2已被Ethernet大一統, FC想藉FCOE延續生命, 還是被專家們唱衰(如冬瓜頭) reminder to myself data corruption will occur serious chain reaction http://www.zdnet.com/blog/storage/data-corruption-is-worse-than-you-know/191 SAN needs redundant separate fabric( no connected) + multipath software + redundant HBA SAN connection scheme is p2p SAN connectivity is p2mp ( target-initiator) SAN nodes divide into host(initiator)  and storage( target) SAN no broadcast (heavily rely on  switch intelligence) SAN forwarding is kinda routing (or TRILL)

being network Engineer, you will face tough decisions sometimes that force you to 1) stand still in technical space 2) transform into sales role  Anyway, I choose as engineer and hopefully keep improving.

http://etherealmind.com/the-only-constant-is-change-fundamentals-are-the-exception/ 讀完這篇, 真的深有同感, 一樣身為老賊, 我也花了兩年多搞IBM networking ( SDLC , LLC, DLSW), 掛了, 一整年搞ATM ( PNNI, SVC.....), 掛了, 一整年搞光網路 (SDH, WDM,,,,) , 掛了(SDH),然後花至少五年搞MPLS, Metro Ethernet, Mulitcast, 恩, 還沒掛 , 還沒算花在學modem , lease line ( T1, T3,MUX,ADM...), Frame Relay等的L1/L2的troubleshooting practice 上 還沒完, 其實這些都還有一點同質性, 更難的是另外一個世界, 偏偏搞IP(夾在中間)的一定要能和下(L1/L2, metro, mobile, optical), 和上(Application, cloud)互動, 還有, Software來了, 再把programming請回來吧

Cisco's Insieme Doesn't Like Your SDN Model More Interesting Stuff in Overlay SDN 一個是overlay, 另一是controller mode, 說穿了就是信不信openflow夠scale到可以全網覆蓋 我是不信啦

http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier.pdf http://www.igvita.com/slides/2013/io-radio-performance.pdf

Antifragile: Things That Gain from Disorder 等了六個月 , 終於要出了, 讀這種深度的書, 還是只能是中譯書

深層封包檢測這技術, 各類技術的界線越來越模糊, 例如, ADC的廠商 已說它們可做firewall的工作了, Firewall也加入更多的頻寬管理功能 來個分類 Firewall - zone security policy enforcement/id integration Load balancer/ADC (layer7) - content manipulation/host liveness bandwidth control/shaper  PCEF -charging/qos enforcement/telecom integration cache (static/video) - hierarchical storage/video site content fetch customization  Session border controller - SIP/IMS diameter DRA/DEA - telecom signaling gateway Application performance management( APM) Carrier grade NAT -ALG

http://www.infoworld.com/t/linux/cumulus-networks-unveils-cisco-killer-221007 http://perspectives.mvdirona.com/2013/06/18/CumulusNetworksASneakPreviewOfOneOfMyFavoriteStartups.aspx 更開放或更封閉 有點弔詭的是, Zebra 已經玩過好一陣了,  Pica8也有軟加硬的方案, 也許是更好的硬體和plugin軟體的整合 不過, 近來看到的進展都聚焦在data center, 而且是open source的,  非新創事業其實離open source的應用還是有好一段距離, 同理, 有所謂brand或support的方案還是有存活的空間

哎, 讀了這麼久, 門外漢就還是不能入門 FC世界的思考邏輯真的和IP的世界差很多, Storage對網路的需求也真是 完全不同於real time/best effort流量, 真的好像外太空來的 FCOE把FC帶進Ethernet的世界, 不過, 這思考邏輯的轉彎真是網路人能搞定的 嗎?一如VXLAN的multicast , 真的要在fabric開嗎?有人會troubleshoot嗎? 不過,  FC的buffer credit真是很好的idea, 但是, 這out-box signal還是讓人覺得太heavy了 FOCE的Qos policy也讓人害怕 這世界會選簡單還是複雜? 我選簡單

http://www.lightreading.com/big-switch-pulls-back-from-opendaylight/240156064 真的又好像96-98的MPLS規格戰大戲, 上一次是算Cisco贏嗎? 其實也許不是, packet 和cell based的架構都寫進規格裡了, 還是端看客戶要不要用, 好不好用 這次也是, 真的SDN幫訴求的是網路架構的激進改變, 就是要傳統vendor的命, 這次的大戲值得繼續follow 我的看法是follow 軟體行業大廠如何在open source的浪潮下存活下來的歷程就知, 現在已到不把control/data用力拆開，網路就不能持續創新的階段

Computer Science Department Distinguished Computer Scientist Lecture Software-Defined Networking at the Crossroads 這talk這幾天在 SDN community瘋傳, 看來真有 MPLS和SDN陣營的區別,真要分我的話, 我想我是MPLS派的吧 這裡看來SDN有點小妥協, 承認MPLS的aggregation scheme是對的, 全網的state爆炸一定要有解法, 看來還是所謂的dumb core/smart edge 這讓我想起1996-1999時的tag switching/ip switching/label switching的過程,  VLAN也是, 真正可用的方案至少還要好幾年 (也許五年吧）, 傳統垂直整合的設備廠商還有一些喘息的時間, 但是, 現在如不做積極的改變(但換大腦的難度太高), 那就掛定了 另外, 學者看的是整體的未來架構, 工程師高興的是用 SDN有解法了

這算是蠻難的挑戰, 不過當要涉入一個完全不懂的領域, 我們也許要先問自己, 讀懂移動這對我有何幫忙? 如果我們設定的是我們能用相同的語言和搞移動的工程師交談, 了解移動在導入全IP的路程中會有的問題與挑戰 一旦確立這目標後, 我會有幾個建議 1. 了解移動網路的架構及演進(這是最重要的) 2. RF懂一點就夠了, 搞IP的應該也不會去搞cell planning吧 如果是如此, 那一定是 IP Design for Mobile Networks 第一二章算是精簡的RF(Radio)的段落, 對我們應該足夠了, 大多移動的書花了太多篇幅

including data centers, networks, compute, storage, databases and load balancers 當然,我最在意的還是網路, 但是其他的領域還是要有一定程度的了解, 否則不能從整體的角度思考, 這很難很難,哎 http://www.zdnet.com/amazons-vogels-next-gen-it-architectures-need-to-be-cost-aware-7000008106/

算來MPLS是我職業生涯花最多時間的協定, 也是到今天唯一讓我覺得能對網 路起巨大改變的架構轉移, SDN就還不是 不過, 我一直都在思考為何就是有些用戶就是抗拒MPLS, 當然, 還有 BGP 哈, 這兩個協定偏偏就是 J在行的, 一再要拿出來用, Qfabric肚子裡就是 BGP和MPLS 購回的新公司也還是主打這兩樣, 我也是這兩個協定的 supporter, 我至少花了超過五年的時間 才能稍稍掌握, 不過, 原先的抗拒力從何來是該好好想想 http://www.sdncentral.com/companies/juniper-ankur-singla-sdn/2013/05/ Traffic Engineering with MPLS  是本超棒的書, 沒細讀完這本, 我實在不能相信 你已掌握TE的精要, 這也是唯一你能找到的書 相對MPLS-Enabled Applications: Emerging Developments and New Technologies 的精要,  MPLS Fundamentals 就是本參考書 MPLS的Qos其實就是骨幹的Qos, 這和邊緣的 Qos思路完全不同, 加入TE/FRR後更是 讓情況複雜到底, 這兩本是你該讀的 QoS for IP/MPLS Networks Deploying IP and MPLS QoS for Multiservice Networks: Theory & Practice

搞網路的遇到網路效能有問題時, 常問的一個問題是 CPU使用率如何? Memory勒 上周發現客戶只有信心5-10秒丟一筆路由更新, 把我嚇了一跳, 我以為我們已到了新世紀了, openflow controller公司不是告訴我們cluster VM可以搞定控制層的CPU負載嗎? 哀, 這就是搞其他層太久的後遺症

產品和理論不能在家裡自己搞, 我就被狠狠打醒了 - 不要妄想一個方案可以搞定 - 頻寬消耗就是大事(對半大不小的ISP來說, 以台灣來說, 應該只有一家不是) - 自己防的要等ISP不丟你的包

必要/不退流行/花再多時間也不浪費         Ethernet,TCP,  DNS, HTTP, OSPF, BGP(*) 一時流行/說掛就掛      WiMax 有點小眾/必有需求        SIP, MPLS(RSVP, VPN....), Sync, ISIS 掛了          ATM, SNA(DLSW, SDLC, ), SDH

https://speakerdeck.com/etherealmind/cloud-networking-is-not-virtual-networking-london-vmug-20130425 重開一台網路設備可能導致全網掛點, 這是所謂的SDN不可能完全照抄web 2.0(or 3.0)的瘋狂進展的原因 網路設備間的相依度比起應用或server來的高太多了

Network, Interrupted 網路再搞單一廠商垂直整合(control + data plane)就是死路一條, 這篇用非常激烈的語句強烈提醒大家 你信嗎?

http://bits.blogs.nytimes.com/2012/12/06/planning-his-legacy-cisco-chief-maps-an-expansion/ 雖說這件事在其他領域早就發生, 但在networking ,這就很

MUST read! High Performance Browser Networking and this IMPACT OF TCP AND HTTP ON WEB APPLICATION PERFORMANCE

嗯, 我知道這領域有太多書了, 一本比一本厚, 但我們總是想有沒有一本薄一點的, 少抄一點手冊, 符合 McKinsey MECE的書 那是  VMware vSphere Design  , 很快的, 也有第二版了 不過, 在虛擬化, VMware當然是絕對的王者, 只是open source 的雲端服務只怕不是築技術和綁平台可以抵擋的, OPEN才是絕對的王道啊

固然不像vmware買nicira那樣對著networking industry嗆聲, 這又是另一種的 全新融合的可能, 雖然我認為失敗的可能性很高, 不過, 在這個不革自己的命 就不能生存的時代, 這嘗試是絕對必要的 只是, 路不再像以往那樣清晰可見, 到了必須自己走一條出來的時候

我们慢慢凋零，但从未死去－－NetScreen往事

GIAC Gold Papers Computer security research and whitepapers.

這問題還是有沒有需求 NAT64能work還是要靠DNS64, 所以NAT46也還要請回DNS, 所以是DNS46了 DNS64有RFC, 而且是 Category: Standards Track, 真有人要NAT46嗎? http://tools.ietf.org/html/rfc6147 DNS DNS, NAT-PT因你而bye

A comparison of IPv6 tunneling mechanisms draft-steffann-tunnels-00 Maybe I am wrong. But not many people are bothering using tunnel scheme. Tunneling is so error-prone (MTU....) Anyway it is good for internet historian.

徐立冰 - 腾云－云计算网络技术 不過L2/L3好像不sexy了

http://www.valleytalk.org/wp-content/uploads/2013/03/OpenStackOperationsGuide.pdf

讀ipsec N年了, 讀了就忘, 該是有個了結 http://tools.ietf.org/html/draft-bhatia-moving-ah-to-historic-00.html AH能做的看來 ESP都OK,所以說bye吧 http://blog.ine.com/2010/05/28/when-transport-mode-becomes-tunnel-mode-free-of-charge/ 大多數的環境都不會用transport mode(你知道juniper SRX完全不支援transport mode嗎?) 因為transport mode只會protected ipsec peer的IP 所以, 只搞定ESP+tunnel mode應該就夠了 另外IPSec 是直接跑在IP上的,  PAT+IPsec要有怪招才行, 每家功能都不一樣(ALG?) IP Protocol ID of 50 (0x32) for IPSec Encapsulating Security Payload (ESP) traffic IP Protocol ID of 51 (0x33) for IPSec Authentication Header (AH) traffic

http://www.cyut.edu.tw/~ckhung/b/gnu/regexp.php

這問題初看不大不了, 實情是多數狀況下, 封包只會走一條路, 以前以為這問題的解法只有 BGP + IGP (maybe RSVP) plus intradomain/interdomain的招數而已 ( 我只會router) 沒想到有另一系tricks就是傳統的link balancer L4/L7 flow based LB + NAT + ACL based link selection (Geo DB) + DNS( or GSLB) 這兩類的方案的應用場景非常不同, 第一類你如沒ASN, 也就別想了

http://radioaccess.blogspot.tw/2013/03/the-issues-with-wi-fi-offloading.html 倒是從來沒想過這問題, 因為較light weighted/less manageability + marcocell traffic explosion, wifi offload 有了機會, 但你深究就知, 大多數現在的implementation還是以便宜取向 不過, wifi打的就是便宜, 想他做多點事真的太為難他了 http://www.tomshardware.com/picturestory/571-wi-fi-beamforming-networking.html http://www.tomshardware.com/reviews/wi-fi-performance,2985.html

Evolution of the IP Model 這篇提到的網路設計的誤區, 下面是再提醒自己的要點(或是現在很有感覺的要點) Claim: Reachability is symmetric (*****) Claim: Multicast/broadcast is less expensive than replicated unicast Claim: The end-to-end latency of the first  packet to a destination is typical Claim: Reordering is rare Claim: Loss is rare and probabilistic, not deterministic Claim: An end-to-end path exists at a single point in time Claim: A host has only one address on one interface Claim: An address used by an application is the same as the address used for routing Claim: Packets are unmodified in transit Claim: Source addresses are not forged

What kind of signalling issues have to be solved by introducing LTE? from Zahid Ghadialy 當resiliency + SCTP要被加入網路設計時問題就來了 不過,  看來大部分的diameter還是跑在TCP上

http://forums.juniper.net/t5/The-New-Network/Decoding-SDN/ba-p/174651 J還是把服務串連再請回來, 原先要在自己硬體的內部搞平台, 運營商就也來個NFV, 不過有個根底的問題沒解(或很難)  這些所謂的服務就是Deep packet inspection, 要維護state,也因此對網路設備的要求是同一session(依協定)去回要經過同一設備 就路由層級可搞一些把戲, 但SDN ( or openflow)有更酷的工具來完成

雲端資安與隱私：企業風險應對之道

TCP SYN-Cookie背后的人和事 - 续 " SynCookie如何根据正常连接的第三个报文验证ACK报文并且构建Session了。 Syn-Cookie feature的前提有以下几个： 不会建立session 不会queue SYN报文而是丢弃它 不在本地保存任何Session相关信息或checksum 要完成的事情是在第三个报文到来之后做以下两件事： 检验是否这个ACK的前两个报文确实来过 根据第三个报文重构整个Session的信息。" 不会建立session是極重要的, 就是不能再maintain state, 這是stateless的招術 沒想到搞kernel的人還是有時有盲點的啊 TCP SYN-Cookie背后的人和事 from  http://www.kernelchina.org/ in case I would like to study source code in the future

CDN技术详解  ~  雷葆华  (作者),  孙颖  (作者),  王风  (作者),  陈晓益  (作者),  等  (作者)

http://www.networkworld.com/news/2011/040411-vyatta-herrell.html "The x86 architecture is rapidly becoming a superior price/performance hardware alternative in networking; the packet processing performance on x86 increased 100X in the last four years." Vyatta CEO Kelly Herrell, “ Vyatta readies for virtual machine explosion ” 

The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference h ttp://www.tcpipguide.com/index.htm TCP/IP Illustrated, Vol. 1: The Protocols   93年的書, 還是bible級, but little bit old

Wireshark Network Analysis: The Official Wireshark Certified Network Analyst Study Guide http://sharkfest.wireshark.org/

http://chrisgrundemann.com/ - from Cablelab http://www.nanog.org/meetings/nanog56/presentations/Wednesday/wed.general.howard.24.pdf Total Cost of Ownership of Carrier-Grade NAT Conclusion in short : magic number - $40 per user if you can buy address from market (where?) $0~40 ->> buy $40~70 ->> CGN >$70 ->> sell your IP(?) & CGN difference from traditional NAT - Transparency via  Endpoint-independent Mapping (EIM), Endpoint-independent Filtering (EIF), address pooling, hairpinning, and port preservation - Fairness algorithm - Stateful sync - Log - session capacity  - low overhead - TCP connection setup rate - low overhead - throughput via customized sw/hw combination confusing terms fixed NAT -predetermined - deterministic it is not static NAT https://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-01 Almost cover everything http://www.ietf.org/edu/documents/ietf78-nat-tutorial.pdf another confusing but deprecated now ful

http://www.internetsociety.org/articles/using-json-ietf-protocols 不過, 看來好像已結束了

http://www.data.proidea.org.pl/euronog/1edycja/materialy/prezentacje/Lukasz_Bromirski_IP_Anycast.pdf

http://radioaccess.blogspot.de/

http://searchnetworking.techtarget.com/news/2240175970/Networking-outlook-Controllers-Layer-4-7-will-roil-SDN-2013-market 我不太相信能如此快, 但這篇一再確認這趨勢

AWS雲端企業實戰聖經：Amazon Web Services改造企業IT體質

http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf 我看我太愛這概念了, 花如此多的時間, LB不僅提供了HA, 也是提高鏈路使用率的工具 其實BCP 128已存在很久了, MPLS 的LB本就複雜到底, 另外, 千萬不要小看reordering, end-point並不能handle(尤其是video, 在加tunnel, 就瘋了) 竟然還有這本書 Practical Load Balancing: Ride the Performance Tige 不過, 網路類的依然是 undocumented的, 有空再來整理一下

結果是錯的, 至少在現在看來 道路是為車輛而存在的, 現在車輛變了, 乘載的東西也改了 以往看見的little trick已變成必須, 必須以系統的思考全面考量 Programmability/L7(flow) intelligence 必定是必要技能

Bigger screens lead to greater data usage -- "Samsung Galaxy Note users download three times more data than users with a screen size less than 4 inches," notes Ciqual.

說來話長 不過這裡有些結論 - NAT在路徑間改了封包內容,  IPsec設計來就不想你半途改他,天性不合 - 只有ESP+tunnel mode+ALG有機會解 - 或NAT-T (基本上是架橋UDP飛過)

https://devcentral.f5.com/blogs/us/your-sdn-overlay-protocol-cheat-sheet Std Std Link Spec # of pages Complexity Bridge Type Transport Encap Overhead in Bytes QinQ 802.1ad IEEE 15 Low L2 L2   PBB 802.1ah IEEE 30 Medium L2 L2   SPB 802.1aq IEEE ($5.00)  340 High L2 L2 22 Edge Virtual Bridge 802.1Qbg IEEE ($5.00) 191 High       VNTag 802.1BR IEEE ($5.00) 135   L2     TRILL RFC 6325-7 IETF 150 High     20 LISP IETF Draft IETF 98 High L2, L3 UDP   OTV IETF Draft IETF 27 Medium L2 UDP   MPLS RFC 3031-2 IETF 62   L2 L2   VPLS RFC 4761-2 IETF 29 Low L2 L2+MPLS   OpenFlow ONF Draft ONF 106 High L2 L2   vCDNI None VMware 0 Low L2 L2   VXLAN IETF Draft IETF 20 Low L2 UDP 50 NVGRE IETF Draft IETF 19 Low L2 IP 42 STT IETF Draft IETF 20 Low L2 Fake TCP  

http://www.tenereillo.com/GSLBPageOfShame.htm http://www.tenereillo.com/GSLBPageOfShameII.htm https://devcentral.f5.com/blogs/us/the-skeleton-in-the-global-server-load-balancing-closet http://blog.loadbalancer.org/gslb-why-do-global-server-load-balancers-suck/ http://support.citrix.com/servlet/KbServlet/download/22506-102-671576/gslb-primer_FINAL_1019.pdf http://tools.ietf.org/html/rfc5507 Panel - DNS Amplification Attacks: BCP38, mitigation, reputation or what?

但你如是提供服務的人 的確, BGP和DNS是最重要的協定 其實觀念應該都懂, 但一些terminology就是不熟, 說來就是好像不懂的樣子 還有, 真沒有一本有完整框架的書 例如, recursive/iterative query 先讀讀這些 DNS Tutorial @ IETF 80 – Gudmundsson, Koch • Naming, DNS, & Security, DPU IT 263-901 - Lewis • Securing DNS, EDUCAUSE SP – St Sauver • DNS Debugging and monitoring, RIPE64 – Damas, Kerr • An Introduction to DNSSEC, NANOG54 – Larson • DNS(SEC) Troubleshooting, NANOG53 - Sinatra 除了在internet上的DNS, DNS在內部服務也非常重要, 如 GPRS Control Plane DNS from  https://devcentral.f5.com/blogs/us/dns-for-communications-service-providers-ndash-why-are-people-unhappy

http://www.apps.ietf.org/rfc/bcplist.html

http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.lightning3.whyte.sdn.controlled.exchange.fabric.pdf But will it be interesting because of SDN? "SDN is to Networking as Open Source is to Operating Systems"  from slides (or software development?) Networking guys shall think it over and over

Fast Reroute對很多人是個大問號, 尤其是該如何在網路的層次思考(不是一條鍊路歐) 沒想到有這本書, 唯一只談這題目, 和實務相關(嗯, 很多學院論文型的其實, well....) 近來FRR走的更遠了, 這是這本老書唯一的問題 Ensuring Rapid Restoration in Junos OS-Based

才說Qos不重要了, 為何又推薦書呢?唉, 老傢伙以前會的把戲, 總想拿出來說說嘴吧 不過, 又想說不要Qos的公司有時是bandwidth多到可以不食人間煙火的大傢伙(連Google在core bandwidth都很省著用, 有非常複雜的設計), 其他要省錢的多是使用個各種方法榨出bandwidth來用, 不只Qos, 壓縮, cache, DPI,,,,, 不過, 在edge或獨立的box搞Qos是相對直覺的, 當然, 機制也可以非常複雜, 在Core搞Qos就不然了, 路由, 替選路徑, 流量工程, 有太多互動的可能 這書看來是僅有的, 能讓你真的知道如何真正的在Core或Edge 建置Qos的參考書

http://tools.ietf.org/html/rfc6790  published in  November 2012 entropy用完了, 生一個來用 LSR能用來hash的seed不足以引進變異 an ingress LSR (e.g., a PE router) has detailed knowledge of a packet's contents, typically through a priori configuration of the encapsulations that are expected at a given PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.)

OpenStack Essentials   By Dan Radez <2014/10/10>中文書竟然比英文書多! openstack部署实践 OpenStack开源云王者归来——云计算、虚拟化、Nova、Swift、Quantum和Hadoop OpenStack实战指南 <2014/05/05> 有中文書了 ! 用OpenStack建立如Amazon的雲端環境 ha, 好像沒太多的選擇, 請服用 OpenStack Cloud Computing Cookbook http://www.amazon.com/OpenStack-Cloud-Computing-Cookbook-Jackson/dp/1849517320 這本免費 OpenStack Beginner’s Guide V3.0 for Essex on Ubuntu 12.04 (Precise Pangolin) http://cssoss.files.wordpress.com/2012/05/openstackbookv3-0_csscorp2.pdf

沒有懸念 HTTP: The Definitive Guide 不過, 作為newbie in this field, 我很驚訝地發現這竟是2002的書, 沒有新版, 這是因為HTTP已經夠好了嗎? 還是1.1到2.0的轉換的時間要像IPv4到IPv6一樣嗎?

我不是存儲(或儲存)的專家, 但找出一本就能搞定那領域的書的能力還是有些自信 那一定是, 大話存儲︰網絡存儲系統原理精解與最佳實踐 (簡體版) 王者歸來：資料存儲系統架構極限剖析(繁體版) 這本書是暢銷書,IT領域的人一定較知道, 搞網路的就不一定了, 都是牆阿 作者是業內人士,歷史發展 信手拈 來, 讀完之後, 你也就入門了, 這書有也有二部(足見受歡迎的程度) , 但 二部厚多也深多了, 只想 入門的建議止步

一直以來, internet能具有如此高的延展性將如此多的設備連接在一起, 我們也許會歸功於網路的開放性以及標準化, 所以這是個議題嗎? 我們也許要把網路的構成分為主機和網路設備來看, 主機當然由軟體和硬體組成, 在軟體這塊, 由於open source 的概念, web 2.0以及不斷的發展(如cloud), 看來連microsoft都要適度的加入這概念, 硬體也有facebook的open compute 開始進一步的降低 cost 那網路設備呢?一直以來, 高端的路由軟體一直被 C&J統治, 至少在internet peering 這塊, 更是大致如此, 網路設備一直是高度集成的,當然在網路設計近年來的觀念一直是分離的控制層和轉發層要維持高的延展性, 但是在設備本身一直都是軟體和硬體都由同一家公司提供 對C&J來說,這樣的生意模式搞了十年多, 我想是more than happy呆在comfort zone的, 不過我想cloud將會改變這態勢, 但是, 當然不是一時三刻 第一個要作改變的應該是最接近主機(或server)的switch, 這一塊一直都是price sensitive, 大容量commodity 的chipset 更易取得, VM的興盛讓switch必須更能配合主機, 更開放看來是唯一的路, 更遠的router, 底層的光, 基站就還能在呆在comfort zone一會 寫了這些, 不外乎是提醒自己, 網路設備這塊也會被一層一層被拆開, source code必須被公開, 一如過去open source業界的發展, 這真是paradigm shift, 特別是概念上的 過去一直都覺得未來運營商如能存活, 一定要能引進像google/facebook的DNA, 更軟體導向, 沒想到要先革命的是自己的觀念

The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference   by  Charles M. Kozierok   (Oct 1, 2005) 如果只有一本 還多的, 十幾年前沒搞定的還是會回來 TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series)  [Hardcover] W. Richard Stevens   (Author) TCP/IP Protocol Suite (McGraw-Hill Forouzan Networking)   by   Behrouz A. Forouzan

請不用花錢,就是 OSPF Version 2 RFC 這麼完整易讀的RFC真的很難得, 還是發明者自己寫的, 我想市面上找不到好的書是因為這原因,因為不需要了

一樣沒有懸念, 一定是 Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions 市場上就沒有幾本Multicast的書, 寫的能讓你讀的懂的只有這一本(真的), 我知道還有另一本Cisco Press 的書, (只有Vol 1的那本, 但這本大可能只會讓你搞糊塗而已) Multicast這技術必須處理很多state的東西, 因此延展性是極大的問題, 這本書直指要點, 不是照抄RFC 有點歷史的書(10年前), 所以我真的學懂Multicast也就是這十年的事, Multicast對原先只懂unicast routing的人是反向思考的東西, 不過, 我也花了兩年才能稍微掌握,另外, Multicast一定要有Source/receiver, 只有router 設定是不能看出效果的 那Multicast在VPN呢?那是讓你讀到想哭的東西(有Yakov搞的東西, 他是不會讓它容易的, 另一例是seamless MPLS), 不會哭的, 請讀 Deploying Next Generation Multicast-enabled Applications: Label Switched Multicast for MPLS VPNs, VPLS, and Wholesale Ethernet <2013/09>強力競爭出現! http://www.amazon.com/Multicast-Routing-SpringerBriefs-Computer-Science/dp/1461418720

還是很進階很專的書, 花了我至少六個月才能掌握內容, 沒有經歷真正的網路設計是不可能寫出這本書的, 這書也陪我撐過在06年暗無天日的non stop 一百天的proposal

這本也是我的愛書, 在書海裡尋尋覓覓,最高興的是找到一本好像有點冷門(其實我想這本不是), 但又能解答你工作時的疑問, 不過, 這本書的問題是, 由教授執筆, 所以有時及提及的技術現在是沒人用的,對我們這種較"功利"想趕快解決疑難雜症的人,是要花點時間過濾 這本書很建議與前一本 Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices 一併服用

一樣沒有懸念, 一定是 Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices  這本真是奇書阿, 奇不在於他談的不是多深(當然也很深),而是如你身為一個SE,又不是硬體研發出身的, 這本書給你了一個框架,又有一些歷史的描述,例如, lookups方法的比較,anyway, 如果你想更深入, 讀就對了

說真的, 我不知道為什麼有人要寫這本書, 這麼進階,這麼小群體,會有幾個人需要看這本書呢?這本書又一定很難寫,因為一定得建一個lab才能搞定,不過, 如果你需要做網路整併,或是把一整個網路換掉(這十年我就有過三次),你真的會感謝竟然有這本書阿,讀這種書你真能感覺佛心來的 不過,真的很進階, 非常適合睡前讀

嗯, 我知道, 沒太多人用IS-IS,除了幾個特大的運營商之外, 大多數人的選擇應該還是OSPF, 我的看法是, 你還是應該讀IS-IS,為什麼?這兩個協議的比較會讓你對OSPF有更深的理解 如果是這樣, 那也沒有懸念, 那一定是 The Complete IS-IS Routing Protoc ol 我知道,另外還有幾本IS-IS的書, 但若論完整度(含C&J)來說, 這是最好的選擇,篇幅稍長,但是非常深入 談到作者, Hannes原先是professional services engineer, 但後來轉RD, 現在是J的DE, 這經歷真是很特別

那沒有懸念, 一定是 MPLS-Enabled Applications: Emerging Developments and New Technologies 這本書有我最喜愛的技術書籍風格,簡潔, 直入要點,對MPLS有一點基礎的工程師會很感謝這種風格 這本書是J公司兩位MPLS的專家撰寫, 一位是developer, 一位是SE, Ina幾年在NANOG有幾篇類似的簡報, 建議補充服用

Practical BGP by Russ White, Danny McPherson, Srihari Sangli 比起其他的磚頭, 這本頁數還好, 每一句都重要 , 好好用功吧 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) confederation 就別讀了, 除了以前的Uunet(現在的Verizon Business)在用, 我還真不知這世上有誰用, 以前還有客戶只不到十台就要搞,RR都不用了,每一字都讀熟吧 另外, 階層RR真的不是個good idea, 除非你有上千台路由器, 可以簡單的不要複雜, 牢記牢記(說給自己聽的)

若要說這麼多年在工作上有何遺憾, 我想說的是始終沒能讓客戶使用, 相信, RSVP 中國現在的特大號運營商的網路絕對比AT&T, Verizon 還大, 但是網路結構卻始終未引入MPLS,更別提RSVP了, 台灣客戶也一樣, 雖小, 顧忌一樣多, 即使MPLS在現網於97就上線了也一樣 我想可能是以下的原因 1. IP和MPLS的互動與應用對工程師還是不直覺, 留在comfort zone, 繼續使用BGP作為TE  的手段 2. 網路太大, 太多廠牌 3. 管理還是麻煩 在通訊及電信這塊, 技術不會很快死去( 對比運算和3C), 只是會慢慢變成恐龍 個別層級的整合會發生, 但不會近在眼前

One of the techniques to prevent certain attacks (especially resource starvation approach such as DDOS) is throwing even more resources to absorb it. Anycast DNS is the one. High capacity load balance equipped with high amount memory is another way for it. Of course it is only for larger enterprises or service providers.

http://en.wikipedia.org/wiki/Firewall_(computing) Being newbie in new domain especially in networking industry(everyone said the same) , I always lost in the sea of technical terms. Such as firewall , it has long history and each generation has different focus. Finding something neutral is quite important instead of jumping in vendor specific materials.

http://en.wikipedia.org