bgp lab 6-4...

nice reflectors...

sj1

int s1/1
ip add 192.168.1.5 255.255.255.252
clock rat 128000
no shut

sj2

int lo0
ip add 10.2.2.1 255.255.255.0

int s1/1
ip add 192.168.1.6 255.255.255.252
no shut

int s1/2
ip add 172.24.1.17  255.255.255.0
clock rat 128000
no shut

rj3

int  s1/2
ip add 172.24.1.18 255.255.255.0
no shut

don't do the loopback on sj3 yet... oh yeah, the diagram...

from wiki: http://en.wikipedia.org/wiki/Route_reflector

A route reflector (RR) is a network routing component. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP). An RR acts as a focal point for IBGP sessions. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR - acting as a route reflector server - rather than peer with every other router in a full mesh. All the other IBGP routers become route reflector clients.

all three get rip v2

sj1

router rip
ver 2
no auto-summ
netw 192.168.1.0

sj2

router rip
ver 2
no auto-summ
netw 172.24.0.0
netw 192.168.1.0
netw 10.0.0.0

sj3

router rip
ver 2
no auto-summ
netw 172.24.0.0

cop r s

sj1#sh ip route | excl L
     

Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 1 subnets
R        10.2.2.0 [120/1] via 192.168.1.6, 00:00:28, Serial1/1
      172.24.0.0/24 is subnetted, 1 subnets
R        172.24.1.0 [120/1] via 192.168.1.6, 00:00:28, Serial1/1
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.4/30 is directly connected, Serial1/1


foreach address {
10.2.2.1
192.168.1.5
192.168.1.6
172.24.1.17
172.24.1.18
} {
ping $address }

works for me...

http://tools.ietf.org/html/rfc4456#section-4

.  Route Reflection
   The basic idea of route reflection is very simple.  Let us consider
   the simple example depicted in Figure 1 below.

                   +-------+        +-------+
                   |       |  IBGP  |       |
                   | RTR-A |--------| RTR-B |
                   |       |        |       |
                   +-------+        +-------+
                         \            /
                     IBGP \   ASX    / IBGP
                           \        /
                            +-------+
                            |       |
                            | RTR-C |
                            |       |
                            +-------+

                    Figure 1: Full-Mesh IBGP

   In ASX, there are three IBGP speakers (routers RTR-A, RTR-B, and
   RTR-C).  With the existing BGP model, if RTR-A receives an external
   route and it is selected as the best path it must advertise the
   external route to both RTR-B and RTR-C.  RTR-B and RTR-C (as IBGP
   speakers) will not re-advertise these IBGP learned routes to other
   IBGP speakers.

   If this rule is relaxed and RTR-C is allowed to advertise IBGP
   learned routes to IBGP peers, then it could re-advertise (or reflect)
   the IBGP routes learned from RTR-A to RTR-B and vice versa.  This
   would eliminate the need for the IBGP session between RTR-A and RTR-B
   as shown in Figure 2 below.

                  +-------+        +-------+
                  |       |        |       |
                  | RTR-A |        | RTR-B |
                  |       |        |       |
                  +-------+        +-------+
                        \            /
                    IBGP \   ASX    / IBGP
                          \        /
                           +-------+
                           |       |
                           | RTR-C |
                           |       |
                           +-------+

from odom, ocg

 If an optional attribute is transitive , a BGP process should accept the path in which it is
included, even if it doesn’t support the attribute, and it should pass the path on to its peers.

If an optional attribute is nontransitive , a BGP process that does not recognize the attribute
can quietly ignore the Update in which it is included and not advertise the path to its other
peers.