Weird Default Route issue

[David Lee]

So i have a weird entry in my routing table that I cant figure out.  The one thing I do know is that its not supposed to be there.  Its a router off a router using the same protocol as the upstream router, BGP.   Ping and everything works, but its causing issues with trying to use another downstream router and redistribute BGP into either EIGRP or OSPF. 

Router# sh ip route

Gateway of last resort is 10.10.200.252 to network 0.0.0.0

* 0.0.0.0/32 is subnetted, 1 subnets

B* 0.0.0.0 [20/0] via 10.10.200.252

Its the default route that is being learned from BGP, but I know its not supposed to show * 0.0.0.0/32    I have some other networks using the same model routers on a completely different segment that looks correct.

GGR-C2901-02#sh ip route

Gateway of last resort is 152.181.47.41 to network 0.0.0.0

B*    0.0.0.0/0 [2/0] via 152.181.47.41, 1w1d

This router looks correct.  Both routers are only running BGP at the moment.  This one has custom Distance due to the backup WAN solution, but that shouldn't affect how the default route appears. 

It all works, its a bid odd. 

Thanks

David

[Rob Cluett]

Is there an ip route statement somewhere with the mask set to 255.255.255.255 rather than 0.0.0.0 ?

Example...

"ip route 0.0.0.0 255.255.255.255 10.10.200.252"

[Rob Cluett]

can you post the configs?

[Julio E. Moisa]

Hi 

Could you please share a screenshot, also the last route displayed has an administrative distance of 2, is that correct?

[David Lee]

Hi Julio,

Im not sure what you want me to take a screenshot of.  I also explained what the distance of 2 was for.   That is on a completely separate system not even remotely connected to the one with the oddness.  I was just logging into that system to verify that BGP wasn't being wonky there too.  the AD of 2 is for the WAN failover solution for that particular config.

[Julio E. Moisa]

Hi,

Your config looks fine, if it is not on production, you could try to refresh the route into the routing table:

clear ip route 0.0.0.0

or from the upstream router you could advertise a default route through the peering:

router bgp 7018

bgp log-neighbor-changes

no synchronization

neighbor 10.10.200.251 default-originate 

[David Lee]

Here are the upstream configs and the one is question.  The configs are vanilla outside of whats below as this is a completely new network not connected to the one that is working with no issues.

Upstream -

interface GigabitEthernet0/2

ip address 10.10.200.252 255.255.255.248

ip nat inside

duplex auto

speed auto

!

!

router bgp 7018

bgp log-neighbor-changes

no synchronization

neighbor 10.10.200.251 remote-as 7020

network 10.2.5.0 mask 255.255.255.0

network 10.3.5.0 mask 255.255.255.0

network 192.168.5.0

network 10.5.5.0 mask 255.255.255.0

network 10.10.200.248 mask 255.255.255.248

network 0.0.0.0

redistribute connected

!

ip nat inside source list 10 interface GigabitEthernet0/0 overload

ip classless

ip route 0.0.0.0 0.0.0.0 10.50.100.252

!

!

!

access-list 10 permit 192.168.0.0 0.0.255.255

access-list 10 permit 10.10.0.0 0.0.255.255

access-list 10 permit 10.100.0.0 0.0.255.255

------------------------------------------------------------------------------------------------------------

Here is the one in question

interface FastEthernet0/0

ip address 10.10.200.251 255.255.255.248

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

shutdown

!

interface Serial0/0/0

ip address 10.10.42.251 255.255.255.0

clock rate 2000000

!

interface Serial0/0/1

no ip address

clock rate 2000000

!

!

router bgp 7020

bgp log-neighbor-changes

no synchronization

neighbor 10.10.200.252 remote-as 7018

neighbor 10.10.42.252 remote-as 65000

network 10.10.200.248 mask 255.255.255.248

[Richard Burts]

I suspect that your issue is this statement in the BGP config of the uupstream router.

network 0.0.0.0

I would suggest that they should specify the mask for this network entry. When you have a network statement with no mask in BGP then BGP makes assumptions to use the default mask for that network and in this case that assumption may be causing the issue. 

HTH

Rick