Subject: Re: bgp router id

From: Tulip Rasputin <[email-masked]>
Date: Tue, 2 Dec 2003 05:43:19 -0500 (EST)

Alok,

My original question has been unanswered but I will attempt to answer yours.
 
> my question was why cant the IP/and or router-id be an RFC 1918 IP address
> for peers which are *internal to the AS*...like RRs or iBGP speakers?
> 
> why is it  *unfortunate*??

Suppose one of your IBGP peer aggregates some routes. It will put its Router ID in the Aggregator
field and will advertise this to other peers. Now, for this case, lets assume it uses an RFC 1918
IP address. There is a probability that when this path is leaked out of your own AS, and received
by some other IBGP peer (which again may use RFC 1918 addresses) of some other AS, things may not
go as expected. Its thus always better to use non RFC 1918 IP addresses for your BGP speakers.

> I also understand that there is a field called Originator id in the RR RFC
> (which may not have much relevance if one was to look at poison reverse or
> cases where RRs would *not* send back routes learnt from RR back to the same

Poison reverse only works for directly connected peers/routers. By "direct" I don't mean a
"direct" physical connection, but rather a "direct" logical connection. 

We need the concept of Originator ID in BGP because the RR can receive the path it originally
originated, from a peer, after it has traversed mulitple hops, and not necessarily from a router
to which it had advertised this before!

Simply put, Poison reverse will not help in BGP. 

The BGP experts may be able to provide a clearer picture.

Regards,
Rasputin

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Alok Dube" <[email-masked]>
Date: Tue, 2 Dec 2003 17:20:07 +0530

Hi,

thanks for the clarification,

> go as expected. Its thus always better to use non RFC 1918 IP addresses
for your BGP speakers.

this holds true when one does not aggregate at the eBGP peering node but
rather at a node  in the AS only (a pure iBGP speaker performs the
aggregation etc).
The other point ofcourse being, why does one need to know the aggregation
point?

> to which it had advertised this before!

cluster_id?

i  agree that having a unique router-id  would lead to faster convergence
(still the router-id can be unique in the AS if the speakers are purely
iBGP/RRs and dont run eBGP).

but iBGP per se doesnt pass on what what it learns from any other iBGP peer.

so if its purely RRs and each iBGP node talks to only 1 RR cluster then:

1. the RRs are not clients of each other so they dont learn from
neighbouring RRs what they send to them (iBGP peering)
2. if an RR was to send out routes it has learnt from another RR,
cluster_id/cluster_list would suffice to say that there was a loop.

ofcourse this breaks when an iBGP peer talks to multiple RRs (a client of
multiple RRs)

thanks again,

-rgds
Alok

---

From: "Alok Dube" <[email-masked]>
Date: Tue, 2 Dec 2003 17:20:07 +0530

Hi,

cluster_id?

thanks again,

-rgds
Alok