Mailing List Archive

Check the "inactive reason" field on router A ( show route
<prefix-in-question> extensive ).

- Kisito

At 11:11 4/21/2003, Tay Chee Yong wrote:
>Hi all,
>
>I have 2 route reflectors (Router A and Router B).
>2 RR clients (C and D)
>
>Both C and D are the clients of A and B
>A and B are full mesh
>
>Both A and B are using the same cluster id, 1.1.1.1
>
>I then add router E to be client of B only, with some routes filtering.
>
>Strangely, router A is not selecting the better route from B learned from
>E, instead router A is registering the better route from its learned eBGP
>peer.
>
>Why aren't B propagating the better route learned from E to router A?
>
>Regards,
>Cheeyong
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp

On Mon, Apr 21, 2003 at 05:11:07PM +0800, Tay Chee Yong wrote:
> Hi all,
>
> I have 2 route reflectors (Router A and Router B).
> 2 RR clients (C and D)
>
> Both C and D are the clients of A and B
> A and B are full mesh
>
> Both A and B are using the same cluster id, 1.1.1.1
>
> I then add router E to be client of B only, with some routes filtering.
>
> Strangely, router A is not selecting the better route from B learned from
> E, instead router A is registering the better route from its learned eBGP
> peer.
>
> Why aren't B propagating the better route learned from E to router A?

A router reflector will discard all routes learned with it's own cluster
id, see rfc2796 section 7, which say

CLUSTER_LIST

Cluster-list is a new optional, non-transitive BGP attribute of Type
code 10. It is a sequence of CLUSTER_ID values representing the
reflection path that the route has passed. It is encoded as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code| Length | value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where Length is the number of octets.

When a RR reflects a route, it must prepend the local CLUSTER_ID to
the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new
one. Using this attribute an RR can identify if the routing
information is looped back to the same cluster due to mis-
configuration. If the local CLUSTER_ID is found in the cluster-list,
the advertisement received should be ignored.

/Jesper

--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

I think the issue here is the fact that A and B have the same cluster ID.
When router B learns a route from its client (router E), on reflecting the
route, it attaches the clusterID to the route and sends it to other clients
and Router A. However, when router A gets the route it sees that it came
from the same clusterID therefore it drops it. You can verify this by
looking at routes you are advertising to Router A from B. Also check
whether A is even installing it into the routing table. I would suspect
that it is not due to router A thinking that the route it just received is
looped and discarding it before it is even processed into the RIB-IN-ADJ
table. You can also overcome this issue (if in fact it is the issue) by
changing the cluster-id on Router A. Please let me know the outcome.
Thanks.




Thanks,

Mario Puras
SoluNet Technical Support
Mailto: mpuras@solunet.com
Direct: (321) 309-1410
888.449.5766 (USA) / 888.SOLUNET (Canada)



-----Original Message-----
From: Tay Chee Yong [mailto:tcy@pacific.net.sg]
Sent: Monday, April 21, 2003 5:11 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] BGP Route Reflector


Hi all,

I have 2 route reflectors (Router A and Router B).
2 RR clients (C and D)

Both C and D are the clients of A and B
A and B are full mesh

Both A and B are using the same cluster id, 1.1.1.1

I then add router E to be client of B only, with some routes filtering.

Strangely, router A is not selecting the better route from B learned from
E, instead router A is registering the better route from its learned eBGP
peer.

Why aren't B propagating the better route learned from E to router A?

Regards,
Cheeyong

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

Cheeyong,

I concur with Jesper, this is due to the same cluster-id on A and B. You can
fix this situation by either making the cluster-id different on A and B or
by fully meshing the clients.

Hope this help.







_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Hi Jesper,

Thanks for your pointer! We will do the necessary changes to resolve the
problem.

Regards,
Cheeyong


On Mon, 21 Apr 2003, Jesper Skriver wrote:

: On Mon, Apr 21, 2003 at 05:11:07PM +0800, Tay Chee Yong wrote:
: > Hi all,
: >
: > I have 2 route reflectors (Router A and Router B).
: > 2 RR clients (C and D)
: >
: > Both C and D are the clients of A and B
: > A and B are full mesh
: >
: > Both A and B are using the same cluster id, 1.1.1.1
: >
: > I then add router E to be client of B only, with some routes filtering.
: >
: > Strangely, router A is not selecting the better route from B learned from
: > E, instead router A is registering the better route from its learned eBGP
: > peer.
: >
: > Why aren't B propagating the better route learned from E to router A?
:
: A router reflector will discard all routes learned with it's own cluster
: id, see rfc2796 section 7, which say
:
: CLUSTER_LIST
:
: Cluster-list is a new optional, non-transitive BGP attribute of Type
: code 10. It is a sequence of CLUSTER_ID values representing the
: reflection path that the route has passed. It is encoded as follows:
:
: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | Attr. Flags |Attr. Type Code| Length | value ...
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
: Where Length is the number of octets.
:
: When a RR reflects a route, it must prepend the local CLUSTER_ID to
: the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new
: one. Using this attribute an RR can identify if the routing
: information is looped back to the same cluster due to mis-
: configuration. If the local CLUSTER_ID is found in the cluster-list,
: the advertisement received should be ignored.
:
: /Jesper
:
:

Hi all,

Thanks for all the solutions and advise. Greatly appreciated it.

Cheeyong

On Mon, 21 Apr 2003, jerome fabre wrote:

: Cheeyong,
:
: I concur with Jesper, this is due to the same cluster-id on A and B. You can
: fix this situation by either making the cluster-id different on A and B or
: by fully meshing the clients.
:
: Hope this help.
:
:
:
:
:
:
:
: _________________________________________________________________
: Protect your PC - get McAfee.com VirusScan Online
: http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
:

I dont believe that fully meshing the clients (routers C, D and E) will
solve this problem. The "no-client-reflect" is configured under the
peer-group that defines Router C, D and E (i.e. the clients) not Router A.
So Router B will still advertise the router to router A. Router A will then
drop it due to the same cluster-id being configured. The only fix to this
given the scenario at present is to change the cluster-id on router A (or
B).




Thanks,

Mario Puras
SoluNet Technical Support
Mailto: mpuras@solunet.com
Direct: (321) 309-1410
888.449.5766 (USA) / 888.SOLUNET (Canada)



-----Original Message-----
From: jerome fabre [mailto:hansito36@hotmail.com]
Sent: Monday, April 21, 2003 9:59 AM
To: tcy@pacific.net.sg
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] BGP Route Reflector


Cheeyong,

I concur with Jesper, this is due to the same cluster-id on A and B. You can

fix this situation by either making the cluster-id different on A and B or
by fully meshing the clients.

Hope this help.







_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

I meant fully meshing the clients with the RRs. In this case E with A and B.

>From: MPuras@solunet.com
>To: hansito36@hotmail.com
>CC: juniper-nsp@puck.nether.net
>Subject: RE: [j-nsp] BGP Route Reflector
>Date: Mon, 21 Apr 2003 15:12:38 -0400
>
>I dont believe that fully meshing the clients (routers C, D and E) will
>solve this problem. The "no-client-reflect" is configured under the
>peer-group that defines Router C, D and E (i.e. the clients) not Router A.
>So Router B will still advertise the router to router A. Router A will
>then
>drop it due to the same cluster-id being configured. The only fix to this
>given the scenario at present is to change the cluster-id on router A (or
>B).
>
>
>
>
>Thanks,
>
>Mario Puras
>SoluNet Technical Support
>Mailto: mpuras@solunet.com
>Direct: (321) 309-1410
>888.449.5766 (USA) / 888.SOLUNET (Canada)
>
>
>
>-----Original Message-----
>From: jerome fabre [mailto:hansito36@hotmail.com]
>Sent: Monday, April 21, 2003 9:59 AM
>To: tcy@pacific.net.sg
>Cc: juniper-nsp@puck.nether.net
>Subject: Re: [j-nsp] BGP Route Reflector
>
>
>Cheeyong,
>
>I concur with Jesper, this is due to the same cluster-id on A and B. You
>can
>
>fix this situation by either making the cluster-id different on A and B or
>by fully meshing the clients.
>
>Hope this help.
>
>
>
>
>
>
>
>_________________________________________________________________
>Protect your PC - get McAfee.com VirusScan Online
>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp


_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail

But even then if you loose one link from one of the clients to the RRs, you
are back to square one. So you're still better off with changing the
cluster-id on the RRs.






>From: MPuras@solunet.com
>To: hansito36@hotmail.com
>CC: juniper-nsp@puck.nether.net
>Subject: RE: [j-nsp] BGP Route Reflector
>Date: Mon, 21 Apr 2003 15:12:38 -0400
>
>I dont believe that fully meshing the clients (routers C, D and E) will
>solve this problem. The "no-client-reflect" is configured under the
>peer-group that defines Router C, D and E (i.e. the clients) not Router A.
>So Router B will still advertise the router to router A. Router A will
>then
>drop it due to the same cluster-id being configured. The only fix to this
>given the scenario at present is to change the cluster-id on router A (or
>B).
>
>
>
>
>Thanks,
>
>Mario Puras
>SoluNet Technical Support
>Mailto: mpuras@solunet.com
>Direct: (321) 309-1410
>888.449.5766 (USA) / 888.SOLUNET (Canada)
>
>
>
>-----Original Message-----
>From: jerome fabre [mailto:hansito36@hotmail.com]
>Sent: Monday, April 21, 2003 9:59 AM
>To: tcy@pacific.net.sg
>Cc: juniper-nsp@puck.nether.net
>Subject: Re: [j-nsp] BGP Route Reflector
>
>
>Cheeyong,
>
>I concur with Jesper, this is due to the same cluster-id on A and B. You
>can
>
>fix this situation by either making the cluster-id different on A and B or
>by fully meshing the clients.
>
>Hope this help.
>
>
>
>
>
>
>
>_________________________________________________________________
>Protect your PC - get McAfee.com VirusScan Online
>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail