So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer. We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit. The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?). no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled. Cheers, Stephen Griffin
This seems like something to address with your Comcast contacts? What you're saying sounds right, but we have no knowledge of your contractual obligations. On Wed, May 14, 2025 at 11:09 AM Stephen Griffin via NANOG < nanog@lists.nanog.org> wrote:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6...
Hi Stephen It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement. HTH Brian Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan> Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6...
I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question. yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable. I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ? -chris On Wed, May 14, 2025 at 11:31 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan>
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/STGC5JQC...
No export is pretty obviously the wrong choice here, what you want is announce to customers only. -----Original Message----- From: Christopher Morrow via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 9:41 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Christopher Morrow <morrowc.lists@gmail.com> Subject: Re: Xfinity on Campus I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question. yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable. I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ? -chris On Wed, May 14, 2025 at 11:3 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan>
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ NBQIF6L6YZEGWGY7WAHJNKQT7ISVTVAJ/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST GC5JQCQO7R7T7MO3C4WVB57MR2WZMY/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZN...
I think Brian may have touched on this earlier in the thread, but a dirty way to accomplish would be sending to AS7922 your de-aggregated /24s with the noexport community. Send your aggregates(> /24) to your transit provider(s). If a AS7922 customer is default-free, they'd find you through your transit, if they default through AS7922, they reach you there. Path asymmetry is still a concern on both sides though. I concur with the earlier statement about resolving through your customer rep. AS7922+Customers feels more natural while still maintaining their ability to later sell you transit. Eric ________________________________ From: John van Oppen via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 2:24 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; John van Oppen <john@vanoppen.com> Subject: RE: Xfinity on Campus No export is pretty obviously the wrong choice here, what you want is announce to customers only. -----Original Message----- From: Christopher Morrow via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 9:41 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Christopher Morrow <morrowc.lists@gmail.com> Subject: Re: Xfinity on Campus I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question. yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable. I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ? -chris On Wed, May 14, 2025 at 11:3 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan>
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ NBQIF6L6YZEGWGY7WAHJNKQT7ISVTVAJ/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST GC5JQCQO7R7T7MO3C4WVB57MR2WZMY/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZN... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5JX56YQM...
I've got one of these circuits too, and it's very strange how they handle them internally. From Comcast's point of view, these circuits don't even exist! They're not configured the same way as their "customers" circuits are. That means, calling for support for them is next to impossible... The goal of the circuit is to just provide IPTV traffic and nothing else. But, as you've been suggesting, you can adjust the BGP communities to use it for other purposes, such as advertising to their customers within their AS or even using the circuit for transit... I'd caution against this, as the commit rate is fairly low from what I've experienced, but it does work. -- Bryan Ward Lead Network Engineer Dartmouth College Network Services -----Original Message----- From: Eric C. Miller via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 4:00 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Eric C. Miller <eric@ericheather.com> Subject: Re: Xfinity on Campus I think Brian may have touched on this earlier in the thread, but a dirty way to accomplish would be sending to AS7922 your de-aggregated /24s with the noexport community. Send your aggregates(> /24) to your transit provider(s). If a AS7922 customer is default-free, they'd find you through your transit, if they default through AS7922, they reach you there. Path asymmetry is still a concern on both sides though. I concur with the earlier statement about resolving through your customer rep. AS7922+Customers feels more natural while still maintaining their ability to later sell you transit. Eric ________________________________ From: John van Oppen via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 2:24 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; John van Oppen <john@vanoppen.com> Subject: RE: Xfinity on Campus No export is pretty obviously the wrong choice here, what you want is announce to customers only. -----Original Message----- From: Christopher Morrow via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 9:41 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Christopher Morrow <morrowc.lists@gmail.com> Subject: Re: Xfinity on Campus I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question. yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable. I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ? -chris On Wed, May 14, 2025 at 11:3 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan>
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ NBQIF6L6YZEGWGY7WAHJNKQT7ISVTVAJ/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST GC5JQCQO7R7T7MO3C4WVB57MR2WZMY/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZN... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5JX56YQM... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YK4AYYV7...
Jason from Comcast here… If there are other things you think are valuable to do with these connections or would like them configured in a different way – we’re all ears. Just email Tony (cc’d) and I off-list – and others reading on NANOG using this service are welcome to do the same. Have a nice weekend, Jason From: Bryan Ward via NANOG <nanog@lists.nanog.org> Date: Thursday, May 15, 2025 at 15:20 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>, Bryan Ward <Bryan.Ward@dartmouth.edu> Subject: RE: Xfinity on Campus I've got one of these circuits too, and it's very strange how they handle them internally. From Comcast's point of view, these circuits don't even exist! They're not configured the same way as their "customers" circuits are. That means, calling for support for them is next to impossible... The goal of the circuit is to just provide IPTV traffic and nothing else. But, as you've been suggesting, you can adjust the BGP communities to use it for other purposes, such as advertising to their customers within their AS or even using the circuit for transit... I'd caution against this, as the commit rate is fairly low from what I've experienced, but it does work. -- Bryan Ward Lead Network Engineer Dartmouth College Network Services -----Original Message----- From: Eric C. Miller via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 4:00 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Eric C. Miller <eric@ericheather.com> Subject: Re: Xfinity on Campus I think Brian may have touched on this earlier in the thread, but a dirty way to accomplish would be sending to AS7922 your de-aggregated /24s with the noexport community. Send your aggregates(> /24) to your transit provider(s). If a AS7922 customer is default-free, they'd find you through your transit, if they default through AS7922, they reach you there. Path asymmetry is still a concern on both sides though. I concur with the earlier statement about resolving through your customer rep. AS7922+Customers feels more natural while still maintaining their ability to later sell you transit. Eric ________________________________ From: John van Oppen via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 2:24 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; John van Oppen <john@vanoppen.com> Subject: RE: Xfinity on Campus No export is pretty obviously the wrong choice here, what you want is announce to customers only. -----Original Message----- From: Christopher Morrow via NANOG <nanog@lists.nanog.org> Sent: Wednesday, May 14, 2025 9:41 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Christopher Morrow <morrowc.lists@gmail.com> Subject: Re: Xfinity on Campus I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question. yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable. I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ? -chris On Wed, May 14, 2025 at 11:3 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://urldefense.com/v3/__https://www.cdlan.it/*__;Lw!!CQl3mcHX2A!Cywp7UeJ... > | [image: CDLAN SPA - LinkedIn] <https://urldefense.com/v3/__https://it.linkedin.com/company/cdlan__;!!CQl3mc... >
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaOxxeKHA$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaOxxeKHA$> GC5JQCQO7R7T7MO3C4WVB57MR2WZMY/
_______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZNZ6RC7FJH2IUFUHVYDWGIXHZP/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaN_fYlsA$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZNZ6RC7FJH2IUFUHVYDWGIXHZP/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaN_fYlsA$> _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5JX56YQMCC2KJFM5PJHML4EIALGFKS4D/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbcl8fnbw$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5JX56YQMCC2KJFM5PJHML4EIALGFKS4D/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbcl8fnbw$> _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YK4AYYV7KNCWQ6JR4UVBQXEKVVRXIEET/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbfnR5MsQ$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YK4AYYV7KNCWQ6JR4UVBQXEKVVRXIEET/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbfnR5MsQ$> _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/26SNFNKCYLWKCANBE34FL7JL6B24H72R/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjb0ltAjrQ$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/26SNFNKCYLWKCANBE34FL7JL6B24H72R/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjb0ltAjrQ$>
Hey Jason and Tony, thanks for chiming in. After following up with my team, we ended up getting all sorted out. Originally, nobody my colleague spoke with could find the circuit or figure out how to route the support request. After contacting our account manager, everything ended up OK. He provided us with the circuit IDs and support contact info we needed. Aside from the campus TV service, we have about 2 dozen locations with Comcast CBCI service where we provide SDWAN support. We also have hundreds of work-from-home users with Xfinity home internet. Having their traffic reach the main campus network via this circuit is great. It’s better than having the traffic go out to another provider and then back to our network. Based on Stephen’s original question about sending the no-export community, I don’t know if having customer reachability was originally intended for these circuits, but it does work and I hope it can continue to work that way. It seems like an all-around good thing for your customers. -- Bryan Ward Lead Network Engineer Dartmouth College Network Services bryan.ward@dartmouth.edu<mailto:bryan.ward@dartmouth.edu> Scheduling a meeting? I prefer Zoom. From: Livingood, Jason <Jason_Livingood@comcast.com> Sent: Friday, May 16, 2025 1:56 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Stephen Griffin <pktslngr@gmail.com>; Bryan Ward <Bryan.Ward@dartmouth.edu>; Tauber, Tony <Tony_Tauber@comcast.com> Subject: Re: Xfinity on Campus Jason from Comcast here… If there are other things you think are valuable to do with these connections or would like them configured in a different way – we’re all ears. Just email Tony (cc’d) and I off-list – and others reading on NANOG using this service are welcome to do the same. Have a nice weekend, Jason From: Bryan Ward via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Date: Thursday, May 15, 2025 at 15:20 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Stephen Griffin <pktslngr@gmail.com<mailto:pktslngr@gmail.com>>, Bryan Ward <Bryan.Ward@dartmouth.edu<mailto:Bryan.Ward@dartmouth.edu>> Subject: RE: Xfinity on Campus I've got one of these circuits too, and it's very strange how they handle them internally. From Comcast's point of view, these circuits don't even exist! They're not configured the same way as their "customers" circuits are. That means, calling for support for them is next to impossible... The goal of the circuit is to just provide IPTV traffic and nothing else. But, as you've been suggesting, you can adjust the BGP communities to use it for other purposes, such as advertising to their customers within their AS or even using the circuit for transit... I'd caution against this, as the commit rate is fairly low from what I've experienced, but it does work. -- Bryan Ward Lead Network Engineer Dartmouth College Network Services -----Original Message----- From: Eric C. Miller via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Wednesday, May 14, 2025 4:00 PM To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Stephen Griffin <pktslngr@gmail.com<mailto:pktslngr@gmail.com>>; Eric C. Miller <eric@ericheather.com<mailto:eric@ericheather.com>> Subject: Re: Xfinity on Campus I think Brian may have touched on this earlier in the thread, but a dirty way to accomplish would be sending to AS7922 your de-aggregated /24s with the noexport community. Send your aggregates(> /24) to your transit provider(s). If a AS7922 customer is default-free, they'd find you through your transit, if they default through AS7922, they reach you there. Path asymmetry is still a concern on both sides though. I concur with the earlier statement about resolving through your customer rep. AS7922+Customers feels more natural while still maintaining their ability to later sell you transit. Eric ________________________________ From: John van Oppen via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Wednesday, May 14, 2025 2:24 PM To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Stephen Griffin <pktslngr@gmail.com<mailto:pktslngr@gmail.com>>; John van Oppen <john@vanoppen.com<mailto:john@vanoppen.com>> Subject: RE: Xfinity on Campus No export is pretty obviously the wrong choice here, what you want is announce to customers only. -----Original Message----- From: Christopher Morrow via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Wednesday, May 14, 2025 9:41 AM To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Stephen Griffin <pktslngr@gmail.com<mailto:pktslngr@gmail.com>>; Christopher Morrow <morrowc.lists@gmail.com<mailto:morrowc.lists@gmail.com>> Subject: Re: Xfinity on Campus I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net<mailto:rviewsxr@route-server.newyork.ny.ibone.comcast.net> and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question. yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable. I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ? -chris On Wed, May 14, 2025 at 11:3 AM Brian Turnbow via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://urldefense.com/v3/__https://www.cdlan.it/*__;Lw!!CQl3mcHX2A!Cywp7UeJ... <https://urldefense.com/v3/__https:/www.cdlan.it/*__;Lw!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjYSGRnlSQ$%20> > | [image: CDLAN SPA - LinkedIn] <https://urldefense.com/v3/__https://it.linkedin.com/company/cdlan__;!!CQl3mc... <https://urldefense.com/v3/__https:/it.linkedin.com/company/cdlan__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjYGuaqG6w$%20> >
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
_______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaOxxeKHA$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ST__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaOxxeKHA$> GC5JQCQO7R7T7MO3C4WVB57MR2WZMY/
_______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZNZ6RC7FJH2IUFUHVYDWGIXHZP/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaN_fYlsA$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6KG5YOZNZ6RC7FJH2IUFUHVYDWGIXHZP/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjaN_fYlsA$> _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5JX56YQMCC2KJFM5PJHML4EIALGFKS4D/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbcl8fnbw$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5JX56YQMCC2KJFM5PJHML4EIALGFKS4D/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbcl8fnbw$> _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YK4AYYV7KNCWQ6JR4UVBQXEKVVRXIEET/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbfnR5MsQ$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YK4AYYV7KNCWQ6JR4UVBQXEKVVRXIEET/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjbfnR5MsQ$> _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/26SNFNKCYLWKCANBE34FL7JL6B24H72R/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjb0ltAjrQ$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/nanog@lists.nanog.org/message/26SNFNKCYLWKCANBE34FL7JL6B24H72R/__;!!CQl3mcHX2A!Cywp7UeJolghnl4dl2gNpoJ8R93mv7FvLnBWvBa64tdXKRK3FCrw_XaaK0db6DtWXQUICljwHzt9ImMkFjb0ltAjrQ$>
Hi Chris! Yes, you are correct, I did look at multiple locations including another Comcast customer. :) As was mentioned elsewhere, this is only an issue if the advertised routes are prover-independent aggregates. If the networks are deaggregated, this becomes less of an issue, but that poses its own challenges, especially if networks are (effectively) not able to be deaggregated. It is also a bit of an operational chore, for both sides. In any event, I'm talking with 7922 under separate cover, but I wanted to respond to my esteemed former colleague. :) Stephen On Wed, May 14, 2025 at 12:40 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net
and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question.
yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable.
I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ?
-chris
On Wed, May 14, 2025 at 11:31 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to
You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan>
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to
BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means
you. their that
billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/STGC5JQC...
On Tue, May 20, 2025 at 3:54 PM Stephen Griffin <pktslngr@gmail.com> wrote:
Hi Chris!
howdy! :) I'm glad to see you (even over email :) )
Yes, you are correct, I did look at multiple locations including another Comcast customer. :)
I figured as much... :)
As was mentioned elsewhere, this is only an issue if the advertised routes are prover-independent aggregates. If the networks are deaggregated, this becomes less of an issue, but that poses its own challenges, especially if networks are (effectively) not able to be deaggregated. It is also a bit of an operational chore, for both sides.
In any event, I'm talking with 7922 under separate cover, but I wanted to respond to my esteemed former colleague. :)
awesome, I'm glad livinggood / et-al are helping out. Ideally this is making things better for you AND other folks :) -chris
Stephen
On Wed, May 14, 2025 at 12:40 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
I'd guess that Stephen already checked the looking-glass at: ssh rviewsxr@route-server.newyork.ny.ibone.comcast.net
and validated that the prefix(s) in question are marked no-export... I suspect that a university also brings their own IP and ASN to the party, so seeing which prefixes have which communities is also something Stephen's done before asking the original question.
yea... we can't (unless we are also comcast-campus-customers) know the contract particulars, but the question at the end seems reasonable.
I'd suspect the overall assumption in the relationship is that the prefixes seen on 7922 from the neighbors are equality visible to all folks that default to comcast's network? perhaps this is a situation where: "access to the comcast eyeball set" is the goal of the relationship not 'access to ALL comcast customers' ?
-chris
On Wed, May 14, 2025 at 11:31 AM Brian Turnbow via NANOG <nanog@lists.nanog.org> wrote:
Hi Stephen
It really depends on the network you are advertising. Say for example you are advertising a /24 or /48 that is part of a block being advertised directly by 7922, or maybe the university's AS. In this case even without announcing your netblock outside of 7922 they will still be receiving the traffic via their announcement. so no blackholing and traffic would still be coming in from the customers to you. You can check this via looking glasses /route servers etc Your logic would apply only to a unique netblock that is covered by another announcement.
HTH Brian
Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan>
Il giorno mer 14 mag 2025 alle ore 17:09 Stephen Griffin via NANOG < nanog@lists.nanog.org> ha scritto:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/STGC5JQC...
I think the question is for what purpose/reason Comcast offers you this connection, it sounds like it may have downsides or side effects in practice, but I have a suspicion Comcast offers this in order to help with performance and routing from the students connections to the university systems, and as residential type users they are covered by the routing policy they require you to use, so it accomplishes the goal they set out to do, make connections between Xfinity on Campus users at your university and the university's own systems fast and cheap for them to handle. I'm not sure why you say this is configured like a normal customer, I assume that's in regards to other aspects of the setup, as normal customer would propagate routes in more directions than peering, not less, but it may also tie back into the why, the team wanting to sell Xfinity on Campus wants connections from students to the university to be fast and cheap to handle and so adds this to that offering to help with that, but they are the customer facing team, they can only set up versions of customer side links, not peering or other types of links. Again, all pure speculation, but I suspect it is driven by the goal and reason why they bundle this extra connection for you, and given it's not as transit for you as an incentive to sign up (given the no-export), I suspect it's something like what I'm guessing here. On 5/14/2025 11:08 AM, Stephen Griffin via NANOG wrote:
So, I currently work for a university that offers Xfinity on Campus for our students. As part of that, we receive essentially peering.. with a twist... it is actually configured more like a normal customer.
We're required to send 7922:999, which is essentially 7922's no-export. However, 7922:888 (7922+customers), seems like the better choice, while still respecting the goal of not providing transit.
The former makes it such that 7922 doesn't advertise our prefixes to their BGP customers, which can lead to blackholes if their customer is default-free and their other provider(s) have an outage, or if the customer is doing link (but not provider) redundancy with BGP. It also means that billable traffic from xfinity customers to us is actually driven away from 7922, which would seem to not be in 7922's best interest (maybe folks no longer bill on usage?).
no-export and its ilk just seems like the wrong choice in nearly every case, but I thought I would check myself with the assembled.
Cheers, Stephen Griffin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NBQIF6L6...
participants (9)
-
Brian Turnbow -
Bryan Ward -
Christopher Morrow -
Eric C. Miller -
Glenn McGurrin -
John van Oppen -
Livingood, Jason -
Ross Tajvar -
Stephen Griffin