NetworkTalk & BGP

B.3.a) Ibgp session within RT-A.

1. The outline is simple: if ISP-D-Link1 and ISP-D-Link2 are both down on RT-A, inbound/outbound traffic of Zone-C and Zone-D-E customers still need to go to the Internet, and so leave over the 2nd router RT-B.

For that purpose, we need to receive the FIB of router RT-B in router RT-A and tag it with LocalPref 90.

Important note:

  • The FIB is the “forwarding information base” resulting of the best routes given by the “routing information table” (RIB).
  • In our case if we have 3 BGP tables, IS-IS, OSPF, etc. The best routes are stored into the RIB. Then some other information is added (like some static routes and BGP routes, which could have next-hop that are not directly connected) and result into the FIB.
  •  For an Ibgp session between two routers, they exchange their FIB table. Of course, the FIB table from a neighbor router is received as a BGP table into the other router.

 2. For instance, for Zone-D-E:

  • o outbound/upload traffic will leave-out through:
    • ISP-D-Link1 (tagged with LocalPref 100) on router RT-A if all links are up.
    • If ISP-D-Link1 link is cut, traffic will pass through ISP-D-Link2 and not the Ibgp neighbor link of RT-B.
  • We should remember that with same attributes and local-preferences, Ebgp routes are preferred to Ibgp routes.
    • If ISP-D-Link1 and ISP-D-Link2 are cut, Zone-D-E and Zone-C upload traffic will pass over router RT-B thanks to the Ibgp session.
  • o inbound/download traffic will come back through the communities values that we tag , values defined in paragraph B.2

3. On RT-A, we tag with local-pref 90 the BGP table received from the Ibgp neighbor RT-B:

router bgp 1000
bgp log-neighbor-changes
neighbor ibgp_client peer-group
neighbor ibgp_client remote-as 1000
neighbor ibgp_client description “Peering with iBGP Core Routers”
neighbor ibgp_client password 7 “…”
neighbor ibgp_client update-source Loopback1
neighbor 11.11.226.27 peer-group ibgp_client
neighbor ibgp_client send-community both

//Important , do not forget next-hop instruction

neighbor ibgp_client next-hop-self
neighbor ibgp_client route-map IBGP-Neighbor-IN in
neighbor ibgp_client route-map IBGP-Neighbor-OUT out

//With the following route-map we tag the BGP table of RT-B received in RT-A with LocalPref90.

route-map IBGP-Neighbor-IN permit 10
set local-preference 90

4. On router RT-B, we send the FIB to RT-A :

router bgp 1000
bgp log-neighbor-changes
neighbor ibgp_client peer-group
neighbor ibgp_client remote-as 1000
neighbor ibgp_client description “Peering with iBGP Core Routers”
neighbor ibgp_client password 7 “…”
neighbor ibgp_client update-source Loopback1
neighbor ibgp_client version 4
neighbor 11.11.226.26 peer-group ibgp_client
!
neighbor ibgp_client send-community both
neighbor ibgp_client next-hop-self
neighbor ibgp_client route-map IBGP-Neighbor-IN in
neighbor ibgp_client route-map IBGP-Neighbor-OUT out

//With the following route-map we advertise the FIB of RT-B to RT-B.
route-map IBGP-Neighbor-OUT permit 20

//Note: blank or empty route-map will send all routes present in FIB.

5. If ISP-C or ISP-B links are down on RT-B, download/ingress traffic regarding Zone-B and Zone-G need to come back from the Internet to the Customer, through the other router RT-A, and so from ISP-D-Link1.

In RT-B, the route-map “IBGP-Neighbor-OUT” sends to RT-A:

  • the FIB table including the best routes of BGP tables of the upstream links,
  • but also routes and prefix lists advertised in router RT-B, in other words, routes for Zone-B and Zone-G.

As a consequence, if ISP-C and ISP-B links are both down (and how we structure the redundancy priorities through the communities values) the ingress traffic will come back from ISP-D-Link1 to Zone-B and Zone-G customers to RT-B over RT-A.

Note: local-communities values tagged to Ebgp neighbors on each router are not exported through the Ibgp session.

 

top

Come back to Tutorial Index”

Advertisements