Re: Angled Polish Connectors and DWDM
Hi Aaron, Are there situations when angled connectors are not to be used? Are they 'safe' or even recommended for any kind of DWDM application? To my knowledge APC is always better than PC connectors. APC are used to eliminate back reflections. Due to the angled connector reflections are sent mostly towards the cladding and not the core and therefore. The effecs of back reflections are great. Read this http://documents.exfo.com/appnotes/anote044-ang.pdf I can not see why APC connectors are not to be used, even with DWDM. The only problem with APC is that there are different kinds of angles (8 degrees and 9 degrees) and polishments of the tip. When using the wrong connectors (for example a 8 degrees against a 9 degrees in a coupler) you will introduce more loss. This would be the reasons why some people fear to use APC. regards, Igor
facebook lost their A-record for www.facebook.com?
[igor@vds ~]$ host -t A www.facebook.com ns1.facebook.com Using domain server: Name: ns1.facebook.com Address: 204.74.66.132#53 Aliases: www.facebook.com has no A record However: [igor@vds ~]$ dig A www.facebook.com @ns1.facebook.com ; DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 A www.facebook.com @ns1.facebook.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 55657 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.facebook.com. IN A ;; AUTHORITY SECTION: www.facebook.com. 86400 IN NS glb2.facebook.com. www.facebook.com. 86400 IN NS glb1.facebook.com. ;; ADDITIONAL SECTION: glb2.facebook.com. 3600IN A 69.171.255.10 glb1.facebook.com. 3600IN A 69.171.239.10 ;; Query time: 11 msec ;; SERVER: 204.74.66.132#53(204.74.66.132) ;; WHEN: Wed Mar 7 08:42:44 2012 ;; MSG SIZE rcvd: 104 Not sure what is going wrong here. People @ facebook? regards, Igor
bgp update destroying transit on redback routers ?
Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message: send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610 We use redback smartedge routers (SE100) currently for BGP. Anyone who have seen this also? regards, Igor
Re: bgp update destroying transit on redback routers ?
AGGREGATOR is an optional transitive attribute of length 6. -- In theory, there is no difference between theory and practice. But, in practice, there is. Typical, because: AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). Usage of this attribute is described in 5.1.7 And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. regards, Igor
Re: bgp update destroying transit on redback routers ?
And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. Looking futher: Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information cross BGP speakers that do not support the four-octet AS numbers. However this router is AS4 capable, but probably fails to understand a 4-byte AS in the normal AGGREGATOR attribute. If I understand correctly a AS4 capable router should understand when announcing that to it's peer. I'm I correct? Should I file this as a bug? (redback/ericsson is already looking also) regards, Igor
Re: bgp update destroying transit on redback routers ?
So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem? Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions... I've opened a case at Ericsson, still waiting for an answer :-/ Correct. This was pointed out to me just now off-list by another reader. Ericsson coder also contacted me and noted that is fixed a few months ago, but he is not sure which release has the fix. I hope he will respond on-list about this for everyone to read. regards, Igor
Re: bgp update destroying transit on redback routers ?
Hi all, A new update. A coder from ericsson told me that the problem is not 4-byte asn related. It is related to aggregator-asn=0 and aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and IP-address. The question is now, are all other vendors wrong in accepting this attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC stating 'which shall contain its own AS number and IP address') or is Ericsson being to strict? regards, Igor
Re: bgp update destroying transit on redback routers ?
http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? regards, Igor
Re: someone from verisign? website down over ipv6
I've been told that this is fixed now. Can you confirm? Correct. Site is working now over a tunneled ipv6. Great work! Still working on the whois problem. Good luck with this. regards, Igor
someone from verisign? website down over ipv6
Dear someone from Verisign, It looks from over here (and some other hosts I checked) that http://www.verisigninc.com/ is dead when using a host having iPv6 dual-stack. Some packets do come over, so the browser is not failing over into IPv4. Also the whois server for whois.nic.name is not working for IPv6 dual-stack hosts. The IPv6 part of the whois server claims that he is dead and so again failover to IPv4 is not going to happen. Contact me off-list if necessary. regards, Igor Ybema
Re: someone from verisign? website down over ipv6
Hi, extra info: Site problem looks path mtu related. On tunneled hosts the site does not work. On native hosts it does. Looks like something is blocking icmpv6 path mtu requests. My tunnels are ok, so must be in the verisign network, my guess a misconfigured firewall. Whois server problem is also on native ipv6 hosts so this is not mtu related. regards, Igor
Re: Top webhosters offering v6 too?
Oxilion, dutch based provider (AS48539), also provides cloud services based on RHEV. They do provide IPv6 also. See for a redhat notice about this: http://www.redhat.com/about/news/prarchive/2010/oxilion.html Their site is mostly dutch, however this one is in English also http://oxilion.nl/virtual-datacenter-en regards, Igor
Re: Significant Announcement (re: IPv4) 3 February - Watch it Live!
I think they were under a TCP-SYN attack :) The video was super choppy from here and I have bandwidth to burn at this time of the day. A little disappointing, but I'm sure (fingers crossed) someone will have a clean recording of it that they will make available. I saw that also. Switched to windows media stream which was working fine. However,.. stream was not available on a IPv6 only host. Epic fail! :) regards, Igor
just seen my first IPv6 network abuse scan, is this the start for more?
Hi, Since recently we noticed Neighbour table overflow warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second. Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. Are there more people who have seen this behaviour recently? Is this a start of hackers/spammers onto the IPv6 network? This is the first scan I have seen. I already contacted the ISP for the source address. No answer yet. If I have more news I will post them here. regards, Igor Ybema the Netherlands
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Not necessarily so useless, as it was hitting your boxen, eh? True :) Any noticeable effect on router CPU? Not visible in the graphs. A Foundry XMR was the router and all load on the CPU's in the router didn't change anything. regards, Igor
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 If I understand the RFC correctly it is based on an attack within the same subnet. Looks a lot like arp-flooding. However this scan was from a external host. The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). On the router side I clearly saw the icmp traffic from the source doing a scan on these destination hosts. None of these IPv6 addresses are alive so no succes in scanning for comprised machines. regards, Igor
Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
Hi, We are using 6to4 on our fallback site because the provider there is not able to provide us native IPv6 yet. We have also installed a fallback nameserver over there using a 6to4 address. This works good and no complains what so ever in the past. However, last week Denic (registry for .de) changed their policy (or their checks). They don't allow a nameserver for a .de domain anymore which contains a 6to4 address. The policy is it should be a global unicast AND the block should be assigned to a RIR for suballocation purpose. The 6to4 range is Global Unicast (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) but it is not assigned to a RIR because it is a special block. This fails their policy and their checks (resulting in a ERROR: 105 All IPv6 Addresses must be Global Unicast). Ok, policy is policy and we should not complain. However, I'm asking your opinions about this policy. I find this really stupid because this completely brakes use for 6to4 in Germany and their is no good reason to block it. We know we should push our provider to support native IPv6, and we do. But this should not stop us using IPv6 6to4. regards, Igor Ybema
IPv6 internet broken, cogent/telia/hurricane not peering
Hi, I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia. However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane. This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable. I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'. I'm currious about you point of view. regards, Igor Ybema Senior network Administrator Oxilion
Re: IPv6 internet broken, cogent/telia/hurricane not peering
Just saw that telia - HE AND telia - Cogent got fixed. They are now connected through CW. Maybe someone got woken up by these messages :) Cogent and HE is still broken but then again, i...@cogent is still beta. regards, Igor
