Refer to 3560 output drop increase issue.
All voice in one vlan 36.
And have some data vlan.

Follow are topology(summary):
——————————-

 +-----------+            +-----------+
 |   6509    |            |   6509    |
 +-----\-----+            +-----/-----+
        \                     //
         \                   /
 完整阅读

由于最近处理一个静态BFD的问题。
在此贴出BFD的配置及相关的资源链接供大家参考。
关于相关BFD协议的内容和他的模式问题，本想用dynamips加12.2(33)SRC来做测试并抓包分析，但发现一配置BFD，模拟器就crash，先后更换了SRD，SRE及更换了NPE-G1和 NPE-G2，现象一样存在。毕竟只是模拟器呀。。。。。。

所以关于相关BFD的更进一步分析，只能等到手头有设备时直接SPAN了。

注：VRF下的静态BFD，只从12.2(33)SRC才开始支持，支持平台为7600和7200。
6500需要在12.2(33)SXI才支持。 完整阅读

Topology:

PC(modem)———-ISDN———(E1 Pri)2811(PVDM2)

Configuration:

network-clock-participate wic 0
network-clock-select 1 E1 0/0/0
!
isdn switch-type primary-net5
!
chat-script offhook1 "" "ATH1" OK \c
chat-script callback1 ABORT ERROR ABORT BUSY "" "ATZ" OK "ATDT \T" TIMEOUT 30 CONNECT \c
！
interface Serial0/0/0:15
 ip unnumbered Loopback0
 encapsulation ppp
 dialer rotary-group 1
 完整阅读

ISDN Dialer fail for PVDM2

From Show diag:
—————————————————————————–
CISCO2821
HWIC-1CE1T1-PRI
PVDM2-36DM

From Show Run
—————————————————————————–

network-clock-participate wic 1
!
modem country v12 sweden
dot11 syslog
ip source-route
!
controller E1 0/1/0
 完整阅读

As everyone knows, the NTP is sync clock protocol.
That knowledge less other protocol.
But there are some attention:
——————————————
1. When you config more than one server in customer network.
Please don’t use the same stratum.
Base on the stratum, refer to
http://www.cisco.com/en/US/docs/ios/netmgmt/command/reference/nm_10.html#wp1093957
If customer use same stratum, it would instability and lost sync.

2013-1-22 更新
There are two reason will lead NTP flapping(lost sync):
1. If you have 2 ntp servers this sort of behavour can happen if the ntp parameters from those servers are similar. This is likely if your peering to two N7Ks. Note also that “prefer” is not a priority selection on XR.
2. NTP version mismatch between V3 and V4

Refer to “Prefer” option, may solve this problem, in most of the case but this is not a 100% solution. If the time from the “preferred” source reaches the client earlier than other configured peers, it is taken to be authoritive and independent of the current time and offset. And we sync to it, but before the NTP client is synchronized to this preferred peer (which should take a few seconds in general or a maximum of 5 minutes), if time updates from other configured peers reach the NTP client, the clock selection algorithms are applied to all of these and we have all the time sources pass through the selection algorithms and NTP tunes the client’s time to some peer, considering the other factors of offset, sync distance and dispersion.

We do have more than 2 servers at the same stratum level, in the CASE, We should try using prefer option to see if we have no issues with time stabilities. But if we have the two servers almost at the same distance, even “prefer” option would not help much.

So it is advisable to to have one server per stratum level.

完整阅读