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 <[email protected]> wrote: > I'd guess that Stephen already checked the looking-glass at: > ssh [email protected] > > 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 > <[email protected]> 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 < > > [email protected]> 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/[email protected]/message/NBQIF6L6YZEGWGY7WAHJNKQT7ISVTVAJ/ > > > > > _______________________________________________ > > NANOG mailing list > > > https://lists.nanog.org/archives/list/[email protected]/message/STGC5JQCQO7R7T7MO3C4WVB57MR2WZMY/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/5AKUSC6LPI2TFDEHUYXAA2VXJU55UUFI/
