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 .... On Aug 16, 2017 4:04 PM, "Ben Russell" <brussell@stratusnet.com> wrote:
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]
On Thu, 17 Aug 2017, chris wrote:
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). -- Mikael Abrahamsson email: swmike@swm.pp.se
Strict vs. loose. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mikael Abrahamsson" <swmike@swm.pp.se> To: "chris" <tknchris@gmail.com> Cc: "NANOG list" <nanog@nanog.org> Sent: Thursday, August 17, 2017 1:27:17 AM Subject: Re: Cogent BCP-38 On Thu, 17 Aug 2017, chris wrote:
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). -- Mikael Abrahamsson email: swmike@swm.pp.se
On Thu, Aug 17, 2017 at 7:35 AM, Mike Hammett <nanog@ics-il.net> wrote:
Strict vs. loose.
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 -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 17 August 2017 at 16:11, William Herrin <bill@herrin.us> wrote:
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. -- ++ytti
On Aug 17, 2017, at 9:11 AM, William Herrin <bill@herrin.us> wrote:
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.
Well not completely useless. BCP will still drop BOGONs at the edge before they leak into your network. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/
On 29 August 2017 at 03:38, Robert Blayzor <rblayzor.bulk@inoc.net> wrote:
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. -- ++ytti
On 29 August 2017 at 03:38, Robert Blayzor <rblayzor.bulk@inoc.net> wrote:
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.
-- ++ytti
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. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/
Hi,
Op 29 aug. 2017, om 15:29 heeft Rob Evans <internetplumber@gmail.com> het volgende geschreven:
Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely.
[Citation needed.] :)
I am pretty confident that I know those policies well enough to say that you won't find any ;) Cheers, Sander
On 30 Aug 2017, at 6:38 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi,
Op 29 aug. 2017, om 15:29 heeft Rob Evans <internetplumber@gmail.com> het volgende geschreven:
Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely.
[Citation needed.] :)
I am pretty confident that I know those policies well enough to say that you won't find any ;)
Indeed… your infrastructure, your choices (good or bad ;-) /John
On Tue, Aug 29, 2017 at 08:41:12AM -0400, Robert Blayzor wrote:
On 29 August 2017 at 03:38, Robert Blayzor <rblayzor.bulk@inoc.net> wrote:
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
Give me a contact and I might send enough cupcakes for most of their engineers =D PS: Progression pain is still progression. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 08/17/17 02:02, chris wrote:
Time for someone to bake them a bcp38 cake ....
On Aug 16, 2017 4:04 PM, "Ben Russell" <brussell@stratusnet.com> wrote:
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]
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 On 15.08.2017 17:36, Ben Russell wrote:
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]
participants (13)
-
Alain Hebert -
Ben Russell -
chris -
Job Snijders -
John Curran -
marcel.duregards＠yahoo.fr -
Mikael Abrahamsson -
Mike Hammett -
Rob Evans -
Robert Blayzor -
Saku Ytti -
Sander Steffann -
William Herrin