Log for 電訊台

Dear Customer,

OCI Netinfra team answered

140.91.214.14 is OCI ICN Elpaso IPs. traffic is NOT hair pinning around US. 140.91.214.14 is registered under US in internet registry but thats not to say IP is located in US.

no issues observed here!

ataherim@icn2-j1-gateway2> show route 140.91.214.14 table INTER

INTERNET.inet.0: 972186 destinations, 2384900 routes (963321 active, 1 holddown, 12758 hidden)
+ = Active Route, - = Last Active, * = Both

140.91.214.0/23 *[BGP/170] 2d 20:44:26, MED 0, localpref 1500, from 198.19.214.128
AS path: I, validation-state: unverified
> via Tunnel Composite, Push 1000000
[BGP/170] 2d 20:44:26, MED 0, localpref 1500, from 198.19.214.143
AS path: I, validation-state: unverified
> via Tunnel Composite, Push 1000000

what the fuck

| 140.91.214.14 - 3 | 216 | 211 | 249 | 252 | 277 | 252 |
| 193.122.119.233 - 2 | 220 | 216 | 250 | 252 | 267 | 251 |

200 ms ping wo

話説點解我HKBN會走咗去tata communication

AS6453

我連去oracle cloud south korea可以200ms咁離譜

話説點解hkbn會有AS10103同AS9269兩隻ASN? 佢做咩要分upstream同downstream?

一個係商業網一個係 backbone 網

其實而家仲有 AS9381 同 AS17444

反正呢家打去qc team 無人接電話...

香港寬頻過咗咁耐都仲未整合 九倉 同 新世界電信 嘅 resource

cls

懶到狗咁

之前同 HKBN 要 MetroE，人地個地址淨喺得九倉線，於是個 demarc 竟然唔同咗

我無得用我個 HKBN demarc 黎駁呢條線，會貴好多

https://en.wikipedia.org/wiki/Acoustic_coupler
wow

未必係懶到狗嘅...本來佢地network team成個field咁做

原來係咁

合拼左幾多年…….

2018 開始？

真係唔知佢哋 哈哈

起碼 MetroE 呢啲其實可以整合到

係 core 行多條線就得

佢地有得合嘅話，今年份成績表唔會柒左然後要瘋狂兜人

頭先打咗去hkbn qc team問個清 諗睇下點解oracle cloud south korea會走咗去tata
佢哋話呢個係oracle控制...個upstream佢哋個router覺得快就快...睇嚟要oracle人工干預
順便問佢哋點解家居寬頻仲未有ipv6 佢話點解要有 我問點解要冇
我話全世界都開始ipv6 deployment 但佢又攞pccw嚟反駁
話呢家ipv6啲peer都未齊根本上唔靚...
好...心服口服

唉

香港班老屎忽究竟幾時先全部普及ipv6

我可以話用6rd或者tunnel broker玩一陣這 但係我真係頂唔q順he.net經常100ms爆炸

同埋我要/48嘅prefix assignment for calico同proxmox vm用

佢 hea 你啫

Ipv6方便你姐

唔方便isp喎

我覺得BGPv6方便得多

起碼多好多AS做peering

ipv4唔平 搞到AS入場費好高

咪要同n倍咁多peer deal....

所以咪唔方便囉😂

咁又其實諗真啲佢哋又未有權去broadcast ipv6 range畀所有人...

咁樣先可以eliminate single point of failure㗎

咁唔係要internet嚟做乜

唔會，multi node嫁嘛😂

同埋要炒車個陣，大家learn返黎都係食屎

咁what 7 is single point of dailure

node多自然critieria咪多 flexible咁多點解會食屎?

唔係嗰個都走同一條circuit ma

Bgp learn route 特性，而且仲要peer

唔係咁睇

咁唔好shortest path咪得 改用a* heuristic

最多只可以話多node learn嘅時間耐啲，炒車範圍未必咁大

😂

你一改就改曬所有 router 嘅 algo

好難做窩

係

但救個陣又係咁多時間

又係67

咁咪好 增加robustness

救嘅時間呢....

我會選擇預先learn多幾條做backup route

Learn返黎得100M嘅

你咪又係wtf

Traffic唔會eliminate

所以咪要learn多幾條然後用priority queue排

無用，jam左

我就相信你多咗咁多條路 唔係條條路都會jam嘅

除非大家peer 都係30T 起跳，剩返嘅路夠食traffic

Traffic唔會eliminate 😂

so spread it

law of large numbers

Reminding... How

點divert走都係咁多

well 反正我嘅諗法就係似SCTP咁

除非炒車個邊救得返

但首先有足夠大水喉

Spread都好，都要夠水喉

又係

所以多node leaen嘅時候耐啲，死嘅慢啲

係咁多姐

Traffic係咁多，水喉得咁大，自然jam同排隊，呢個無得走

所以一係分薄traffic 一係將啲水駁去其他水喉 一係水喉整大 一係水喉識自己節制...

然後你見到300ms latency 繼續屌鬼

唔記得咗bgp仲有convergence speed...好似係O(n^2)

Bgp v6多啲人，水喉都係咁幼，好過無系列

至弊都係淨係support ipv4啲gear有沉沒成本...

先改善水喉幼嘅問題

你知道 v6 route 要佔 4 倍 TCAM space 嗎

同 v4 比

optimize 咗用 trie 同 bloom filter 都要 2 倍 TCAM

即係一個 10M entries 嘅 TCAM 淨係可以塞 5M v6

雖然而家 v6 少 route

v4 就好 X 多條 route，因為越來越碎

論 route lookup cost 嘅話 v6 > v4

呢個 Juniper 用先，Cisco 而家Silicon One 都用

其實而家啲水喉比幾年前粗好多架啦

係 HKBN 自己唔 upgrade 啲 transit

而且ipv6相對亦都少好多range 因為容易滿足胃口

但係 ipv6 切碎嘅 potential 高過 v4

除非你控制得好

tcam memory
atm machine
acs system

？

主要係 唔係技術問題合唔到

感覺係管理問題

4 pounds

how see

咩 spec

need check

liquidation auction

怕太舊