Thắc mắc về BGP Community!

[rockerptit]

Mình có một thắc mắc khi làm lab về BGP Community như sau:

Giả sử ta có:
RA thuộc AS 20
RB thuộc AS 1
RA và RB có thiết lập EBGP session.
RB quảng bá mạng 197.1.0.0/16 cho RA.

Trên RB, cấu hình một route-map nhằm set giá trị community thành 20:17 để ép RA cài đặt Local Preference trog AS 20 đối với các route từ RB gửi sang thành giá trị 50.

Trên RB:
route-map COM permit 10
set community 20:17

router bgp 1
neighbor RA-ip-address route-map COM out
neighbor RA-ip-address send-community

Tuy vậy, khi show ra bảng BGP Table, rõ ràng RA đã nhận được Community từ RB gửi sang, nhưng RA vẫn để nguyên Local Preference là 100 :106:

RA#sh ip bgp 197.1.0.0
BGP routing table entry for 197.1.0.0/16, version 40
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
1
1
192.168.31.1 from 192.168.31.1 (2.0.0.2)
Origin IGP, localpref 100, valid, external, best
Community: 20:17
22 1
192.168.20.1 from 192.168.20.22 (22.0.0.22)
Origin IGP, localpref 100, valid, external

Mong các cao thủ giúp đỡ ạ! :)

[Mr.LeVy]

Má ơi, làm gì có chuyện ép người ta set LP trong eBGP chứ. LP chỉ có ý nghĩa local và lan truyền trong AS thôi mà.

[rockerptit]

Má ơi, làm gì có chuyện ép người ta set LP trong eBGP chứ. LP chỉ có ý nghĩa local và lan truyền trong AS thôi mà.

:)
Đúng là Local Preference chỉ có ý nghĩa trong Local AS, nhưng ở đây mình kô nói đến Local Preference, mình đang nói về BGP Community Attribute.
:)

[Mr.LeVy]

:)
Đúng là Local Preference chỉ có ý nghĩa trong Local AS, nhưng ở đây mình kô nói đến Local Preference, mình đang nói về BGP Community Attribute.
:)

CL 20:7 thì liên quan gì đến LP 200 chứ. Muốn map chúng với nhau thì phải dùng route-map trên RA.

RB gắn prefix với CL, sau đó thông báo với RA. Dựa vào route-map của mình, RA map CL với LP và lan truyền trong its AS. Thế là xong.

Nếu không có route-map trên RA thì chẳng có lý do gì ép RA phải map CL 20:7 thành LP 200 cả (nhưng 100 thì ok, thì đó là giá trị default)

[rockerptit]

CL 20:7 thì liên quan gì đến LP 200 chứ. Muốn map chúng với nhau thì phải dùng route-map trên RA.

RB gắn prefix với CL, sau đó thông báo với RA. Dựa vào route-map của mình, RA map CL với LP và lan truyền trong its AS. Thế là xong.

Nếu không có route-map trên RA thì chẳng có lý do gì ép RA phải map CL 20:7 thành LP 200 cả (nhưng 100 thì ok, thì đó là giá trị default)

Mình nghĩ nếu thực sự bạn chưa tìm hiểu gì về Community Attribute thì cũng kô nên vội đưa ra ý kiến gì ở đây cả. :)

Giả sử RB là Router của Customer, RA là Router của ISP 1
RB có kết nối tới RC là Router của ISP 2

Bây giờ RB muốn đường kết nối với RA là đường backup cho các return traffic từ Internet đi vào RB, vào mạng của Customer, ta cần triển khai BGP Community. RB gửi Community sang RA, mong muốn RA đặt Local Preference xuống 50, tất nhiên là sẽ có bảng map giá trị Community tương ứng với giá trị của Local Preference.
Có thể dùng MED attribute, nhưng MED chỉ có tác dụng đối với các AS kết nối trực tiếp với mạng của Customer, đối với các traffic khác từ các AS bên ngoài thì MED vô tác dụng.

Bây h bạn bảo rằng cấu hình trên RA ư?, RA là Router của ISP, chả nhẽ bạn đột nhập vào hệ thống của họ để đánh mấy dòng CLI chăng =)), hay là bạn hack luôn cả ISP vậy =))

Giải pháp dùng BGP Community được đưa ra đối với trườg hợp này. Bạn có thể tìm hiểu thêm ở đây:

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801475b2.shtml

[Mr.LeVy]

Mình nghĩ nếu thực sự bạn chưa tìm hiểu gì về Community Attribute thì cũng kô nên vội đưa ra ý kiến gì ở đây cả. :)

Giả sử RB là Router của Customer, RA là Router của ISP 1
RB có kết nối tới RC là Router của ISP 2

Bây giờ RB muốn đường kết nối với RA là đường backup cho các return traffic từ Internet đi vào RB, vào mạng của Customer, ta cần triển khai BGP Community. RB gửi Community sang RA, mong muốn RA đặt Local Preference xuống 50, tất nhiên là sẽ có bảng map giá trị Community tương ứng với giá trị của Local Preference.
Có thể dùng MED attribute, nhưng MED chỉ có tác dụng đối với các AS kết nối trực tiếp với mạng của Customer, đối với các traffic khác từ các AS bên ngoài thì MED vô tác dụng.

Bây h bạn bảo rằng cấu hình trên RA ư?, RA là Router của ISP, chả nhẽ bạn đột nhập vào hệ thống của họ để đánh mấy dòng CLI chăng =)), hay là bạn hack luôn cả ISP vậy =))

Giải pháp dùng BGP Community được đưa ra đối với trườg hợp này. Bạn có thể tìm hiểu thêm ở đây:
http://www.cisco.com/en/US/tech/tk36...801475b2.shtml

Pótay, bác đúng là cao thủ thiệt, hèn chi phát biểu tùm lum. Em đâu kêu bác đi hack gì đâu chứ.
Còn trong link trên, nếu R1 với R2 ko có route-map

R1
route-map Peer-R3 permit 10
match community 1
set local-preference 130

R2
route-map Peer-R3 permit 10
match community 1
set local-preference 120

thì nó làm quái gì mà map được LP từ CL chứ.

Còn nữa chỉ có 2 giải pháp để điều khiển traffic theo hướng INBOUND thôi là AS-PATH & MED (áp dụng OUTBOUND). Còn WEIGHT & LP là để điều khiển traffic theo hướng OUTBOUND (áp dụng INBOUND).

Thiệt tình. Khi nào bác tìm ra giải pháp thì post lên đây với. Trình độ CCNA của em chỉ biết đến đây thôi hihi.

[Mr.LeVy]

Mình nghĩ nếu thực sự bạn chưa tìm hiểu gì về Community Attribute thì cũng kô nên vội đưa ra ý kiến gì ở đây cả. :)

Giả sử RB là Router của Customer, RA là Router của ISP 1
RB có kết nối tới RC là Router của ISP 2

Bây giờ RB muốn đường kết nối với RA là đường backup cho các return traffic từ Internet đi vào RB, vào mạng của Customer

Dùng AS-PATH là ok. Prepend 1,2 hay 3 lần tùy. Tuy nhiên 1 quy tắc cần phải nhớ là traffic return vào AS từ Internet thì không thể nào điều khiển theo ý mình nếu ko có sự giúp đỡ của các AS upstream.

Ví dụ bác có Prepend 1000 lần nhưng AS upstream thích dùng các thuộc tính khác (ưu tiên hơn AS-path) thì bác vẫn phải bó tay thôi.

[rockerptit]

Dùng AS-PATH là ok. Prepend 1,2 hay 3 lần tùy. Tuy nhiên 1 quy tắc cần phải nhớ là traffic return vào AS từ Internet thì không thể nào điều khiển theo ý mình nếu ko có sự giúp đỡ của các AS upstream.

Ví dụ bác có Prepend 1000 lần nhưng AS upstream thích dùng các thuộc tính khác (ưu tiên hơn AS-path) thì bác vẫn phải bó tay thôi.

=))
Mình có đả động gì đến AS-Path Prepending Tool gì đâu, mình đang muốn thảo luận về Community, một trong những phương thức để giải quyết bài toán Primary inbound link đối với Customer.

Mình cũng biết là đối với Traffic Outgoing thì sử dụng Weight và Local Preference. Hay là đối với Traffic Incoming thì sử dụng MED và AS-Path Prepending.

Tuy nhiên MED thì chỉ có thể lan truyền tới AS directly connected thôi, kô truyền ra được các AS đằng sau...
Còn AS-Path Prepending thì tốn dung lượng Memory và thực sự kô thể tối ưu bằng Community.

Rốt cuộc mình chỉ muốn thảo luận về BGP Community thôi, các giải pháp khác mình kô muốn đề cập ở đây.
:)

[Mr.LeVy]

=))
Mình có đả động gì đến AS-Path Prepending Tool gì đâu, mình đang muốn thảo luận về Community, một trong những phương thức để giải quyết bài toán Primary inbound link đối với Customer.

Mình cũng biết là đối với Traffic Outgoing thì sử dụng Weight và Local Preference. Hay là đối với Traffic Incoming thì sử dụng MED và AS-Path Prepending.

Tuy nhiên MED thì chỉ có thể lan truyền tới AS directly connected thôi, kô truyền ra được các AS đằng sau...
Còn AS-Path Prepending thì tốn dung lượng Memory và thực sự kô thể tối ưu bằng Community.

Rốt cuộc mình chỉ muốn thảo luận về BGP Community thôi, các giải pháp khác mình kô muốn đề cập ở đây.
:)

Em có ý tốt giúp bác thêm các giải pháp khác mà hihi. Kinh nghiệm 2 năm làm việc với ISP COGENT, em chỉ có thể thảo luận được như thế thôi.

[rockerptit]

Em có ý tốt giúp bác thêm các giải pháp khác mà hihi. Kinh nghiệm 2 năm làm việc với ISP COGENT, em chỉ có thể thảo luận được như thế thôi.

Ok, Bạn đang làm ở đâu hay đã từng làm ở đâu mình không quan tâm. Dù sao mình cũng cảm ơn những thảo luận của bạn :)

[Mr.LeVy]

Uh, đúng rồi. Chí ít bác cũng phải cảm ơn một tiếng chứ, dù em ko giúp được bác nhiều. Để em có động lực mai mốt thảo luận với bác về các chủ đề khác tiếp chứ. :105: