Mailing List Archive

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.”

>
> 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.”
>>
>

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
>>
>