RE: 69/8...this sucks

["Stephen J. Wilcox" <steve () telecomplete co uk>]

On Wed, 12 Mar 2003, David Luyer wrote:

> Iljitsch van Beijnum wrote:
> > On Tue, 11 Mar 2003, Owen DeLong wrote:
> >
> > > In short, it doesn't.  Longer answer, if the ISP configures 
> > > his router correctly, he can actually refuse to accept
> > > advertisements from other sessions that are longer versions
> > > of prefixes received through this session.
> >
> > How???
>
> There is a technically possible (but rather twisted) way you
> could not use the adverts, but not a way to refuse receiving
> them that I know of.

I think youre mixing up with ingress filtering by prefix list which you can 
specify prefix length on and hence ignore longer (or smaller) matches.

Steve

> Consider the connection between ISP X and ISP Y.
>
> ISP Y and is the provider who wants to null route any bogon
> traffic, even if ISP X advertises a more specific route for
> it.
>
> EBGP session between 192.168.0.1/30 and 192.168.0.2/30.
>
> ISP Y places 192.168.0.2 into VRF "X-Real".
> Also in VRF "X-Real" is 192.168.1.1
>
> Now a VRF "X-Bogon" is created containing
> 192.168.1.2 and 192.168.2.1.
>
> And finally the ISP's Default-IP-Routing-Table or other general
> internet VRF contains 192.168.2.2.
>
> 192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected.
> (for example, create virtual interfaces on a GigE representing
> each side of a pair in the relevant VRFs and then loop the
> VLANs of each pair of virtual interfaces -- is there a way
> to create two "paired" loopback interfaces to interconnect VRFs
> rather than extending to a physical connection like I always have?)
>
> 192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router
> in Default-IP-Routing-Table) communicate via IBGP route
> reflection.  Either dynamic or static routing can be used to
> ensure 192.158.1.1 and 192.168.2.2 know the way to reach each
> other.
>
> BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon
> feed, and modifies the received routes to set the next hop either
> into oblivion (eg. out a loopback with no ip unreachables set and
> a deny ip any any ACL) or to a some kind of DoS/worm tracking
> server (since almost all of this traffic will be part of some
> kind of attack or worm, and you will quite probably want to
> know about it; you can also set your default route in your
> regular network to such a server that records all traffic
> received).
>
> Policy routing is applied on interface 192.168.1.2 saying "set
> IP default next hop 192.168.2.2" and on interface 192.168.2.1
> saying "set IP default next hop 192.168.1.1".
>
> It would work.  I've done things similar to this example in a
> lab to prove they work.  I wouldn't want to let a configuration
> like this loose on the production internet, though, and anyone
> who would is probably a _Certifiable_ Cisco Internet Engineer.
>
> David.