Could someone from Cogent contact me off-list? We are having an issue with one of our downstream customers who is multi-homed to another carrier. The end customer is advertising their prefix to both us and the other carrier. Both us and the other carrier peer with 174. However, if the prefix is preferred through us and the outbound traffic flows over the other carrier it is dropped. We suspect uRPF-strict on the other carriers Cogent link. We are working together with the other carrier and have a ticket open the help desk seem to be confused. Any help would be appreciated. Thanks
Ben Russell
Senior Network Engineer
Stratus Networks
(309)370-3174
[logo]
Time for someone to bake them a bcp38 cake ....
I am all for people deploying BCP38, but from the original email this is definitely not a cause for celebration. BCP38 should be used against single homed customers only if you're doing it by using uRPF. Otherwise extreme care needs to be taken to make sure traffic isn't dropped because uRPF does the wrong thing (like it seems in this case).
Hi Mike,
Doesn't loose mode URPF allow packets from anything that exists in the
routing table regardless of source? Seems just about worthless. You're
allowing the site to spoof anything in the routing table which is NOT
BCP38.
Strict mode URPF down paths guaranteed to be single-homed. Manually
configure allowed sources and announcements for BGP-talking customers.
Regards,
Bill Herrin
Give me a contact and I might send enough cupcakes for most of their engineers =D
PS: Progression pain is still progression.
Doesn't loose mode URPF allow packets from anything that exists in the
routing table regardless of source? Seems just about worthless. You're
allowing the site to spoof anything in the routing table which is NOT
BCP38.
Correct. uRPF/loose is pretty undesirable, what you get for the
premium you pay, it's rarely justifiable.
Strict mode URPF down paths guaranteed to be single-homed. Manually
configure allowed sources and announcements for BGP-talking customers.
JunOS offers 'strict feasible', which would allow packet if there is
some route pointing to that interface, not necessarily best.
But even that would not be well received by customers, some do TE by
omitting advertising prefix out, yet send traffic out without any
specific policy, so you may receive traffic from prefix they are
allowed to advertise but they do not.
I've previously used in JunOS same prefix-list for BGP and firewall
filter with good success, but unfortunately sometimes even telling
what prefixes might be behind specific BGP session/interface is not
trivial.
Well not completely useless. BCP will still drop BOGONs at the edge before they leak into your network.
Assuming you don't use them in your own infra. And cost of RPF is lot
higher than cost of ACL. Them being entirely static entities they
should be in your edgeACL. The only real justification for loose RPF
is source based blackholing.
Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely. And if you’re using RFC1918 space in your global routing table, then thats another fiasco you’ll have to deal with. Managing ACL’s for customer routes has far more overhead (and cost, ie: time, human error, etc) than to just use RPF on an edge port. I believe the OP was talking about multi-homed, in that case if run a tight ship in your network RPF loose is probably a good choice. It at least gives you an easy way to not accept total trash at the edge.
>
>> Well not completely useless. BCP will still drop BOGONs at the edge
>> before they leak into your network.
>
> Assuming you don't use them in your own infra. And cost of RPF is lot
> higher than cost of ACL. Them being entirely static entities they
> should be in your edgeACL. The only real justification for loose RPF
> is source based blackholing.
Well, if you are using public IP addresses for infra you are violating
your RIR’s policy more than likely.
There may be some miscommunication here or confusion on terminology
used. But for instance using public, globally unique addresses for your
router's loopback addresses, or router-to-router linknets is fine and
not a violation.
And if you’re using RFC1918 space in your global routing table, then
thats another fiasco you’ll have to deal with.
Then don't do that! 
Managing ACL’s for customer routes has far more overhead (and cost,
ie: time, human error, etc) than to just use RPF on an edge port. I
believe the OP was talking about multi-homed, in that case if run a
tight ship in your network RPF loose is probably a good choice. It at
least gives you an easy way to not accept total trash at the edge.
I am not sure what "RPF loose" offers that can't be done with a static
general purpose edge ACL can't offer to protect your infrastructure and
deny obvious bogons.
Kind regards,
Job
Really surprised that AS174 put in place any anti-spoofing.
We are bgp-transit customer of CGNT and received traffic originated from
RFC1918 on our public p2p link with them
Indeed… your infrastructure, your choices (good or bad 
/John