Re: Question about the use of NO_EXPORT in BGP route announcements

[Tarko Tikan]

hey,


Yeah, no. Provided they are singlehomed customers who generally set (or take) a
default route to that transit, they are completely fine. Their transit knows
the prefix and will use it. It gets more problematic for multihomed customers.


Well I have no idea why do you say that all such customers always have 
default route pointed to their transit provider. If that is the case 
then everything is OK ofc but you can't really take that for granted.


--
tarko

Re: Question about the use of NO_EXPORT in BGP route announcements

[Tarko Tikan]

hey,


But are there good reasons when an AS might announce a prefix
(route) to a transit provider with NO_EXPORT attached?  The IP
address space in consideration here is meant to have global
reachability.


This can be very harmful. Consider IP transit customer of said transit 
provider that is single homed to said transit provider.


Transit provider will select the aggregate prefix with no-export as best 
and will not propagate it to its customers while there can be 
alternative routes available between the prefix owner and transit 
provider. This will result loss of connectivity for those singlehomed 
customers.


--
tarko

Re: constant FEC errors juniper mpc10e 400g

[Tarko Tikan]

hey,

That said, I don't expect any subsea cables getting built in the next 3 
years and later will have 10G as a product on the SLTE itself... it 
wouldn't be worth the spectrum.


10G wavelengths for new builds died about 10 years ago when coherent 
100G became available, submarine or not. Putting 10G into same system is 
not really feasible at all.


--
tarko

Re: v6 route mess frm AS266970

[Tarko Tikan]

hey,


is a massive route leak not even menntioned when it is only ipv6?


We saw no impact to v6 traffic during the leak (and we have quite a lot 
of v6 traffic). I guess testament that RPKI works?


--
tarko

Re: Deployments of Provider Backbone Bridging (PBB)

[Tarko Tikan]

hey,


I've had two private replies, both of which suggest that
PBB has little to no share in the overall pie of the 
aggregation technology space,

nor in the overall pie of the core technology space.

However, a third correspondent states that Bard (Google's "Chat-based AI 
tool") claims that
PBB is deployed by AT&T, Verizon, China Mobile, Deutsche Telecom and 
Comcast.

This correspondent warns that Bard "could be hallucinating" :)


AFAIK this reflects the reality very well. There are huge PBB 
deployments in very large networks but the overall number of networks, 
using PBB, is very low. Even in those networks PBB is/will be phased out 
so don't expect any new deployments. It is still well supported by the 
vendors who initially invested into PBB.


--
tarko

Re: 10G CPE w/VXLAN - vendors?

[Tarko Tikan]

hey,

equal-cost paths that we want to load-balance across, are the hard 
part.  I’m not going to trust STP for that, and we aim for <3sec 
failover where we do have redundant paths.  ERPS can handle the 
failover, but not the load-balancing.


You have EVPN already, perhaps just use active-active multihoming lag 
over those two paths? It'll give you loadbalancing in both directions.


--
tarko

Re: Coherent 100G in QSFP28

[Tarko Tikan]

hey,


Looks like coherent 100G in the QSFP28 form factor is finally on the horizon.


To the best of my knowledge the actual products are like ~1y away.

50GHz spacing and with -4dB output power can traverse multiple ROADMs so 
more like 400G-ZR+ than 400G-ZR


--
tarko

Re: Websit of RADB stucked on Cloudflare

[Tarko Tikan]

hey,


whois.radb.net  Ipv4 is down


Not fully, sometimes queries via v4 succeed, sometimes terminated by 
"connection reset by peer".


--
tarko

Re: Websit of RADB stucked on Cloudflare

[Tarko Tikan]

hey,

At least when accessing here from Brazil, it gets stuck in the 
cloudflare tool.

> Anyone else with this problem?

+1

We also see intermittent issues with whois.radb.net connections.

--
tarko

Re: EVPN ESI BUM Forwarding

[Tarko Tikan]

hey,

The switches doing it are two Arista 7050SX3 with a single instance 
VXLAN EVPN. It should be a pretty simple setup. Not aware of any knobs 
to modify any of this behavior or what we could be missing.


Hard to speak for Arista (we do also have EVPN-VXLAN implementation with 
7050SX3 and A-A MH and don't see mentioned issue) but I wouldn't be 
suprised if this is Arista bug considered their EVPN story has been 
pretty rough in other similar areas (like A-S MH not blocking on non-DF 
etc).


Let us know if you find some correlation with other events that might 
explain this.


--
tarko

Re: EVPN ESI BUM Forwarding

[Tarko Tikan]

hey,

"The EVPN split-horizon procedure ensures that the BUM traffic 
originated by the multi-homed PE and sent from the non-DF to the DF, is 
not replicated back to the CE (echoed packets on the CE). To avoid these 
echoed packets, the non-DF (PE1) sends all the BUM packets to the DF 
(PE2) with an indication of the source Ethernet-Segment. That indication 
is the ESI Label (ESI2 in the example), previously signaled by PE2 in 
the AD per-ESI route for the Ethernet-Segment. When PE2 receives an EVPN 
packet (after the EVPN label lookup), the PE2 finds the ESI label that 
identifies its local Ethernet-Segment ESI2. The BUM packet is replicated 
to other local CEs but not to the ESI2 SAP."


https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-split-horizon

--
tarko

Re: Github/gist list of modern telemetry/networking polling tools

[Tarko Tikan]

hey,

snmp_exporter
gnmic

feeding to prometheus
+ alertmanager
+ grafana

Building meaningful dashboards and setting up actionable alerts 
(relevant for your network) is the hardest part.


--
tarko

Re: 100GbE beyond 40km

[Tarko Tikan]

hey,


How is everyone accomplishing 100GbE at farther than 40km distances?


See previous thread 
https://www.mail-archive.com/nanog@nanog.org/msg109955.html



--
tarko

Re: ROA coverage info

[Tarko Tikan]

hey,


Anyone know why https://rpki-monitor.antd.nist.gov/ is down?


Their NSes seem to be under DDOS attack on generally unreachable 95% of 
the time for a few days now.


This is also impacting time.nist.gov and generating a lot of queue in 
recursive DNSes to a extent that we had to block time.nist.gov and 
related names in our recursors (obviously there is a lot of equipment 
out there that has hardcoded time.nist.gov for time sync).


--
tarko

Re: IS-IS and IPv6 LLA next-hop - just Arista, or everyone?

[Tarko Tikan]

hey,


I did an L3VPN over SRv6 test recently using IS-IS as the IGP.  I
thought it was quite cool that I didn't configure any IPv6 addressing
at all in the core... simply enabled v6 on interfaces and allowed
FE80 LL's to run... IS-IS neighbored up... then added a mp-ibgp v6
loopback (rfc 4193) to the PE's and let BGP neighbor up... L3VPN
worked over SRv6 (of course with all that weird (new) locator
magic).


For less adventurous - you can also do unnumbered ISIS or OSPF. It works 
equally as good and enables one to do plug-and-play SR-MPLS like you 
would do layer-2 network.


--
tarko

Re: 100G over 100 km of dark fiber

[Tarko Tikan]

hey,


If it’s just a single 100G channel needed you could try 100GBASE-ZR4. Specified 
for 80km, 30db power budget they could actually reach more the 80km.
Dispersion should also be „no" problem in the 1310nm length. I have to say that 
I never tried this on 100km distance without coherent solutions.


Just to add to my original suggestion, we just did 100G-ZR4 over 30dB 
link with pre-FEC BER 3.174E-11.


As OP is asking for a solution for 25dB I don't see any reason why ZR4 
would not work and why you would need coherent, amplifiers or any other 
additional solution except when you are limited by QSFP28 SFF power.


--
tarko

Re: 100G over 100 km of dark fiber

[Tarko Tikan]

hey,


I need to push 100G over 100 km of dark fiber. Since there are no 100G 
pluggable optics with this reach (~25 dB), I have been offered coherent 
transport systems to solve my problem. This is all good and well, except total 
system costs start from high five figures.


100G-ZR4 QSFP28 is on the market and works. Just watch out for power 
limitations, your typical DC switch might not support it but proper 
stuff has no problems providing 6.5W of power.


--
tarko

Re: Rate-limiting BCOP?

[Tarko Tikan]

hey,


Provided you are using a strictly egress queueing platform, which OP's
ASR9k is not, its ingress NPU will drop packets, causing all customers
sharing the physical interface to suffer.


Correct, QoS is a tricky thing that needs to be planned correctly. I was 
just pointing out additional benefits (or drawbacks depending where you 
look from).


--
tarko

Re: Rate-limiting BCOP?

[Tarko Tikan]

hey,


Being able to do this as close to the customer as possible is always
most effective, especially if you run LAG's between a switch and
upstream router.


DDoS can be a problem in this scenario. Assuming the PEs have plenty of 
capacity available and you can afford DDoS to reach PE, then you would 
shape to customer contract speed, drop the DDoS traffic and would not 
congest your access device uplink.


--
tarko

Re: alternative to voip gateways

[Tarko Tikan]

hey,


But this all results in a sh1te load of 48 port gateways (power is not
a concern), but wondering if there is another solution that is more
cost effective? Seems the regular NEC's Siemens and so on might have
an option but I can imagine it will be far more expensive than a bunch
of individual gateways.


Huawei was already suggested and Nokia ISAM also works very well for 
your application


https://www.nokia.com/networks/products/intelligent-services-access-manager-isam-voice/#overview

Majority of the small consumer gateways (including the 48p ones) will 
not work on long loops, they are ment to be used inside a building etc.



--
tarko

Re: CGNAT Solutions

[Tarko Tikan]

hey,


I'm wondering if there are any real world examples of this, namely in
the realm of subscriber to IP and range of ports required, etc.  ie: Is
is a range of 1000 ports enough for one residential subscriber? How
about SMB where no global IP is required.

One would think a 1000 ports would be enough, but if you have a dozen
devices at home all browsing and doing various things, and with IOT,
etc, maybe not?


1000 ports doesn't mean you can have at max 1000 layer-4 sessions at 
once. It means you can have 1000 sessions to single destination IP+port. 
You can reuse same source port numbers for different destination IP or 
even destination port.


We are seeing very good results with 256 ports per subscriber in the 
mobile scenario where consumer is mobile handset. So not directly 
translatable to broadband setup but still good datapoint.


If you must go CGNAT today it's only reasonable to use PBA (so you log 
only block allocations) or pure deterministic where you have strict 
mapping between inside IP and outside IP+portrange so you don't need any 
logs at all.


--
tarko

Re: BIRD / BGP-ORR experiences?

[Tarko Tikan]

hey,


I was asking in relation to your IS-IS + SR-IOV issues.


Well ISIS works with bridge but we like to keep our virtualized NFs 
simple so KVM hosts have dedicated 10G port for NFs (that connects 
directly to a metro node) and we run SR-IOV.


--
tarko

Re: BIRD / BGP-ORR experiences?

[Tarko Tikan]

hey,


Were you previously running IS-IS on a UNIX/Linux system running in a VM?


No, we had RR function inline on ASBRs.

To be clear, our RRs are not BIRD but Nokia VSRs.

--
tarko

Re: BIRD / BGP-ORR experiences?

[Tarko Tikan]

hey,


Nice to hear ORR has come a long way that it's somewhat usable.


It is usable, we have taken it even a step forward:

- virtualized RR
- add-path
- ORR
- IGP topology to RR via BGP-LS so we don't have to extend ISIS to VMs 
(there are some issues with SR-IOV)


--
tarko

Re: Elephant in the room - Akamai

[Tarko Tikan]

hey,

I see my Akamai aanp cache utilization at all-time highs the last 2 
nights as well.  Curious what it is.


Halo Reach release.

--
tarko

Re: Spectrum (Charter) Fragmented UDP

[Tarko Tikan]

hey,


I don't know anything specific to this case, but you'd serve your best
interest to send small enough packets that do not need fragmentation,
particularly in the backbone.


In this case the SIP invite is already sent fragmented from the source 
and no fragmentation is required in transit. Someone probably thought 
"we see a lot of DDOSes with UDP fragments, better drop them altogether".


--
tarko

Re: Mx204 alternative

[Tarko Tikan]

hey,

This > means, as you say if you want physical 10G or lower ports then a> 

7210-sas-sx64 would be needed which is less than ideal.
Or you could talk to your account team, there are some new MDAs coming 
for IOM-5 and SR-1 that might suit the 10G/1G requirements without 
breakout or satellite.


--
tarko

Re: few big monolithic PEs vs many small PEs

[Tarko Tikan]

hey,


So what is the primary goal of us using the aggregation/access layer? It's to 
achieve better utilization of the expensive router ports right? (hence called 
aggregation)


I'm in the eyeball business so saving router ports is not a primary concern.

Aggregation exists to aggregate downstream access devices like DSLAMs, 
OLTs etc. First of all they have interfaces that are not available in 
your typical PEs. Secondly they are physically located further 
downstream, closer to the customers. It is not economical or even 
physically possible to have an MPLS device next to every DSLAM, hence 
the aggregation.


Eyeball network topologies are very much driven by fiber layout that 
might have been built 10+ years ago following TDM network best practices 
(rings).


Ideally (and if your market situation and finances allow this) you want 
your access device (or in PON case, perhaps even a OLT linecard) to be 
only SPOF. If you now uplink this access device to a PE, PE linecard 
becomes a SPOF for many, let's say 40 as this is a typical port count, 
access devices.


If you don't want this to happen you can use second fiber pair for 
second uplink but you typically don't have fiber to second aggregation 
site. So your only option is to build on same fiber (so thats a SPOF 
too) to the same site. If you now uplink to same PE, you will still 
loose both uplinks during software upgrades.


Two devices will help with that making aggregation upgrades invisible 
for customers thus improving customer satisfaction. Again, it very much 
depends on market, in here the customers get nosy if they have more than 
one or two planned maintenances in a year (and this is not for some 
premium L3VPN service but just internet).


--
tarko

Re: few big monolithic PEs vs many small PEs

[Tarko Tikan]

hey,


For availability I think it is best approach to do many small edge
devices.


This is also great for planned maintenance. ISSU has not really worked 
out for any of the vendors and with two small devices you can upgrade 
them independently.


Great for aggregation, enables you to dual-home access devices into two 
separate PEs that will never be down at the same time be it failure or 
planned maintenance (excluding the physical issues like power/cooling 
but dual-homing to two separate sites is always problematic for eyeball 
networks).


--
tarko

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

[Tarko Tikan]

hey,


The Cloudflare blog
entry is 4 years old, if they had started actively pursuing proper fix
to the ECMP problem, the fix would be in production right about now.


You can find more recent overview at
https://blog.cloudflare.com/increasing-ipv6-mtu/

--
tarko

Re: Service provider story about tracking down TCP RSTs

[Tarko Tikan]

hey,


But why did the TLS Hello has a TTL lower that the TCP Syn ?

Do you have any information on that ?


Consumer CPEs are typically some BCM reference design where initial TCP 
handshake is handled by linux kernel and everything following (including 
NAT) is handled in SOC.


I've seen those systems not decrement TTL at all, decrement TTL before 
checking if packet is destined to itself etc. This case is weird as 
typically the hardware part is faulty, not the kernel.


--
tarko

Re: Confirming source-routed multicast is dead on the public Internet

[Tarko Tikan]

hey,


What if... Bear with me for a moment here, we don't try to force VoD onto a
multicast setup? Multicast is used extensively by all major ISPs(if they
have the rights) to deliver IPTV.


We are an IPTV provider in europe and we definetly see share of linear 
TV (that we are delivering via intra-AS multicast today) decreasing YOY.


OTT plays a big part but even more customers use our own on-demand 
services including network PVR.


Numbers don't add up yet but in 3-4 years even the intra-AS multicast 
will not make sense for us any more, easier/better to deliver everything 
via unicast.


--
tarko

Re: IPv6 addressing plan spreadsheet issue

[Tarko Tikan]

hey,

How did you actually create the .txt file? Is the filesize spoofed in 
some way?

8191PB is a lot of storage.


Probably just handcrafted index.html with fake file size and CGI script 
that outputs the actual prefixes on-demand?


--
tarko

Re: 40G reforming

[Tarko Tikan]

hey,


I want to take advantage of the fact that 40G is transported as four
individual streams. Each of the four streams are to be converted from 850
nm to a 1550 DWDM channel (one channel per stream). And the reverse at the
other end of the link.


You probably want something similar to:
http://www.10gtek.com/qsfp-extender


--
tarko

Re: improving signal to noise ratio from centralized network syslogs

[Tarko Tikan]

hey,


This is done with the 'logging facility'
command on the devices:

After defining your syslog server's IP
address and the level of messaging you want
(I set it to debug because I want to see
everything):

on the routers: logging facility local0
on the switches:  logging facility local1


Alternative, and more universal, way to do it is to use multiple IPs for 
syslog server. Then configure correct syslog server IP on the device.


syslog-ng and others can all do filtering to different destinations 
based on the IP where message was received.


--
tarko

Re: Gonna be a long day for anybody with CPE that does WPA2..

[Tarko Tikan]

hey,


Any word on other vendor's response to this?


Aruba - 
http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007_FAQ_Rev-1.pdf


--
tarko

Re: Multicast stream monitoring tools

[Tarko Tikan]

hey,


If you are in the  Video content delivery business using mcast then
these folks are one of the leaders.  You can put multiple probes
and make sure your mcast coming off source is solid, through the
core router solid, and at the edge...   http://www.ineoquest.com/
they are not cheap but worth every dollar


I can recommend http://www.agama.tv/

We use it for general purpose monitoring but not so much for interactive 
debugging.


Shameless plug: for debugging I wrote https://github.com/tarko/CCmon 
some years ago and it works great. Wanted to have alternative to all 
windows based software out there that will just report number of CC 
errors but will not support multiple streams (or copies of the software 
running), will not produce useful logs for correlation etc.


--
tarko

Re: New Switches with Broadcom StrataDNX

[Tarko Tikan]

hey,


Juniper has chosen to use their own silicon for most of their dense 100G 
platforms, but you’ll see these chips used by pretty much everyone else I 
imagine at some point in the next year.


Juniper silicon has one big advantage over BCM88670 - it supports 2M FIB 
entries. This makes PTX1000 (and QFX10002) very attractive platform for SPs.


--
tarko

Re: IPv6 Implementation and CPE Behavior

[Tarko Tikan]

hey,


Are most CPE devices generally not IPv6 capable in the first place?  For those 
that are capable are they usually still configured with IPv6 disabled, 
requiring the customer to enable it?  For those CPE that are capable and 
enabled, is there a common configuration such as full blown DHCPv6 with PD?


In my experience, IPv6 is mostly disabled. But this will vary from 
region to region due to different vendors on the market.


When IPv6 is already enabled, it mostly is DHCPv6 PD, otherways it'll 
not really make sense as CPE. Some routers will also need M-bit set in 
the RA, others will just blindly do DHCPv6.


But it tends to be PD _and_ NA, NA can or can not be annoying depending 
on your network setup.


We have also seen issues with DHCP timers, make sure you have a way to 
protect your DHCP servers and relays when CPE starts sending out request 
every millisecond.


--
tarko

Re: DHCPv6 PD & Routing Questions

[Tarko Tikan]

hey,


So I'd say there is equipment out there that works, as expected, but as
seen in this thread, plenty of equipment that doesn't.


Latest OpenWrt releases include https://github.com/sbyx/odhcpd as 
DHCPv4/6 server. This enables hierarchical PD on these platforms, ie. 
subdelegate /64s from the /56 PD prefix you received from SP.


It's not the most configurable thing at this point but it does the job.

--
tarko

Re: Favorite GPON Vendor?

[Tarko Tikan]

hey,


I used Huawei GPON gear at previous job.


+1 for the MA5600 series. They are decent boxes compared to most of the 
other vendors that tend to be hardcore telco with (undocumented) TL1 
management plane.


--
tarko

Re: NetFlow - path from Routers to Collector

[Tarko Tikan]

hey,


It should've already been spent for an OOB/DCN network, which should've
been provisioned with flow telemetry in mind.


Bad advice. No amount of money will fix major platforms that are not 
happy to export flow telemetry via router management ports. Sometimes it 
can be done via nasty vrf leaking hacks, sometimes it cannot be done at 
all. Management ports are typically directly connected to routing 
engines while netflow data is generated in hardware in PFE.


In-band netflow works on all platforms without such issues.

--
tarko

Re: BRAS sugestion

[Tarko Tikan]

hey,


Our company are constantly growing and we're looking for a 30k+
subscribers BRAS, does the community have a sugestion?


I can tell only good stories about Alcatel 7750-SR. Extensive BNG 
feature set (both v4 and v6) and very stable platform.


--
tarko

Re: FTTx Active-Ethernet Hardware

[Tarko Tikan]

hey,


I understand it is now being replaced by the ASR920, which is a little
odd if you look at port density differences between the two alone.


It is being replaced by ASR-920-24SZ-M - 24GE Fiber and 4-10GE: Modular 
PSU. I don't think this ASR920 has been announced yet :)


--
tarko

Re: Estonian IPv6 deployment report

[Tarko Tikan]

hey,


I assume you have a star-network below the BNG? Ie no rings or similar in the
access network?


Most of our network below BNG is MPLS, so no, it's not a star per say. 
But as PWs are point-to-point, you are technically correct. Below MPLS 
there is some ethernet too and this is all strictly star/tree.


I would encourage everyone to push MPLS as close to customer as 
possible, this makes redundancy, BNG placement etc. all much easier as 
you can use IGP/MPLS + PWs.


--
tarko

Re: Estonian IPv6 deployment report

[Tarko Tikan]

hey,


How do you protect customers from each other?

There are many nasty IPv6 attacks you can do when on a shared VLAN.


Split-horizon (switchport protected in Cisco world). Customers can't 
send packets directly to each other, all communication has to go via BNG 
router. Obviously we protect L2 as well like limiting number of MACs per 
customers, make sure BNG MAC cannot be learned from customer ports etc. 
We don't use any L3 (both v4 and v6) inspection in ANs, everything 
happens in BNG.


It's actually much better and logical for v6 as it is for v4. In v4 
world you have to implement proxy-arp, in v6 world there is no need for 
customers to send packets to each others link-local WAN addresses and 
packets sent to PD addresses are by default routed via BNG.


--
tarko

Estonian IPv6 deployment report

[Tarko Tikan]

hey,

Some time ago, many people noticed rapid IPv6 deployment growth in 
Estonia (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom 
were behind this, other operators don't have any serious IPv6 
deployments at the moment. We rolled out v6 to everyone (both business 
and residential customers) with last-gen CPE, there was no hop-in our 
hop-out program - aim was to do it perfectly and without customers even 
noticing. I'm happy to say that we achieved this goal :)


To satisfy general interest, I promised small (somehow it turned out 
longer than I expected) technical writeup how we enabled v6 for our 
subscribers. If you have any other questions, feel free to ask and I do 
my best to answer them. You can also skip the technical content and 
there are some statistics below.



Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband 
service is deployed in shared service vlans. IPv6 traffic shares vlan 
with IPv4.


Service vlans are transported over MPLS metro network using pseudowires 
and terminated in geo-clustered Alcatel 7750 BNG routers.


Each subscriber is allocated up to 4 mixed v4 and v6 IP hosts. For v4 we 
are using the usual DHCP, for IPv6 we are using DHCPv6 with IA_PD only, 
no IA_NA is provided. Unfortunately DHCPv6 provides no way to signal 
IPv6 default-route thus we have to fall back to RA for default-route. RA 
does not include any on-link prefixes or DNS information. RAs are L2 
unicasted to CPE MAC so no other CPE in service vlan picks up those RAs. 
To ensure rapid switchover between BNG routers, we are signalling 
virtual link-local address as default-route.


We are using ALU internal DHCP/DHCPv6 servers to allocate leases but we 
also signal IP information from radius (in such case BNG "fakes" DHCP 
server) for static IP customers. Provided IPv6 prefix is always /56 and 
we keep the old lease for 24h even if the CPE is turned off (actual 
lease time is 30min).


Unfortunately, IPv6 LDRA is not available on most of our access 
platforms so we have to rely on IPv4 session information for 
authentication. This linking is done in the radius server during 
subscriber authentication (excellent radiator + quite awful SQL queries 
:) - if subscriber has IPv4 session (that has been authenticated using 
DHCP opt82), same MAC address is allowed to have IPv6 session on exactly 
the same virtual BNG port. IPv4 and v6 session are both tied to same 
subscriber and share shapers, QOS etc.


We were able to enable IPv6 only on our last-gen Inteno CPEs. They run 
modified OpenWrt and because it's linux - everything is possible :)


In CPE, /56 is divided up to /64s, first one is currently reserved but 
we will configure it on loopback interface and use it for CPE 
management. Second /64 is configured on LAN and third is configured on 
public wifi SSID (if you choose to enable this option).


In the LAN, IPv6 config is provided by RAs, we also support RDNSS and 
stateless DHCPv6 for DNS. There is also ingress IPv6 firewall in the CPE 
and configuration is modifiable by user.


To make deployment as smooth as possible, we rolled out IPv6 capable CPE 
software first. Then, during the BNG platform refresh, we deployed L2 
ACLs that dropped all IPv6 traffic based on 0x86dd ethertype. We then 
deployed IPv6 config to all BNGs and could verify everything before 
single v6 lease was handed out to the subscribers.


Then, interface by interface, we replaced L2 ACL with one that only 
allowed 0x86dd for certain, supported, OUIs. This is the current 
situation and we are investigating ways to support 3rd party CPEs - main 
problem is unreliable IPv6 config in CPEs. Many don't enable DHCPv6 (or 
enable NA but no PD) but still pick up default-route from RA and happily 
signal it to LAN. Some others hammer our BNGs with NA request every 0.1 
seconds etc.



As statistics go, there are 3+ active IPv6 subscribers (almost 15% 
of our customer base, based on our public numbers), 81% of them have 
have at least one IPv6 enabled device in the LAN, 70% have more than 
one. Most IPv6 traffic is generated by Google+Youtube, Facebook and 
Akamai. Not bad for a country with 1.3M people.


Next up: mobile network :)

--
tarko

Re: 2000::/6

[Tarko Tikan]

hey,


Any decent router won't allow you to enter just anything in that range
into the export rules  with a /6,  except 2000::  itself, and will
even show you a failure response instead of silently ignoring the
invalid input,  for the very purpose of helping you avoid such errors.


IOS was already brought up, luckily Junos and TIMOS do just that (both 
for prefix-lists and static routes). Unfortunately directly connected 
networks remain and there is no way to solve that.


--
tarko

Re: 2000::/6

[Tarko Tikan]

hey,


There is no matching entry in whois for 2000::/64 (or shorter), so it is 
unlikely that 2000::/64 was an intended configuration.


2000::/64 has nothing to do with it.

Any address between 2000::::::: and 
23ff::::::: together with misconfigured 
prefix length (6 instead 64) becomes 2000::/6 prefix.


--
tarko

Re: 2000::/6

[Tarko Tikan]

hey,


2000::/64 doesn't make much sense either.


No and it was obviously not what was configured.

But something like 2001:7d0:1:1::1/64 misconfigured on interface as 
2001:7d0:1:1::1/6 becomes 2000::/6


--
tarko

Re: 2000::/6

[Tarko Tikan]

hey,


maybe i am more than usually st00pid this evening, but i am no smarter
on what actually happened, how it was detected


Dunno about others but I personally detected it using my tools that look 
for our prefixes (or more specifics) being advertised by someone else. 
Large covering prefix obviously triggered the bells.


I'm pretty sure it was a typo in the config, the prefix length had to be 
/64 but was entered as /6 instead.


--
tarko

2000::/6

[Tarko Tikan]

hey,

2000::/6 with aspath 3257 3549 has appeared in global routing table. 
Surely we can't be only ones seeing it. Looks like someone messed up 
interface/route config at 3549 by omitting 4 from the prefixlen.


According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
"2000::/6 is visible by 79% of 92 IPv6 RIS full peers."

--
tarko

Re: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL

[Tarko Tikan]

hey,


Yeah - funny…it's been years since I heard of specific Estonian issues (and 
caveat - I am estonian and know
Tarko).  Back in 2007 there were plenty of problems but many have been cleaned 
up.  Some took a few years.


Still waiting for examples. I can say for sure that none of the major 
operators in Estonia are spam friendly (and  or ignore abuse related 
issues. There might be one or two hosting/content operators, mostly with 
Russian origins, but even they have grown up.


I'm well connected in local community - if you do have specific 
complaints, let me know.



Tarko - have you got this resolved yet?


Nope :(

--
tarko

Re: network quality measurement probes+reporting

[Tarko Tikan]

hey,


   - any-to-any measurement, not just hub<->spoke (or sufficiently cheap hub)


May I add:

- local data caching on probes (don't want to see holes in data if 
central collector/NMS is unavailable for short period)

- DHCPv4/6 support with possibility to do periodic release/renew

--
tarko

Re: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL

[Tarko Tikan]

hey,


My home IP is in both the PBL and the SORBS DUL and I have no trouble
using ebay or paypal.


Thanks for confirmation.


Given that the problem range is in Estonia, I expect that it's some
combination of abuse from the specific range and general issues with
traffic from Estonia.


What makes you say that? Any specific examples of trouble you are 
getting from Estonian networks?


--
tarko

Re: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL

[Tarko Tikan]

hey,


Can you share the data that makes you think it's the former?


I can't say I'm absolutely sure, hence the question to wider audience. 
But I can say that it's only subset of prefixes that are blocked


What I can do, is provide some blocked IPs as example:
90.190.226.239
90.191.156.199
84.50.65.135

--
tarko

Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL

[Tarko Tikan]

hey,

For a while now, we have been getting complains from our broadband 
customers about not being able to reach ebay.com/paypal.com


We have nailed it down to some small prefixes and they are all listed in 
SORBS DUHL / Spamhaus PBL and have been listed for ages. These are 
indeed dynamic IP pools and should not send any email (not that SMTP has 
anything to do with HTTP).


For some reason, it looks like ebay/paypal is now blocking HTTP access 
based on these blacklists.


Does anyone have working contact in their NOC or with security people? 
All emails to public contacts have not been answered to.


--
tarko

Re: IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs

[Tarko Tikan]

hey,


Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but 
I believe they are no longer. Juniper has their Subscriber Management feature 
pack on their MX routers, and Cisco has their Broadband Network Gateway on 
their ASR routers. Besides these two vendors I am not sure what other solutions 
are out there. I believe both of these solutions communicate upstream to 
external radius servers and DHCP servers. Is anyone using Subscriber 
Management, or is there another way of doing it?


ALU is the most known (and yet least known as subscriber management is 
mainly used by big telcos who are not sharing what they do internally) 
and has best subscriber management features both v4 and v6. Google "ALU 
7750".


--
tarko

Re: Circuit Bandwidth Simulator applet etc

[Tarko Tikan]

hey,


I would like a applet or program I can feed it nodes and a network
topology, then just set hypothetical transmit speeds at child nodes
then have the applet or program display the Parent node bandwidth.  Is
there any Visio applets or macros out there I wonder?


http://totem.run.montefiore.ulg.ac.be/

Written in Java and quite usable. Topology and traffic matrix are 
stored/read in XML so it's easy to generate your own with scripts.


--
tarko

Re: high performance open source DHCP solution?

[Tarko Tikan]

hey,

> The free DHCP solution, ISC, seems to be having scaling issues (i.e.
> handling only about 200 DHCPDISCOVER and 20 DHCPRENEW requests), and I
> was wondering if anyone had any open source suggestions of solutions
> that could scale much better?

You are doing something wrong:

* turn off ping-check
* use proper raid controller with battery backup (because isc dhcpd does fsync 
every time it writes to dhcpd.leases)
* ...
* profit

-- 
tarko

_
NANOG mailing list
NANOG@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

Re: Prefix 120.29.240.0/21

[Tarko Tikan]

hey,

Looks like this broken update was around from 08:32:15 UTC until 09:47:44 UTC 
(this matches what we saw):
http://www.ris.ripe.net/dashboard/120.29.240.0/21

Other providers, like Easynet, have also hit news with unexpected trouble this 
morning. Go do RIS search for 87.80.0.0/13 - lots of prefix unstability with 
exactly these start and end times. I'm doing some more digging but if any folks 
with already existing tools (hinthint Renesys :) want to help.. Seems it was 
bit more widespread that first thought.

-- 
tarko

Re: Prefix 120.29.240.0/21

[Tarko Tikan]

hey,

> The same here, but in my case we're downstream itself :) 

What version are you running?

This seems to hit some versions in even worse way.

-- 
tarko