Anyone here from Verizon keeping tabs on FiOS v6?
Maintenance outage last night, PD woke up shortly afterward and collected a /56, no joy after that -- egress traffic gets where it's going, ingress is dropped not far into 701. Only visible covering route is the 2600:4000::/24 aggregate, both externally and via Verizon's looking glass. It looks like there are several reports of the same issue in other areas over the last couple months, where those that work have covering /36s advertised externally and the broken ones don't, e.g. no 2600:4041:2000::/36 here. Happy to follow up off-list, if so inclined. Thanks! -Rob
Re: Short-circuited traceroutes on FIOS
On Tue, 10 Dec 2019, Joe Maimon wrote: Anyone have an idea why there are some destinations that on residential verizon fios here in NY area terminate right on first external hop? They're returning fake ICMP echo replies from their BNGs for echo packets with TTL=1, thus any ICMP traceroute (Windows and mtr by default, etc.) seems to terminate at their layer 3 edge. UDP/TCP traceroute are unaffected, ICMP works fine if you set the initial TTL to n+1 where n is the hop that's lying. Support claims that it was a mistake, but it's also been 15+ months and it's pretty deliberate behavior. Draw your own conclusions... -Rob
Re: Mx204 alternative
On Mon, 2 Sep 2019, Hank Nussbacher wrote: What about handling LAG on 1Gb/sec links? That is a major showstopper if indeed it is missing: It works, but only about as well as anything else to do with 1G interfaces works on the MX204, and only then when you're running at least 18.1R3... show version |match "(model|junos):" Model: mx204 Junos: 18.1R3-S4.2 show interfaces ae0 |match speed Link-level type: Flexible-Ethernet, MTU: 1522, Speed: 40Gbps, show lacp interfaces ae0 |find protocol LACP protocol:Receive State Transmit State Mux State xe-0/1/4 Current Slow periodic Collecting distributing xe-0/1/5 Current Slow periodic Collecting distributing xe-0/1/6 Current Slow periodic Collecting distributing xe-0/1/7 Current Slow periodic Collecting distributing show chassis hardware |match SX Xcvr 4 REV 02 740-011613 - SFP-SX Xcvr 5 REV 02 740-011613 - SFP-SX Xcvr 6 REV 02 740-011613 - SFP-SX Xcvr 7 REV 02 740-011613 - SFP-SX show interfaces xe-0/1/4 |match speed Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None, Flow control: Disabled, Speed Configuration: 1G It just gets more bizarre from there. Don't run 1G on these boxes if you can find any way to avoid it. -Rob
Re: Zayo vs Coent
On Fri, 9 Nov 2018, Ca By wrote: Zayo will provide you all of the internet Only the parts for which someone has remembered to call in updates and/or which Zayo has remembered to apply to every manually maintained per-session prefix list, or for which someone has badgered them enough to switch to max prefixes only. They have an incurable allergy to IRR, and it's a bundle of fun to sort out when something gets missed. -Rob
Re: What's the point of prepend communities?
On Thu, 26 Oct 2017, Jason Lixfeld wrote: Absolutely. I understand the "Prepend to Network blah” use case. The case I don’t get is where the ISP makes no distinction in their policy document about how the prepending of their own AS is applied to their upstream announcements, implying that it’s announced to everyone. The "prepend to everybody" communities are usually implemented as "prepend to all peers", excluding customers, and for some variable definition of "all". YMMV, caveat emptor, et cetera -- in most cases you'll need to experiment. I've used "prepend to all peers" communities a few times to avoid saturating transit links that are being consolidated but still under contract, in order to keep the link viable and in use by the immediate neighbor and their customers, but otherwise make it less attractive to the rest of the world under normal conditions. -Rob
