This topic has been archived. It cannot be replied.
-
工作学习 / 学科技术讨论 / 在router1上设了 set static a.b.c.d discard, 然后advertise路由 a.b.c.d 到router2. 请教高手在route2上去a.b.c.d的数据包是在router2上直接就discard掉了呢还是到了router1才被丢掉?
-whatthehell(cyberman);
2009-5-29
(#5300115@0)
-
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是什么意思了;btym how to adverise in your guys mind
-eagle_no1(瞎起哄);
2009-5-29
{38}
(#5300436@0)
-
假设router2的IP地址在router1上reachable, 如果我在router1 上traceroute router2-IP source a.b.c.d, 应该还是通的吧?即使源地址是a.b.c.d
-whatthehell(cyberman);
2009-5-29
(#5300494@0)
-
请看解释如果a.b.c.d是R1上的一个端口(物理的或者逻辑的),这条路由会直接注入到路由表里,distance=0,你自己配的那条discard的路由distance是1,由于distance大,不会注入到路由表的,尽管你配置了discard的路由,它不会有任何作用。
如果a.b.c.d不是R1上的一个端口,你怎么可能在R1上以它为源地址ping R2呢?
我说的是Cisco, 对Juniper,基本不懂。
-ccie18614(加拿大枫叶);
2009-5-29
{323}
(#5300524@0)
-
多谢你的分析,很有道理。我是在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;get it a try and let us know the result.
-eagle_no1(瞎起哄);
2009-5-29
{40}
(#5300639@0)
-
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)
-
我的理解如果是eBGP,next-hop自然是R1.
如果是iBGP,由于在R1,你这条路由是由于直连端口或者静态路由产生的,next-hop自然也是R1.
所以在这里,不存在next-hop的问题。
不知道你的实际情况到底是怎样,仅供参考。
-ccie18614(加拿大枫叶);
2009-5-29
{195}
(#5300844@0)
-
如果是静态路由(set static a.b.c.d discard) 通过IBGP advertise, IBGP通常是不修改next-hop 值的, 那这个静态路由是不是到了Router2还是以discard作为next-hop呢(CISCO里的Null0 是一样的吧)在着手准备用Juniper setup一个网络(multihome BGP + OSPF),想把一些概念搞搞清,动手时心中有谱
-whatthehell(cyberman);
2009-5-29
{92}
(#5301044@0)
-
我觉得不是这样的
-ccie18614(加拿大枫叶);
2009-5-30
{1604}
(#5301420@0)
-
看得出来, 你对路由理解挺深入的。看样子最关键的还是我对next-hop这个概念在不同情况下(protocol)的行为不是很清楚。 我觉得你说的有道理,虽然目前我还没有实物论证。等设备来了看吧。
-whatthehell(cyberman);
2009-5-30
(#5301698@0)
-
i see, now i know how your initial question comes from. ...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.
-eagle_no1(瞎起哄);
2009-5-30
{312}
(#5301426@0)
-
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 routeserves 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.
-diresu(makeITwork);
2009-6-1
{304}
(#5305855@0)