Một giải pháp cho sự bùng nổ của số lượng các liên kết IBGP trong một AS là Route Reflectors (RR).

BGP sẽ không quảng bá một tuyến đường được học từ một IBGP cho một IBGP khác. Với RR chúng ta có thể cho phép một bộ định tuyến ánh xạ (reflect) IBGP được học cho một IBGP khác. Điều này sẽ giảm số lượng các liên kết IBGP trong một AS.

Trong những trường hợp bình thường, một mạng lưới IBGP full mesh nên được duy trì giữa RTA, RTB và RTC trong AS100. Bằng cách sử dụng các khái niệm đường phản xạ RR, RTC có thể được bầu làm một RR và có peer IBGP  ngang hàng với  RTA và RTB. Peer giữa RTA và RTB là không cần thiết vì RTC sẽ  phản xạ đường cho các bản cập nhật đến từ RTA và RTB.

neighbor route−reflector−client

Các router với các lệnh trên sẽ là RR và hàng xóm sẽ là clients của RR đó. Trong ví dụ này, RTC sẽ được cấu hình neighbor route−reflector−client trỏ tới IP của RTA và RTB. Sự kết hợp của RR và client của nó được gọi là cluster. RTA, RTB và RTC trên sẽ tạo thành một cluster với một RR duy nhất trong AS100.

Các peer IBGP khác của RR mà không phải là clients được gọi là non−clients.

Trong một AS có thể có nhiều hơn một route reflector; một RR sẽ đối xử với các RR khác như một IBGP khác. Các RR có thể cùng thuộc cluster (client group) hoặc cluster khác. Trong một cấu hình đơn giản, AS có thể được chia thành nhiều cluster, mỗi RR sẽ được cấu hình với RR khác như một non−client peers trong mô hình fully meshed. Clients không peer với IBGP bên ngoài cluster của chúng.

Xét sơ đồ trên: RTA, RTB và RTC tạo thành một cluster duy nhất với RTC là RR. Theo RTC, RTA và RTB là clients và các router khác là non−client. Hãy nhớ rằng clients  của một RR được tạo bằng cách sử dụng lệnh neighbor route−reflector−client. Cũng như vậy, RTD là RR cho clients RTE và RTF; RTG là một RR trong một nhóm thứ ba. Lưu ý rằng RTD, RTC và RTG là fully meshed nhưng các router trong một cluster thì không. Khi một tuyến đường nhận được một RR, nó sẽ làm như sau:

Sau đây là cấu hình BGP của các router RTC, RTD và RTB:

RTC#

router bgp 100

neighbor 2.2.2.2 remote−as 100

neighbor 2.2.2.2 route−reflector−client

neighbor 1.1.1.1 remote−as 100

neighbor 1.1.1.1 route−reflector−client

neighbor 7.7.7.7 remote−as 100

neighbor 4.4.4.4 remote−as 100

neighbor 8.8.8.8 remote−as 200

RTB#

router bgp 100

neighbor 3.3.3.3 remote−as 100

neighbor 12.12.12.12 remote−as 300

RTD#

router bgp 100

neighbor 6.6.6.6 remote−as 100

neighbor 6.6.6.6 route−reflector−client

neighbor 5.5.5.5 remote−as 100

neighbor 5.5.5.5 route−reflector−client

neighbor 7.7.7.7 remote−as 100

neighbor 3.3.3.3 remote−as 100

Khi IBGP được học tuyến đường bằng cách ánh xạ, nó có thể xảy ra các vòng lặp thông tin định tuyến. Route Reflector có một số phương pháp để ngăn chặn điều này:

Giá trị orgin là bước thứ 5 trong 13 bước để chọn tuyến đường.

BGP Multiple RRs within a Cluster 

Thông thường, một nhóm các clients sẽ có một RR duy nhất. Trong trường hợp này, các cluster sẽ được xác định bởi các router ID của RR. Để tăng cường khả năng dự phòng và tránh Single Points Of Failure, một cluster có thể có nhiều hơn một RR. Tất cả RR trong cùng một nhóm cần phải được cấu hình với 4 byte cluster−id để một RR có thể nhận cập nhật từ RR khác trong cùng một cluster.

Một cluster−list là một chuỗi các cluster−ids của các tuyến đường đã được thông qua. Khi một RR ánh xạ một tuyến đường từ non−clients bên ngoài cluster, nó sẽ thêm các  cluster−id cục bộ tới cluster−list. Nếu bản cập nhật này có một cluster−list rỗng thì RR sẽ tự tạo ra. Sử dụng thuộc tính này, một RR có thể xác định được các thông tin định tuyến bị lặp trở lại một cluster do cấu hình sai. Nếu các cluster−id cục bộ được tìm thấy trong cluster-list, quảng bá sẽ bị bỏ qua.

Trong sơ đồ trên RTD, RTE, RTF và RTH thuộc về một cluster với RTD và RTH cùng là RR cho cluster này. Lưu ý rằng RTH cấu hình fully mesh ngang hàng với tất cả các RR. Trong trường hợp RTD down, RTH sẽ thay thế nó. Sau đây là cấu hình của RTH, RTD, RTF và RTC:

RTH#

router bgp 100

neighbor 4.4.4.4 remote−as 100

neighbor 5.5.5.5 remote−as 100

neighbor 5.5.5.5 route−reflector−client

neighbor 6.6.6.6 remote−as 100

neighbor 6.6.6.6 route−reflector−client

neighbor 7.7.7.7 remote−as 100

neighbor 3.3.3.3 remote−as 100

neighbor 9.9.9.9 remote−as 300

bgp route−reflector 10 (This is the cluster−id)

RTD#

router bgp 100

neighbor 10.10.10.10 remote−as 100

neighbor 5.5.5.5 remote−as 100

neighbor 5.5.5.5 route−reflector−client

neighbor 6.6.6.6 remote−as 100

neighbor 6.6.6.6 route−reflector−client

neighbor 7.7.7.7 remote−as 100

neighbor 3.3.3.3 remote−as 100

neighbor 11.11.11.11 remote−as 400

bgp route−reflector 10 (This is the cluster−id)

RTF#

router bgp 100

neighbor 10.10.10.10 remote−as 100

neighbor 4.4.4.4 remote−as 100

neighbor 13.13.13.13 remote−as 500

RTC#

router bgp 100

neighbor 1.1.1.1 remote−as 100

neighbor 1.1.1.1 route−reflector−client

neighbor 2.2.2.2 remote−as 100

neighbor 2.2.2.2 route−reflector−client

neighbor 4.4.4.4 remote−as 100

neighbor 7.7.7.7 remote−as 100

neighbor 10.10.10.10 remote−as 100

neighbor 8.8.8.8 remote−as 200

Lưu ý rằng ta không cần lệnh cluster cho RTC vì chỉ có một RR tồn tại trong cluster đó. Một điều quan trọng cần lưu ý nữa đó là peer−groups không được sử dụng trong cấu hình ở trên. Nếu clients bên trong một cluster không thiết lập IBGP trực tiếp giữa chúng và các client trao đổi cập nhật thông qua các RR, peer-goups không nên sử dụng.

Lệnh bgp client−to−client reflection được kích hoạt mặc định trên RR. Nếu BGP client−to−client reflection được tắt trên RR và việc tạo dự phòng BGP đã được thực hiện giữa các client thì sử dụng peer groups sẽ là phù hợp.

Trước khi thảo luận về đồng bộ hóa ta hãy nhìn vào kịch bản sau đây. RTC trong AS300 gửi bản tin cập nhật về mạng 170.10.0.0. RTA và RTB đang chạy IBGP, vì vậy RTB sẽ nhận được bản cập nhật và có thể tới mạng 170.10.0.0 qua next hop là  2.2.2.1 (hãy nhớ rằng next hop được thực hiện thông qua IBGP). Để đạt được next hop, RTB sẽ phải gửi lưu lượng truy cập qua RTE.

Giả sử rằng RTA không redistribute mạng 170.10.0.0 vào trong IGP, vì thế ở thời điểm này RTE không biết mạng 170.10.0.0 tồn tại.

Nếu RTB bắt đầu quảng bá tới AS400 rằng nó thể tới mạng 170.10.0.0 sau đó lưu lượng truy cập đến từ RTD qua RTB để tới mạng 170.10.0.0 sẽ đi qua và bị drop ở RTE.

Trạng thái đồng bộ hóa: Nếu một AS có lưu lượng truy cập từ một AS khác đến một AS thứ ba, BGP không nên quảng bá một tuyến đường trước khi tất cả các router trong AS đó đã được học về các tuyến đường thông qua IGP.

BGP sẽ đợi cho đến khi IGP biết được các tuyến đường trong AS và sau đó sẽ quảng bá cho các AS bên ngoài. Điều này được gọi là đồng bộ hóa.

Trong ví dụ trên, RTB sẽ chờ để biết thông tin về mạng 170.10.0.0 thông qua IGP trước khi nó bắt đầu gửi các bản cập nhật cho RTD. Ta có thể đánh lừa RTB nghĩ rằng IGP được truyền thông tin bằng cách thêm một tuyến tĩnh trong RTB trỏ đến mạng 170.10.0.0. Nên cẩn thận để đảm bảo rằng các router khác có thể tới mạng 170.10.0.0 nếu không ta sẽ có vấn đề để tới mạng đó.

Lab test: https://www.mediafire.com/?yd3opt3gij8cgqv

Vô hiệu hóa Synchronization

Trong một số trường hợp, ta không cần phải đồng bộ hóa. Khi tất cả các router đều chạy BGP hoặc khi không muốn có lưu lượng truyền qua AS nào đó, ta có thể vô hiệu hóa việc đồng bộ. Vô hiệu hóa tính năng này có thể cho phép ta có ít tuyến đường trong IGP hơn và BGP cho phép hội tụ nhanh hơn.

Vô hiệu hóa Synchronization không phải là tự động, nếu tất cả các router trong AS chạy BGP và bạn không phải chạy bất kỳ IGP, các router không có cách nào biết được điều đó, và router sẽ phải chờ mãi cho một bản cập nhật IGP về một tuyến đường nhất định trước khi gửi nó cho các router bên ngoài. Bạn cần phải vô hiệu hóa đồng bộ bằng tay trong trường hợp này để định tuyến để làm việc một cách chính xác:

router bgp 100

no synchronization

(Phải dùng lệnh clear ip bgp để lệnh no syn được thực hiện)

RTB#

router bgp 100

network 150.10.0.0

neighbor 1.1.1.2 remote−as 400

neighbor 3.3.3.3 remote−as 100

no synchronization

!−− RTB puts 170.10.0.0 in its IP routing table and advertises it to

!−− RTD even if it does not have an IGP path to 170.10.0.0)

RTD#

router bgp 400

neighbor 1.1.1.1 remote−as 100

network 175.10.0.0

RTA#

router bgp 100

network 150.10.0.0

neighbor 3.3.3.4 remote−as 100

BGP Nexthop Attribute

Thuộc tính BGP nexthop là địa chỉ IP của hop tiếp theo mà mạng đó được sử dụng để tới một địa điểm nhất định.

Đối với EBGP, hop tiếp theo luôn luôn là địa chỉ IP của những hàng xóm được quy định trong lệnh neighbor. Trong ví dụ trên, RTC sẽ quảng bá 170.10.0.0 để RTA có thể tới được 170.10.20.2 và RTA sẽ quảng bá 150.10.0.0 để RTC tới được mạng 170.10.20.1. Đối với IBGP, hop kế tiếp được quảng bá bởi EBGP nên được đưa vào trong IBGP. Bởi vì các quy tắc đó, RTA sẽ quảng bá 170.10.0.0 tới IBGP hàng xóm RTB, với hop tiếp theo là 170.10.20.2. Vì vậy theo RTB, hop tiếp theo để tới mạng 170.10.0.0 là 170.10.20.2 và không phải là mạng 150.10.30.1.

You should make sure that RTB can reach 170.10.20.2 via IGP, otherwise RTB will drop packets destined to 170.10.0.0 because the next hop address would be inaccessible. For example, if RTB is running IGRP you could also run igrp on RTA network 170.10.0.0. You would want to make IGRP passive on the link to RTC so BGP is only exchanged.

Bạn nên chắc chắn rằng RTB có thể tới mạng 170.10.20.2 thông qua IGP, nếu không RTB sẽ loại bỏ gói tin đến 170.10.0.0 vì không có tuyến đường tới đó.

RTA#

router bgp 100

neighbor 170.10.20.2 remote−as 300

neighbor 150.10.50.1 remote−as 100

network 150.10.0.0

RTB#

router bgp 100

neighbor 150.10.30.1 remote−as 100

RTC#

router bgp 300

neighbor 170.10.20.1 remote−as 100

network 170.10.0.0

*RTC sẽ quảng bá mạng 170.10.0.0 tới RTA với NextHop 170.10.20.2

*RTA sẽ quảng bá mạng 170.10.0.0 tới RTB với NextHop 170.10.20.2

(External NextHop qua EBGP sẽ được gửi qua IBGP)

BGP Nexthop (Multiaccess Networks)

Ví dụ sau đây cho thấy cách nexthop sẽ hoạt động trên mạng multiaccess như ethernet.

Giả sử rằng RTC và RTD trong AS300 đang chạy OSPF. RTC đang chạy BGP với RTA. RTC có thể tới mạng 180.20.0.0 qua 170.10.20.3. Khi RTC gửi một bản cập nhật BGP tới RTA về 180.20.0.0 nó sẽ sử dụng địa chỉ 170.10.20.3 như là hop kế tiếp (không phải địa chỉ IP của nó 170.10.20.2). Điều này là do mạng giữa RTA, RTC và RTD là một mạng multiaccess và điều này khiến RTA sử dụng RTD như là một hop kế tiếp tới mạng 180.20.0.0 hơn là làm thêm hop qua RTC.

* RTC sẽ quảng bá 180.20.0.0 tới RTA với nexthop là 170.10.20.3.

BGP Nexthop (NBMA)

Nếu quá trình chuyển tiếp là một frame relay hoặc mạng NBMA (Non Broadcast Media Access) mà ta muốn RTC sẽ quảng bá 180.20.0.0 để RTA có next hop là 170.10.20.3. Vấn đề là RTA không có PVC trực tiếp đến RTD và không thể tới được hop kế tiếp. Trong trường hợp này định tuyến sẽ thất bại.

Để khắc phục tình trạng này một lệnh gọi là NextHopself được tạo ra.

Lệnh Nexthopself

neighbor {ip−address|peer−group−name} next−hop−self

Lệnh next-hop-self cho phép ta buộc BGP sử dụng một địa chỉ IP được chỉ định là hop kế tiếp thay vì để giao thức chọn hop tiếp theo.

Trong ví dụ trước, cấu hình sau đây giải quyết vấn đề:

RTC#

router bgp 300

neighbor 170.10.20.1 remote−as 100

neighbor 170.10.20.1 next−hop−self

RTC quảng bá 180.20.0.0 với NextHop là 170.10.20.2

Origin là một thuộc tính bắt buộc xác định nguồn gốc của thông tin đường dẫn. Thuộc tính origin cho ta ba giá trị:

IGP: Network Layer Reachability Information (NLRI) là interior với originating AS. Điều này thường xảy ra khi ta sử dụng lệnh network trong BGP hoặc khi IGP được redistribute vào trong BGP, thì nguồn gốc của các thông tin đường dẫn sẽ là IGP và được thể hiện với một "i" trong bảng BGP ( Show ip bgp)

EGP: NLRI được học qua EGP (Exterior Gateway Protocol). Điều này được mô tả bằng chữ "e" trong bảng BGP.

INCOMPLETE: NLRI là không biết hoặc được học thông qua con đường khác. Điều này thường xảy ra khi ta redistribute một static route vào BGP và nguồn gốc của các tuyến đường sẽ không đầy đủ. Điều này được thể hiện với bằng dấu "?" trong bảng BGP.

RTA#

router bgp 100

neighbor 190.10.50.1 remote−as 100

neighbor 170.10.20.2 remote−as 300

network 150.10.0.0

redistribute static

ip route 190.10.0.0 255.255.0.0 null0

RTB#

router bgp 100

neighbor 150.10.30.1 remote−as 100

network 190.10.50.0

RTE#

router bgp 300

neighbor 170.10.20.1 remote−as 100

network 170.10.0.0

RTA sẽ tới mạng 170.10.0.0 thông qua : 300 i (có nghĩa là tuyến đường tiếp theo có AS là 300 và giá trị orgin là IGP).

RTA cũng sẽ tới mạng 190.10.50.0 qua : i (có nghĩa là thông tin mạng này cùng AS và giá trị orgin là IGP).

RTE sẽ tới mạng 150.10.0.0 qua : 100 i (AS kế tiếp là 100 và giá trị orgin là IGP).

RTE sẽ cùng tới mạng 190.10.0.0 thông qua: 100 ? (AS kế tiếp là 100 và giá trị origin là incomplete "?", đến từ một static route).

Chú ý:

NLRI

- Thay vì truyền thông tin về một đích có thể đến được là Network và Subnet mask thì BGP truyền NLRI, gồm Prefix và chiều dài của prefix. Prefix sẻ miêu tả cho đích có thể đến được và chiều dài của prefix là miêu tả cho số lượng bit của subnet mask. Ex: NLRI<19, 192.168.1.0> miêu tả prefix 192.168.1.0, và chiều dài là 19 bit mask.

- Withdraw Route : Bản tin này cung cấp một danh sách các tuyến cập nhật không còn đến được nữa và cần phải thu hồi hay xoá ra khỏi bảng định tuyến của BGP. Một bản tin cập nhật không bao gồm thông tin NLRI hay các thông tin thuộc tính thì nó chỉ được dùng cho Withdraw

Thuộc tính của Path

- Hầu hết cấu hình BGP tập trung vào thuộc tính của path. Mỗi tuyến có giá trị thuộc tính được định nghĩa có thể gồm : thông tin path, route preference, next hop, và tóm tắt route. Nhà quản trị sử dụng những thuộc tính này để tạo các chính sách định tuyến. Dựa trên các giá trị của thuộc tính BGP có thể được cấu hình để lọc các thông tin định tuyến, các path, hay các động thái khác. Có các loại thuộc tính sau:

i. Well-know mandatory: là thuộc tính mà bắt buộc phải tồn tại trong bản tin cập nhật. Nó phải được nhận ra bởi tất cả các Peer. Nếu một thuộc tính Well-know bị thiếu, thì một bản tin chỉ thị lỗi đựoc tạo ra. Điều này đảm bảo rằng tất cả các BGP peer phải thoả thuận theo một chuẩn nhất định.

ii. Well-know discretionary: là thuộc tính được nhận ra bởi tất cả các BGP peer, nhưng có thể hoặc không gởi bản tin câp nhật.

iii. Optional transitive : là thuộc tính có thẻ hay không được nhận ra bởi tât cả các BGP peer. Vì thế thuộc tinh transitive có thể chấp nhận và truyền đi thậm chí no không được nhận ra.

iv. Optional nontransitive: là thuộc tính mà có thê hoặc không nhận ra bởi tất cả BGP peer. Cho dù nhận ra hay không thì nó cũng không được truyền di cho Peer khác.