iBGP peering.



Wow! Christmas is on coming Saturday. Merry Christmas to you all, today I’m reading about iBGP peering and hope that I can finish BGP chapter before 2010 ending. This is my iBGP lab, but seem like if I run this, it will be a heavy load for my poor Dell laptop.fuuu…

This time, enterprise have two core routers, IE-1 and IE-2, both are connecting to the internet, different ISP. In this case, we assume that , IE-1 configured to received default route and full BGP update from ISP-1 router. But for IE-2 only configured to received a default rout and partial BGP update, meaning that ISP-3 router will only send a partial part of his BGP updates, not including the updates from ISP-2 but including the customers of ISP-3, 202.1.1.1/24 network in this case.

When a packet from Enterprise want to go to 202.1.1.1/24, it will arrived at both IE-1 and IE-2, which are up link routers. Here, we can assume that OSPF is running within enterprise. Then IE-1 will send packet to IE-2 only but not to ISP-1 because IE-1 know that IE-2 has better route to ASN-5.

Without that iBGP connection, the routers will have no way to know if the other routers have a better BGP path.

- If one router has only one uplink to internet, no need to use loopback interface as update source, as the result, no need to use eBGP multihop subcommand.

- But, even though iBGP peering use loopback IP address (it should use because of the below reasons), it does not need to configure eBGP multihop subcommand.

The inter-connection between iBGP peering within Enterprise routers should use loopback interface. Because internet connected routers of same enterprise might not using the common subnets. Maybe, the routers in separate building or may actually be in different cities or even in different countries for the sake of redundancy. In such case, it makes sense to configure iBGP peers using loopback IP addresses for TCP connection so the single link failure does not cause the iBGP peering fail.

This is the configuration example of the redistribution of the enterprise’s public address range of 202.202.0.0/19 by redistribution from OSPF and summarizing with the aggregate-address BGP subcommand. And as you can see, this is obvious that local BGP ASN and remote BGP ASN are same. So that line is for iBGP peering within same ASN.

Example:

Router bgp 4

Aggregate-address 202.202.0.0 255.255.224.0 summary-only

Redistribute ospf 1 route-map only-128-107

Neighbor 10.1.1.1 remote-as 4


Thanks !!!

0 comments:

Post a Comment