nanog mailing list archives
RE: Tricky BGP into IGP Question
From: Tim Wolfe <TimW () InfoGroupNW com>
Date: Wed, 24 Jan 2001 10:10:33 -0800
Yes I am. Here is where it gets wierd. 1 is announcing routes to 2a via
ebgp. 2a has ibgp connection to 2b. 2a also has ospf connection to 2b. 2a
and 2b are redist static and redist connected, however the /30 between 1 and
2a does not show up in the ospf database, or in 2b's routing table. Ditto
for the /30 connecting 2b and 3. When I do a sho ip bgp on 2b as follows:
=======================
gw0.pdx.or#sho ip bgp 216.116.32.0
BGP routing table entry for 216.116.32.0/20, version 416205
Paths: (1 available, no best path)
Not advertised to any peer
7441 11102
216.239.168.254 (metric 20) from 216.239.168.254 (207.189.160.254)
Origin IGP, localpref 100, valid, internal
gw0.pdx.or#sho ip route 216.116.32.0
% Network not in table
gw0.pdx.or#
=======================
This being one of the routes announced by 1 (who is actually as7441, 11102
is their customer but the results are the same for 207.189.128.0/18 which
originates from 7441.) When I go to 2a:
=======================
gw0.eug.or#sho ip bgp 216.116.32.0
BGP routing table entry for 216.116.32.0/20, version 10769259
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
160.81.36.89 216.239.160.254
7441 11102
207.189.191.9 from 207.189.191.9 (207.189.191.21)
Origin IGP, localpref 100, valid, external, best
gw0.eug.or#sho ip route 216.116.32.0
Routing entry for 216.116.32.0/20, supernet
Known via "bgp 16402", distance 20, metric 0
Tag 7441, type external
Last update from 207.189.191.9 2d12h ago
Routing Descriptor Blocks:
* 207.189.191.9, from 207.189.191.9, 2d12h ago
Route metric is 0, traffic share count is 1
AS Hops 2
gw0.eug.or#
=======================
The bgp route is actually installed. This (according to Cisco) route is
probably not being installed because it can't find a valid next hop. I set
both ibgp peers to next-hop-self, as 1's peer address is not in the igp, but
to no avail. I also noticed that the interconnecting (between 1 and 2a)
does show up as being distributed into ospf on 2a but no in the ospf
database or in 2b's table:
=======================
gw0.eug.or#sho ip route 207.189.191.8
Routing entry for 207.189.191.8/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf 1
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
gw0.eug.or#sho ip ospf database
OSPF Router with ID (207.189.160.254) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
206.163.76.254 206.163.76.254 960 0x80001B22 0xE804 3
207.189.160.254 207.189.160.254 822 0x800008F2 0xC573 2
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
207.189.160.254 207.189.160.254 822 0x80000023 0x784B 0
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
216.239.160.254 207.189.160.254 822 0x80000023 0xA9D8
216.239.161.0 207.189.160.254 822 0x80000023 0x780C
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
206.163.76.254 207.189.160.254 822 0x80000023 0x47E5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 207.189.160.254 822 0x8000006E 0xC552 1
198.68.7.0 207.189.160.254 822 0x80000023 0x70CE 0
198.68.19.0 207.189.160.254 822 0x80000023 0xEB47 0
198.68.20.0 207.189.160.254 822 0x80000023 0xDB57 0
198.68.22.255 207.189.160.254 822 0x800000AC 0xB7EE 0
198.106.192.0 207.189.160.254 822 0x80000023 0x88DD 0
206.163.32.0 206.163.76.254 197 0x800000A7 0x8B21 0
206.163.32.255 206.163.76.254 197 0x800000AD 0x8E15 0
206.163.34.0 206.163.76.254 197 0x800000AD 0x7829 0
206.163.35.0 206.163.76.254 197 0x800000AE 0x6B34 0
206.163.76.0 206.163.76.254 197 0x800000A9 0xB0CA 0
206.163.140.0 207.189.160.254 822 0x800000AC 0xB01B 0
206.163.152.0 207.189.160.254 822 0x80000023 0x3F0A 0
207.189.160.0 207.189.160.254 822 0x80000023 0x8C9D 0
207.189.163.0 207.189.160.254 822 0x80000023 0x8E91 0
207.189.164.0 207.189.160.254 822 0x80000023 0x839B 0
207.189.165.0 207.189.160.254 822 0x80000023 0x78A5 0
216.239.160.0 206.163.76.254 197 0x800000AC 0xA933 0
216.239.160.0 207.189.160.254 822 0x800000AB 0x83EA 0
216.239.167.255 206.163.76.254 197 0x800000AC 0x8449 0
216.239.168.0 207.189.160.254 824 0x80000023 0x6482 0
gw0.eug.or#
========================
gw0.pdx.or#sho ip route 207.189.191.8
% Network not in table
gw0.pdx.or#sho ip ospf database
OSPF Router with ID (206.163.76.254) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
206.163.76.254 206.163.76.254 928 0x80001B22 0xE804 3
207.189.160.254 207.189.160.254 793 0x800008F2 0xC573 2
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 207.189.160.254 793 0x8000006E 0xC552 1
198.68.7.0 207.189.160.254 793 0x80000023 0x70CE 0
198.68.19.0 207.189.160.254 793 0x80000023 0xEB47 0
198.68.20.0 207.189.160.254 793 0x80000023 0xDB57 0
198.68.22.255 207.189.160.254 793 0x800000AC 0xB7EE 0
198.106.192.0 207.189.160.254 793 0x80000023 0x88DD 0
206.163.32.0 206.163.76.254 166 0x800000A7 0x8B21 0
206.163.32.255 206.163.76.254 166 0x800000AD 0x8E15 0
206.163.34.0 206.163.76.254 166 0x800000AD 0x7829 0
206.163.35.0 206.163.76.254 166 0x800000AE 0x6B34 0
206.163.76.0 206.163.76.254 166 0x800000A9 0xB0CA 0
206.163.140.0 207.189.160.254 793 0x800000AC 0xB01B 0
206.163.152.0 207.189.160.254 793 0x80000023 0x3F0A 0
207.189.160.0 207.189.160.254 793 0x80000023 0x8C9D 0
207.189.163.0 207.189.160.254 793 0x80000023 0x8E91 0
207.189.164.0 207.189.160.254 793 0x80000023 0x839B 0
207.189.165.0 207.189.160.254 793 0x80000023 0x78A5 0
216.239.160.0 206.163.76.254 166 0x800000AC 0xA933 0
216.239.160.0 207.189.160.254 793 0x800000AB 0x83EA 0
216.239.167.255 206.163.76.254 166 0x800000AC 0x8449 0
216.239.168.0 207.189.160.254 793 0x80000023 0x6482 0
=======================
It seems very wrong to me that 207.189.191.8/30 (peer interface between 1
and 2a) doesn't show up, despite redistributing connected and static.. Any
ideas?
--Tim
=============================================
Timothy M. Wolfe CCNA, NSA
Sr. Security Engineer tim () ignw com
InfoGroup Northwest 541.485.0957 x108
=============================================
-----Original Message-----
From: Peter Stemwedel [mailto:peter () iPeer net]
Sent: Wednesday, January 24, 2001 9:29 AM
To: 'Tim Wolfe'
Subject: RE: Tricky BGP into IGP Question
are you not running iBGP on 2B?
-----Original Message-----
From: Tim Wolfe [mailto:TimW () InfoGroupNW com]
Sent: Tuesday, January 23, 2001 3:26 PM
To: 'nanog () merit edu'
Subject: Tricky BGP into IGP Question
What is the preferred way to get transit customers routing information
into
your IGP so that BGP will announce the route to it's neighbors.
1===2a===2b====3
|
4
1 is the customer, announcing to 2a, who propogates 1's route to 2b and
to
4. 2b will not announce the route to 3 as it doesn't have a route in
it's
routing table for 1's route. I was thinking about redistributing bgp
into
my igp using a route-map based on as-path filter, but that seems
somewhat
kludgy. What are you all doing to accomplish this or am I just missing
something here?
Thanks,
--Tim
=============================================
Timothy M. Wolfe CCNA, NSA
Sr. Security Engineer tim () ignw com
InfoGroup Northwest 541.485.0957 x108
=============================================
Current thread:
- Tricky BGP into IGP Question Tim Wolfe (Feb 24)
- Re: Tricky BGP into IGP Question Anne Marcel (Feb 24)
- Re: Tricky BGP into IGP Question Clayton Fiske (Feb 24)
- RE: Tricky BGP into IGP Question Barry Raveendran Greene (Feb 24)
- <Possible follow-ups>
- Re: Tricky BGP into IGP Question Danny McPherson (Feb 24)
- Re: Tricky BGP into IGP Question Paul Donner (Feb 24)
- RE: Tricky BGP into IGP Question Tim Wolfe (Feb 24)