Le 2018-03-07 16:19, Saku Ytti a écrit :
Hey,
How would this work?
ISP1--ISP2---ISP3 | | +-------ISP4-----+
In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4
- ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4
ISP1 will receive traffic from ISP3 through ISP2, and that is not in the eBGP session, so prefix gets dropped.
Internet is symmetric and people don't advertise consistently, so while maybe undesirable above stuff does happen. It's not obvious to me what this eBGP-routes-in-VRF and RPF-to-VRF would solve, which use case does it address which is not addressed by existing tooling.
Internet is not symmetric ;) My problem is more simple : I'm multihomed, so I cannot use uRPF strict mode, because my traffic is not symetric. Prepend can help, but that obviously not the way of doing TE for inbound traffic, expect if you love crappy design or you multihomed is just under 10 peerings. Loose mode is not useful, because of so many parameters, default route, local-pref / med inside the network, which lead to asymetrical path. So routes not inserted in FIB. So uRPF strict mode not possible. But in loose mode, because even Tier1 are not doing any BCP 38 filters (tested and verified for all least 3 Tier1), ACL or prefix list (that's not the point of BGP hijack here), I received UDP spoofed traffic from routes I don't learned on this port. By in case my router has 2 ports, one with Level3, one with Cogent, uRPF loose mode will look at the FIB (so for all ports), not one where the packet is coming from and the BGP table facing this port + BGP table. This is exactly my idea : why should I allowed uRPF passing traffic from routes not learned on this port ?? Why if I have Cogent + Level3 and I denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get spoofed traffic from Level3 ranges over Cogent peering port ? That's just silly this kind of mode doesn't exist in uRPF ... I'm aware it's due to hardware limitation, because uRPF look into FIB, not BGP Table or RIB, but that could help denying spoofed traffic that comes over transit tier 1 because the BCP38 to the downstreams are not in place, or not automatic (I'm still thinking why Level3 as an IRR and do use it for filtering downstreams ...)
There is much cheaper feature which has worked for decades which applies better to this problem. While you generate list of prefixes ISP2 COULD announce to you, that includes the prefix ISP3 is NOT announcing, but COULD. The same prefix-list you use for BGP announcements use in your ACL.
Yeah agreee, but not usable and programmable regarding huge upstreams values (over 100, I know hw even for smaller values that will say "my ASIC is limited man").
On 6 March 2018 at 23:16, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote: Le 2018-03-06 19:39, Barry Greene a écrit :
On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) <list-nanog@beufa.net> wrote: Hope one day the 3rd mode of uRPF will be something else than a plan ... uRPF is not very usefull when multi homed. And as far as I know, multi homed networks are increasing as fast as PNI development ;) This was working microcode code when I left in 2008. Several operators tested, but none deployed (no pushing or pulling).
Yep, but saw only reference of it, but no real CLI implementation (especially on Cisco), so I guess it's not a killer feature to sell routers ;) In 2005 : https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf "A third phase is currently under way that will create a way to have strict enforcement of the uRPF check on individual ISP-ISP edges. Here, external BGP (eBGP) peer sessions will send specific prefixes to a dedicated Virtual routing and forwarding (VRF) table. This will allow uRPF to query the VRF table that contains all the routes for that specific eBGP peering session over the interface, thus verifying (authorizing) the source addresses of packets matching the advertised routes from the peered ISP" That's obviously not so sexy, but I guess the problem is on hardware performance, as the prefer method should to have a look on BGP tables, and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ? -- FABIEN VINCENT _@beufanet_ -- FABIEN VINCENT _@beufanet_