Redistribution!

[themask]

Mình có vấn đề như sau:

Trên cùng một router, không bao giờ có trường hợp các route được phân phối (redistributed routes) lại được phân phối lần nữa vào miền ban đầu hay sang miền thứ 3.
Nếu điều này đúng thì router dùng cơ chế gì để xác định route nào xuất phát từ miền nào ( network command?).

Xin i' kiến mọi người!

[1'hpSky]

Mình nghĩ thế này,
Để phân phối các route vào một area, AS.. chúng ta dùng các lệnh redistribute (co thể summary trước khi redis..). Như vậy Router biết các Routes nào là routes được redistribute. Biết được rồi thì nó đâu có Redistribute ngược lại nữa.
Hơn nữa một số giao thức dùng Split-horizon, thì redistributed routes đâu có được send back to original router?
Bạn nào có ý kiến khác không!!!

[themask]

sure là phải có cơ chế gì gì đó ngòai tag để đánh dấu route...và route không bị redis ngược lại.

ví dụ ntn nhé,

tren cùng một router có 3 miền A (RIP), B( OSPF) và C (EIGRP)

router ospf
redis rip
...
then...
router eigrp
redis ospf

như vậy mọi người nghĩ thử xem khi sh ip route eigrp có thấy các route của RIP ko?

:wink:

[netpro]

themask ,

Trên CCO có một example như thế này:

Route Tagging
EIGRP has the notion of internal and external routes. Internal routes are ones that have been originated within an EIGRP autonomous system (AS). Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the EIGRP AS. External routes are ones that have been learned by another routing protocol or reside in the routing table as static routes. These routes are tagged individually with the identity of their origination.

External routes are tagged with the following information:

The router ID of the EIGRP router that redistributed the route.

The AS number where the destination resides.

A configurable administrator tag.

Protocol ID of the external protocol.

The metric from the external protocol.

Bit flags for default routing.

As an example, suppose there is an AS with three border routers. A border router is one that runs more than one routing protocol. The AS uses EIGRP as the routing protocol. Let's say two of the border routers, BR1 and BR2, use Open Shortest Path First (OSPF) and the other, BR3, uses Routing Information Protocol (RIP).

Routes learned by one of the OSPF border routers, BR1, can be conditionally redistributed into EIGRP. This means that EIGRP running in BR1 advertises the OSPF routes within its own AS. When it does so, it advertises the route and tags it as an OSPF learned route with a metric equal to the routing table metric of the OSPF route. The router-id is set to BR1. The EIGRP route propagates to the other border routers. Let's say that BR3, the RIP border router, also advertises the same destinations as BR1. Therefore BR3, redistributes the RIP routes into the EIGRP AS. BR2, then, has enough information to determine the AS entry point for the route, the original routing protocol used, and the metric. Further, the network administrator could assign tag values to specific destinations when redistributing the route. BR2 can use any of this information to use the route or re-advertise it back out into OSPF.

Using EIGRP route tagging can give a network administrator flexible policy controls and help customize routing. Route tagging is particularly useful in transit ASes where EIGRP would typically interact with an inter-domain routing protocol that implements more global policies. This combines for very scalable policy based routing.

Như vậy, mỗi routing protocol có một cơ chế khác nhau để tránh trường hợp của themask nêu . trong trường hợp này thì mình nghĩ EIGRP sẽ redistribute cả RIP . Cách tốt nhất là ta phải control việc redistribute này .

Correct me if i'm wrong :D

chúc vui ,

[1''hpSky]

Re: Redistribution!

Câu hỏi của Themask khá rộng, ý tưởng của 1'hpSky thì đúng nhưng câu trả lời đó chung chung quá.

Tagging mà netpro đề cập là một giải pháp cho vấn đề routing-loop giữa các AS như themask đã nêu. Về cơ bản là thực hiện mask các redistributed route ntn để có thể nhận dạng nếu route được import ngược trở lại.

Đơn cử trường hợp cooperation giữa các giao thức định tuyến trong môi trường MPLS/VPN, mà điển hình là OSPF chạy giữa PE-CE, hoặc phức tạp hơn chỉ có một số PE-CE chạy OSPF.

Khi nhận được các Routing Update từ CE router, PE thực hiện redistribute các route này vào MP-IBGP để propgate tới các PE khác trong toàn mạng Core. Egress PE redistribute ngược lại vào OSPF area khác của Customer. Sau khi travel trong area này, route được gửi đến Egress PE. PEBởi AD của OSPF = 110, trong khi của MP-iBGP = 200, nên Egress PE sẽ thay thế best route, propagating ngược lại Ingress PE, redistribute vào Area ban đầu = > loop

Vấn đề này giải quyết bằng down bit trong optinal field của LSA
OSPF.

Một trường hợp khác, hình sau:

[1''hpSky]

Re: Redistribution!

Câu hỏi của themask khá rộng. Ý tưởng của 1'hpSky đúng nhưng chung chung quá.

Giải pháp tagging mà netpro đề cập là một trong các giải pháp thực hiện vấn đề themask đã nêu. Tuy nhiên, vấn đề này phụ thuộc nhiều vào hoàn cảnh cụ thể, công nghệ cụ thể

Đơn cử trong môi trường MPLS với OSPF chạy giữa PE-CE:



Giải quyết bằng cách thay tag field bởi ID của AS core.



Giải quyết vấn đề này bằng cách set down bit trong trường option của LSA OSPF. Hình này còn mô tả vấn đề sub-optimal routing (PE1-PE2). Giải quyết bằng cách không set bit routing trong LSA header.

[danguyennhi]

Re: Redistribution!

theo em thì

redistributed routes vẫn có thể bị/được redistribute vào một routing protocol thứ ba hoặc thậm chí là redistributed ngược trở lại routing protocol ban đầu. Điều này đặc biệt đúng với các routing protocol như RIP v.1 hoặc IGRP.

[themask]

Re: Redistribution!

Hi, long time no see!

Với trường hợp Multiredistributed points, route có thể được phân phối lại nhiều lần trên nhiều miền khác nhau. Tuy nhiên, trên cùng một router, route không bao giờ được phân phối lần nữa qua miền thứ 3.

have fun, take a look at this for details ( notice at line in bold):


------------------

There were some questions in the last couple of months which got me started thinking. The questions were about situations in which you're
redistributing with three different protocols on one router, i.e. EIGRP- OSPF - RIP. The question was along the lines of "I redistribute EIGRP
into OSPF and OSPF into RIP - why don't the EIGRP routes show up in RIP?" My experience in doing scenarios had been that this was working as
designed, but I finally felt compelled to understand this better. I've read some Cisco doc and labbed some situations to prove to myself how this works and thought I'd share my thoughts with you. Hopefully these are helpful to someone. And if I'm wrong in any of this please let me know!

One thing I noticed in reading the Cisco doc is that talk about redistributing "derived routes" between "routing domains." The more I
read this the more it occurred to me that what they're talking about is routes in the main IP routing table which were learned from a particular
protocol. So for example, in the question above: RIP will learn about OSPF routes by searching the main routing table for OSPF derived routes
rather than by searching the OSPF database directly. If we track the distribution path for an EIGRP learned route then it would seem that

A) the EIGRP route will be installed in the main routing table as it has the lowest distance,

B) OSPF will learn the route through redistribution since an EIGRP derived route is in the main routing table, and

C) RIP will not learn about the route since there is no OSPF derived route in the main routing table to redistribute. As expected then you must also redistribute EIGRP directly into RIP to get the EIGRP routes.

To test all this I set up a small 4 router network which looks like this:


R4
|
------------------------------------ Frame Cloud
| | |
R1 R2 R3
| | |
------------------------------------ Ethernet 10.10.10.0/24


R4 is the hub of a frame cloud with spokes out to R1, R2, and R3. R1, R2, and R3 all have ethernet interfaces in a common IP subnet. R1 is
talking RIP to R4. R2 is talking OPSF to R4. R3 is talking EIGRP to R4. R4 is redistributing every each protocol into both of the others. I then used
the 3550 to which these routers are connected to bring interfaces online or take them offline. I did some debugs on the routers which I logged to a
syslog server. Rather than send an even longer e-mail I put the results up on a web page at: http://home.comcast.net/~dbuechner/syslog.html


What I learned is that my expectations seemed to bear out on the routers. I was able to see routes get modified or dropped based on
redistribution criteria. For example if you do the following: the EIGRP learning about this interface from redistribution into RIP and OSPF on R4. If I
then configure a STATIC route to 10.10.10.0/24 on R4 the STATIC route replaces the EIGRP route in the main routing table. The lack of the
EIGRP route in the main routing table then causes both OSPF and RIP (and therefore R2 and R1) to lose their routes to the interface.

I also understand the 'distribution list <x> out <routing-protocol>' statement better now. Essentially what you are doing is applying the
access-list <x> to routes derived from <routing-protocol> when you send updates out. So for example I was getting a route from EIGRP which I
redistributed into RIP. I then added a distribution list to filter this route by adding 'distribution list 1 out eigrp 1' under the RIP
protocol. RIP then lost the route. If i shutdown the R3 interface and brought up the R2 interface I then had an OSPF derived route in the
routing table on R4. This route got redistributed through RIP to R1 because the distribution list command was specifically looking for EIGRP. Also, when the distribution list is keeping RIP from advertising the route I did notice one (originally confusing) thing: the route still shows up in the RIP database on R4. The distribution list doesn't keep the route out of the database, just out of the updates being sent out.

The more I thought about this the more sense it made. While I certainly don't have access to the IOS code I started to remember my CS training - specifically in the areas of algorithms and data structures. It makes sense from a coding perspective for the OSPF process to be isolated from changes to the data structures used by other routing protocols. If everyone just looks at the main routing table it is much cleaner.

What's happening also makes sense from a routing perspective. The whole reason behind administrative distances is to handle the mismatch between
routing protocol metrics. It makes sense that the same problem would occur when you redistribute. If I'm redistributing two protocols into OSPF,
for example, and both have routes to somewhere in common, how else would I decide which route to take on except by utilizing the AD? Since the AD determination is already done for a route to be placed in the main routing table it makes sense to get your routes for redistribution from there as
well.

[longphi11]

To ko hieu ve cau hoi nay` lam,nhung neu theo y' to thi` cac' routes cua router khi duoc config cac routing protocols no' se co' co che Tag,nhu vay no' co' the phan biet duoc cac routes voi nhau