From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Tue Mar 11 2003 - 18:41:16 GMT-3
Synchronization..... What a concept.
I've been studying this lately and I hope I can explain what I've learned.
To start with, assuming that no one else in your network is advertising
200.200.200.0/24, I believe you need to make the OSPF and BGP router-id's on
Router 'A' the same.
As far as I can tell, it's only in synchronization that the router-id's have
to be the same. The receiving router, router B in your case, matches the
router-id's of the iBGP route it received with the OSPF route it received.
If the two are not the same you're not-synchronized.
Other Problems with Synchronization
In AS's where a BGP router "Z" learns a route from several iBGP sources, the
IGP route may be learned/originated from a redistribution at an EBGP router
"A". The iBGP from router A does't get to router "Z" because of the "only
forward the Best Route" rule done at some other, intermediate router. In
this case since Router Z knows the route from router A via OSPF, all other
iBGP routes at router Z will show as unsynchronized!!
Note that most BGP routers that receive an external route, allow that route
into their IP routing table as an EBGP route. The RIB will show that
externally learned route as the Best Route and all iBGP routes for the same
prefix will be unsynchronized since there is no IGP route for that prefix in
the routing table.
Just an additional synchronization anomaly that I ran into. If the EBGP peer
is slow to come up, an iBGP peer that is up and has advertised a prefix that
is related to an OSPF route in the IP routing table --- will come up as
synchronized. When the EBGP peer finally comes up, the BGP routing process
does not make the EBGP route the preferred route -- and therefor the EBGP
route is not installed in the IP routing table. The synchronized route stays
synchronized and remains the Best Route from the BGP processes perspective.
Useful troubleshooting for no synchronization:
1) make sure you do not have a EBGP route in the routing table for the
prefix in question. There should be an IGP route for the prefix in question.
2) do a trace from the router in question to the prefix. Make sure that the
trace passes through the router that sent you the iBGP update that is
unsynchronized.
3) if the IGP route originated from a BGP -- > OSPF redistribution at the
router that sent you the non synchronized iBGP route, then the OSPF and BGP
router id's at that originating router must not be the same.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Donny MATEO
Sent: Tuesday, March 11, 2003 1:44 AM
To: ccielab@groupstudy.com
Subject: RE: BGP problem, BGP's relation with IGPs
----- Forwarded by Donny MATEO/ADPC/ASIA/BANQUE_INDOSUEZ/FR on 11-03-2003
14:45 -----
Donny MATEO
To:
<mohammed@sulafsolutions.com>
11-03-2003 14:20 cc:
Subject: RE: BGP problem,
BGP's relation with IGPs(Document link: Donny MATEO)
No problem,
router id has nothing to do with subnet advertisement. Even if that subnet
is not known to the other router it doesn't matter. It's only used for ID.
try it out first and see how it goes.
Donny
"Mohammed Al-zubi"
<mohammed@sulafsol To: "'Donny MATEO'"
<donny.mateo@sg.ca-indosuez.com>
utions.com> cc:
<ccielab@groupstudy.com>, <nobody@groupstudy.com>
Subject: RE: BGP problem,
BGP's relation with IGPs
11-03-2003 14:07
Please respond to
mohammed
Well, I failed to mention this, it gets complicated, router A has a loopback
5.5.5.5, and it has to be in an ospf area that is deferent than the area
between A and B, and router B has a loopback 2.2.2.2 but that loopback is
in another routing protocol (ISIS) which is distributed into OSPF at some
router on the network, the IBGP session between A and B uses loopback
(update-source ...) and A see's the loopback of B and vise versa. let me
know what you think
Mohamemd
-----Original Message-----
From: Donny MATEO [mailto:donny.mateo@sg.ca-indosuez.com]
Sent: Monday, March 10, 2003 9:55 PM
To: Mohammed Al-zubi
Cc: ccielab@groupstudy.com; nobody@groupstudy.com
Subject: Re: BGP problem, BGP's relation with IGPs
Hi,
I think you got one of those problem indicated by the OSPF router ID should
match the BGP router ID.
fixed you BGP router id or OSPF router ID to the same value.
>From your show command either you fix your ospf router id to 200.200.200.5
or you fix your BGP router id to 5.5.5.5
Regards,
Donny
"Mohammed Al-zubi"
<mohammed@sulafsol To:
<ccielab@groupstudy.com>
utions.com> cc:
Sent by: Subject: BGP problem, BGP's
relation with IGPs
nobody@groupstudy.
com
11-03-2003 09:26
Please respond to
"Mohammed Al-zubi"
Hello group,
the issue is related to synchronization, from my understanding (and it
could be wrong) is that if sync is enabled (default) a route would not be
advertised to an EBGP peer unless that route is in the routing table of the
sending router. So here comes the question, I have 2 routers that are not
directly connected that have an IBGP session between them, A and B. B also
has an EBGP session with C. There is a loopback on A with the address
200.200.200.5 /24, and there is a network statement in the BGP process for
that address on A, also, the loopback is part of the OSPF process so router
B sees the route in its routing table as an OSPF route, it also sees the
route in the BGP RIP, but its not synchronized. Why is it not synched if
its in the routing table, I added a static route on router B for
200.200.200.0/24 and pointed it to null zero, and it works, I delete it, the
B router stops advertising that route to its EBGP neighbors and the route
becomes not synchronized. I have attached the different shows I did
<----IBGP----><-----EBGP---->
A-------X----Y-----B(R2)-------------------C
2#sho ip route 200.200.200.0
Routing entry for 200.200.200.0/24
Known via "ospf 1", distance 110, metric 846, type inter area
Last update from 120.20.234.4 on Serial0/0.234, 00:06:05 ago
Routing Descriptor Blocks:
* 120.20.234.4, from 5.5.5.5, 00:06:05 ago, via Serial0/0.234
Route metric is 846, traffic share count is 1
R2#sho ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
O IA 200.200.200.0/24 [110/846] via 120.20.234.4, 00:06:35, Serial0/0.234
170.70.0.0/24 is subnetted, 10 subnets
D 170.70.13.0 [90/158208] via 120.20.23.7, 00:19:22, FastEthernet0/0
D 170.70.15.0 [90/158208] via 120.20.23.7, 00:19:22, FastEthernet0/0
D 170.70.9.0 [90/158208] via 120.20.23.7, 00:19:22, FastEthernet0/0
D 170.70.11.0 [90/158208] via 120.20.23.7, 00:19:22, FastEthernet0/0
D 170.70.5.0 [90/158208] via 120.20.23.7, 00:19:22, FastEthernet0/0
R2#sho ip bgp
BGP table version is 8, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i200.200.200.0 5.5.5.5 0 100 0 i
R2#sho ip bgp 200.200.200.0
BGP routing table entry for 200.200.200.0/24, version 8
Paths: (1 available, no best path)
Not advertised to any peer
Local
5.5.5.5 (metric 846) from 5.5.5.5 (200.200.200.5)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
This message is for information purposes only and its content
should not be construed as an offer, or solicitation of an offer,
to buy or sell any banking or financial instruments or services
and no representation or warranty is given in respect of its
accuracy, completeness or fairness. The material is subject
to change without notice. You should take your own independent
tax, legal and other professional advice in respect of the content
of this message. This message may contain confidential or
legally privileged material and may not be copied, redistributed
or published (in whole or in part) without our prior written consent.
This email may have been intercepted, partially destroyed,
arrive late, incomplete or contain viruses and no liability is
accepted by any member of the Credit Agricole Indosuez group
as a result. If you are not the intended recipient of this message,
please immediately notify the sender and delete this message
from your computer.
This message is for information purposes only and its content
should not be construed as an offer, or solicitation of an offer,
to buy or sell any banking or financial instruments or services
and no representation or warranty is given in respect of its
accuracy, completeness or fairness. The material is subject
to change without notice. You should take your own independent
tax, legal and other professional advice in respect of the content
of this message. This message may contain confidential or
legally privileged material and may not be copied, redistributed
or published (in whole or in part) without our prior written consent.
This email may have been intercepted, partially destroyed,
arrive late, incomplete or contain viruses and no liability is
accepted by any member of the Credit Agricole Indosuez group
as a result. If you are not the intended recipient of this message,
please immediately notify the sender and delete this message
from your computer.
This archive was generated by hypermail 2.1.4 : Sat Apr 05 2003 - 08:51:37 GMT-3