From: Albert Lu (albert_ccie@xxxxxxxxx)
Date: Thu Nov 29 2001 - 20:30:12 GMT-3
Is there any way of changing the source of the route in OSPF? Can probably
redistribute into another OSPF process, that would be my idea, but that is
more of a hack.
Albert
-----Original Message-----
From: SFeldberg@edeltacom.com [mailto:SFeldberg@edeltacom.com]
Sent: Friday, November 30, 2001 12:30 AM
To: Albert Lu
Cc: ccielab@groupstudy.com; 'Marc Russell'; nobody@groupstudy.com;
'Chua, Parry'; 'Vincent Zhang'
Subject: RE: BGP routes when it is learned from OSPF! - A valid
conclusion?
This behavior is expected with OSPF and BGP, when BGP sync has not been
disabled. Adding another route to the table (static, EIGRP, RIP,etc) will
resolve the problem as will disabling BGP synchronization.
Steve
"Albert Lu"
<albert_ccie@y To: <SFeldberg@edeltacom.com>
ahoo.com> cc: <ccielab@groupstudy.com>,
"'Marc Russell'"
Sent by: <mrussell@ccbootcamp.com>,
<nobody@groupstudy.com>, "'Vincent Zhang'"
nobody@groupst <vincentzhang@yahoo.com>, "'Chua,
Parry'" <Parry.Chua@compaq.com>
udy.com Subject: RE: BGP routes when it
is learned from OSPF! - A valid
conclusion?
11/28/2001
06:45 PM
Please respond
to "Albert Lu"
Hello Steve,
I'm having this problem too, the route from OSPF is in the routing table,
but the route in BGP table will not sync with the OSPF route. The route is
there, and I just don't know why it won't sync.
However, after I added a static route, it synced up and everything was
fine.
Albert
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
SFeldberg@edeltacom.com
Sent: Wednesday, November 14, 2001 3:04 AM
To: Chua, Parry
Cc: ccielab@groupstudy.com; Marc Russell; nobody@groupstudy.com; Chua,
Parry; Vincent Zhang
Subject: RE: BGP routes when it is learned from OSPF! - A valid
conclusion?
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.
Steve
"Chua, Parry"
<Parry.Chua@c To: "Chua, Parry"
<Parry.Chua@compaq.com>,
ompaq.com> <SFeldberg@edeltacom.com>, "Marc
Russell"
Sent by: <mrussell@ccbootcamp.com>
nobody@groups cc: <ccielab@groupstudy.com>,
tudy.com <nobody@groupstudy.com>, "Vincent
Zhang"
<vincentzhang@yahoo.com>
Subject: RE: BGP routes when
it
is learned from
11/12/2001 OSPF!
11:14 PM
Please
respond to
"Chua, Parry"
Attach is my test, R4 is the RR, test by advertise a route from RR and
RR cleint R5, verify
the result at RR client R2.
> Parry Chua
>
>
-----Original Message-----
From: Chua, Parry
Sent: Tuesday, November 13, 2001 11:36 AM
To: SFeldberg@edeltacom.com; Marc Russell
Cc: ccielab@groupstudy.com; nobody@groupstudy.com; Vincent Zhang
Subject: RE: BGP routes when it is learned from OSPF!
Hi,
Firstly, thank to KBI to give me the right pointer but wrong section. I
manage to find the answer but would like to know the reason, answer at :
http://www.cisco.com/warp/public/459/25.shtml BGP Best Path Selection
Algorithm,
Paths marked as "not synchronized" in the show ip bgp <longer-prefixes>
output. If BGP synchronization is enabled, which it is by default in
Cisco IOS. Software, there must be a match for the prefix in the IP
routing table in order for an internal (iBGP) path to be considered a
valid path. If the matching route is learned from an OSPF neighbor, its
OSPF router ID must match the BGP router ID of the iBGP neighbor. Most
users prefer to disable synchronization using the no synchronization BGP
subcommand.
Route advertise from RR client to RR may valid/best_path if OSPF and BGP
RID match, next this route will advertise by the RR to the other RR
client which have the two RID.
The reason that "not syn" is due to the mismatch RID of IBGP and OSPF.
See below, could someone give more detail explaination
> 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:26 GMT-3