From: Martin D. Fierbaugh (marty@networkwv.com)
Date: Mon Dec 01 2003 - 12:31:15 GMT-3
Thanks everyone for their input and feedback...
I took Brian's suggestion and changed the BGP router-id on R2 to match
the one I already had configured on OSPF for R2.
Whammo... sync.
I thought this to be a fairly useful issue to discuss since BGP seems to
be a little temperamental of OSPF router ids and matching them to sync a
route. I am not aware of any other IGPs behaving this way. Someone may
want to confirm.
Thanks again everyone...
**********************************
Martin D. Fierbaugh, CCNP
Manager IP Routing
NTELOS Advanced Data Engineering
(w) 304.353.8916
(m) 304.415.0427
**********************************
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Porta
Sent: Monday, December 01, 2003 10:19 AM
To: 'Jonathan V Hays'; 'Pun, Alec CL'; 'Martin D. Fierbaugh';
ccielab@groupstudy.com
Subject: RE: NMC Sample LAB - BGP Sync and OSPF
Jonathan,
The purpose is to make R3 "sync" with 192.168.x.x
Let's compare the following two alternatives:
1) Redistribute BGP into OSPF at R1
However R3 has no direct BGP peering relation with R1
R1----eBGP-----R2-----iBGP----R3
192.168.x.x would not Sync !
2) Redistribute BGP into OSPF at R2,
R2 will create Type-5 external link state 192.168.x.x in OSPF database
R3 will have this type-5 192.168.x.x in OSPF database too
==> 192.168.x.x in R3's BGP table sync !
Please let me know your thoughts
Thanks.
Porta
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jonathan V Hays
Sent: Monday, December 01, 2003 3:15 AM
To: 'Pun, Alec CL'; 'Martin D. Fierbaugh'; ccielab@groupstudy.com
Subject: RE: NMC Sample LAB - BGP Sync and OSPF
Correct. The point is that the router ID's of the ORIGINATING router for
the prefix in question should be the same.
As I said below, if OSPF says the prefix originated from R2 and BGP says
the same prefix originated from R1, to me the simplest thing to do is to
redistribute BGP into OSPF on R1. I suppose you could also change the
BGP router ID to match the OSPF router ID.
Jonathan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Pun, Alec CL
Sent: Sunday, November 30, 2003 8:33 PM
To: Jonathan V Hays; 'Martin D. Fierbaugh'; ccielab@groupstudy.com
Subject: RE: NMC Sample LAB - BGP Sync and OSPF
If synchronization is enabled and the underlying IGP is OSPF, make sure
the router ID for prefix that appear in OSPF and BGP table must be the
SAME. This is an extra requirement for OSPF only.
regards,
alec
-----Original Message-----
From: Jonathan V Hays [mailto:jhays@jtan.com]
Sent: Sunday, November 30, 2003 9:57 PM
To: 'Martin D. Fierbaugh'; ccielab@groupstudy.com
Subject: RE: NMC Sample LAB - BGP Sync and OSPF
Going back to my notes, I see I have noted that I think the NMC solution
is incorrect for this particular problem.
>From page 41 of the Sample Scenario PDF:
"Issue: Use the default synchronization method on R2 and R3. Solution:
Redistribute EBGP learned updates on router R2 into OSPF."
But the result of redistributing EBGP into OSPF on R2 is that OSPF says
that 192.168.x.x routes originate from R2 while BGP says the routes
originate from R1. Result: not synchronized.
I found that when I redistributed BGP into OSPF on R1 the problem was
solved.
HTH,
Jonathan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Martin D. Fierbaugh
Sent: Sunday, November 30, 2003 8:11 AM
To: ccielab@groupstudy.com
Subject: NMC Sample LAB - BGP Sync and OSPF
After reading many posts in the archives, I came across this scenario.
In order to satisfy a requirement in this lab, you need to leave
synchronization turned on in an iBGP environment and pass the
announcement to a route reflector client. OSPF has the IGP route, route
is in the routing table, yet BGP seems to think the route is not
synchronized.
Based upon a few posts, I see that this is either intentionally or
unintentionally broken in IOS (proof below).
My questions are is it, in fact, broken? If so, why is it even on
this lab?
Anyone else try this sample lab and run into this?
NMC practice lab, section 8
Thanks,
________________________________
Martin D. Fierbaugh, CCNP
Manager IP Routing
NTELOS Advanced Data Engineering
(w) 304.353.8916
(m) 304.415.0427
sh ip route...
C 172.16.123.0/24 is directly connected, Serial0/0
O E2 172.16.77.0/24 [110/20] via 172.16.123.1, 00:40:27, Serial0/0
O E2 192.168.102.0/24 [110/1] via 172.16.123.1, 00:40:27, Serial0/0 O E2
192.168.103.0/24 [110/1] via 172.16.123.1, 00:40:27, Serial0/0 O E2
192.168.100.0/24 [110/1] via 172.16.123.1, 00:40:27, Serial0/0 O E2
192.168.101.0/24 [110/1] via 172.16.123.1, 00:40:27, Serial0/0 O*E2
0.0.0.0/0 [110/1] via 172.16.123.2, 00:40:27, Serial0/0
R3#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
100 700
172.16.123.1 from 172.16.2.1 (172.16.20.5)
Origin incomplete, localpref 100, valid, internal, not
synchronized R3#
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003
This archive was generated by hypermail 2.1.4 : Sat Jan 03 2004 - 08:25:34 GMT-3