通过 mac 跟踪 server 对应的 sw 端口

之前机器有问题总是麻烦 IDC 的值班人员去人肉查询,效率低出错高。后来想了下应该可以通过 mac 对应找到服务器的网线接在交换机的那个端口。查了下 manual,果真有。

以这台机器为例:
$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 77:11:22:4d:3b:ba
          inet addr:192.168.10.24  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:119248637867 errors:0 dropped:0 overruns:0 frame:1548
          TX packets:119025695631 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:27302958509591 (27.3 TB)  TX bytes:28642036038875 (28.6 TB)
          Interrupt:48 Memory:dc000000-dc012800

可以看到这台服务器的 mac 地址是 7711.224d.3bba,登录到 sw 上查找:
sw#show mac address-table address 7711.224d.3bba
          Mac Address Table
——————————————-

Vlan    Mac Address       Type        Ports
—-    ———–       ——–    —–
   2    7711.224d.3bba    DYNAMIC     Gi0/18
Total Mac Addresses for this criterion: 1

当然也可以『反向』查询了:
#show mac address-table interface Gi0/2
          Mac Address Table
——————————————-

Vlan    Mac Address       Type        Ports
—-    ———–       ——–    —–
   2    1122.3344.a7f5    DYNAMIC     Gi0/2
Total Mac Addresses for this criterion: 1

简单快速高效 :-)

channel-misconfig (STP) 分析防范

Errdisable 是 cisco 设备的一种机制,该机制会在设备出现 looping、psecure-violation 等情况下 shutdown 或者 suspend 出现问题的端口,同时端口也会的 LED 也会变成橙色。

某台二层设备跟三层连接时,发现做 EC 的某个端口出现了 err-disable 的状态,下面几种方式都可以查看到 error:
#show int G1/0/23 status
Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/23                     err-disabled trunk      a-full a-1000 10/100/1000BaseTX

#show int G1/0/23
GigabitEthernet1/0/23 is down, line protocol is down (err-disabled)
正常的应该是:
GigabitEthernet1/0/23 is down, line protocol is down (notconnect)

#show interfaces status err-disabled
Port      Name               Status       Reason
Gi1/0/23               err-disabled channel-misconfig (STP)
Continue reading

基础网络升级(四)

其实到基础网络升级(三)应该就结束了,不过在使用过程中发现内网的路由之前规划的不是很好,老机房(192.168.10.0/24)的都是从一台 NAT 上出去,当时为了省事,把新机房(192.168.20.0/24, 192.168.30.0/24)的所有流量通过路由到了老机房,然后再从那台 NAT 出去。这样造成结果就是流量比较『混乱』,一个出口也同时存在 SPOF 的问题。比较好的方式还是老的不变,新的从新机房的 NAT 上出去,这样至少有两个出口,一个挂了还有挽救的措施 ;-)
要修改的地方不是很多,老机房的 NAT(192.168.10.254)、三层设备的路由不需要变。NAT 通过 MASQUERADE 的方式出去:
# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        
MASQUERADE  all  —  0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

# cat /etc/iptables
-A POSTROUTING  -o eth0 -j MASQUERADE

老三层设备的静态路由信息,默认路由是指向 NAT 的 IP:
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.10.254
ip route 192.168.20.0 255.255.255.0 192.168.1.2
ip route 192.168.30.0 255.255.255.0 192.168.1.2
no ip http server
ip http secure-server
!

新 NAT 机器(192.168.20.254):
# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        
MASQUERADE  all  —  0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

# cat /etc/iptables
-A POSTROUTING -o em2 -j MASQUERADE

新三层设备,默认的路由指向新 NAT 设备:
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.20.254
ip route 192.168.10.0 255.255.255.0 192.168.1.1
no ip http server
ip http secure-server
!

以上只是简化的模型,实际的比这个复杂些,不过思想不变。

基础网络升级(三)

前两篇(1, 2)基本覆盖了此次升级的整个思想以及操作过程包括一些细节的涉及,不过在升级完之后,我们部署在老机房的监控系统发现,从老到新的中间的链路的质量比较差,三层之间路由接口的丢包很严重:
# ping IP_NEW repeat 8000

平均会丢 100+ 个包,丢包率超过了 1%,从监控到对端服务器的丢包就更严重了,平均都在 10%,峰值能达到 80%,注意这是两个打通的内网,我们也因此几乎无法登录到新机房的服务器进行操作,即使进去了,ssh 也是『卡』的让人随时受不了,网页完全打不开。丢包没有任何的时间特征,几乎是全天候。花了很长的时间 debug 确认了应该不是我们的问题之后,目光转移到了我们的服务商那里,猜测可能是中间链路的光纤或者连接器之类的问题。

期间,由于不稳定造成了几次很严重的网络中断。后来,对方的工程师也承认这根光纤衰减跟正常的偏差较大。最终决定更换这根光纤。

结果可想而知,下图是我们新机房某台交换机的 ping latency,效果很明显。

有时候我们会太天真的认为,光纤是很稳定的,正常情况下,是不可能出问题的,不过偏偏就是中了。

事后也进行了一些讨论包括 post-mortem,不过都是些治标不治本的点到为止,尽管我对此事非常的关注甚至『恼火』,在跟对方的邮件沟通中措辞非常的严厉,不过也只是搔搔痒罢了,我能做的就这么多。
当然,上面一系列的工作不属于我的工作范畴,既然做了就把他做好,至于有些不该知道的,就装作不知道好了。这个基础升级就写到这里为止,再下去就真的要到非技术层面了。

基础网络升级(二)

上一篇做的主要工作其实只是打通了两个机房的内网。升级完成之后,由原来的『无序』变得相对『有序』。

由于历史原因,起初的网络不得不如此的冗长 :-(

不过,经过研究发现,本质上依然无序的二层结构,除了启用了 ip routing。因为,机房与机房之间的连接是通过两台二层机器完成的,这两台机器纯粹充当了网线的角色,使用 access 相连接,同时又出现了 SPOF 的问题。

基础网络升级(一)里面完成的部分操作

Continue reading

基础网络升级(一)

最近又兼职做了好多网络方面的工作。包括某个新机房的网络部署以及某个机房的网络改造升级。
新机房的网络部署没什么好说的,基本是 0 风险,顺便带着实习生熟悉环境。
原有的某个机房最初的网络结构是普通的二层,通过 trunk 级联,并且级联的很奇葩,基本是一个主干拖着若干的枝叶。由于当初上线比较紧急,没有多少时间来做这方面的调研,导致目前该机房的网络存在严重的隐患。
最明显的就是 SPOF 以及单条链路带宽趋向饱和,有的在高峰期维持在 1G,丢包率也随之上升。
花了不少时间调研之后决定将其改造成三层网络,access 以及 Aggregation 通过 ethernet channel 做绑定,三层的通过 StackPower 以及 StackWise Plus 做 Failover。
升级前做了大量的准备工作,借此机会也统一了我们的基础网络设施的规范以及操作。凌晨开始操作,按照先前规划好的顺序一台一台的插拔,保证前一台插拔无误之后再进行下一台的操作,最坏的情况就是将该台设备 rollback。实际操作,两人配合,基本从拔到插到最后网络联通在 10s 之内。整个过程还是比较顺利的,几乎没有出现什么问题,即使出现的,也都在控制范围之内。
最后的效果还是很明显的。升级后的机房的网络利用率高峰基本维持在 50% 左右,新部署的机房由于数据量太大,高峰时段的链路带宽利用率还是超过了 90%,目前比较可行的就是四条链路做绑定或者直接上 10G 的 uplink,不过这两者都需要上 45xx 系列的大块头了,或者是至少 4 台设备做 stackwise。