z**r
发帖数: 17771 | 1 以前都是泛泛看了些，最近遇到一个诡异问题，仔细研究了一下RFC4861，讲究真多，
呵呵 |
v***v
发帖数: 5504 | 2 把你的诡异问题说来听听。。。。
【在 z**r 的大作中提到】
: 以前都是泛泛看了些，最近遇到一个诡异问题，仔细研究了一下RFC4861，讲究真多，
: 呵呵
|
z**r
发帖数: 17771 | 3 不如先考考大家吧。
俺把问题简化一下，两个router back to back连接，同时都连接到一个traffic
generator，比如spirent testcenter，两个router用ipv6 static routes来resolve连
接到spirent testcenter的link subnet。spirent send traffic，但是发现每隔30秒
就会有一些packet drop，如果改变nd的timer，packet drop就跟着这个timer走，改成
50秒，就每50秒drop。
怎么回事儿？如何解决？
STC---2001::/64---R1---2000::/64---R2---2002::/64---STC
on R1:
ipv6 route 2002::/64 2000::2
on R2:
ipv6 route 2001::/64 2000::1
【在 v***v 的大作中提到】
: 把你的诡异问题说来听听。。。。
|
v***v
发帖数: 5504 | 4 听起来是挺怪的，应该是IOS stack本身的问题吧，timer的一些jitter值加加减减没做
好留下空档？按理说next hop cache，L2 address cache这些东东都应该及时被更新了啊
【在 z**r 的大作中提到】
: 不如先考考大家吧。
: 俺把问题简化一下，两个router back to back连接，同时都连接到一个traffic
: generator，比如spirent testcenter，两个router用ipv6 static routes来resolve连
: 接到spirent testcenter的link subnet。spirent send traffic，但是发现每隔30秒
: 就会有一些packet drop，如果改变nd的timer，packet drop就跟着这个timer走，改成
: 50秒，就每50秒drop。
: 怎么回事儿？如何解决？
: STC---2001::/64---R1---2000::/64---R2---2002::/64---STC
: on R1:
: ipv6 route 2002::/64 2000::2
|
f*****m
发帖数: 416 | 5 相对于neighbor solicitation message interval, neighbor reachable time 设的不
够大?
1. 把neighbor reachable time 设大一点,譬如3倍neighbor solicitation message
interval
2. 或者 static ipv6 neighbor
【在 z**r 的大作中提到】
: 不如先考考大家吧。
: 俺把问题简化一下，两个router back to back连接，同时都连接到一个traffic
: generator，比如spirent testcenter，两个router用ipv6 static routes来resolve连
: 接到spirent testcenter的link subnet。spirent send traffic，但是发现每隔30秒
: 就会有一些packet drop，如果改变nd的timer，packet drop就跟着这个timer走，改成
: 50秒，就每50秒drop。
: 怎么回事儿？如何解决？
: STC---2001::/64---R1---2000::/64---R2---2002::/64---STC
: on R1:
: ipv6 route 2002::/64 2000::2
|
z**r
发帖数: 17771 | 6 没觉得那两条static routes有什么问题？比如next hop应不应该是global unique
address?
了啊
【在 v***v 的大作中提到】
: 听起来是挺怪的，应该是IOS stack本身的问题吧，timer的一些jitter值加加减减没做
: 好留下空档？按理说next hop cache，L2 address cache这些东东都应该及时被更新了啊
|
z**r
发帖数: 17771 | 7 neighbor reachable time设成多大，就在那个interval 有packet drop。这个怪俺第
一个帖子没说清楚，只笼统的说了一句nd timer，应该是nd ReachableTime。
俺是通过两个办法fix这个的，第一种去掉static，跑OSPFv3 or ISIS，第二种是把
static routes的next hop改成对方router的link local address。不过说到底，这两
种其实还是一个fix，dynamic routing protocol(IGP)也是用link local作为next hop
的。
那问题是为什么用link local就可以fix呢？
【在 f*****m 的大作中提到】
: 相对于neighbor solicitation message interval, neighbor reachable time 设的不
: 够大?
: 1. 把neighbor reachable time 设大一点,譬如3倍neighbor solicitation message
: interval
: 2. 或者 static ipv6 neighbor
|
v***v
发帖数: 5504 | 8 俺觉得你这些还是workaround, stack还是有虫虫，把某个cache清早了。按理说你配
global和linklocal都可以的啊，没听说过static route只能配linklocal,当然你这个
情况ll更优化一点。next hop的global得查表1得到linklocal，linklocal查表2得到L2
。瞎估计一下，更新的时候，表1先被清了没及时更新（可能中间把锁放了）。
hop
【在 z**r 的大作中提到】
: neighbor reachable time设成多大，就在那个interval 有packet drop。这个怪俺第
: 一个帖子没说清楚，只笼统的说了一句nd timer，应该是nd ReachableTime。
: 俺是通过两个办法fix这个的，第一种去掉static，跑OSPFv3 or ISIS，第二种是把
: static routes的next hop改成对方router的link local address。不过说到底，这两
: 种其实还是一个fix，dynamic routing protocol(IGP)也是用link local作为next hop
: 的。
: 那问题是为什么用link local就可以fix呢？
|
z**r
发帖数: 17771 | 9 RFC actually mentions the next-hop should be link-local.
L2
【在 v***v 的大作中提到】
: 俺觉得你这些还是workaround, stack还是有虫虫，把某个cache清早了。按理说你配
: global和linklocal都可以的啊，没听说过static route只能配linklocal,当然你这个
: 情况ll更优化一点。next hop的global得查表1得到linklocal，linklocal查表2得到L2
: 。瞎估计一下，更新的时候，表1先被清了没及时更新（可能中间把锁放了）。
:
: hop
|
v***v
发帖数: 5504 | 10 嗯，这个有道理，next-hop一定要link local domain才可能一个hop就过去啦。但这个
内部结构的next-hop和static route用户界面的next-hop不能等同概念。用户界面印象
中大都支持global unicast ip或者link local做next-hop（虽然global的可能不推荐
，但既然支持就应该支持好撒），就像你原先那样配置也没出错信息啊，大多时候不也
运行良好吗。不请用户吃饭人家就咬定是你IOS的问题你也没办法，大概JNPR就没有这
个问题:-)
【在 z**r 的大作中提到】
: RFC actually mentions the next-hop should be link-local.
:
: L2
|
v***v
发帖数: 5504 | 11 有些情况恐怕admin还就只能输global address。毕竟link local有可能变啊，强迫用
户端输link local要搞死人的。。。 |
z**r
发帖数: 17771 | 12 不用link-local做next-hop也不是不行，但是redirect message会有一点问题，需要重
新resolve link-local的link layer address，就是在这个过程中，丢包发生了。
【在 v***v 的大作中提到】
: 嗯，这个有道理，next-hop一定要link local domain才可能一个hop就过去啦。但这个
: 内部结构的next-hop和static route用户界面的next-hop不能等同概念。用户界面印象
: 中大都支持global unicast ip或者link local做next-hop（虽然global的可能不推荐
: ，但既然支持就应该支持好撒），就像你原先那样配置也没出错信息啊，大多时候不也
: 运行良好吗。不请用户吃饭人家就咬定是你IOS的问题你也没办法，大概JNPR就没有这
: 个问题:-)
|
z**r
发帖数: 17771 | 13 那就hard code link local啊，比如ipv6 address fe80::beef link-local
【在 v***v 的大作中提到】
: 有些情况恐怕admin还就只能输global address。毕竟link local有可能变啊，强迫用
: 户端输link local要搞死人的。。。
|
z**r
发帖数: 17771 | 14 另外，static route中的next-hop本来就是可以recursive的，所以本质上只要能通过
其他途径reach next hop，就可以。但是这个ipv6 static route还是有点不同感觉
【在 v***v 的大作中提到】
: 嗯，这个有道理，next-hop一定要link local domain才可能一个hop就过去啦。但这个
: 内部结构的next-hop和static route用户界面的next-hop不能等同概念。用户界面印象
: 中大都支持global unicast ip或者link local做next-hop（虽然global的可能不推荐
: ，但既然支持就应该支持好撒），就像你原先那样配置也没出错信息啊，大多时候不也
: 运行良好吗。不请用户吃饭人家就咬定是你IOS的问题你也没办法，大概JNPR就没有这
: 个问题:-)
|
