Skip to main content

Posts

Showing posts from 2015

ACI有感

才說網路攻城獅喜歡CLI, C就搞一個用GUI管網路的架構(API也可啦) 看完packet flow, 只能說一堆疑問, 真要除錯(沒有不出錯的盒子), 要有 debug command吧  ,

是這麼搞的

http://ethancbanks.com/2014/10/16/cisco-aci-fabric-forwarding-in-a-nutshell/ 開始讀ACI, 我以為是像NSX類似的架構. 至少還是網路咖可以理解的 範圍, 我錯了, 沒什麼 routing/switching的東西, 這一個矩陣就可看做一個 交換機, 裡面怎麼跑不要你管,  用就是了

老賊之開眼界(2)

L2 交換這件事又讓我嚇一跳, 原來vPC/MCT/MC-LAG/MLAG是被拿來 幹L2的multipath多路徑 果然不能只聽一家之言, 這招看來是最普遍的(也最XX) 還有一堆技術 L2的 -TRILL ( fabricpath , VCS) -SPB (PBB變種) -SPB+ -IRF - stacking(專屬) -802.1BR port extender L3 - 把bgp routing/EVPN請進data center來

有趣!但還是太貴了

http://www.get-console.com/shop/en/airconsole-20/73-airconsole-pro-20-single.html Airconsole 2.0 is our popular portable, battery powered, RS232 Serial over WIFI and Bluetooth Adaptor. Designed to be seamlessly used with Mobile Apps on iOS, Android and also on PC, MAC OSX and Linux, Airconsole provides flexible and convenient access to physical Serial and Ethernet ports from devices (such as iPads and iPhones) that have only WIFI or Bluetooth interfaces.

MUST read! network engineer

http://queue.acm.org/detail.cfm?ref=rss&id=2856460 A Purpose-built Global Network: Google's Move to SDN A discussion with Amin Vahdat, David Clark, and Jennifer Rexford 網路設備廠的噩夢, 連internet-facing的router也要自幹了 - we quickly concluded that a centralized view of global demand would allow us to make better decisions more rapidly than would be possible with a fully decentralized protocol. >>全域智能 - Our biggest frustration was that hardware and software were typically bundled together into a single platform, which basically left you at the mercy of certain vendors to come up with any of the new features you needed to meet requirements already confronting you. >>不爽 -What's more, buying a bundled solution from a vendor meant buying all the capabilities any customer of that vendor might want, with respect to both hardware and software. >> 一張專輯只要其中幾首歌的概念 -we realized decentralized protocols wouldn't necessarily give us predictability and control over o

SP的SDN前路

http://events.linuxfoundation.org/sites/events/files/slides/odls15_sdnatatt.pdf http://events.linuxfoundation.org/sites/events/files/slides/odl_summit15_chiosi.pdf 仔細想全自建SDN的導入, 真的只有原生於internet的hyperscale大咖 能自幹,  連ATT都不見得能算是, 其他人就別想了 為什麼? 自建SDN基本上是軟加硬的全面整合計畫,  從設計到實做到測試 全得自己來 解決方案和設備供應商就別想hyperscale業者了, 不是hyperscale業者的也別 想全部自己來了, 你不會想上網還要自己寫一個OS

難得Slash這麼歡樂

Scipass- Science DMZ 2.0

https://globalnoc.iu.edu/sdn/scipass.html 原先Science DMZ的概念就是把科研與一般上網服務的流量隔離 其實就是避開L4-7設備的瓶頸, Scipass引入SDN的概念, 將分析後的 智能反饋回網路控制 一如SDN的進展,  現在只是剛開始而已 當然有時間差 , 但是網路速度和 L4-7設備的進展(當然和價位有關, 100G的 IPS要多少錢)落差只會越來越大 , 立即攔下威脅的好處和可能性也越來越低了

網路咖看資安

威脅是真的 但客戶還是只能用嚇的 除非要當很專的malware研究員 不然就別看組合語言的相關內容了 知道原理就好了 知道了也不會用的更好 安全大多只是信心罷了 廣度雜度是必備的 OS  protocols authentication,  就一個active directory就可以把你玩死 ......

Hyperscale

明明是網路設備業者的大肥羊 偏偏都選擇自己來 更可怕的是玩的還比你好很多 反到是你得向他拜師學藝 http://www.nextplatform.com/2015/06/23/bringing-hyperscale-sdn-lessons-down-to-enterprises/ https://www.sdxcentral.com/articles/news/hyperscale-white-box-switches-prepare-to-be-shocked/2015/04/

再看SDN

原先 Openflow被視為SDN的同義詞, 其實是一個通用的低階語言 原來有router/switch搞定各種網路問題(backup, restoration, topology filter. load sharing...) ,看了Google/facebook可以自己幹, 也想自己來 翻開電信級的設備的架構來看, 要自己來真的是頗嚇人的, 除了 下一些flow之外. 真能把自己的App和SW放上production嗎

PA真是能吹牛

前Netscreen No 10說,如果他(Nir)是防火牆之父 , 哪我們就是防火牆的祖父 haha http://www.darkreading.com/who-invented-the-firewall/d/d-id/1129238 http://checkpoint-master-architect.blogspot.ch/2015/09/stateful-inspection-who-invented-it.html Nir從 onesecure來, 說架構被他影響也太離譜了

unified (or single) OS

我以為one JUNOS是唯一的失敗 還是有人在networking業界談single OS http://packetpushers.net/arista-eos-benefits-challenges/ 在3C這塊, M, G, A也先後要面對這問題 不過 , 搞統合好像沒啥好下場 http://technews.tw/2015/11/03/google-android-chrome-os/

Mobile Edge Computing

http://www.networkworld.com/article/2979570/cloud-computing/microsoft-researcher-why-micro-datacenters-really-matter-to-mobiles-future.html 其實這觀念Nokia也正在強推, 只是mobility需要的錨定點不能太分散, 太集中又有三角路由 的低效率, 肯定要在tunnel 間插斷做點事 , 技術上的細節還要再看看

F5 SP show cases

The F5 Handbook for Service Providers: 15 Ways to Increase Revenue Dynamic Service Chaining/Intelligent Traffic Steering 4 Subscriber and Application Bandwidth Control 6 Fair Usage Policy 8 Tiered Service Plans 10 Analytics 12 OTT Monetization 14 Bandwidth on Demand 16 TCP Optimization 18 URL Filtering 20 Content Insertion 22 Intelligent DNS for the Mobile Core 24 Intelligent DNS Infrastructure 26 S/Gi Firewall 28 Interworking—SDC 30

翻牆被攔科普

https://theinitium.com/article/20150904-mainland-greatfirewall/ https://openvpn.net/index.php/open-source/documentation/security-overview.html https://en.wikipedia.org/wiki/OpenVPN 這就難怪OpenVPN 會被攔 OpenVPN has two authentication modes: Static Key  -- Use a pre-shared static key TLS  -- Use SSL/TLS + certificates for authentication and key exchange Because SSL/TLS is designed to operate over a reliable transport, OpenVPN provides a reliable transport layer on top of UDP  一直以為OpenVPN = SSL VPN (network mode), 唉

老賊之開眼界(1)

http://virtualadc.blog.51cto.com/3027116/1050151 這20年的職業生涯有很長一段時間是一隻 矇著眼的井底之蛙, 我以為搞定router就夠了, 當我知道所謂的LLB(link load balancer) 是這麼幹的, 把SLB反過來用, 搞個wildcard VIP就能引用L7的控制力度 我真的嚇壞了, 企業環境的方案就是能這樣搞出一個 solution 解決問題(因為沒有其他方案)  , 大公司就能用 更具資源更全面的方式找解法 lesson learned : 問題不會只有一種解法

翻牆的障礙

https://theborgqueen.wordpress.com/2015/07/15/stop-hiding-just-ask/ 不知是否我有誤讀, 現在各領域激烈的融合, 一個技術人員如果 想在下一階段生存, 就必須冒著當無知的菜鳥在工作中低頭問 暗中學(連書都不會有的), 而你連基本術語的sense都沒有

網路攻城師該學什麼語言

http://python.jobbole.com/81878/ 96年在北卡幹了幾個月C語言程式猿, 就趕忙撤退回台 沒想到還是要面對這個抉擇 我想, 不可能有懸念了 看來看去還是只有這唯一的選擇- Python 今天在linkedin看到一位在J待了15年的 Escalation Engineer ,  1970就出來工作當programmer, 20年後搞網路( Pacific Bell, INS ,Ascend , J) 又搞了20年, 現在退休當   Developer  -  The NetBSD Foundation Kernel hacker, bug fixer,utility infielder, and regression tester 我的20年也要到了, then?

技術的生與死

如果你只能讀一本Security的書, 我建議

祕密與謊言--如何建構網路安全防衛系統 Secrets and lies : digital security in a networked world 也許這本書已經有點歷史,  不過現在讀來還是面面俱到 其實如果不搞assembly hacks, 其實Security這塊還是人的因素 大於技術, 身為乙方的vendors其實是只是一再的出報告"恐嚇"客戶 (當然, 威脅是真的, 搞你也是真的) 工程人員搞安全的沮喪是不會有完美的方案(連騙自己都騙不了), 搞網路也許也有一點機會 (我曾經以為MPLS就是了) Bruce Schneier當然是絕對的指標, 我竟然以前不知道他,  可見我 在這塊我有多淺就好

必讀! 不過 G好任性, 不好用就搞一個自用的protocol

http://www.sdnap.com/sdn-technology/6039.html Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network” http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf sigcomm 2015看來不只要期待上篇, 還有 -  Inside the Social Network's (Datacenter) Network -  BlindBox: Deep Packet Inspection over Encrypted Traffic (真的嗎?)

Recent Advances in Machine Learning and their applications to networking

這年頭還強調硬體, 搞Lab? 讓我們再看下去

http://forums.juniper.net/t5/Industry-Solutions-and-Trends/All-The-Force-Tiny-Footprint-Look-Out-for-The-Antman-of-Core/ba-p/276309 http://www.businesswire.com/news/home/20150415005290/en/Juniper-Networks-Introduces-Industry%E2%80%99s-Fastest-Firewall#.VbBUjLOqpBc http://forums.juniper.net/t5/Community-Talk/Announcing-the-Lab-Madness-2015-Bracket/ba-p/270934

NFV的未來

https://www.youtube.com/watch?v=A7GrIWKkGUQ  by Tom Anschutz 原以為NFV 就是將原使用專屬硬體的網路設備變成虛擬版本跑在 資料中心的大量伺服器中 , 再用新種的services chaining把他串起來 看完這youtube和這兩頁, 我想有domain knowhow的人員其實未來還是很被需要 的, why? AT&T在想的絕不是這麼簡單, 我記得有評論說NFV 能大幅改變網路規劃的 方式, 是以全網當成一個系統,  將控制與轉發分離的天條,  仔細的審視各功能的 整併, 建立一個可全系統調度的網路服務, 個別技術不是重點, 高彈性的網路服務才是 不過,  這一切還是軟硬體已到達可思考實作的起始臨界點, 很多技術或範本都還不存 在 ,  但是 , 真的好玩的來了 ,  五年的困惑也有了一些解答

各領域的 "跟上" 資源 (updating...)

搞技術到老真的要有覺醒, 你得不斷的學習, 其實,  學也就算了,  難的是難入門, 要當可悲的 菜鳥(要老鳥被踐踏是很難受的,因為那是遙遠的記憶) anyway, 不是真有興趣也走不到這一步,  都已經菜過了 ,  就不能白白放掉,  要持續跟上, 其實"難入門"的一大主 因,  是很多領域連那唯一的一本書都沒有(例如 load balancer, , proxy/cache..), 此外, 你必須知道這領域的歷史,  包袱,  未來可能的進展 唉 IP https://www.ietf.org/ RFC有空還是要看看有沒有新的 https://www.nanog.org/ https://www.ripe.net/ 每一季都有會議 http://www.lightreading.com/ https://www.sdxcentral.com/ http://blog.ipspace.net/ Mobility http://blog.3g4g.co.uk/ http://www.4gamericas.org/en/resources/white-papers/ http://www.rysavy.com/writing http://mobilesociety.typepad.com/mobile_life/ http://disruptivewireless.blogspot.tw/ Application delivery/performance https://devcentral.f5.com/ https://devcentral.f5.com/users/38/my-contributions/typeid/42 http://apmdigest.com/ http://apmblog.compuware.com/ https://www.igvita.com/ https://sharkfest.wireshark.org/ Security SANS Reading Room http://www.darkreading.com/ http://krebsonse

from Avi

https://blog.avinetworks.com/2014/12/01/3-customer-stories-that-helped-shape-avi-networks 以下節錄一段 網路軍火商不要想著賣東西給自家就能造軍火的公司 此外,SDN不是要顧客的network team寫code, 對客戶而言 把問題解決是第一要務, 背後解法不是最重要的 One of my initial chats was with the CIO of a large public e-commerce company. My curiosity was piqued when he told me he didn't want staff experts who are “an inch wide and a mile deep.” Instead, he wanted smart, innovative generalists who could focus on the big problems. “I have every tool under the sun, whether for performance or visibility or acceleration,” he said. “ But I don’t have folks who understand these tools. I can’t attract that kind of specialized talent, and it’s too expensive.” Today, a big part of our mission is to  mask technical complexities  from the user by engineering solutions that are not only “intelligent,” but intuitive and  exceedingly simple to use . And simple is not easy. Simple is the removal of everything except what matters, and that takes longer and is much

ONS 2015 video

ONS 2015 video 熱騰騰, Amin Vahdat的keynote還是最多人關注 Google的影響力可見一斑, 此外Amin 的演說精簡 直指要點, 聽來很是享受與具高度啟發性, 尤其是 簡報完後的Q&A 期待九月的更多細節

latest DC engineer requirements

Experience in architecting large IP/MPLS and DC networks.  Expert in BGP, OSPF, IS-IS. Expert in TCP/IP protocol stacks and experimental performance enhancements. Deep knowledge of IPv6, network security, and protecting control planes. >>Solid understanding of Linux routing Experience with SDN Technologies (OpenFlow, OVS, IO-Visor, Nuage, OpenContrail, BigSwitch, etc) >>Proficient in reading and writing Python, Bash, Perl, Ruby. >>Knowledge of automation frameworks (Ansible, Chef, Puppet, etc.)  Deep understanding of Optical technologies, DWDM, and modern data center architectures.

Google 之自己來和網路業界的樣樣通

http://www.wired.com/2015/06/google-reveals-secret-gear-connects-online-empire/ 昨天熬夜聽ONS google 的演講, google 不止運算與網路硬體自己來, 連協定 也自己創造一個, 這讓我想起Qfabric的巨大失敗,我想那時google 的人在聽J 的簡報時不知在想什麼, Qfabric可是花了超多錢, 排擠掉多少內部專案,才搞 定的, google到底花了多少人力與金錢, 他們真的比較聰明嗎? 網路業界可能不服氣, 畢竟google要發展最符合他們需要的設備(多的功能不要), 網路業界要發展可以賣給很多人的設備(一堆雜七雜八的功能) 多數企業不可能花這樣多的訂製工作(連facebook都沒吧), 網路業界也要認清 ultrascale的設備是不可能賣給google的

感恩! 直指要點的好書 我終於有讀懂的感覺了

Python 程式設計入門

一般企業與web scale 企業對安全的看法截然不同

http://blogs.wsj.com/cio/2015/05/11/google-moves-its-corporate-applications-to-the-internet/ http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/43231.pdf http://buzzorange.com/techorange/2015/05/14/google-beyondcorp/ 畫重點 基本假設是,內部網絡實際上跟互聯網一樣危險。因為 1)一旦內網邊界被突破,攻擊者就很容易訪問到企業內部應用。 2)現在的企業越來越多采用移動和雲技術,邊界保護變得越來越難。所以乾脆一視同仁,不外區分內外網,用一致的手段去對待。 "這種訪問模式要求客戶端是受控的設備,並且需要用戶證書來訪問。"在這種模式下,信任關係從網絡層面遷移到了設備層面。

殘酷的4G : 寬頻網路背後的戰爭 = The battle behind broadband brutal 4G

some backhaul bandwidth calculation 2G - per antenna/basestation 5Mbps 5Mhz - GSM carrier -200kHz = 25 carriers 7 channels per carrier -> so 175 channels HSPA+ 22/42 Mbps ( up/down) (using  5Mhz) LTE 86/326 Mbps ( if 20Mhz) how much bandwidth improvement via LTE 20Mhz( who has 20Mhz?) LTE design for telecom - key objective is latency LTE still is highly telecom optimized( why using expensive telecom oriented network technology to serve internet traffic? - Do we really need 10ms or even 1ms latency? bad baby discipline ( 壞寶寶)- spend huge efforts to serve poor quality users Wide LTE deployment is because of WiMAX competition WiMaz ( since 2000- called Worldwide interoperability of "microwave" access) - it was backhaul microwave technology 802.16d fixed WiMAX then mobile WiMax 802.16e ( by Sprint) Why Intel promoted WiMax/WiFi -> push more computing requirements -- same as virtualzation or NFV ...... Qulacomm was the killer to WiMax Death of

ghost story (for Firewall vendors)

http://etherealmind.com/why-firewalls-wont-matter-in-a-few-years/ 其實這還是兩種 IT運算環境的爭論, 像google不愛 VM, 可能不甩 compliance , 有一堆超強攻城師, 一般企業可沒有, 一般企業的雇員也有 買 IBM/Cisco不會被fired 的迷思 這類想法能提供另一面的思考方向,  但說firewall在幾年內就無關緊要 是聳動了點, 不過,  不這麼寫, 有人會看嗎 AppSec is Eating Security AppSec is Eating Security from Alex Stamos

Analytics in SDN

https://www.sdxcentral.com/articles/news/how-att-honed-its-sdn-nfv-plan-code-first-tweak-later/2015/05/ http://www.lightreading.com/carrier-sdn/level-3-analytics-unlocks-sdn-potential/d/d-id/715664

SDN definition

SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower level functionality -Device Provisioning Systems -Service Provisioning Systems -Routing and Forwarding Adjustment Controllers I love SDN Toolbox part https://ripe70.ripe.net/wp-content/uploads/presentations/7-SDN-4-Years-Later.pdf

Full stack engineer

敢自稱自己是的人不是神人就是不知天高地厚 但我可以以此為學習目標吧, 而且, 這title多是在internet公司搞研發的 我在這networking已待到看過幾次輪迴, 也知道技術的起落有多快 不過. 能經歷各個不同領域當菜鳥.  嘗盡冷暖  也是自找的 現在的困境仍是樣樣摸 樣樣鬆 讀了這 忘了那 尤其跨領域的 (就連networking 也分上下層阿)的思考模式真的非常不同 更別提還要把programming找回來 不過, 一般說的 Full stack engineer還是能搞定front-end 到back-end的programmer 最好還懂網路 from  http://www.sitepoint.com/full-stack-developer/ 我想的是L1-L7 Anyway, move on  "Read, read, read. Read everything—trash, classics, good and bad, and see how they do it. Just like a carpenter who works as an apprentice and studies the master. Read! You'll absorb it"

都是網路的錯嗎

https://code.facebook.com/posts/1499322996995183/solving-the-mystery-of-link-imbalance-a-metastable-failure-state-at-scale/ https://blog.gslin.org/archives/2014/12/10/5434/facebook-%E5%9B%A0%E7%82%BA-connection-pool-%E9%81%B8%E6%93%87%E6%A9%9F%E5%88%B6%EF%BC%8C%E5%8A%A0%E4%B8%8A%E7%B3%BB%E7%B5%B1%E7%9A%84%E8%A4%87%E9%9B%9C%E6%80%A7%E8%80%8C%E5%B0%8E%E8%87%B4%E7%9A%84/