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)