IEWBv3 LAB 2 TASK5.1 posted 03/15/2006
I realized that for R2 to peer with R4 (22.214.171.124), it routes thru R3 (due to R3 redis OSPF into EIGRP 10 & R2 distance for external eigrp is 109) Therefore, the specific route 126.96.36.199/32 on R2 is routed via R3, thus BGP prefix on R2 learnt from R6 is being sent to R3 first before reaching R4 as the BGP peer. R4 appends ORIGINATOR as R3 when it receives the bgp prefix. Therefore R3 does not accept the BGP prefixes from R6 when R4 reflects it back to R3. Here's a capture of the output on R2, R3:
Rack1R2#sh ip bg 188.8.131.52 <----Learnt from R6
BGP routing table entry for 184.108.40.206/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
100 54 50 60
220.127.116.11 from 18.104.22.168 (22.214.171.124)
Origin IGP, localpref 100, valid, external, best
Rack1R3#deb ip bg up
126.96.36.199 rcv UPDATE about 188.8.131.52/8 -- DENIED due to: ORIGINATOR is us;
Rack1R3#sh ip bg
The Solutions guide doesn't mention anything on this. Am i supposed to ignore and accept the fact that R3 will deny the BGP prefix from R6 & in turn does not advertise it out to R5?
Thanks in advance...