Re: VDSL
We bond 8 VDSL2 pairs together, so getting 500Mbps is easily possible if they are close to the DSLAM. On Fri, Oct 18, 2019 at 5:28 PM Ryland Kremeier wrote: > We provide between 250Mb/s and 1Gb/s fiber-to-the-home services to all our > subscribers. We do not use VDSL. > > I personally do not have our services in my area yet as I live at the > furthest possible point to which we will expand. So until then I use > Centurylink. > > > > *From:* Matt Harris > *Sent:* Friday, October 18, 2019 9:08 AM > *To:* Ryland Kremeier > *Cc:* Rod Beck ; Nanog@nanog.org > *Subject:* Re: VDSL > > > > On Fri, Oct 18, 2019 at 8:46 AM Ryland Kremeier < > rkreme...@barryelectric.com> wrote: > > Can confirm. Currently on VDSL in rural Missouri, speed is capped at > 5Mb/s, but has the capability of 7.5Mb/s. All customers from the provider > here are on VDSL. > > > > I'm guessing from your email address that you get that from your electric > coop, too? At the state fair a couple of months ago, I had the opportunity > to speak to the guy who architected and implemented the FTTH rollout for > Ralls County electric coop, up north of StL along the IL border. They did, > from what I could tell from my conversation, everything right and were > providing gigabit services to their users even in relatively rural areas. > Hopefully you guys will get something like that going at some point soon as > well! > > >
RE: VDSL
We provide between 250Mb/s and 1Gb/s fiber-to-the-home services to all our subscribers. We do not use VDSL. I personally do not have our services in my area yet as I live at the furthest possible point to which we will expand. So until then I use Centurylink. From: Matt Harris Sent: Friday, October 18, 2019 9:08 AM To: Ryland Kremeier Cc: Rod Beck ; Nanog@nanog.org Subject: Re: VDSL On Fri, Oct 18, 2019 at 8:46 AM Ryland Kremeier mailto:rkreme...@barryelectric.com>> wrote: Can confirm. Currently on VDSL in rural Missouri, speed is capped at 5Mb/s, but has the capability of 7.5Mb/s. All customers from the provider here are on VDSL. I'm guessing from your email address that you get that from your electric coop, too? At the state fair a couple of months ago, I had the opportunity to speak to the guy who architected and implemented the FTTH rollout for Ralls County electric coop, up north of StL along the IL border. They did, from what I could tell from my conversation, everything right and were providing gigabit services to their users even in relatively rural areas. Hopefully you guys will get something like that going at some point soon as well!
RE: VDSL
Can confirm. Currently on VDSL in rural Missouri, speed is capped at 5Mb/s, but has the capability of 7.5Mb/s. All customers from the provider here are on VDSL. From: NANOG On Behalf Of Matt Harris Sent: Tuesday, October 15, 2019 12:38 PM To: Rod Beck Cc: Nanog@nanog.org Subject: Re: VDSL On Tue, Oct 15, 2019 at 12:25 PM Rod Beck mailto:rod.b...@unitedcablecompany.com>> wrote: Hi, I discovered that the Budapest cable company was using VDLS to provide services up to 500 megs into the buildings where my flats are located. VDSL is a pretty old standard. I recollect people talking about it back in 1998. Is it being heavily deployed in Last Mile networks state side? Hey Rod, Are you sure they're using VDSL (I'm assuming you mean VDSL2 which is still in fairly wide use around the world)? 500mbit VDSL2 would have a very short run limitation afaik. It wouldn't be last mile, more like last meter. :) It's not super-widely used in the US today since Verizon and others have built out increasing FTTH networks and always had to compete with DOCSIS based services which are very widespread here, though I wouldn't be surprised if it was still frequently the "better than satellite!" service available in some rural areas that aren't too hard to reach with cabling. A decade ago, you would've seen a lot more VDSL2 deployments here in the US, though usually no more than 25 or 50 mbit capacity for the end-user. https://en.wikipedia.org/wiki/List_of_VDSL_and_VDSL2_deployments has a bunch of interesting details though I can attest to some of them being fairly out of date.
Re: Request comment: list of IPs to block outbound
Hello,
On Fri, Oct 18, 2019 at 7:40 PM Saku Ytti wrote:
> It's interesting to also think, when is good time to break things.
>
> CustomerA buys transit from ProviderB and ProviderA
>
> CustomerA gets new prefix, but does not appropriately register it.
>
> ProviderB doesn't filter anything, so it works. ProviderA does filter
> and does not accept this new prefix. Neither Provider has ACL.
>
>
> Some time passes, and ProviderB connection goes down, the new prefix,
> which is now old prefix experiences total outage. CustomerA is not
> happy.
>
>
> Would it have been better, if ProviderA would have ACLd the traffic
> from CustomerA? Forcing the problem to be evident when the prefix is
> young and not in production. Or was it better that it broke later on?
That's an orthogonal problem and it's solution hopefully doesn't
require a traffic impacting ingress ACL.
I'm saying this breaks valid configurations because even with textbook
IRR registrations there is a race condition between the IRR
registration (not a route-object, but a new AS in the AS-MACRO), the
ACL update and the BGP turn-up of a new customer (on AS further down).
Here's a environment for the examples below:
Customer C1 uses existing transits Provider P11 and P12 (meaning C1 is
actually a production network; dropping traffic sourced by it in the
DFZ is very bad; P11 and P12 is otherwise irrelevant).
Customer C1 is about to turn-up a BGP session to Provider P13.
Provider P13 is a Tier2 and buys transit from Tier1 Providers P1 and P2
Provider P2 deploys ingress ACLs depending on IRR data, based on P13's AS-MACRO.
Example 1:
P13's AS-MACRO is updated last-minute because:
- provisioning was last minute OR
- provisioning was wrong initially OR
- it's an emergency turn-up
- whatever the case IRR records are corrected only 60 minutes before the turn up
- and C1 is aware traffic towards C1 will completely converge only
after additional 24 hours (but that's accepted, because $reasons;
maybe C1 just needs TX bandwidth - in a hypothetical emergency turn-up
for example)
At the turn-up of C1_P13, traffic with as-path C1_P13_P2 is dropped,
because the ingress ACL at P2 wasn't updated yet (updated only once
every night). P13 expected prefixes not getting accepted at P2 on the
BGP session, but never would have imagined that traffic sourced from
valid prefixes present in the DFZ would be dropped.
Example 2:
Just as in example 1, C1 turns up BGP with P13, but the provisoning
was "normal". P13 AS-MACRO was updated correctly 36 hours before the
turn-up.
However, at P2 the nightly cronjob for IRR updates (prefix-lists and
ACL ingress filters) failed. It's is monitored and a ticket about the
failing cronjob was raised, however they either:
- the did not recognize the severity, because "worst-case some new
prefixes are not allowed in ingress tomorrow"
- where unable to fix it in just a few hours
- did fix it, but did not trigger a subsequent full rerun ("it will
run next time", or "it could not complete anyway before the next run")
- maybe the node was actually just unreachable for a regular
maintenance, so automation could not connect this time around
- or maybe automation just couldn't connect to the $node, because
someone regenerated the SSH key by mistake this morning
Whatever the case, the point is: for internal problems at P2, the ACL
wasn't updated during the night like it usually does. And at turn-up
of C1_P13, C1_P13_P2 traffic is again dropped on the floor.
When you reject a BGP prefix, you don't blackhole traffic, with an
ingress ACL you do. That is a big difference and because of this, you
*but more importantly every single downstream ASN* need to account for
race conditions and failures in the entire process, that includes the
immediate resolution thereof, which is not required for BGP strict
prefix-lists and uRPF loose mode.
Is this deployed like this in a production transit network? How does
this network handle a failure like in example 2? How does it
downstream customers handle the race conditions like in example 1?
For the record: I'm imagining myself operating P13 getting blamed in
both examples for partially blackholing C1's traffic at the turn-up.
Thanks,
Lukas
Re: Request comment: list of IPs to block outbound
Hello! On Tue, Oct 15, 2019 at 12:46 PM Saku Ytti wrote: > > On Mon, 14 Oct 2019 at 09:30, Vincent Bernat wrote: > > > How much performance impact should we expect with uRPF? > > Depends on the platform, but often it's 2nd lookup. So potentially 50% > decrease in performance. Some platforms it means FIB duplication. And > ultimately it doesn't really offer anything over ACL, which is, in > comparison, much cheaper feature. > I would encourage people to toolise this, then the ACL generation is > no cost or complexity. And you can use ACL for many BGP customers too, > as you create 'perfect' prefix-list for customer, you can reference to > same prefix-list in ACL, without actually needing customer to announce > that prefix, as it's entirely valid to originate traffic from > allowable prefix without advertising the prefix (to you). This has the potential to brake things, because it requires symmetry and perfect IRR accuracy. Just because the prefix would be rejected by BGP does not mean there is not a legitimate announcement for it in the DFZ (which is the exact difference between uRPF loose mode and the ACL approach). For BGP customers where I control the announced IP space (it's mine, the customer has a private ASN and the only reason for BGP is so he can multi-home to different nodes of my network), sure. For real "IP Transit" where the customers may itself have multiple downstream ASNs, there is no guarantee that everyone in the chain will update the IRR records 24 - 48 hours before actually sourcing traffic from a new prefix (or enabling that new downstream as-path). Some other transit may just allow prefixes "manually" (for example, because of LOA's or inetnum objects, as opposed to route objects), so *a valid announcement is in the DFZ*, you are just not accepting it on your customers BGP session. In fact, maybe my downstream customer just wants to send traffic to my network, but not receive any, so I don't actually have to include that customer in my AS-macro (an exotic use-case for sure, just trying to point out that there will always be asymmetry). Routing, BGP and the IRR data is asymmetric by definition and neither real-time nor 100% accurate. That's not a problem for BGP and strict ingress prefix-lists, but it is a problem for ingress ACL'ing, because the latter effectively blackholes traffic, while uRPF loose mode does not (if there is a announcement for it in the DFZ). So I don't think ACL's can replace uRPF loose mode in the DFZ and frankly I find this proposal to be a bit dangerous. If my transit provider would do this without telling me, I'm turning up a new transit customer with an incomplete IRR record, causing an immediate partial outage for them, I would be *very* surprised (along with some other emotions). cheers, lukas
Re: Request comment: list of IPs to block outbound
> On 19 Oct 2019, at 04:42, Saku Ytti wrote: > > On Fri, 18 Oct 2019 at 20:15, Lukas Tribus wrote: > >> This has the potential to brake things, because it requires symmetry >> and perfect IRR accuracy. Just because the prefix would be rejected by >> BGP does not mean there is not a legitimate announcement for it in the >> DFZ (which is the exact difference between uRPF loose mode and the ACL >> approach). > > It's interesting to also think, when is good time to break things. > > CustomerA buys transit from ProviderB and ProviderA > > CustomerA gets new prefix, but does not appropriately register it. > > ProviderB doesn't filter anything, so it works. ProviderA does filter > and does not accept this new prefix. Neither Provider has ACL. > > > Some time passes, and ProviderB connection goes down, the new prefix, > which is now old prefix experiences total outage. CustomerA is not > happy. > > > Would it have been better, if ProviderA would have ACLd the traffic > from CustomerA? Forcing the problem to be evident when the prefix is > young and not in production. Or was it better that it broke later on? Having been through this exact situation recently (made worse by the fact that it was caused by provider b’s upstreams not having updated their filters and not provider b itself), I would suggest its 100 times better for it to happen right at the start rather than randomly down the track > > -- > ++ytti
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Oct, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 779749 Prefixes after maximum aggregation (per Origin AS): 297110 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 374872 Total ASes present in the Internet Routing Table: 65913 Prefixes per ASN: 11.83 Origin-only ASes present in the Internet Routing Table: 56659 Origin ASes announcing only one prefix: 24237 Transit ASes present in the Internet Routing Table:9254 Transit-only ASes present in the Internet Routing Table:277 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table:30 Number of instances of unregistered ASNs:30 Number of 32-bit ASNs allocated by the RIRs: 29125 Number of 32-bit ASNs visible in the Routing Table: 23851 Prefixes from 32-bit ASNs in the Routing Table: 108145 Number of bogon 32-bit ASNs visible in the Routing Table:16 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:323 Number of addresses announced to Internet: 2841942656 Equivalent to 169 /8s, 100 /16s and 154 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.4 Total number of prefixes smaller than registry allocations: 260164 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 209506 Total APNIC prefixes after maximum aggregation: 60778 APNIC Deaggregation factor:3.45 Prefixes being announced from the APNIC address blocks: 203864 Unique aggregates announced from the APNIC address blocks:84786 APNIC Region origin ASes present in the Internet Routing Table: 10095 APNIC Prefixes per ASN: 20.19 APNIC Region origin ASes announcing only one prefix: 2808 APNIC Region transit ASes present in the Internet Routing Table: 1506 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5126 Number of APNIC addresses announced to Internet: 771040896 Equivalent to 45 /8s, 245 /16s and 38 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:229089 Total ARIN prefixes after maximum aggregation: 106880 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 227231 Unique aggregates announced from the ARIN address blocks:108281 ARIN Region origin ASes present in the Internet Routing Table:18626 ARIN Prefixes per ASN:12.20 ARIN
Re: Request comment: list of IPs to block outbound
On Fri, 18 Oct 2019 at 20:15, Lukas Tribus wrote: > This has the potential to brake things, because it requires symmetry > and perfect IRR accuracy. Just because the prefix would be rejected by > BGP does not mean there is not a legitimate announcement for it in the > DFZ (which is the exact difference between uRPF loose mode and the ACL > approach). It's interesting to also think, when is good time to break things. CustomerA buys transit from ProviderB and ProviderA CustomerA gets new prefix, but does not appropriately register it. ProviderB doesn't filter anything, so it works. ProviderA does filter and does not accept this new prefix. Neither Provider has ACL. Some time passes, and ProviderB connection goes down, the new prefix, which is now old prefix experiences total outage. CustomerA is not happy. Would it have been better, if ProviderA would have ACLd the traffic from CustomerA? Forcing the problem to be evident when the prefix is young and not in production. Or was it better that it broke later on? -- ++ytti
Re: Best components for a full mvno core network?
This is interesting but so many variables to unpack to determin what the right solution is. What are the main goals of your org? What exact pain points are you trying to fix? On Wed, Oct 16, 2019, 8:28 AM Dario Renaud wrote: > Hello, > > At my day job, we are considering going Full MVNO. Which means building a > mobile core network. > > I was wondering if some of you would have feedback or advices on the > solutions currently available? > > We would like to avoid the big providers (Ericsson & such). > Ideally, something opensource, or, if proprietary, a company maybe willing > to license access to the code (one can dream). > > There seems to be a lot of bits and pieces available out there, with a mix > of full, fullish or partial solutions. This makes for quite the puzzle. > > Among the ones I found most interesting: > > nextEPC, covering, well, the EPC… (https://github.com/nextepc/nextepc). > It looks like the more active open EPC implementation out there. > > And it seems that Yate people have a commercial product covering basically > everything needed ( > https://yatebts.com/solutions_and_technology/mobile_virtual_network_operator/). > > > What do you think? > > Regards > > Dario Renaud >
Re: VDSL
On Fri, Oct 18, 2019 at 8:46 AM Ryland Kremeier wrote: > Can confirm. Currently on VDSL in rural Missouri, speed is capped at > 5Mb/s, but has the capability of 7.5Mb/s. All customers from the provider > here are on VDSL. > I'm guessing from your email address that you get that from your electric coop, too? At the state fair a couple of months ago, I had the opportunity to speak to the guy who architected and implemented the FTTH rollout for Ralls County electric coop, up north of StL along the IL border. They did, from what I could tell from my conversation, everything right and were providing gigabit services to their users even in relatively rural areas. Hopefully you guys will get something like that going at some point soon as well!
Re: Friendly contact at Comcast about possible RF leaks
In the general case, I think, the FCC's enforcement branch actually takes care of being a clearinghouse for this sort of problem... according to my friend who used to do this for the FCC anyway. On Fri, Oct 18, 2019 at 1:32 AM Brandon Martin wrote: > > On 9/30/19 10:38 PM, Brandon Martin wrote: > > Anyone know a friendly contact at Comcast regarding possible RF leaks on > > their HFC plant? I'm not a Comcast customer, so I can't get in via front > > line support (not that it would probably do me much good, anyway), and I'm > > not looking to lodge a formal complaint or anything. I just want to give a > > heads-up about some issues I've noticed locally that haven't been addressed > > for a while and hopefully let things get addressed. > > > > I'm in Central Indiana, if anyone wants to try to route me directly to the > > right people. A general contact is fine, too. > > This has been taken care of and the leak apparently corrected. Thanks for > all those who reached out to me! > -- > Brandon Martin
RE: Viability of GNS3 network simulation for testing features/configurations.
> problem I've run into is our IOS isn't supported Not sure what you mean, like you can’t find the same exact version of IOS XRv 9000? Surely going with similar XRv version to your production one would be much closer than going with IOSv adam From: NANOG On Behalf Of rylandkremeier Sent: Wednesday, October 16, 2019 6:12 PM To: Yan Filyurin ; Jason Kuehl Cc: Subject: Re: Viability of GNS3 network simulation for testing features/configurations. We have 9 ASR's so I don't think it would be too hard to host them in the GNS3 vm insurance we're using. The main problem I've run into is our IOS isn't supported, which is where Cisco IOSv comes in, hoping it could be configured in a way to act very closely like our deployed hardware. I'm not so much worried about hardware faults, more so network configurations and testing of new methods. In a perfect world I would be able to copy the running configs from deployed hardware into GNS3. At least that's how closely I would like GNS3 running. Not a ton of info out there on IOSv, so I'm curious as to how it's configured. If it's the "universal" IOS that I would imagine it should be, then it could work. Thanks for the links, those are both things I didn't run across during initial research. -- Ryland Kremeier
RE: Viability of GNS3 network simulation for testing features/configurations.
> From: Saku Ytti > Sent: Thursday, October 17, 2019 3:41 PM > > On Thu, 17 Oct 2019 at 15:15, wrote: > > > But as you can see A) and B) can easily be tested with a single DUT (or some > small topology around it) using actual HW plugged in a loop with IXIA/Spirent > testers. > > Snake topology does conserve IXIA/Spirent ports but will not allow you to > test everything. I see no practical way of just having bunch of IXIA/Spirent > ports to verify behaviour under various types of congestion. Unfortunately > the 'bunch' is getting rather large, since even the smallest atom of a modern > networking chip may contain dozens of 100GE ports. > More IXIA/Spirent ports is your answer we use the "dumb" IXIA cards for NPU/PFE and fabric fairness testing as those are much cheaper. adam
Re: Friendly contact at Comcast about possible RF leaks
On 9/30/19 10:38 PM, Brandon Martin wrote: > Anyone know a friendly contact at Comcast regarding possible RF leaks on > their HFC plant? I'm not a Comcast customer, so I can't get in via front > line support (not that it would probably do me much good, anyway), and I'm > not looking to lodge a formal complaint or anything. I just want to give a > heads-up about some issues I've noticed locally that haven't been addressed > for a while and hopefully let things get addressed. > > I'm in Central Indiana, if anyone wants to try to route me directly to the > right people. A general contact is fine, too. This has been taken care of and the leak apparently corrected. Thanks for all those who reached out to me! -- Brandon Martin
Re: asymmetric routing issue on microsoft torix ix
>> So you are left with your regular inbound influence bag of tricks, >> e.g. prepending towards Shaw. > > the primary inbound steering tool is selective advertisement of > sub-prefixes > > i was shocked that the prepending presentation at ripe79 was blind to > this btw the ripe79 preso, https://ripe79.ripe.net/wp-content/uploads/presentations/64-prepending_madory2.pdf, did a good job of showing how prepending presents an attack surface. randy
