我觉得不是这样的 -ccie18614(加拿大枫叶) @卡尔加里华人论坛:卡尔加里枫下论坛 The Rolia Forum of Calgary

我觉得不是这样的

ccie18614(加拿大枫叶)

本文发表在 rolia.net 枫下论坛我觉得这是两个不同的next-hop概念，对于BGP来说，next-hop是一个attribute,不一定就是实际数据转发的next-hop,而在IGP中，next-hop应该是一个下一个可以物理直达的端口（一般情况）。

你说得对，如果R1是通过eBGP peer R0得到的一条路由，这条路由中本身就有next-hop这一attribute,那就是R0.而R1在转发给iBGP peer的过程中中，缺省情况是不修改next-hop这一attribute的，也就是R2得到的路由next-hop这一attribute依然是R0。这是一个在同一AS中next-hop继承的问题，既然是继承，前提条件是必须已经有了。

对于你的case,R1 本身不是从任何BGP(包括eBGP and iBGP)peer 中得到的a.b.c.d的路由，所以本身也就谈不到next-hop这一BGP attribute(虽然路由表中它有next-hop,但是这里的next-hop不是BGP概念的next-hop attribute)，这完全是一个IGB的路由。R1将这一条路由advertise到其它BGP(iBGP and eBGP)peer的时候，它会把自己设置成next-hop这一 BGP attribute，而不是把路由表里的next-hop设置成BGP next-hop这一attribute. 简单来说，R1只是告诉BGP peer，发往a.b.c.d的数据包发给我(这是它advertise的意图），至于数据包到了R1这么处置，他会查看路由表来决定它自己的next-hop。

你可以考虑下一个常用的例子：

R1自身有很多详细的a.b.0.0/16的路由，比如a.b.c.0/24,a.b.d.0/24,a.b.e.0/24.......在做汇聚的时候，往往自己静态产生一条a.b.0.0/16指向null0的静态路由然后advertise出去（是否需要静态产生这条汇聚路由要看具体情况），他的意思是告诉peer,所有的发往a.b.0.0/16的数据都发到我这里来。至于来了之后，R1会做最长匹配找到最精确的路由，比如说a.b.c.0/24,而不是a.b.0.0/16。只是一个常用的策略。如果按照你说的，那些得到a.b.0.0/16的peer岂不直接就把数据报discard掉了。

我对BGP的实际经验不是很多,不是100%保证我说的对，这只是我的理论理解，最好你还是做实验确认一下，并且通报一下实验结果。更多精彩文章及讨论，请光临枫下论坛 rolia.net

(#5301420@0)
Last Updated: 2009-5-30
This post has been archived. It cannot be replied.

hmm, you should ask first does router 2 have a calculated alternate route to a.b.c.d then go back to your question. -buma(。。。。); 2009-5-29 (#5300127@0)

lets suppose it does NOT have an alternative route to a.b.c.d. I am just trying to get an exact idea how the discard next hop behaves, on platform such as Juniper. -whatthehell(cyberman); 2009-5-29 (#5300177@0)

router 1 -buma(。。。。); 2009-5-29 (#5300219@0)

哎，自称是L2/L3的网络砖家看不懂题啊。谁能告诉我每句都有什么逻辑联系？ -eagle_no1(瞎起哄); 2009-5-29 (#5300209@0)

当然是在R1上，由于这条路有被advertise到R2,在R2上看到的a.b.c.d的next-hop是R1. -ccie18614(加拿大枫叶); 2009-5-29 (#5300381@0)

o, 终于看懂advertise是什么意思了; -eagle_no1(瞎起哄); 2009-5-29 {38} (#5300436@0)
btym how to adverise in your guys mind
假设router2的IP地址在router1上reachable，如果我在router1 上traceroute router2-IP source a.b.c.d, 应该还是通的吧？即使源地址是a.b.c.d -whatthehell(cyberman); 2009-5-29 (#5300494@0)

请看解释 -ccie18614(加拿大枫叶); 2009-5-29 {323} (#5300524@0)
如果a.b.c.d是R1上的一个端口（物理的或者逻辑的），这条路由会直接注入到路由表里，distance=0,你自己配的那条discard的路由distance是1，由于distance大，不会注入到路由表的，尽管你配置了discard的路由，它不会有任何作用。
如果a.b.c.d不是R1上的一个端口，你怎么可能在R1上以它为源地址ping R2呢？

我说的是Cisco, 对Juniper，基本不懂。

多谢你的分析，很有道理。我是在Juniper上，但看起来其实是一样的。 -whatthehell(cyberman); 2009-5-29 (#5300572@0)

the icmp packet will reach router 2, and router 2 will reply to router 1, but the reply packet will be dropped on data path of router 1. so you can not see the reply information after you issue traceroute command. -eagle_no1(瞎起哄); 2009-5-29 (#5300543@0)

I am tracerouting from a direct port address, so I am able to get the echo reply from router2. but if I ping or traceroute router1 from router2, I think I will not be able to get any response. -whatthehell(cyberman); 2009-5-29 (#5300594@0)

i am not sure, seems ccie's explanation sensible. from development point of view, the discarding happens in egress side, in that case , you still can get reply if you ping from router 2; -eagle_no1(瞎起哄); 2009-5-29 {40} (#5300639@0)
get it a try and let us know the result.

sure thing -whatthehell(cyberman); 2009-5-29 (#5300684@0)

我想你假设的是IGP,例如OSPF,RIP吧。但如果我是用BGP advertise 路由a.b.c.d, 并且没有设nexthop self, 那么数据包在router2上就消失了吧？ -whatthehell(cyberman); 2009-5-29 (#5300621@0)

我的理解 -ccie18614(加拿大枫叶); 2009-5-29 {195} (#5300844@0)
如果是eBGP，next-hop自然是R1.
如果是iBGP，由于在R1,你这条路由是由于直连端口或者静态路由产生的，next-hop自然也是R1.
所以在这里，不存在next-hop的问题。

不知道你的实际情况到底是怎样，仅供参考。

如果是静态路由(set static a.b.c.d discard) 通过IBGP advertise, IBGP通常是不修改next-hop 值的，那这个静态路由是不是到了Router2还是以discard作为next-hop呢(CISCO里的Null0 是一样的吧） -whatthehell(cyberman); 2009-5-29 {92} (#5301044@0)
在着手准备用Juniper setup一个网络（multihome BGP + OSPF)，想把一些概念搞搞清，动手时心中有谱

我觉得不是这样的 -ccie18614(加拿大枫叶); 2009-5-30 {1604} (#5301420@0)
本文发表在 rolia.net 枫下论坛我觉得这是两个不同的next-hop概念，对于BGP来说，next-hop是一个attribute,不一定就是实际数据转发的next-hop,而在IGP中，next-hop应该是一个下一个可以物理直达的端口（一般情况）。

你说得对，如果R1是通过eBGP peer R0得到的一条路由，这条路由中本身就有next-hop这一attribute,那就是R0.而R1在转发给iBGP peer的过程中中，缺省情况是不修改next-hop这一attribute的，也就是R2得到的路由next-hop这一attribute依然是R0。这是一个在同一AS中next-hop继承的问题，既然是继承，前提条件是必须已经有了。

对于你的case,R1 本身不是从任何BGP(包括eBGP and iBGP)peer 中得到的a.b.c.d的路由，所以本身也就谈不到next-hop这一BGP attribute(虽然路由表中它有next-hop,但是这里的next-hop不是BGP概念的next-hop attribute)，这完全是一个IGB的路由。R1将这一条路由advertise到其它BGP(iBGP and eBGP)peer的时候，它会把自己设置成next-hop这一 BGP attribute，而不是把路由表里的next-hop设置成BGP next-hop这一attribute. 简单来说，R1只是告诉BGP peer，发往a.b.c.d的数据包发给我(这是它advertise的意图），至于数据包到了R1这么处置，他会查看路由表来决定它自己的next-hop。

你可以考虑下一个常用的例子：

R1自身有很多详细的a.b.0.0/16的路由，比如a.b.c.0/24,a.b.d.0/24,a.b.e.0/24.......在做汇聚的时候，往往自己静态产生一条a.b.0.0/16指向null0的静态路由然后advertise出去（是否需要静态产生这条汇聚路由要看具体情况），他的意思是告诉peer,所有的发往a.b.0.0/16的数据都发到我这里来。至于来了之后，R1会做最长匹配找到最精确的路由，比如说a.b.c.0/24,而不是a.b.0.0/16。只是一个常用的策略。如果按照你说的，那些得到a.b.0.0/16的peer岂不直接就把数据报discard掉了。

我对BGP的实际经验不是很多,不是100%保证我说的对，这只是我的理论理解，最好你还是做实验确认一下，并且通报一下实验结果。更多精彩文章及讨论，请光临枫下论坛 rolia.net

看得出来，你对路由理解挺深入的。看样子最关键的还是我对next-hop这个概念在不同情况下（protocol)的行为不是很清楚。我觉得你说的有道理，虽然目前我还没有实物论证。等设备来了看吧。 -whatthehell(cyberman); 2009-5-30 (#5301698@0)

i see, now i know how your initial question comes from. ... -eagle_no1(瞎起哄); 2009-5-30 {312} (#5301426@0)
the information "set static a.b.c.d discard", which is a local configuration on R1, WON'T advertise outside of R1. So there is not way that R2 discards this IP package explicitly. as a result. weather the IP package in R2 will be discarded or not, only depends on if the route information in the table or not.

agree！ -ccie18614(加拿大枫叶); 2009-5-30 (#5301438@0)

简单的说，如果R2路由表里有a.b.c.d这条路由，就不会在R2上discard,如果没有这条路由，就会直接discard. -ccie18614(加拿大枫叶); 2009-5-29 (#5300914@0)

奇怪，今天是星期五晚上，大虾们居然在这里答疑解惑。我以为这时应该在什么地方开心HAPPY啊。 -whatthehell(cyberman); 2009-5-29 (#5301054@0)

Discard route -diresu(makeITwork); 2009-6-1 {304} (#5305855@0)

serves many purposes. In BGP, it is common and almost certain that statical route is to prevent route oscillation. Router1 is to influence router2, even if Router1 don't really has any route to destination (in compare to summary route). This route origin is neither iBGP nor eBGP but incomplete/unknown.

@Calgary

我觉得不是这样的

Replies, comments and Discussions:

More Topics