RFC 1771 and implementation - iBGP filtering

From: paguanel@gmail.com
Date: Thu Oct 09 2008 - 02:54:08 ART


Going through RFC 1771 I found nothing that said that you could not manipulate
the attributes (sent or received) of an iBGP peer.

In fact the Cisco IOS allows to modify all possible attributes of an iBGP
received/sent route: weight - inbound only- , local-preference, med,
next-hop origin and community, ( except AS PATH of course).

I find the possibility of modifying attributes other than local-as a bit at
cross purpose with the intent of maintaining consistency within an iBGP cloud.

Is this common / accepted practice of "playing" with attributes of iBGP peers ?

Here is the RFC section about consistency and common set of policies:

" If a particular AS has multiple BGP speakers and is providing transit

service for other ASs, then care must be taken to ensure a consistent

view of routing within the AS. A consistent view of the interior

routes of the AS is provided by the interior routing protocol. A

consistent view of the routes exterior to the AS can be provided by

having all BGP speakers within the AS maintain direct BGP connections

with each other.

 

Using a common set of policies, the BGP speakers

arrive at an agreement as to which border routers will serve as

exit/entry points for particular destinations outside the AS. This

information is communicated to the AS's internal routers, possibly

via the interior routing protocol. Care must be taken to ensure that

the interior routers have all been updated with transit information

before the BGP speakers announce to other ASs that transit service is

being provided."

http://tools.ietf.org/html/rfc1771 "

Thank you for your input

Kind Regards

Pierre-Alex

Blogs and organic groups at http://www.ccie.net



This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:20 ARST