From: SFeldberg@xxxxxxxxxxxxx
Date: Mon Nov 12 2001 - 15:39:27 GMT-3
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 Z
hang
Sent by: <vincentzhang@yahoo.com>
nobody@groupstu cc: ccielab@groupstudy.com, nobo
dy@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:13 GMT-3