Pages

network cisco ccna gns3 certification arteq

network cisco ccna gns3 certification arteq
a network runs through it

Search insearchofthecert

Monday, August 27, 2012

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

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.
 
 
 

No comments:

Post a Comment