I saw it version of this earlier:
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip route clueless
No seriously..
What if that customer has a VPN design with a dial backup behind their firewall.
Using BGP to suck down a default route from the provider,
when that default route goes away, then the internal router initiates the dial
backup solution to the remote network.
They should not be sending out any BGP routes though..
But.. See example above...
OR
They are in the process of preparing for Multi-homeing and just
have not got it up yet... You know one provider is toiling with the
T-1 facility FOC etc..
Sure this is somewhat unusual, but I have seen it, and corrected it...
Jim
No seriously..
What if that customer has a VPN design with a dial backup behind their
firewall.
Using BGP to suck down a default route from the provider,
when that default route goes away, then the internal router initiates the
dial
backup solution to the remote network.
They should not be sending out any BGP routes though..
But.. See example above...
<snip other method>
Sure this is somewhat unusual, but I have seen it, and corrected it...
Oh, I agree that there are times when BGP is used in a single uplink
scenario, but it is not common. However, someone pointed me to ip verify
unicast source reachable-via any which seems to be available on some of the
cisco Service provider releases. It's an interesting concept and I'm itching
to play with it. If you aren't in my routing table, then why accept the IP
address?
-Jack
I've been using this method to do "loose source verification" for a while
now, and it's certainly better than nothing, but it doesn't really do as
much as it should when you only receive a partial table from a peer. I've
been toying with the idea of supporting strict reverse path verification
on peering links by using vrfs. It works really well in the Lab, but
migrating the whole network into an MPLS VPN just to get some extra
source filtering ability seems a little extreme to me for some reason...
It'd work really well if Cisco allowed the global table as a vrf
import/export target though.