Out of ideas - Comcast issue BGP peering with Tata
I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata. This is causing random destinations to drop connectivity if Comcast routes it through them. Comcast has confirmed they are advertising my block to Tata and that the RPKI is good, however when you check the Tata looking glass you can see they're not accepting it. I've tried escalating within Comcast who refuses to contact Tata as they've validated the issue is not on their end but they agree with my assessment that Tata is not accepting the prefix for some reason. I've tried multiple email for Tata support (below), but they all circle around to a helpdesk who says I do not have a circuit with them so they cannot help me. Is there anyone from Tata willing to contact me off list to help sort this out? Or anyone with ideas on specifically why other ISPs are accepting my route but not Tata? It would be greatly appreciated. Emails I've tried Corporate Helpdesk corp.helpdesk@tatacommunications.com<mailto:corp.helpdesk@tatacommunications.com> Tata Communications IP Service Support( AS-6453) IPServiceSupport@tatacommunications.com<mailto:IPServiceSupport@tatacommunications.com> IPNOC (Tata Communications - AS6453) IPNOC@tatacommunications.com<mailto:IPNOC@tatacommunications.com> lg@as6453.net<mailto:lg@as6453.net> Response from Tata: "Acknowledge your email. However, since you are not associated with TCL we would not be in a position to help you on this. Request you to contact comcast for the assistance that you are seeking from us." Response from Comcast: "This was sent back to me as not us. Basically, it's not a RADB or RPKI issue. This is being accepted and re-advertised to TATA but not being accepted on their end. But another route that we checked off of that same SUR is being advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an example of the TATA looking glass. I would suggest that you would probably need to work with other networks as to why those that are specific ones are not accepting the block but as previously mentioned it's not a RADB or RPKI issue and as a result not a Comcast issue."
I many years ago worked at Tata, responsible for their BGP, they are giving you the right answer, Comcast has to be the one contacting them, as then both sides can see what is being sent and received and can resolve this issue. -jim On Fri, Nov 17, 2023 at 10:04 AM Jamie Chetta via NANOG <nanog@nanog.org> wrote:
I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata. This is causing random destinations to drop connectivity if Comcast routes it through them. Comcast has confirmed they are advertising my block to Tata and that the RPKI is good, however when you check the Tata looking glass you can see they’re not accepting it.
I’ve tried escalating within Comcast who refuses to contact Tata as they’ve validated the issue is not on their end but they agree with my assessment that Tata is not accepting the prefix for some reason.
I’ve tried multiple email for Tata support (below), but they all circle around to a helpdesk who says I do not have a circuit with them so they cannot help me.
Is there anyone from Tata willing to contact me off list to help sort this out? Or anyone with ideas on specifically why other ISPs are accepting my route but not Tata? It would be greatly appreciated.
Emails I’ve tried
Corporate Helpdesk corp.helpdesk@tatacommunications.com
Tata Communications IP Service Support( AS-6453) IPServiceSupport@tatacommunications.com
IPNOC (Tata Communications - AS6453) IPNOC@tatacommunications.com
lg@as6453.net
Response from Tata:
“Acknowledge your email.
However, since you are not associated with TCL we would not be in a position to help you on this.
Request you to contact comcast for the assistance that you are seeking from us.”
Response from Comcast:
“This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. This is being accepted and re-advertised to TATA but not being accepted on their end. But another route that we checked off of that same SUR is being advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an example of the TATA looking glass. I would suggest that you would probably need to work with other networks as to why those that are specific ones are not accepting the block but as previously mentioned it’s not a RADB or RPKI issue and as a result not a Comcast issue.”
Comcast has to be the one contacting them
This is the correct answer. It's pretty straight forward ; Comcast needs to get with Tata, say "hey, I'm announcing prefix FOO to you, your LGs don't look like you're accepting it. Can we figure out why?" On Fri, Nov 17, 2023 at 10:43 AM jim deleskie <deleskie@gmail.com> wrote:
I many years ago worked at Tata, responsible for their BGP, they are giving you the right answer, Comcast has to be the one contacting them, as then both sides can see what is being sent and received and can resolve this issue.
-jim
On Fri, Nov 17, 2023 at 10:04 AM Jamie Chetta via NANOG <nanog@nanog.org> wrote:
I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata. This is causing random destinations to drop connectivity if Comcast routes it through them. Comcast has confirmed they are advertising my block to Tata and that the RPKI is good, however when you check the Tata looking glass you can see they’re not accepting it.
I’ve tried escalating within Comcast who refuses to contact Tata as they’ve validated the issue is not on their end but they agree with my assessment that Tata is not accepting the prefix for some reason.
I’ve tried multiple email for Tata support (below), but they all circle around to a helpdesk who says I do not have a circuit with them so they cannot help me.
Is there anyone from Tata willing to contact me off list to help sort this out? Or anyone with ideas on specifically why other ISPs are accepting my route but not Tata? It would be greatly appreciated.
Emails I’ve tried
Corporate Helpdesk corp.helpdesk@tatacommunications.com
Tata Communications IP Service Support( AS-6453) IPServiceSupport@tatacommunications.com
IPNOC (Tata Communications - AS6453) IPNOC@tatacommunications.com
lg@as6453.net
Response from Tata:
“Acknowledge your email.
However, since you are not associated with TCL we would not be in a position to help you on this.
Request you to contact comcast for the assistance that you are seeking from us.”
Response from Comcast:
“This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. This is being accepted and re-advertised to TATA but not being accepted on their end. But another route that we checked off of that same SUR is being advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an example of the TATA looking glass. I would suggest that you would probably need to work with other networks as to why those that are specific ones are not accepting the block but as previously mentioned it’s not a RADB or RPKI issue and as a result not a Comcast issue.”
This passing the buck thing was old a very long time ago. CDNs and security services are great at it too. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jamie Chetta via NANOG" <nanog@nanog.org> To: nanog@nanog.org Sent: Friday, November 17, 2023 8:17:42 AM Subject: Out of ideas - Comcast issue BGP peering with Tata I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata. This is causing random destinations to drop connectivity if Comcast routes it through them. Comcast has confirmed they are advertising my block to Tata and that the RPKI is good, however when you check the Tata looking glass you can see they’re not accepting it. I’ve tried escalating within Comcast who refuses to contact Tata as they’ve validated the issue is not on their end but they agree with my assessment that Tata is not accepting the prefix for some reason. I’ve tried multiple email for Tata support (below), but they all circle around to a helpdesk who says I do not have a circuit with them so they cannot help me. Is there anyone from Tata willing to contact me off list to help sort this out? Or anyone with ideas on specifically why other ISPs are accepting my route but not Tata? It would be greatly appreciated. Emails I’ve tried Corporate Helpdesk corp.helpdesk@tatacommunications.com Tata Communications IP Service Support( AS-6453) IPServiceSupport@tatacommunications.com IPNOC (Tata Communications - AS6453) IPNOC@tatacommunications.com lg@as6453.net Response from Tata: “ Acknowledge your email. However, since you are not associated with TCL we would not be in a position to help you on this. Request you to contact comcast for the assistance that you are seeking from us.” Response from Comcast: “ This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. This is being accepted and re-advertised to TATA but not being accepted on their end. But another route that we checked off of that same SUR is being advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an example of the TATA looking glass. I would suggest that you would probably need to work with other networks as to why those that are specific ones are not accepting the block but as previously mentioned it’s not a RADB or RPKI issue and as a result not a Comcast issue.”
Im not sure, just thinking, maybe is a thing with the /24. Is it possible to you get from Comcast maybe a /22 ?? Regards Diego From: NANOG <nanog-bounces+diefierr=cisco.com@nanog.org> on behalf of Mike Hammett <nanog@ics-il.net> Date: Friday, November 17, 2023 at 09:51 To: Jamie Chetta <jamie.chetta@ricoh-usa.com> Cc: nanog@nanog.org <nanog@nanog.org> Subject: Re: Out of ideas - Comcast issue BGP peering with Tata This passing the buck thing was old a very long time ago. CDNs and security services are great at it too. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Jamie Chetta via NANOG" <nanog@nanog.org> To: nanog@nanog.org Sent: Friday, November 17, 2023 8:17:42 AM Subject: Out of ideas - Comcast issue BGP peering with Tata I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata. This is causing random destinations to drop connectivity if Comcast routes it through them. Comcast has confirmed they are advertising my block to Tata and that the RPKI is good, however when you check the Tata looking glass you can see they’re not accepting it. I’ve tried escalating within Comcast who refuses to contact Tata as they’ve validated the issue is not on their end but they agree with my assessment that Tata is not accepting the prefix for some reason. I’ve tried multiple email for Tata support (below), but they all circle around to a helpdesk who says I do not have a circuit with them so they cannot help me. Is there anyone from Tata willing to contact me off list to help sort this out? Or anyone with ideas on specifically why other ISPs are accepting my route but not Tata? It would be greatly appreciated. Emails I’ve tried Corporate Helpdesk corp.helpdesk@tatacommunications.com<mailto:corp.helpdesk@tatacommunications.com> Tata Communications IP Service Support( AS-6453) IPServiceSupport@tatacommunications.com<mailto:IPServiceSupport@tatacommunications.com> IPNOC (Tata Communications - AS6453) IPNOC@tatacommunications.com<mailto:IPNOC@tatacommunications.com> lg@as6453.net<mailto:lg@as6453.net> Response from Tata: “Acknowledge your email. However, since you are not associated with TCL we would not be in a position to help you on this. Request you to contact comcast for the assistance that you are seeking from us.” Response from Comcast: “This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. This is being accepted and re-advertised to TATA but not being accepted on their end. But another route that we checked off of that same SUR is being advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an example of the TATA looking glass. I would suggest that you would probably need to work with other networks as to why those that are specific ones are not accepting the block but as previously mentioned it’s not a RADB or RPKI issue and as a result not a Comcast issue.”
Is your IRR and RPKI roas all squared away? On Fri, Nov 17, 2023, 8:12 AM Diego Eduardo Zorrilla Fierro (diefierr) via NANOG <nanog@nanog.org> wrote:
Im not sure, just thinking, maybe is a thing with the /24. Is it possible to you get from Comcast maybe a /22 ??
Regards
Diego
*From: *NANOG <nanog-bounces+diefierr=cisco.com@nanog.org> on behalf of Mike Hammett <nanog@ics-il.net> *Date: *Friday, November 17, 2023 at 09:51 *To: *Jamie Chetta <jamie.chetta@ricoh-usa.com> *Cc: *nanog@nanog.org <nanog@nanog.org> *Subject: *Re: Out of ideas - Comcast issue BGP peering with Tata
This passing the buck thing was old a very long time ago.
CDNs and security services are great at it too.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------
*From: *"Jamie Chetta via NANOG" <nanog@nanog.org> *To: *nanog@nanog.org *Sent: *Friday, November 17, 2023 8:17:42 AM *Subject: *Out of ideas - Comcast issue BGP peering with Tata
I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata. This is causing random destinations to drop connectivity if Comcast routes it through them. Comcast has confirmed they are advertising my block to Tata and that the RPKI is good, however when you check the Tata looking glass you can see they’re not accepting it.
I’ve tried escalating within Comcast who refuses to contact Tata as they’ve validated the issue is not on their end but they agree with my assessment that Tata is not accepting the prefix for some reason.
I’ve tried multiple email for Tata support (below), but they all circle around to a helpdesk who says I do not have a circuit with them so they cannot help me.
Is there anyone from Tata willing to contact me off list to help sort this out? Or anyone with ideas on specifically why other ISPs are accepting my route but not Tata? It would be greatly appreciated.
Emails I’ve tried
Corporate Helpdesk corp.helpdesk@tatacommunications.com
Tata Communications IP Service Support( AS-6453) IPServiceSupport@tatacommunications.com
IPNOC (Tata Communications - AS6453) IPNOC@tatacommunications.com
lg@as6453.net
Response from Tata:
“Acknowledge your email.
However, since you are not associated with TCL we would not be in a position to help you on this.
Request you to contact comcast for the assistance that you are seeking from us.”
Response from Comcast:
“This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. This is being accepted and re-advertised to TATA but not being accepted on their end. But another route that we checked off of that same SUR is being advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an example of the TATA looking glass. I would suggest that you would probably need to work with other networks as to why those that are specific ones are not accepting the block but as previously mentioned it’s not a RADB or RPKI issue and as a result not a Comcast issue.”
On Fri, 17 Nov 2023 at 15:17, Jamie Chetta via NANOG <nanog@nanog.org> wrote:
I am out of ideas on how to get this fixed. Long story short I am a customer of Comcast and am advertising my own /24 block I own through them. Comcast of course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just fine, except Tata.
Why don't you share the exact prefix so people can actually look into it? Tata is doing some strict filtering [1] at least for customers (but maybe for peers as well), so if you only rely on non-authoritative registries for recent objects, this may be the reason:
Special note, deprecation of non-authoritative registries
Please note that 'route' and 'route6' objects created after 2023-Aug-15 in non-authoritative registries like RADB, NTTCOM, ALTDB won't be processed. It is recommended to create RPKI ROA objects instead. In rare cases if that's not possible, 'route' and 'route6' must be created in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br or IDNIC.
cheers [1] https://lg.as6453.net/doc/cust-routing-policy.html
Special note, deprecation of non-authoritative registries
Please note that 'route' and 'route6' objects created after 2023-Aug-15 in non-authoritative registries like RADB, NTTCOM, ALTDB won't be processed. It is recommended to create RPKI ROA objects instead. In rare cases if that's not possible, 'route' and 'route6' must be created in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br or IDNIC.
So basically, a giant #@*&$^ you to any legacy holders that aren’t paying an RIR. Great!! Thanks, Tata
Hi friend, Any idea how many segments are in routing table which are still not part of RIR holder ship ? Regards, Gaurav Kansal
On 22-Nov-2023, at 07:40, nanog@nanog.org wrote:
Special note, deprecation of non-authoritative registries
Please note that 'route' and 'route6' objects created after 2023-Aug-15 in non-authoritative registries like RADB, NTTCOM, ALTDB won't be processed. It is recommended to create RPKI ROA objects instead. In rare cases if that's not possible, 'route' and 'route6' must be created in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br or IDNIC.
So basically, a giant #@*&$^ you to any legacy holders that aren’t paying an RIR.
Great!!
Thanks, Tata
Depends on your definition of “RIR holder ship”. ALL (legitimate) prefixes are delegated/registered by an RIR at some level. However, some of them are non-contract and/or non-paid. APNIC is, I believe, the only RIR that eliminated all non-contract registrants. I’m not sure of the exact situation in LACNIC or AFRINIC, but I believe it is generally the same as RIPE and ARIN. Non-contract (for lack of a better term) prefixes cannot get IRR or RPKI services from their RIRs, and usually don’t come with membership (voting rights). Otherwise, they are basically treated the same as other registrations, though they also don’t pay fees. Owen
On Nov 21, 2023, at 22:10, Gaurav Kansal <gaurav.kansal@nic.in> wrote:
Hi friend,
Any idea how many segments are in routing table which are still not part of RIR holder ship ?
Regards, Gaurav Kansal
On 22-Nov-2023, at 07:40, nanog@nanog.org wrote:
Special note, deprecation of non-authoritative registries
Please note that 'route' and 'route6' objects created after 2023-Aug-15 in non-authoritative registries like RADB, NTTCOM, ALTDB won't be processed. It is recommended to create RPKI ROA objects instead. In rare cases if that's not possible, 'route' and 'route6' must be created in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br or IDNIC.
So basically, a giant #@*&$^ you to any legacy holders that aren’t paying an RIR.
Great!!
Thanks, Tata
participants (9)
-
Diego Eduardo Zorrilla Fierro (diefierr) -
Gaurav Kansal -
Jamie Chetta -
jim deleskie -
Lukas Tribus -
Mike Hammett -
owen＠Delong.com -
TJ Trout -
Tom Beecher