Network Manage Tech Experience

Welcome to my tech home !!!
posts - 32, comments - 35, trackbacks - 0, articles - 0
  IT博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2008年8月18日

Google 标签: ,

下面假设客户访问www.abc.com的dns请求流程如图:

clip_image002

1, 首先向其所在运营商的Local DNS发起www.abc.com域名的DNS请求,步骤1;

2, 运营商的Local DNS服务器从RootDNS得知www.abc.com由DNS-CTC、DNS-CNC、DNS-USA1和DNS-USA2来解析,即RootDNS同时返回此4个DNS服务器地址给LDNS(这是DNS的工作原理,它一定会返回所有关于请求的记录,在此即4个DNS服务器。如果只返回一个DNS而此DNS刚好中断服务了,那么Local DNS只能是解析失败了),步骤2和3;

3, Local DNS轮询向这4个DNS服务器发出域名解析的请求,直到返回数据,步骤4;

4, 假如DNS-CTC相应LDNS的域名解析请求,同时返回2台GTM的地址(Listener),步骤5;

5, 接受到请求的GTM首先查询在本地是否有该Local DNS的就近性表项,如果存在,则直接给Local DNS返回速度最快的服务器地址。如果不存在,则通知另外一台GTM发起对该Local DNS的查询,步骤6和7;

6, 两台3DNS分别对LocalDNS进行Probe。例如GTM-A查询该Local DNS的RTT时间为50ms,而GTM-B查询同一Local DNS的RTT时间为100ms,则此时在两台GTM内都形成了该Local DNS的对应就近性表记录;

7, 接受到Local DNS请求的GTM-A根据系统的就近性表返回相应的Data Center内的WEB服务器地址(即1.1.1.1),步骤8;

8, Local DNS获得地址后,将该地址返回给用户,到此DNS请求过程结束,步骤9;

9, 用户向www.albc.com(1.1.1.1)网站发起访问,步骤10。

posted @ 2008-08-18 14:52 chris_lee 阅读(1212) | 评论 (1)编辑 收藏

2008年8月2日

Google 标签: ,

需求:
1,abc.com和www.abc.com两个域名解析成同一个ip(F5上的vip1),提供443服务,并且只提供www.abc.com的证书;但是平时会有人通过访问http://www.abc.com或者http://abc.com来访问。所以通过abc.com来访问的话会有证书确认的提示。
2,xyz.abc.com解析成另外一个ip(F5上的vip2),提供443服务,绑定xyz.abc.com的证书。

需要解决如下问题:
1,所有通过http访问的需要跳转到https来访问,即如:http://www.abc.com需要跳转到https://www.abc.com/或者http://abc.com需要跳转到https://www.abc.com/来访问;
2,所有通过abc.com来访问的需要跳转到www.abc.com来访问;
3,针对上述两个vip,使用统一的irule。

书写irule如下:
rule redirect_http2ssl {
when HTTP_REQUEST {
if { [HTTP::host] equals "abc.com" }{
HTTP::redirect https://www.abc.com[HTTP::uri]
}
else { HTTP::redirect https://[HTTP::host][HTTP::uri] }
}
}

应用irule:
将此irule应用到两个ip(vip1和vip2)的80服务上面。

posted @ 2008-08-02 11:43 chris_lee 阅读(1169) | 评论 (0)编辑 收藏

2008年7月6日

两台Nokia IP防火墙做成cluster,平时两台防火墙都会处理流量,所以在重启的时候需要注意重启的设备是否还有流量在处理。如果其正在处理流量而重启,这样就会导致这部分流量的session中断。所以需要先将此防火墙处理的流量移交给cluster的其他member,接着停止其checkpoint的服务,然后重启。

1,将其处理的流量移交:可以通过其退出cluster来达到此目的。在Nokia的voyager配置cluster的界面里面可以查看到都是哪些端口被监控了,可以将其中的某一个端口(内外网口)down掉,其就会退出cluster。这时可以通过查看cluster的监控来看出其是否退出了cluster。

2,停止此防火墙的checkpoint服务:通过ssh或者telnet登陆防火墙的控制台,输入cpstop回车就可以停止此服务。

3,重启防火墙:通过ssh或者telnet登陆防火墙的控制台,输入reboot回车重启。

4,重启完成后,防火墙自动打开checkpoint服务。然后将第一步down掉的端口up起来,就能自动加入cluster。

posted @ 2008-07-06 12:46 chris_lee 阅读(250) | 评论 (0)编辑 收藏

Google 标签: ,

F5的端口绑定在F5的配置上面叫做端口的Trunk,与cisco技术上的trunk不通。

一般F5的内外网口都会接入在交换机上面,比如cisco的7609等,这样针对F5做端口绑定就需要注意以下问题了:

1,F5端口绑定支持的算法默认为dst-src-ip,是否与互联的交换机兼容;
2,F5同样支持LACP协议,是否与互联交换机兼容等;
3,F5做Trunk配置在不中断服务的情况下,需要先做standby的配置;
4,F5的Trunk需要2个或者多个没有被占用的端口做配置,否则在配置的时候看不到已经绑定了vlan的端口的;

其实最简单的配置F5的Trunk就可以了。 例如如下配置:

环境及需求描述:
思科交换机G1/1连接F5的1.1口,现需要将F5的1.2口与1.1绑成一个trunk使用。

思科交换机配置如下:
int port-channel 1
switchport
swit acce vlan 20
swit mo acce
no shut

int range g1/3-4
switchport
swit acce vlan 20
swit mo acce
channel-group 1 mode on
no shut

F5配置:
先配置standby的F5,将1.1从vlan里面退出来,然后新建trunk,添加1.1和1.2,如下:
image

然后将ext_trunk添加入相应的vlan即可。

最后连线,完成,检测后切换active/standby,配置另外一台F5.

posted @ 2008-07-06 12:29 chris_lee 阅读(1728) | 评论 (0)编辑 收藏

2008年6月6日

Google 标签: ,

一直以来在一个典型的交换三角网络内,存在这样的一个问题:一台没有接入任何一台服务器二层交换机的两个uplink口的RX方向上竟然存在很大的流量。通过在此交换机上抓这两个uplink口的数据包,发现存在很多unicast的包。而从三层交换机上面通过查找arp表和mac表后证明这些数据包不应该会下发到此交换机上。此问题查找了很久都没有找到原因。今天在某朋友的提示下,查看了block-unicast的命令解释。

Understanding How Unicast Flood Blocking Works

You can enable unicast flood blocking on any Ethernet port on a per-port basis. Unicast flood blocking provides you the option to drop the unicast flood packets on an Ethernet port that has only one host that is connected to the port. All the Ethernet ports on a switch are configured to allow unicast flooding; unicast flood blocking allows you to drop the unicast flood packets before they reach the port.

Caution You must have a static CAM entry that is associated with the Ethernet port before you enable unicast flood blocking. If you do not have a static CAM entry that is associated with the port, you will lose network connectivity if you enable unicast flood blocking. You can verify that a static CAM entry exists by entering the show cam static command.

---摘自http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/configuration/guide/uniflood.html

反正此二层交换机下面没有接服务器,于是便在三层交换机的下联此二层交换机的端口上启用了命令:switch block unicast。然后查看二层交换机的端口速率变化,发现很快速率就降到了300K左右,效果非常明显。呵呵,虽然没有从根本上解决上面描述的流量异常转发现象。

然后我通过在此二层交换机下面接入一台服务器(ip=1.1.1.1)来测试启用block-unicast特性的效果。

1,在没有启用block-unicast特性时,在远端长ping 1.1.1.1,然后在三层交换机上面清除此服务器的mac表项,发现根本没有任何丢包;

2,在启用了block-unicast特性后,在远端长ping 1.1.1.1,然后在三层交换机上面清除此服务器的mac表项,发现time-out了,大概丢包15个。

下面来分析一下原因,也即block-unicast特性的处理机制:在端口A上启用了此特性后,所有发给端口A的数据包都要查看一下端口A的相关mac表项,如果此表项有数据包的目的mac地址,就进行转发;否则丢弃。直到此mac相关的arp表项超时,进行arp洪泛后,交换机学习此mac入mac表,才能通信。

总结:在生产网络上,需要谨慎使用此特性,一般不启用,默认也是不启用。当然在二层交换机的access模式端口可以结合端口安全sticky特性来启用block-unicast。

posted @ 2008-06-06 18:35 chris_lee 阅读(355) | 评论 (0)编辑 收藏

2008年6月2日

 

记得在上一家公司时,出现过交换机突然重启了,配置文件也消失了,所以导致一系列问题等。后来通过查问同事找到了原因,是因为交换机的MODE键抵住了机架,导致重启。而通过按住交换机前面板的MODE键10s后交换机会将配置文件清除,然后重启,也就是说恢复到出厂状态。后来通过查找cisco文档发现有一条命令可以解决这个问题。

全局模式命令:no setup express
解释:
When Express Setup is enabled on a new (unconfigured) switch, pressing the Mode button for 3 seconds
activates Express Setup. You can access the switch through an Ethernet port by using the IP address
10.0.0.1 and then can configure the switch with the web-based Express Setup program or the CLI-based
setup program.
When you press the Mode button for 3 seconds on a configured switch, the mode LEDs start flashing. If
you press the Mode button for a total of 10 seconds, the switch configuration is deleted, and the switch
reboots. The switch can then be configured like a new switch, either through the web-based Express
Setup program or the CLI-based setup program.
......
The primary purpose of the no setup express command is to prevent someone from deleting the switch
configuration by pressing the Mode button for 10 seconds.
    ------摘自http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2940/12113ay/2940cr/cli2.pdf

不过同时想到了另外一个问题:交换机做密码恢复时需要使用到这个MODE键,如果在交换机上面配置“no setup express”后,会不会导致不能进行密码恢复了呢?于是我今天针对这个问题做了一个实验,答案是使用“no setup express”命令与交换机密码恢复不冲突。

下面介绍一下交换机密码恢复过程:

1,按住MODE键(大概10s)同时启动电源,在发现SYST灯经过一段时间闪动后,突然变成黄色,然后马上就变成绿色不闪烁,这个时候松开MODE键;

2,终端上面会出现如下界面:
image

3,输入“flash_init”命令,初始化后再输入“dir flash:”命令,显示如下:
image

4,输入“rename flash:/config.text flash:/config.text.renamed”,结果如下:
image
需要注意的是:有可能当你输入上述命令后,系统会提示错误信息,重新输入就可以了。这个问题我碰到过很多次。

5,然后重启交换机,命令:boot
注意:这个模式下可以通过“help”命令来查看命令。

6,重启后进入系统,这是show run命令查看出来的是初始化配置,所以需要重命名flash:/config.text.renamed文件,命令:rename flash:config.text.renamed flash:config.text;

7,将flash:config.text拷贝到内存中,命令:copy flash:config.text system:running-config;

8,这个时候就可以修改密码了,然后保存就行了。

总结:为了解决交换机通过mode重启导致配置丢失的问题,可以在交换机上面配置"no setup express"命令,这个命令与交换机密码恢复没有冲突。

posted @ 2008-06-02 20:00 chris_lee 阅读(473) | 评论 (9)编辑 收藏

2008年5月30日

    这篇文章确实不错,完整仔细地记录了IOS升级碰到的几个问题,值得我学习,所以转载了下来。本文摘自:http://net.yesky.com/94/2534594.shtml

 

      各公司的网络管理员在选购网络设备的时候都是精挑细选,在同等级别的不同厂商之间反复研究,多次比较后选出最佳性价比的产品来。不过有一点可能很多网络管理员都忽略了,那就是网络产品的未来,一个产品不可能一直使用肯定会有出问题的时候,出问题后厂家的服务就显得尤为重要了。同样网络技术是在不断发展前进的,网络产品也要有一定的可升级可扩展性。最近笔者就遇到升级核心设备的问题,现记录如下:

  一,升级环境:

  事情的原因是这样的,公司下属部门申请到一定的经费用于网络升级,因此该部门前几天新买了一台思科的Catalyst6509交换机,并且配备了WS-X6548-GE-TX这个思科在去年四月才新推出的10M、100M、1000M自适应的48口RJ-45交换模块。6509一共有9个插槽,所以可以插上9个模块,为核心设备升级添加模块是习以为常的事情了。不过由于思科的软件推出总是滞后于硬件,所以拿到手的Catalyst6509交换机标准配置的12.2(14)SX1版本的IOS并不能支持该模块。这就涉及到了升级问题,需要升级6509交换机的IOS。于是我和子部门网络管理员从CISCO官方网站找来支持WS-X6548-GE-TX模块的新版本的IOS准备升级。没有想到,这次简单的升级工作却弄得我们两个“准高手”麻烦连连,问题接二连三地出现。

  二,没有RJ-45接口

  对于本次采用的这个WS-X6548-GE-TX模块一共有48个RJ-45端口,然而6509交换机又没有配其他的带RJ-45接口的模块。这可怎么办呢?毕竟用思科的TFTP Server升级IOS就必须得将交换机和网络上的一台装有TFTP Server的PC相连。经过一番寻找,终于发现超级引擎720上面有一个RJ-45模样的接口,旁边写着Link的字样,结果拿来网线插上一试,发现指示灯都不亮。本来我们两个以为有了希望,然而指示灯不亮就说明该接口无法使用,不过因为这个接口是惟一的希望,否则只能用xmodem方式传输41MB的IOS,传输时间恐怕让我望而却步。

  小提示:

  使用XMODEM传输IOS速度上是非常让人头疼的,笔者曾经用XMODEM方式传过一个2950交换机的IOS,总容量也就2MB左右,足足用了两个钟头。按照这个速度来说41MB最快也得30几个小时。

  既然使用XMODEM方式传输IOS不太现实,那么还要从超级引擎720上面那个RJ-45模样的接口入手。从网上搜索到相关资料,原来超级引擎720上的port2 有两种模式:一种是RJ-45接口,还有一种是SFP(a small form-factor pluggable)接口。而默认的设置是SFP,要使用RJ-45接口就必须更改设置。输入以下命令进行修改——

  Router(config)#interface gigabitethemet 5/2

  //进入该接口进行设置

  Router(config-if)#media-type rj45

  //修改模式为RJ45,默认是SFP

  Router(config-if)#no shutdown

  //启用该接口

  执行命令后发现橘红色的指示灯终于变成了绿色,接下来就可以使用传统的TFTP方法将升级所需的IOS文件传到到交换机中。本来以为接下来的事情就应该很轻松,谁知道拦路虎并没有就此罢休。

三,TFTP传输协议不支持32兆

  接下来给接口配上管理地址,再把原来的IOS备份出来。在超级终端全局模式下输入命令:

  Router#copy sup-rootflash: s72033-pk9sv-mz.122-14.SX1.bin tftp://192.168.1.1

  TFTP Server 出现一连串#字号,开始传输数据,本来以为一切OK。谁知道眼看着就要传完的时候,系统提示:“timeout! Write error!”。

  根据系统提示的信息我查询了网线是否断了,磁盘空间是否不足,答案都是否定的。再次执行传输命令故障依旧。到6509上查看传输完毕的IOS大小为32MB,比完整的IOS32.1MB稍微小一点。为什么多出的0.1MB就无法传送呢?

  开始以为是TFTP的软件有问题,版本过低造成的。从网上下载了一个第三方的TFTP server一试,结果还是这样。又找来3Com的TFTP Server,这次效果更差,传到16MB的时候就断开了,系统提示还是超时和写入错误。仔细分析,终于发现了问题关键所在。两次传输,一次正好32MB,一次正好16MB,连字节数都不差,肯定不是传输线路问题。找来资料一查,原来TFTP(Trivial File Transfer Protocol)普通文件传输协议最大就支持传输32MB的文件。于是又找来思科文档,一番查询,找出了第2种解决方法,用FTP就行了。于是在PC上建好FTP服务,键入如下命令:

  Router# configure terminal

  //进入交换机配置模式

  Router(config)# ip ftp username username

  //设置FTP的访问用户名

  Router(config)# ip ftp password password

  //设置登录FTP的密码

  Touter(config)# end

  //结束,退出

  Router#copy sup-bootflash:s72033-pk9sv-mz.122-14.SX1.bin ftp:[//[username[:password]@]192.168.1.1]

  //执行FTP传输命令将原有bin文件上传到FTP,传输文件为s72033-pk9sv-mz.122-14.SX1.bin,FTP服务器地址为192.168.1.1。

  使用FTP传输更新IOS后文件复制非常正常,等待了几分钟,系统提示“successful!”。看来FTP比TFTP就是强大灵活,限制也少很多。

四,协议错误

  将IOS成功备份到FTP上后就轮到将新的用于升级的IOS进行上传了。进入6509配置模式使用如下命令进行操作:

  Router# configure terminal

  //进入配置模式

  Router(config)#ip ftp username username

  //设置登录FTP的用户名

  Router(config)#ip ftp password password

  //设置登录FTP的密码

  Router(config)#end

  //退出设置

  Router# copy ftp:[[//[username[:password]@192.168.1.1] / s72033-jk9o3sv-mz.122-17a.SX.bin] sup-bootflash:

  //复制s72033-jk9o3sv-mz.122-17a.SX.bin新版IOS到本交换机。

  本来以为轻轻松松完成的,结果系统这次提示“Protocol error!”。协议错误?重试一次,下载没有问题的,上传还是提示协议错误。经过笔者分析怀疑问题可能出在FTP Server上,我的FTP Server是用Server-U这个第三方软件做的,会不会是兼容性问题造成的呢?于是换成微软Windows2000自带IIS中的FTP组件建立FTP服务器。再次尝试下载与上传都没有任何问题了,不再提示协议错误。屏幕显示Loading…。几秒钟后又出现提示信息:“Flash空间不足”。

  五,Flash空间不足

  出现FLASH空间不足信息后我特别查询了6509核心设备的硬件配置,默认6509标准配置的Flash为64MB,标配IOS大小为32.1MB,要升级的12.2(17a)SX 版本IOS大小为40.6MB,这样看来空间不足再所难免。但是这个问题还是相对好解决的,将Flash里原来的IOS删除了然后再上传。于是输入命令:

  Router#delete sup-bootflash:s72033-pk9sv-mz.122-14.SX1.bin

  然后再传。提示信息还是空间不足!这个时候交换机的IOS已经被我删除了,要是不小心掉电或者重起的话,交换机就起不来了。在管理界面中用show命令看,IOS文件已经没有了,但是空间还是剩余30多兆,就是说flash没有被清空。这时候想起以前删除vlan.dat文件后要重启交换机才能生效,可是现在重启是万万不行的。怎么办?上思科网站查找有利用价值的信息,终于找到一条命令squeeze,该命令是将已经删除的文件彻底清空,就好比清空回收站一样。运行:

  Router#squeeze sup-bootflash:后再用SHOW命令查看,发现Flash已经被彻底清空,可用空间为64MB。这时候再用FTP上传,几分钟以后就会看见屏幕上提示的成功信息。Reload一下,用show flash命令看IOS版本已经变成了12 .2(17a)SX。插上新模块WS-X6548-GE-TX一试,一切OK,新模块可以正常运行了。

  经验总结:

  本来以为轻松完成的工作却是一波三折,看来高端产品升级也是非常复杂的,很多原来没有重视的环节都会出现这样或那样的问题。本次故障排除使我也明白了一个道理,技术没有尽头,遇到问题到官方网站查询是最好的办法。还有就是做事情之前一定要三思,如果删除FLASH后想当然的执行了RELOAD的话,交换机就无法启动了,那样的后果将会非常严重。操作前请停手思考30秒往往可以减少很多不必要的损失.

                                                                                     ------转载于:http://net.yesky.com/94/2534594.shtml

posted @ 2008-05-30 17:30 chris_lee 阅读(1852) | 评论 (1)编辑 收藏

Google 标签: , ,

今天拿来了一台3750-24TS,查看了一下版本,发现还是使用的ipbase的,所以想升级一下ios。
结果连续几次都出现问题:刚开始传输还比较顺畅,只是有点慢,后来就干脆丢包,然后就是失败。
然后查看了一下flash(Command: dir),发现原来是空间不够了。
所以只好是覆盖当前的ios了。

使用命令:
Switch#archive download-sw /overwrite tftp://a.b.c.d/c3750.****.tar

回车后现象如下:
1,文件上传;
2,examining image;
3,删除old image;
4,然后就是extracting tar里面的文件了;
5,完成。

可以通过dir命令检查一下flash情况,确保image文件没错,就可以重启了。

posted @ 2008-05-30 15:20 chris_lee 阅读(493) | 评论 (1)编辑 收藏

2008年5月29日

   

Google 标签:

日前,莎朗斯通在嘎纳接受采访时的瞎扯屁话,已经遭受整个中国乃至全世界的严厉批评。还是在大学的时候看过其《本能》,从这上面并没有对莎朗斯通留下什么印象,而这次事件发生后,让我以及很多人都认识了这么个母夜叉,这么个无耻的人。鉴于自己的道德,我们不能用很粗鲁的话语进行攻击她,但是就其如此行径,我可以说,任何恶毒的话用于她身上都不过。虽然其在具体的行动上面没有什么很出格的事情,但是她那几句话比那些欺世盗名、甚至是放火抢劫者有过之而无不及。她的两只在哪里?她说话都不经过大脑的?任何有点社会常识和良知的人都应该知道这些话是多么地伤人,伤的是全中国人。其实不仅仅如此,她伤的是道德良知,她伤的是一种无国界的理念,伤的是成为一个合格人的基石。

我们应该封杀她,彻彻底底的封杀她,让她在任何视界,任何情况下消失,包括演艺界、广告界甚至是自己的理念里消失。不要以人的基准来看待它。

而迪奥申明关于此事表示遗憾,也只是为了挽回中国人对迪奥的看法,不要无辜在这么一个产品上面。我觉得迪奥以后应该不会在启用斯通的任何广告效益,也只有这样才能挽回其即将失去的利益。

posted @ 2008-05-29 12:26 chris_lee 阅读(218) | 评论 (2)编辑 收藏

2008年5月26日

最近发现核心交换机有几个下联二层交换机的端口出现了很多丢包,从监控平台上显示如下:

image 
显示为7609的receive discards,登陆上交换机查看端口如下:
image 
从上图中看到有很多数据包overrun(2294627),说明此端口的buffer已经耗尽,其将此buffer里的数据送往PFC的速度慢于此端口的接收数据报的速度,因此这些数据报就会丢弃,如上图Input queue有2289265 drops。overrun的官方解释如下:

Q. What are overruns on a serial interface?

A. Overruns appear in the output of the show interface Serial 0 command when the serial receiver hardware is unable to hand received data to a hardware buffer because the input rate exceeds the receiver's ability to handle the data.

This occurs due to a limitation of the hardware. Overruns occur when the internal First In, First Out (FIFO) buffer of the chip is full, but is still tries to handle incoming traffic. The serial controller chip has limited internal FIFO.

Some chips, for example, have only 256 bytes of buffer space. Data from the network is received into the buffer, whereupon the chip attempts to move the data from the buffer to the router's shared memory for the CPU to process. If the chip is not able to move the data from its internal FIFO buffer into shared memory faster than the rate at which data is received on the interface, then the internal FIFO buffer is full, incoming data is dropped, and the overrun counter is incremented.

------------摘自http://www.cisco.com/en/US/tech/tk801/tk36/technologies_q_and_a_item09186a008014f919.shtml

而同时由上图可以看出此端口没有启用flow-control特性,flow-control的官方解释如下:

image 

因此启用flow-control特性可以避免overrun的现象。但是从根本上来考虑此端口为GE端口速率为1000Mbps,且为full-duplex。而且当时此端口的input速率为22.8Mbps,远没有达到GE的上限。而从硬件架构来看,也远没有达到瓶颈。下为硬件参数显示信息:

image

image 
查看了一下此板卡WS-X6548-GE-TX的结构图,表示每连续8个GE端口共享1G,而且此8GE端口共享16KB的RX BUFFER和1M的TX/RX BUFFER。所以从结构上来看,应该没有达到性能瓶颈的。

补充:

本周通过与cisco case中心交涉,提交几个show命令显示结果给case中心,然后在case中心的协助下:完成以下2种测试:

1,disable head of line blocking which will utilize the interface buffers instead of the
shared buffers.  This will result in only the single over utilized port having drops。查看了一下cisco网站,意思就是说启用head of line blocking使得此8个一组端口的每个端口都启用自己的32kb buffer,而不使用共享的1Mb buffer,这样就能看出到底是哪个端口overrun比较多。详见http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801751d7.shtml
配置命令如下:
6500(config)#service internal       //此命令表示可以启用内部命令,注意内部命令TAB或者?都无效,直接敲入就是了。
6500(config)#interface gigabit 1/1
6500(config-if)#hol-blocking disable
%HOL Blocking is Disabled on: Gi1/1 Gi1/2 Gi1/3 Gi1/4 Gi1/5 Gi1/6 Gi1/7 Gi1/8
这样可以找出来到底是哪一个端口过多overrun,然后将此端口挪到另外一组去。

2,try to config "hold queue 4096 in" to raise the hold queue. please refer to :
http://www.cisco.com/en/US/docs/ios/12_3/interface/command/reference/int_d1g.html#wp1142192
在软件队列处理上通过“hold queue 4096 in”将端口的hold queue调高,看看是否有效果。实际上没有多大效果,依然有很大的丢包。

综合以上测试,case中心给出答复如下:
丢包现象为WS-X6548-GE-TX板卡性能瓶颈所致,即WS-X6548-GE-TX的端口buffer太小,请换成6148A或者6748板卡。下面比较一下此三个板卡的硬件架构:
1),X6548-GE:每8个端口(1-8,9-16,17-24...)共享16KB RX buffer和1MB的RX/TX buffer,并且每8个端口共享1GE带宽,此板卡为fabric-enabled,可以与引擎通过一个8GE的CrossBar或者32GE的系统共享Bus相连;
2),X6148A-GE:每8个端口共享160KB RX buffer,每一个端口独享5.2MB的TX buffer,并且每8个端口共享1GE带宽,但是此板卡为nonfabric-enabled,只能通过32GE的系统共享Bus相连;
3),X6748-GE:每个端口独享166KB的RX buffer和1.164MB的TX buffer,并且此板卡为fabric-enabled,可以与引擎通过每24个端口(1-24,25-48)共享20GE的CrossBar相连或者48GE端口共享32GE的系统共享Bus相连。

posted @ 2008-05-26 15:46 chris_lee 阅读(1532) | 评论 (2)编辑 收藏

2008年5月22日

在文章Catalyst 6000 family Architecture提到过SFM(switch fabric module),这里具体讲述软操作方面的知识。

在一个安装了SFM的交换机上,有如下三种switch modes:
1,compact mode---这种模式用于处理仅仅安装了fabric-enabled modules的交换机(没有安装nonfabric-enabled modules)上fabric-enabled modules之间的数据转发,只需要在switch fabric channel上传输DBus header;

2,truncated mode---这种模式用于处理同时安装了fabric-enabled modules和nonfabric-enabled modules的交换机上的fabric-enabled modules之间的数据转发,只需要在switch fabric channel上传输the first 64 bytes of the frame;
3,bus mode---这种模式用于处理fabric-enabled modules和nonfabric-enabled modules之间以及nonfabric-enabled modules之间的数据转发,在switch fabric channel上传输整个数据帧。

image

配置命令如下:

Router(config)# [no] fabric switching-mode allow {bus-mode | {truncated [{threshold [number]}]}
此命令注意点:
When you enter the ‘no fabric switching-mode allow bus-mode’ command, power is removed from any
nonfabric-enabled modules installed in the switch.
即‘no fabric switching-mode allow bus-mode’ 命令会导致所有nonfabric-enabled modules掉电,所以请慎用!!!

Router(config)# fabric required
此命令注意点:
If you enter the ‘fabric required’ command on a switch that does not have a Switch Fabric Module
installed, all modules except the supervisor engine turn off.
即‘fabric required’命令会导致在没有SFM或者SFM失效的交换机上除了引擎板卡外,其它板卡全部掉电,所以请慎用!!!

监控命令如下:show fabric ? 即可以查看很多信息。

posted @ 2008-05-22 22:07 chris_lee 阅读(1901) | 评论 (0)编辑 收藏

Google 标签: , ,

真郁闷,昨天一台WS-C3560G-48TS无缘无故重启了,使用的c3560-ipbase-mz.122-25.SEE2这个ios,不知道有没有遇到过这样的问题。

还记得去年国庆的时候也是WS-C3560G-48TS无缘无故重启了,找思科开CASE,

给的答复就是升级IOS。

这次我也开了一个case,看看他们怎么答复我。

嗨。。。

真是多事之秋。

2008-5-8,有结果了:

这台交换机无故重启,向CISCO开了一个CASE。由于没有crashinfo等任何错误信息,CISCO通过查看我提供的show-tech文件没有查到任何东西,所以给出如下结论:

这次无故重启有可能是外界环境引起,比如附近温度,湿度,磁场甚至飞机经过等因素。像这样的事情在国内外都发生过。比如说美国出现过每到潮汐时候,某台设备就重启的现象。但是这种无故重启是偶然的,发生频率非常小,而且一般都发生在高端核心设备。

去年10月4日的凌晨2点多,我们也有一台3560crash了。当时开了case,得出的结论是升级ios。此交换机crash 20多天后,升级ios到目前为止没有出现过无故重启的现象。由于在未升级前,此交换机也没有无故重启了,所以不能确定是否为ios的问题。

 

posted @ 2008-05-22 21:58 chris_lee 阅读(492) | 评论 (0)编辑 收藏

本周还真幸运,先避开只上班3天不说,周一以来公司就有一MM给我买了两张电影票《功夫之王》,送给我和我老婆。说是感谢我辛勤工作,这就有点不懂了,本来我做的工作就是本职所在,只是与她们的KPI有关而已,却为了这个请我看电影。哈哈,但是我还是偷偷的通过支付宝付钱给她了。窃喜,可能他还不知道呢!!!

电影票:周二晚7:50 翠苑电影大世界

一个小插曲:

刚进电影院,门口就碰到一个抽奖活动。买2只功夫豆冰棍就能进行抽奖活动。抽奖的道具比较俗套,就是那种时钟类似的,中间的指针“固定不动”,转动圆盘(圆盘上面以不等的圆周标明“一等奖”至“四等奖”。当然“一等奖”只有一个

如此的圆周,而且非常小,这样的几率就小多了)抽奖。看到一哥们在我前面抽奖,转动圆盘,结果发现指针也随着动了起来,只是没有圆盘转动的厉害而已。哈哈,好玩。于是,我将指针先固定到“一等奖”位置(售货员可能没注意看,正忙着呢),小力稍微转动了不到60度,果然指针跟着圆盘一起转动了。可能这个时候正好被售货员看到,他就拿出笔和纸出来说:“我中了一等奖了”,让我进行登记后就可以领取一张《功夫之王》电影票。弄得我很不好意思,于是我直接跟他说我开玩笑的,可以不算的。你猜他怎么说:“没事,你就是中了一等奖了。”嗨,真是无语!那好吧,不拿白不拿。哈哈,真是搞笑。

进场看电影了,整个看下来,从个人感觉,电影太平坦了,没有一点刺激感,完全是“一马平川”类型。猜测老外们肯定喜欢看,因为里面的中国功夫确实不错,打斗的场面着实可以。不过,还是觉得有钱的话,可以去看看,毕竟是成龙和李连杰破天荒的联手主演。哈哈。

整场电影有一个搞笑镜头:

在过沙漠的时候,鲁彦(成龙)求雨,默僧(李连杰)在他上面撒尿。哈哈,搞笑!!!

不过说实在话,电影本身就是搞笑:李连杰饰演孙大圣;“一马平川”的剧情;不到一年的时间,天行者就能跟白发魔女打斗;等等......

下面借用一同事博客的内容:

天行者:"我们是不是不能走出沙漠了?...我都快要冻死了"
默僧(李连杰)慢慢转头(深沉地):"不要忘了呼吸"

哈哈,整晚的遭遇都很搞笑。

posted @ 2008-05-22 21:57 chris_lee 阅读(357) | 评论 (0)编辑 收藏

Google 标签: , , , ,

今天接到应用部门一个需求:

针对他们部门的某个URL: http://www.abc.com/https://www.abc.com/访问,需要直接跳到某一台主机上,而不希望在这个pool成员中轮询。而且正常的访问这个URL,需要跳转到https://www.abc.com/,但是一些程序针对这个域名的

接口调用则不需要跳转,一般的接口调用的URL最后为“.do”。

这个需求比较奇怪,考虑到一般人访问这个域名都是直接访问www.abc.com 其实就是http://www.abc.com/,而程序接口调用则类似为http://www.abc.com/*****.do。这就可以区分开来,在F5的定义中HTTP::uri表示HTTP::host后面的部分。

HTTP::uri

  • Returns the URI of the request. It does not include the protocol (http or https) or hostname, just the path, starting with the slash after the hostname.

------摘自http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__uri.html

所以在LTM上面写下如此irule:

[root@LB-1A-BIG6400:Active] root #b rule http_https_host1 list
rule http_https_host1 {
when HTTP_REQUEST {
if { [HTTP::uri] equals "/" } {
HTTP::redirect https://[HTTP::host][HTTP::uri]

}
elseif { [HTTP::uri] contains "host1" } {
HTTP::redirect https://[HTTP::host][HTTP::uri]
}
}

[root@LB-1A-BIG6400:Active] root # b rule redirect_host1 list
rule redirect_host1 {
when HTTP_REQUEST {
if { [HTTP::uri] ends_with "host1" } {
use node a.b.c.d 80
}
}
}

然后将http_https_host1用在80的virtual server上,而将redirect_host1用在443的virtual server上就ok了。
}

posted @ 2008-05-22 21:54 chris_lee 阅读(2116) | 评论 (2)编辑 收藏

1,首先回顾一下TCP协议:

TCP数据包中有六个标志位(Code Bits):6 位标志域。表示为:紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是:URG、ACK、PSH、RST、SYN、FIN。在整个TCP数据传输过程中ACK位除了在第一次握手的时候置位为0外,其他任何时候都置位为1。
三次握手过程:

在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。

第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;

第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

2,再次拿一个ACL来举例说明(摘自TCP/IP路由技术 第一卷 第556页):

假设你实现了一个访问列表可以阻止外部发起的TCP会话进入到你的网络中,但是你又想让内部发起的TCP会话的响应通过,那应该怎么办?通过检查TCP段头内的ACK和RST标记,关键字established可以实现这一点。如果这两个标记都没有被设置,表明源点正在向目标建立TCP连接,那么匹配不会发生。最终报文将会在访问列表中的后继行中被拒绝。示例如下:

access-list 110 permit tcp any 172.22.0.0 0.0.255.255 established

access-list 110 permit tcp any host 172.22.15.83 eq 25

access-list 110 permit tcp 10.0.0.0 0.255.255.255 172.22.114.0 0.0.255 eq 23

第1行:如果链接是从网络172.22.0.0发起的,那么允许从热和原电到该网络的TCP报文通过;

第2行:允许来自任意源点,且目标端口号是主机172.22.16.83的端口25的TCP报文通过;

第3行:允许来自网络10.0.0.0,去向网络172.22.114.0/24且目标端口为23的TCP报文通过。

通过上面的ACL,大家有没有注意过,一个从any到172.22.15.83的25端口的连接,TCP的三次握手,第一次握手肯定是需要匹配第2行ACL,因为此报文的标志位ACK置位为0,不能匹配第1行ACL。但是此会话的后面的所有数据报文都会匹配第1行了,因为此报文的标志ACK已经置位为1了。这里是否有问题,请相关牛人鉴定!

3,ACL对分片包的处理(摘自一英文技术宝典,经我翻译如下):

当一IP包被分片时,仅在第一个分片中包含所有三层与四层信息,而后续分片则只包含三层信息,四层信息丢失。

ACL的处理机制:

对于permit ACEs:当第一分片被匹配上后,后续分片也会匹配上(不检查四层信息);

对于deny ACEs:所有分片都要检查三、四层信息。实际上,对于deny ACEs,当第一分片被匹配上后被丢弃,而后续分片由于无四层信息则不能匹配该deny ACEs,可能在后面检查时允许通过,则传到目标地后,由于不能进行重组而被丢弃。但这样占用了带宽及目标主机的CPU。

综合以上,根据3,是否可以判定ACL的处理机制有点smart,它可以根据每条ACE条目记录某一个时段的匹配内容,匹配内容主要包括源和目标IP地址,甚至端口号(tcp条目),从而不会将流量报文匹配错。也就是说根据2说的同一会话的后续报文不会去匹配第1行ACL,而根据ACL的记录内容去匹配第2行ACL。

以上纯粹是我个人针对ACL的分析,有任何不对或者有争议之处,还请牛人指正,不胜感激!!!

posted @ 2008-05-22 21:52 chris_lee 阅读(2104) | 评论 (0)编辑 收藏

Google 标签: , ,

关于在vlan的接口上使用ACL配置的方向问题,在几个专业论坛里面看到经常有人提起。在这里我总结一下。还是举例说明吧。

1,拓扑图如:

Host_A(1.1.1.1) <------> (1.1.1.2)E1:SW:E2(2.2.2.2) <------> (2.2.2.1)Host_B

需求(由于是说明ACL放置接口的方向问题,所以需求简单一点):

只允许Host_A访问Host_B,其他访问Host_B的拒绝。

所以在SW上面可以配置如下:

ip access-list extended to_host_b

permit ip host 1.1.1.1 host 2.2.2.1

int e2

ip access-group to_host_b out

这里可以明显的看出方向使用out方向,我知道ACL用在硬接口上面大家都很容易理解,一般都不会弄错。下面说明怎么理解ACL配置在vlan接口上。

2,拓扑图如:

Host_A(1.1.1.1) <------> (1.1.1.2)vlan1:SW:vlan2(2.2.2.2) <------> (2.2.2.1)Host_B

需求(由于是说明ACL放置接口的方向问题,所以需求简单一点):

只允许Host_A访问Host_B,其他访问Host_B的拒绝。

所以在SW上面可以配置如下:

ip access-list extended to_host_b

permit ip host 1.1.1.1 host 2.2.2.1

int vlan2

ip access-group to_host_b out

依然是out方向,其实很简单,大家只要将vlan的虚接口看作是硬接口就行了,不要想得太复杂。但是如果要放在vlan1的IN方向,ACL该怎么写呢?可以如下:

需求(由于是说明ACL放置接口的方向问题,所以需求简单一点):

只允许Host_A访问Host_B,其他访问Host_B的拒绝。

所以在SW上面可以配置如下:

ip access-list extended to_host_b

permit ip host 1.1.1.1 host 2.2.2.1

deny ip any host 2.2.2.1

per ip any any

int e1

ip access-group to_host_b in

其实很简单,有一个规律可以增加些理解:

针对某个vlan接口应用acl的方向问题,大家可以看看acl的源和目标地址段。当源地址段为应用vlan接口的ip段时,就是用in方向;当目的地址段为应用vlan接口的ip段时,就是用out方向。反正有一点需要注意,应用在vlan的ACL为out方向时,其目的地址肯定是此vlan的ip网段内地址或者在acl中用any来匹配,但是用其他具体网段来匹配的话是匹配不上的;应用在vlan的ACL为in方向时,其源地址肯定是此vlan的ip网段内地址或者在acl中用any来匹配,但是用其他具体网段来匹配的话同样是匹配不上的。

posted @ 2008-05-22 21:51 chris_lee 阅读(6498) | 评论 (1)编辑 收藏

大概一个月前我下线了我们网络中的一台CAT2960交换机,然后今天将其上线,结果发现snmp取值有问题。对照了一些其他同类型同服务功能的交换机,发现配置没有变化。一个月前还是可以的,这就奇怪了。

当时的配置如下:

ASW-B7-C2960#sh run | inc snmp

snmp-server group ipneter v3 noauth access 99
snmp-server community passwd RO 99
ASW-B7-C2960#

这些配置跟其他交换机的一样。

而后,查看了一下这个命令:

ASW-B7-C2960#sh snmp user 后没有任何输出结果。

通过snmpwalk的linux取值命令如下:

snmpwalk -v 3 -u haha -a MD5 -A wulitou -l authNoPriv a.b.c.d

通过查看同类型同服务功能交换机配置都没有看到haha这个user。

通过在交换机上面添加如下命令:

snmp-server user haha ipneter v3 auth md5 wulitou access 99

问题得到解决。

然后执行如下命令查看配置:

ASW-B7-C2960#sh run | inc snmp
snmp-server group ipneter v3 noauth access 99
snmp-server community passwd RO 99

依然没有看到命令snmp-server user haha ipneter v3 auth md5 wulitou access 99。看来这条命令是一个隐含命令了,通过show是查看不到的。不知道cisco为什么要这么做。

posted @ 2008-05-22 21:50 chris_lee 阅读(1951) | 评论 (1)编辑 收藏

Google 标签: , ,

前几天,在公司的出口路由器上面实施了ACL控制,效果是达到了,但是查看了一下ACL的匹配数,发现好像不准确。大家做ACL有没有注意过匹配数,请看下面的ACL如下:

Extended IP access list ext_in_prted
    10 permit ospf any any (68585 matches)
  

20 permit icmp any any (139 matches)
    30 permit tcp any any established (6614 matches)
    40 permit udp any eq domain any
    50 permit tcp any 1.1.1.0 0.0.0.255 eq www (20 matches)
    60 deny tcp any 1.1.1.192 0.0.0.63 eq 443
    70 permit tcp any 1.1.1.0 0.0.0.255 eq 443 (26 matches)

根据本公司的实际流量情况可以很明显的看出第50条和第70条匹配数绝对不止这么一些。所以这几天很是研究ACL了一把。觉得一定要清楚cisco的ACL的处理机制原理才能弄明白。

今天又查看了一些文档,终于知道上面的ACL:ext_in_prted那些匹配数是设备软件处理的匹配数,硬件匹配数是用show ip access-lists命令显示不出来的。摘自原文如下:

When you enter the show ip access-list command, the match count displayed does not include
packets processed in hardware.

但是查看了好久,也没有找到在CISCO7609上面使用什么命令查看ACL的硬件匹配数。看来还有待进一步研究看看。

有任何不对或者有争议之处,还请牛人指正,不胜感激!!!

追加于2008-5-8:

今天阅读CAT6500 switch architecture文章时,发现了查看ACL硬件匹配数的命令:

show tcam int te7/1 acl in ip

但是发现两个问题:

1,不知道为什么在一台交换机上面竟然没有看到你个匹配数,而另一台交换机上面却有很多匹配数;

2,而且这条命令看出来的ACL与"show ip access-lists"看出来的ACL竟然有不同。

看来还有待进一步研究啦,不断学习中......

posted @ 2008-05-22 21:49 chris_lee 阅读(1660) | 评论 (0)编辑 收藏

Google 标签: , , , ,

今天突然想到了Bigip系统内部SNAT的效果,做了一个小小的测试,总结如下:
1,SNAT Pool(假定地址为a)只能作为一个对象,即其要发生作用,必须绑定在一个VS或者SNAT中;
2,在Virtual Server(假定地址为b)中,绑用一个SNAT Pool后,针对这个VS的所有访问的源地址都会转换成SNAT Pool中

的地址(假定地址为a);
3,而在SNAT中绑用一个SNAT Pool(假定地址为a)后,这里面就会指定原始源地址(假定地址为c,d,e或者一个网段),源地址(c,d,e等)通过bigip系统路由到外面的访问,就会将此源地址改成a了。请注意这个没有涉及到VS,纯粹是路由出去的SNAT而已,将相当于路由器上或者防火墙上面的SNAT。

SNAT在BigIP上面叫做安全NAT,其实就是源地址NAT而已。

posted @ 2008-05-22 21:41 chris_lee 阅读(2936) | 评论 (2)编辑 收藏

前几天我公司与一家银行建立IPsecVPN,双方使用的都是Nokia的CP。在所有配置相同的情况下,通过如下测试确认双方的隧道已经建立起来:

我方先主动测试对方业务,通讯OK;然后由对方测试我方业务,也OK。

可是第二天过来对方反映隧道建立不起来了。

然后我从我方进行业务测试,发现隧道可以建立,我让对方再测试一下,此时对方也OK了。这就说明当隧道清除后,只有我方主动建立隧道,双方的通讯才OK。否则如果由对方先主动建立隧道,则隧道建立不起来。

研究了很久,发现对方有一处配置有问题:

对方在Network Objects/Check Point里的本地对象中主IP是内网ip,而不是公网ip(假如为A)。但是在此对象中的VPN/Link Selection却选择了Main address。这就表明此对象的VPN的link是Main address(也即那个内网ip:A),而没有与我方进行通信的那个公网ip。这样当然不能主动建立隧道。

需要如此修改:点选此对象的VPN/Link Selection中的Selected address from topology,然后选择那个公网ip即可。

Nokia&CP建立IPsecVPN有很多奇妙的地方,所以需要一点一滴的积累。

posted @ 2008-05-22 21:40 chris_lee 阅读(833) | 评论 (2)编辑 收藏

 

 

在一个由2台cisco7609的核心交换机和多台二层交换机组成的三角形网络中出现了流量异常转发问题,下面具体描述该问题。image 
网络环境描述:
网络拓扑图如右,2台核心交换机上面配置了vlan198、vlan200以及vlan254,每个vlan的HSRP的active和STP的root都分别强制配置在一起。例如vlan198和vlan254的hsrp-active和stp-root在CSW-A上,而vlan200的hsrp-active和stp-root在CSW-B上。

问题描述:
172.17.200.30到172.17.254.30的数据包不知道为什么在ASW-2的上联端口能够抓到。查看了CSW上面的HSRP和STP以及ARP表和MAC地址表都没有问题,都显示不应该转发到ASW-2上面。如果说是ARP表和MAC地址表的aging-time不通,导致有可能当mac地址没有条目后广播产生流量,但是这样的话也不可能有这么大这么久的流量持续啊。

今天终于针对这个问题找到原因了,原来是由于v2和v5的hsrp-active不在一起导致的,也就是存在非对称路由。默认情况下,arp的存活时间为4小时,mac存活时间为5分钟。这就会造成当某服务器A的arp表没有超时,但是mac表超时后,交换机就会洪泛到A的数据流。需要注意的是数据流经过一跳时就会将数据包的mac地址段包括源和目的mac地址都需要重写。下面依据上面拓扑图来分析一下:

1),Ser1(1.1.2.30)往Ser2(1.1.5.30)发数据包,Ser1将数据包发往默认网关,也即CW-A的V2网关:

目的mac地址 源mac地址 源ip地址 目的ip地址
M_V2_GW M_Ser1 1.1.2.30 1.1.5.30

2),CW-A接收到数据包进行解包过程,查找路由表(CEF),查找arp表,能找到1.1.5.30的arp表项,依据arp表进行mac地址的重写,然后查找1.1.5.30的mac表项,发现没有此表项即找不到从哪个端口发包(这里假设mac表已经老化),于是进行洪泛到所有v5的端口进行二层转发,数据包为:

目的mac地址 源mac地址 源ip地址 目的ip地址
M_Ser2 M_V2_GW 1.1.2.30 1.1.5.30

3),CW-B接收到洪泛包,解包后发现目的mac地址为M_Ser2(事实上CW-B永远从数据包的mac地址段看不到M_Ser1的mac地址,因为M_Ser1相关的数据包到了CW-A上面会进行mac地址的重写,将源mac改写成M_V2_GW。除非对Ser1进行arp请求,这是CW-B能从arp的数据报文中读取Ser1的mac地址,更新mac地址表),根据对应的端口直接转发数据包。

目的mac地址 源mac地址 源ip地址 目的ip地址
M_Ser2 M_V5_GW 1.1.2.30 1.1.5.30

4),Ser2接收到数据包进行回应,这里不敷衍了。

这里需要重点注意的是:
数据包到了相应的网关后,网关会根据arp表进行mac地址字段的rewrite。所以网关从mac字段是看不到非本网关网段内主机的mac地址的,只能从arp的影响报文的数据段内找到mac地址。然而arp表的老化时间默认为4小时,mac表的老化时间为5分钟,在不同vlan的hsrp-active布置在不同交换机的情况下,最长就有3小时55分钟相应的mac地址表为空,也就是说在这段时间内相关数据流就会洪泛。

解决方法:

1),将所有vlan的网关布置在同一台交换机上面,这样就没有了负载优势,所有vlan的数据流都由同一台设备进行处理;

2),将arp表和mac表的老化时间调至一致,或者mac地址大于arp老化时间。mac表不老化,从理论上来讲应该就只是占用了tcam条目,应该不会有其他问题,做的时候最好针对各个vlan同时进行arp和mac的clear;

3),静态绑定mac地址或者启用port-security mac sticky特性,甚至与disable-unicast特性结合一起使用,但是未知的意外现象不好估量;

4),服务器上配置脚本每隔4分钟ping一下网关。

posted @ 2008-05-22 21:33 chris_lee 阅读(961) | 评论 (3)编辑 收藏

 

在一个典型的冗余互备的交换网络内部,由于vlan的三层和二层关系,可能会导致数据流比较难以分析。我最近在考虑这个问题,想具体从数据包结构来分析一下交换机对数据流的处理过程。

网络环境描述(如图):

1,两台CW上面都存在vlan2和vlan5;image
2,两台CW之间通过Gi9/1的trunk端口跑HSRP协议,交换环路有STP阻隔;
3,vlan2的HSRP的active和STP的root强制在SW-A上;
4,vlan5的HSRP的active和STP的root强制在SW-B上;
5,1.1.2.30处于vlan2;
6,1.1.5.30处于vlan5。

依据1.1.2.30与1.1.5.30之间的数据交互来进行交换机处理机制分析:
1,服务器Ser1(1.1.2.30)发数据包给Ser2(1.1.5.30),此时数据包为:

目标MAC 源MAC 源IP 目标IP
M_V2_GW M_Ser1 2.30 5.30

2,CW-A接收到数据包,发现目标MAC为自己,于是一层层解包到IP层到目标IP为5.30,于是查找5.30的路由表(CEF表)发现5.30直连在vlan5,于是通过ARP表查找vlan5的网关MAC,然后查找MAC表得知vlan5的网关MAC是通过Gi9/1到CW-B。于是保持IP层数据不变,封装MAC层如下:

目标MAC 源MAC 源IP 目标IP
M_V5_GW M_V2_GW 2.30 5.30

3,CW-B接收到数据包,类似于CW-A的处理过程,封装数据报如下:

目标MAC 源MAC 源IP 目标IP
M_Ser2 M_V5_GW 2.30 5.30

4,Ser2接收到数据包后,一层层解包直到将数据传给相关的应用处理后,回应数据报如下:

目标MAC 源MAC 源IP 目标IP
M_V5_GW M_Ser2 5.30 2.30

5,CW-B接收到数据包后类似于上面的过程处理数据,这里就不敷衍了。

posted @ 2008-05-22 21:27 chris_lee 阅读(894) | 评论 (2)编辑 收藏

2008年5月12日

Google 标签: , , , ,

CAT6000家族中包含了CAT6000和CAT6500系列交换机。CAT6500系列能扩展支持到256Gbps背板和200million pps包处理能力。

Switching Fabric

65系列背板从Switch Bus发展到今天的CrossBar,已经完全解决了背板交换的瓶颈问题。CAT6000系列使用一条32Gbps的switch bus,而Cat6500系列则提供32Gbps Switch Bus和256Gbps的Switch Fabric Module(SFM)。SFM只能插在Slot5(主)和Slot6(备)用来提供高速率路径。需要注意的是CAT6000系列不支持SFM。

Switch Bus是一条总线,所以所有连接在此上面的线卡都能“听到”经过这条总线的数据包,然后根据R-Bus提供的信息来决定是否对这一数据包进行转发或者丢弃。

而SFM则是一个crossbar(交叉矩阵)结构,有多条的channal水平和垂直交错而成,每条channel提供8Gbps交换能力(supervisor720提供每channel 20Gpbs)。Crossbar交换网的扩展能力非常强,交换容量可以做的很大,基本不受硬件条件限制,目前单颗芯片交换容量在256G-700G之间,多颗芯片可以构建T级乃至几T容量的大型交换网络,足以满足当前和未来几年网络对交换容量的需求,并且随着硬件集成技术的进步,单颗Crossbar芯片支持的容量会更大。

CAT6500和SFM提供256Gbps交换能力和100million的包转发能力。720以下引擎每channel提供8Gbps带宽(即RX 8Gbps和TX 8Gbps)。Fabric-enabled模块连接CrossBar中一个channel,支持8Gbps带宽,同时也连接在32Gbps的switch bus上;Fabric-only模块连接CrossBar中2个channel,提供16Gbps带宽。连接线卡本地交换bus和SFM或main 32-Gbps switching bus的关键点叫做medusa,其实是一块ASIC芯片,用来处理双方的数据传输。如下图:

clip_image002

交叉矩阵交换,和它的名字一样,结构像是一个横竖交叉的矩阵,只不过横线(输入端)和竖线(输出端)并不直接相连,而是透过一个场效电晶体 (FET)将每一个横线与竖线连接。如此,只要控制场效电晶体的开关,便可以决定那个输入和那个输出(或那些输出)可以进行交换。矩阵交换的最大优点是允许多个相互不冲突的交换同时进行,并支持点对多点(Multicast)的交换。

Line card

由于有Switch Bus和CrossBar之分,所以配置的线卡也有Fabric-enabled和Non Fabric-enabled。Fabric-enabled说明此线卡能连接到SFM(Switch Fabric Module)上,提供CrossBar的高容量。下表列出了不同线卡与相应交换机的兼容:

clip_image004

Switch Bus Architecture

clip_image006

CAT6000系列交换机由32Gbps串联,所有连接在此Bus上面的端口都能接收到在此Bus上数据帧。Switch Bus包含D-bus(Data bus)、C-bus(Control bus)和R-bus(results bus)。D-bus负责端口之间的数据传输,带宽为32Gbps;C-bus负责端口ASIC和NMP(Network Management Processor)之间信息传递;R-bus负责将引擎上的逻辑信息(比如mac地址,acl匹配和CEF信息等)传递到交换机各个端口。

CrossBar Switching Fabric

CAT6500和SFM提供256Gbps交换能力和100million的包转发能力。720以下引擎每channel提供8Gbps带宽(即RX 8Gbps和TX 8Gbps)。Fabric-enabled模块连接CrossBar中一个channel,支持8Gbps带宽,同时也连接在32Gbps的switch bus上;Fabric-only模块连接CrossBar中2个channel,提供16Gbps带宽。连接线卡本地交换bus和SFM或main 32-Gbps switching bus的关键点叫做medusa,其实是一块ASIC芯片,用来处理双方的数据传输。

Switching Implemtation

Switching Implemtation只要控制平面和数据转发平面两个关键处理功能。控制平面主要维护路由、flow初始化和ACL等。MSFC就是一个控制平面卡,而线卡(包括DFC)主要负责数据转发功能。

Multi