From: Cagri Yucel (cyucel@gmail.com)
Date: Mon Oct 16 2006 - 09:00:35 ART
distance bgp 20 200 255 please
This should prevent your locally generated aggregate into local RIB so
you'll continue to use default route as before.
Regards,
Cagri
On 10/15/06, alberto vargas <avargasn@yahoo.com.br> wrote:
>
> Hello all,
>
> I'm facing a problem in a lab I'm not being able to
> solve it.
>
> This lab runs OSPF, EIGRP and BGP. R3 is the an ASBR
> and is also the only way to get to EIGRP domain. So R3
> is injecting a default route into OSPF and
> redistributing OSPF into EIGRP.
>
> R4 is directly connected to R3 through a frame relay
> network and it runs both OSPF and BGP. R3 and R4 are
> in differents AS, 100 and 400 respectively. The whole
> network use subnets take from 164.1.0.0/16 block.
>
> For clarifying 164.1.45.5 is the IP address of R5
> router that receives the default route from R3 and
> announces it to R4 via an OSPF virtual link. R4 also
> receives that route from R3 but due to virtual link R4
> chooses the default route receveid from R5.
>
> Everything works fine until I configure R4 to send a
> aggregate route, 164.1.0.0/18, to its EBGP peer BB3
> whose ip address is 204.12.1.254.
>
> Following is the routing table of R4 without the
> discard route installed by the aggregate command:
> C 204.12.1.0/24 is directly connected, Ethernet1/1
> 11.0.0.0/24 is subnetted, 1 subnets
> B 11.11.11.0 [20/0] via 204.12.1.254, 00:51:51
> 164.1.0.0/16 is variably subnetted, 7 subnets, 2
> masks
> O 164.1.35.0/24 [110/128] via 164.1.45.5,
> 00:52:00, Serial0/1
> C 164.1.34.0/24 is directly connected, Serial0/0
> C 164.1.45.0/29 is directly connected, Serial0/1
> C 164.1.47.0/24 is directly connected,
> Ethernet1/0
> O 164.1.55.0/24 [110/74] via 164.1.45.5,
> 00:52:00, Serial0/1
> O 164.1.5.0/24 [110/74] via 164.1.45.5,
> 00:52:01, Serial0/1
> O 164.1.7.0/24 [110/20] via 164.1.47.7,
> 00:51:27, Ethernet1/0
> 150.1.0.0/16 is variably subnetted, 3 subnets, 2
> masks
> O 150.1.5.0/24 [110/65] via 164.1.45.5,
> 00:52:11, Serial0/1
> C 150.1.4.0/24 is directly connected, Loopback0
> O 150.1.7.7/32 [110/11] via 164.1.47.7,
> 00:51:27, Ethernet1/0
> O*E2 0.0.0.0/0 [110/1] via 164.1.45.5, 00:51:27,
> Serial0/1
>
> Following is the output of a debug ip packet when BGP
> discard route wasn't installed:
> Mar 1 00:53:15.815: IP: tableid=0, s=164.1.45.4
> (local), d=164.1.26.6 (Serial0/1), routed via FIB
> *Mar 1 00:53:15.815: IP: s=164.1.45.4 (local),
> d=164.1.26.6 (Serial0/1), len 100, sending
> *Mar 1 00:53:15.815: ICMP type=8, code=0
> *Mar 1 00:53:16.071: IP: tableid=0, s=164.1.45.4
> (local), d=164.1.26.6 (Serial0/1), routed via FIB
> *Mar 1 00:53:16.075: IP: s=164.1.45.4 (local),
> d=164.1.26.6 (Serial0/1), len 100, sending
> *Mar 1 00:53:16.079: ICMP type=8, code=0
> *Mar 1 00:53:16.319: IP: tableid=0, s=164.1.45.4
> (local), d=164.1.26.6 (Serial0/1), routed via FIB
> *Mar 1 00:53:16.323: IP: s=164.1.45.4 (local),
> d=164.1.26.6 (Serial0/1), len 100, sending
> *Mar 1 00:53:16.323: ICMP type=8, code=0
>
> Now the discard is installed as you can see:
> C 204.12.1.0/24 is directly connected, Ethernet1/1
> 11.0.0.0/24 is subnetted, 1 subnets
> B 11.11.11.0 [20/0] via 204.12.1.254, 00:47:37
> 164.1.0.0/16 is variably subnetted, 10 subnets, 3
> masks
> O 164.1.35.0/24 [110/128] via 164.1.45.5,
> 00:47:47, Serial0/1
> C 164.1.34.0/24 is directly connected, Serial0/0
> C 164.1.45.0/29 is directly connected, Serial0/1
> C 164.1.47.0/24 is directly connected,
> Ethernet1/0
> O 164.1.55.0/24 [110/74] via 164.1.45.5,
> 00:47:47, Serial0/1
> O 164.1.5.0/24 [110/74] via 164.1.45.5,
> 00:47:47, Serial0/1
> O 164.1.7.0/24 [110/20] via 164.1.47.7,
> 00:47:14, Ethernet1/0
> B 164.1.0.0/18 [200/0] via 0.0.0.0, 00:47:10,
> Null0
> B 164.1.3.0/24 [20/0] via 150.1.3.3, 00:47:10
> B 164.1.8.0/24 [20/0] via 150.1.3.3, 00:46:40
> 150.1.0.0/16 is variably subnetted, 3 subnets, 2
> masks
> O 150.1.5.0/24 [110/65] via 164.1.45.5,
> 00:47:57, Serial0/1
> C 150.1.4.0/24 is directly connected, Loopback0
> O 150.1.7.7/32 [110/11] via 164.1.47.7,
> 00:47:14, Ethernet1/0
> O*E2 0.0.0.0/0 [110/1] via 164.1.45.5, 00:47:14,
> Serial0/1
>
> Follwoing is the output of a debug ip packet when the
> discard route was installed:
> *Mar 1 00:50:57.387: IP: tableid=0, s=164.1.34.4
> (local), d=164.1.26.6 (Null0), routed via RIB
> *Mar 1 00:50:57.387: IP: s=164.1.34.4 (local),
> d=164.1.26.6 (Null0), len 100, sending
> *Mar 1 00:50:57.387: ICMP type=8, code=0
> *Mar 1 00:50:59.387: IP: tableid=0, s=164.1.34.4
> (local), d=164.1.26.6 (Null0), routed via RIB
> *Mar 1 00:50:59.391: IP: s=164.1.34.4 (local),
> d=164.1.26.6 (Null0), len 100, sending
> *Mar 1 00:50:59.395: ICMP type=8, code=0
> *Mar 1 00:51:01.387: IP: tableid=0, s=164.1.34.4
> (local), d=164.1.26.6 (Null0), routed via RIB
> *Mar 1 00:51:01.391: IP: s=164.1.34.4 (local),
> d=164.1.26.6 (Null0), len 100, sending
> *Mar 1 00:51:01.395: ICMP type=8, code=0
>
> In both debugs the ping command was issued on router
> R4.
>
> I can see that the 164.1.0.0/18 is a longest match to
> network 164.1.26.0/24 than the default route. How can
> I solve that? An possible answer is not to allow the
> discard route installation, so I ask what would the
> gurus do?
>
> Regards,
>
> Alberto
>
>
>
> _______________________________________________________
> Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular.
> Registre seu aparelho agora!
> http://br.mobile.yahoo.com/mailalertas/
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- -cagri
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:05 ART