Unless I'm missing something, looks like my internal dns stopped working because there were issues with the link to the US.
All because dnssec is enabled in bind.
Namely queries from a resolver server would timeout looking up MYHOST.MYDOMAIN.com.dlv.isc.org before it got to querying my authoritative server.
Is there any way to work around that?
Seems like a single point of failure, where resolvers will fail if there are any issues with com.dlv.isc.org.
Jean-Francois Pirus | Technical Manager
francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401
Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com
The CARDIGAN SDX system continues to gain scale in a production environment.
The team is proud to announce that they have redesigned the system to
provide OF1.3 multitable support which supports hardware with soft
CARDIGAN now provides a flexible controller framework which scales as
quickly as vendors are increasing their TCAM support.
With the current hardware (Pica8 3290 and Noviflow 1132) the system is
able to support up to 130,000 flows today. The system optimises which
flows are sent to the devices which means that many more routes that
this number can be supported. Being able to support hardware from
multiple vendors on the same framework allows engineers to deploy the
right hardware, in the right location for them.
In the early days of the deployment, there was concern expressed about
the ability of this SDN system to scale. This framework now addresses
those concerns head on.
As can be seen below, the system is currently handling over 14,000
routes. We're going to make some changes so that we can test out the
full capacity over the next few days.
noviswitch# show stats table tableid 2
--------Table id: 2
Active count : 14716
Max_entries : 131071
Lookup count : 0
Match count : 0
The patches to the RouteFlow system which enable these features have
been passed back to the RouteFlow development team so that they can be
accessed by the entire community.
Upwards and onwards.
Just as a bit of a heads-up in case anyone else is hitting this issue (and
We tend to be learning a total of about 511k or so unique IPv4 routes
nowadays from external peers. Combine this with various internal routes and
the actual number of IPv4 routes on a couple of our border routers is a few
short of 512k.
If any of these routers have a RIB or FIB limit of 512k IPv4 routes then
expect some strange issues.
Like random routes not showing up in your routing table..
*cough* brocade xmr default cam partition *cough*
Have a nice day!
I am desperately looking for an IT consultant or company based in Shanghai
who can offer Level 2/3 IT sales & support for my Shanghai office (10
staff) and speaks English as a first language.
Trying to give technical instructions to someone with English as a second
language is causing more harm than good and none of my staff there are
technical enough for some of the steps I require of them.
Any recommendations from our wonderful community much appreciated. Please
Chorus have been swapping cards in DSLAMs from NALT (ADSL Capable) to NVLT (VDSL Capable) throughout their network.
>From looking at the Chorus Planned Network Notifications for a cabinet in BSY (Browns Bay) I can see over the last 2 months they have been swapping cards with about 65 customers at a time.
Since this work began and customers swapped to the new cards we've noticed that some broadcom chipsets are having issues connecting with ADSL, it establishes PPP only around 10-20% of the time with 20 retries.
Sometimes the router can connect within 5 mins and other times can take up to 60 minutes to reconnect.
We've had Alcatel investigate and from our BNG/BRAS the correct PPPoE (chorus do the PPPoA conversion when used) packets are being sent to the CPE down the handovers however the CPE doesn't receive the ConfAck in the negotiation.
Further investigation showed that the CPE was showing DSL sync but a downstream attenuation of 0, Chorus ESPM tool showed the same result, hence why the DSLAM may not be passing all the comms to the CPE.
Cisco routers have no issues, however routers we have seen this issue with are DLINK: DSL-2750B, TP-LINK: W8950ND, NETGEAR: DGN1000,
While I have not seen this issue on any of my direct customers, I have seeing about 30-40 cases on a ISP we manage their network for.
Chorus have a case open for us though this has been ongoing for a few weeks now so just want to know if there are any other operators perhaps seeing similar cases?
We're working on an upgrade project in Tauranga and may need to colocate
some switches in the Chorus CO on Cameron RD.
If you work for a operator that has rack space in this CO and know you can
sublet space out to other operators, I'd appreciate if you could forward me
a contact for one of your commercial guys so I can take it further.
Only after 3-4U so thought I'd ask the community before looking at going
down the road of getting an entire footprint (and having 90% of the space
go to waste!).
*General Manager*Full Flavour
*p. *07 929 7111 *ddi*. 07 281 1391
*s*. Skype username "myfullflavour"
*e*. jesse(a)fullflavour.co.nz <jesse(a)fullflavourmedia.co.nz>
*w*. fullflavour.co.nz <http://www.fullflavourmedia.co.nz/>
*a. *Tauranga Business Centre, 50 Devonport Road, Tauranga
*a*. PO Box 16306, Bethlehem 3176, New Zealand
Telecom have announced their Dial IP service will be retired on Dec 1 this
Are any ISPs on this list intending on still offering dial-up after this
date? Maybe using their own modem banks or via the TelstraVodahugClearDice
Feel free to reply on or off list.
(vaguely representing Inspire Net)
As some of you may have noticed ntp2.ntp.net.nz and its aliases
p2.ntp.net.nz and s2.ntp.net.nz stopped responding late on 08-07-2014.
This is related to a hardware fault with the NTP appliance, we are
currently investigating both repair and replacement options.
As a temporary measure the DNS records for ntp2.ntp.net.nz,
p2.ntp.net.nz and s2.ntp.net.nz have been pointed to ntp3.ntp.net.nz.
Information about these appliances and the services they provide can be
found at https://ntp.net.nz.
If you need any further information, please contact us at
.nz Registry Services
M: +64 21 783 399
P: +64 4 555 0124
GPG: 6516 B4EA 413B CAED 57B5 0956 124C 8AC3 A362 8080