RE: 69/8...this sucks -- Centralizing filtering..
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
It would be nice if vendors had a variant to (in cisco terms) ip verify unicast reverse-path that would work in asymmetrical networks. If you only have a single link to the internet, the command works well, but then why would you ever run bgp for a single uplink?
-Jack
From: "McBurnett, 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
On Mon, Mar 10, 2003 at 01:39:26PM -0600, Jack Bates wrote:
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?
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. -- Russell Heilling http://www.ccie.org.uk PGP: finger russellh@bela.homeunix.net
participants (3)
-
Jack Bates
-
McBurnett, Jim
-
Russell Heilling