From: SFeldberg@xxxxxxxxxxxxx
Date: Sun Nov 18 2001 - 22:07:53 GMT-3
To summarize my findings in the lab:
If R2 and R3 are route-reflector clients of R1, ONLY when OSPF is the IGP,
BGP routes originated on R2 will NEVER be seen as valid on R3 and
vice-versa because:
1). BGP and OSPF router IDs are required to match for BGP routes to be seen
as valid.
2). BGP and OSPF router IDs will never match on R2 and R3 due to presence
of the the R1 route-reflector between the iBGP peers.
Stephen Feldberg
e ^ deltacom
phone: 678.835.5437
sfeldberg@edeltacom.com
"Chua, Parry"
<Parry.Chua@co To: <SFeldberg@edeltacom.com>, "Ma
rc Russell"
mpaq.com> <mrussell@ccbootcamp.com>
Sent by: cc: <ccielab@groupstudy.com>,
nobody@groupst <nobody@groupstudy.com>, "Vincent Zha
ng"
udy.com <vincentzhang@yahoo.com>
Subject: RE: BGP routes when it is
learned from
OSPF!
11/12/2001
08:36 PM
Please respond
to "Chua,
Parry"
Hi,
I have try the test as what has posted, same result, ie OSPF as IGP, the
route advertise at
RR client BGP will has "best and valid"[*>] at the RR bgp table but will
have only "valid"[*] at the other RR client bgp table. It this the
expected behaviour of RR ?
> Parry Chua
>
-----Original Message-----
From: SFeldberg@edeltacom.com [mailto:SFeldberg@edeltacom.com]
Sent: Tuesday, November 13, 2001 2:39 AM
To: Marc Russell
Cc: ccielab@groupstudy.com; nobody@groupstudy.com; Vincent Zhang
Subject: RE: BGP routes when it is learned from OSPF!
Marc,
Please take a loser look at this scenario. RTR-1, RTR-2, RTR-3 all have
sync enbled. OSPF is the IGP. 100.100.1.0 is in area 0, and is
incorporated into BGP using a network statement on RTR-3. RTR-1 is the
route reflector for BGP AS100, with RTR-2 and RTR-3 configured as
clients.
RTR-1#sh ip route
137.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 137.1.2.128/25 is directly connected, Serial0
is directly connected, Serial0.2
C 137.1.3.0/24 is directly connected, Loopback1
100.0.0.0/24 is subnetted, 1 subnets
O 100.100.1.0 [110/11] via 133.3.13.3, 00:00:04, Ethernet0
C 20.0.0.0/8 is directly connected, Virtual-TokenRing0
133.3.0.0/16 is variably subnetted, 8 subnets, 2 masks
O 133.3.2.0/24 [110/65] via 133.3.12.2, 00:00:04, Serial1
O 133.3.3.0/24 [110/11] via 133.3.13.3, 00:00:04, Ethernet0
C 133.3.1.0/24 is directly connected, Loopback0
O 133.3.12.2/32 [110/64] via 133.3.12.2, 00:00:04, Serial1
C 133.3.12.0/24 is directly connected, Serial1
C 133.3.13.0/24 is directly connected, Ethernet0
O 133.3.23.0/24 [110/74] via 133.3.13.3, 00:00:06, Ethernet0
O 133.3.23.2/32 [110/64] via 133.3.12.2, 00:00:06, Serial1
RTR-1#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i100.100.1.0/24 133.3.13.3 0 100 0 i
RTR-3#sh ip route
100.0.0.0/24 is subnetted, 1 subnets
C 100.100.1.0 is directly connected, Loopback1
133.3.0.0/16 is variably subnetted, 8 subnets, 2 masks
O 133.3.2.0/24 [110/75] via 133.3.13.1, 00:00:53, Ethernet0
C 133.3.3.0/24 is directly connected, Loopback0
O 133.3.1.0/24 [110/11] via 133.3.13.1, 00:00:53, Ethernet0
O 133.3.12.2/32 [110/74] via 133.3.13.1, 00:00:53, Ethernet0
O 133.3.12.1/32 [110/10] via 133.3.13.1, 00:00:53, Ethernet0
C 133.3.13.0/24 is directly connected, Ethernet0
C 133.3.23.0/24 is directly connected, Serial1
O 133.3.23.2/32 [110/74] via 133.3.13.1, 00:00:54, Ethernet0
RTR-3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 100.100.1.0/24 0.0.0.0 0 32768 i
RTR-3#sh run
!
interface Loopback0
ip address 133.3.3.3 255.255.255.0
no ip directed-broadcast
ip ospf network point-to-point
!
interface Loopback1
ip address 100.100.1.1 255.255.255.0
no ip directed-broadcast
ip ospf network point-to-point
!
interface Ethernet0
ip address 133.3.13.3 255.255.255.0
no ip directed-broadcast
!
interface Serial1
ip address 133.3.23.3 255.255.255.0
no ip directed-broadcast
!
router ospf 100
router-id 133.3.3.3
network 100.100.1.0 0.0.0.255 area 0
network 133.3.0.0 0.0.255.255 area 0
!
router bgp 100
bgp router-id 133.3.3.3
network 100.100.1.0 mask 255.255.255.0
neighbor 133.3.13.1 remote-as 100
no auto-summary
RTR-2#sh ip route
100.0.0.0/24 is subnetted, 1 subnets
O 100.100.1.0 [110/75] via 133.3.12.1, 00:00:33, Serial0
133.3.0.0/16 is variably subnetted, 7 subnets, 2 masks
C 133.3.2.0/24 is directly connected, Loopback0
O 133.3.3.0/24 [110/75] via 133.3.12.1, 00:00:33, Serial0
O 133.3.1.0/24 [110/65] via 133.3.12.1, 00:00:33, Serial0
C 133.3.12.0/24 is directly connected, Serial0
O 133.3.13.0/24 [110/74] via 133.3.12.1, 00:00:33, Serial0
O 133.3.12.1/32 [110/64] via 133.3.12.1, 00:00:33, Serial0
C 133.3.23.0/24 is directly connected, Serial1
RTR-2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* i100.100.1.0/24 133.3.13.3 0 100 0 i
^^^ Here is the GOTCHA. If EIGRP were the IGP, for example, this BGP
route would have the "best" flag set and would be eligible for
advertisment
by BGP. The question is: What about the interaction between OSPF/BGP
causes BGP to treat this network as if it were not present in the
routing
table?
Steve
Marc Russell
<mrussell@ccboo To:
"'SFeldberg@edeltacom.com'"
tcamp.com> <SFeldberg@edeltacom.com>,
Vincent Zhang
Sent by: <vincentzhang@yahoo.com>
nobody@groupstu cc:
ccielab@groupstudy.com, nobody@groupstudy.com
dy.com Subject: RE: BGP routes
when it is learned from
OSPF!
11/12/2001
12:55 PM
Please respond
to Marc Russell
Remember that external OSPF routes don't redistribute into BGP
automatically.
Marc Russell
www.ccbootcap.com
-----Original Message-----
From: SFeldberg@edeltacom.com [mailto:SFeldberg@edeltacom.com]
Sent: Monday, November 12, 2001 12:39 PM
To: Vincent Zhang
Cc: ccielab@groupstudy.com; nobody@groupstudy.com
Subject: Re: BGP routes when it is learned from OSPF!
This same scenario was just floating around last week [see RE:BGP
synchro
problem (LONG)] and I have not received any solution yet.
Bottom line: there is SOMETHING different about the operation of OSPF
that
we are missing.... c'mon OSPF gurus.... help us out here...
Steve
"Vincent
Zhang" To:
<ccielab@groupstudy.com>
<vincentzhang@ cc:
yahoo.com> Subject: BGP routes when
it
is
learned from OSPF!
Sent by:
nobody@groupst
udy.com
11/11/2001
12:15 PM
Please respond
to "Vincent
Zhang"
Hi all,
considering the following scenario about BGP and OSPF.
In one AS, there are two routers(R1 and R2) runing IBGP,but with sych
is
turned on. So that means when R1 send BGP update routes to R2, the
routes
will show as best(indicated by ">" in bgp table unless the routes also
be
learned from IGP.
The problem is here, even if R2 learns these routes from OSPF, it
doest't
get ">" in BGP table( it tells that these routes are not synchonized) !
But when they are learned from other IGP protocols (such as IGRP,EIGRP),
theese routes get into BGP table with ">" successfully.
Does BGP treats OSPF and other IGP differently?
Thanks, V
----- Original Message -----
From: "Brian Hescock" <bhescock@cisco.com>
To: "fred couples" <r0uterj0ckey@yahoo.com>
Cc: <ccielab@groupstudy.com>
Sent: Sunday, November 11, 2001 10:47 AM
Subject: Re: rip neighbor statement (oops)
> correction: I didn't mean to say ipx at the end.
>
> fred couples wrote:
>
> > There seemed to be a disagreement on using ip rip
> > neighbor statements and blocking broadcasts so I tried
> > it out myself. Here's the results:
> >
> > - rip v1 and no neighbor statement: sent to
> > 255.255.255.255
> > - rip v1 and neighbor statement: sent to
> > 255.255.255.255 and unicast to the neighbor also
> > - rip v1 and neighbor and passive-interface: no worky
> > (technical term of the day)
> > - rip v2 and no neighbor: sent to 224.0.0.9
> > - rip v2 and neighbor: sent to 224.0.0.9 and unicast
> > to neighbor
> > - rip v2 and neighbor and passive-interface: no worky
> >
> > so if the requirement is to turn off ipx traffic being
> > broadcast out you need to use ripv2, which uses
> > multicast, not broadcast.
> >
> > Fred
> >
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:18 GMT-3