From: Kenny (frenzeus@streamyx.com)
Date: Wed Mar 15 2006 - 12:48:18 GMT-3
Hi all,
I realized that for R2 to peer with R4 (132.1.0.4), it routes thru R3 (due to R3 redis OSPF into EIGRP 10 & R2 distance for external eigrp is 109) Therefore, the specific route 132.1.0.4/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 112.0.0.0 <----Learnt from R6
BGP routing table entry for 112.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
132.1.0.4
100 54 50 60
132.1.26.6 from 132.1.26.6 (150.1.6.6)
Origin IGP, localpref 100, valid, external, best
Rack1R2#
Rack1R3#deb ip bg up
132.1.0.4 rcv UPDATE about 112.0.0.0/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...
frenzeus
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:38 GMT-3