- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: BGP Transitive vs. Non-transitive [7:123998] posted 07/23/2007
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

db wrote:
> And, apart from the RFC, it would be wrong (imho) to discard a
> path just
> because it contains some unsupported attributes.
> Regards

Thanks db, I totally agree.  In fact, I put this in the back of my head and
pressed on.  As I was reviewing Route Reflectors and the CLUSTER_LIST PA
(optional, non-transitive), it dawned on me that Doyle must have it wrong. 
All RRs need to fully mesh with other RRs and non-clients (in order for
synch to remain off).  RR clients are allowed to have eBGP peers.  So
suppose a RR client learns of an eBGP route, sends that to the RR, which in
turn reflects the route to all clients and non-clients.  Since the
non-client may very well be a RR itself, the CLUSTER_LIST PA is included. 
Why should that non-client that doesn't support this PA reject the entire
route simply because of the presence this anti-looping PA?  If it's a RR
also, it needs this PA.  If it's not, it doesn't need it but it doesn't seem
to hurt that it's there.  Rejecting such routes would essentially break the
network, as potentially large chunks of the network would become unreachable
to potentially other large chunks of the network (and is "network chunk"
really a technical term?).

Also, thanks for the quotes from the RFC.  I did think to go there myself,
but I'm already reading from several texts at once.  I typically read RFCs
last.  I find them to be more digestible that way.



Message Posted at:
FAQ, list archives, and subscription info: