Re: godaddy spam / abuse suspensions?
On Mon, 2008-11-17 at 05:15 +0530, Suresh Ramasubramanian wrote: On Mon, Nov 17, 2008 at 4:20 AM, James Hess [EMAIL PROTECTED] wrote: One of the secondary/tertiary recursive resolvers may hand the client a cached response that had been obtained before the registrar took any action. Yes, and that'd make a good case for the good old ops practice of dialing down the TTL for a while before any NS change is made. That would work only if Godaddy was considering suspending it for greater than TTL time before actually suspending them...it takes the same time to dial-down TTL (old TTL time) then change it, as it does to just change it outright. -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net [EMAIL PROTECTED]
Re: Prefix Hijack Tool Comaprision
Hi all, .-- My secret spy satellite informs me that at Thu, 13 Nov 2008, Todd Underwood wrote: that's why i recommend that prefix hijacking detection systems do thresholding of peers to prevent a single, rogue, unrepresentative peer from reporting a hijacking when none is really happening. others may have a different approach, but without thresholding prefix alert systems can be noisy and more trouble than they are worth. For those who like to use a peer threshold, BGPmon.net now has minimum peer threshold support. For more information see: http://bgpmon.net/blog/?p=88 Cheers, Andree
Re: Router Choice
Hello,I appreciate all your feedback. I have also recieved more research
material from independent research institutes that give the products thumbs
up.
Best regards
Raymond
On Fri, Nov 14, 2008 at 2:30 PM, Paul Wall [EMAIL PROTECTED] wrote:
Whoa, excessive use of !...this isn't IOS ICMP output.
For those of you who want to have a chuckle, grep the word exit on
any of these fine 7750/7450 router configurations. Seeing a router
configuration that contains 10,000+ instances of the word exit makes
me recall the fine book FINAL EXIT. Seems like a poor mans version of
nesting with { }'s in JUNOS.
Some of my gripes on the Timetra (whens the last time Alcatel built
something themselves instead of acquire it?) box are that it really is
catered to installs where Alcatel is running the design side of the
network as well. The CLI is somewhat non-intuitive for IOS, IOS-XR or
JUNOS operations staff. Here are some examples:
Here in 2008, why are people buying boxes that do not support
candidate configuration or commit/rollback? The only thing you can
commit on the box is routing policy changes. I thought this was a
service provider box?
For years (this might not be the case anymore), any time you attempted
to use the short-form of the show command by typing sh, you
received a syntax error. This is because there were two commands that
began with sh: show and shell. The problem is that the shell command
prompts you for a password that only Alcatel knows (and won't share
with any customers that I'm aware of). So, if your own customers cant
run the command, why give users a headache?
Its a router, why do I have to do show router route to see a routing
table entry? For years, you also had to suffix the command exact on
the end of every command as well.
Pricing wise...they're way above other boxes that you can find
elsewhere that can do the jobs you need. Both the Cisco 7600 and the
Juniper MX line both have a way better CLI and employ a knowledgeable
staff of seasoned former service provider engineers. Alcatel seems to
be comprised of failed router startup guys from Caspian or Chiaro.
Feature wise, they're behind the curve when it comes to competing with
Cisco and Juniper. I think this is also shown in how they name their
software releases as Feature Groups (telco-speak, anyone?).
The main thing I want to speak to is that this box is not made for
your clueful IP operator. Alcatel is very insistent that the customer
use their UNIX/Windows NMS (I believe they call the SAM) to interface
with the routers. Sorry but...that might fly in telcoland where
executives ooh and ahh over point-and-click network management, but I
think most operators are going to find it a tad bit useless.
Sure, they do have NSR, but so did Avici. Does NSR make up for the
lack of features, high pricing and being stuck at 20Gbps per slot?
Yes, they do have 40Gbps per slot on the way, but who doesn't support
40Gbps per slot today?
Why bother stepping back a few years in development when if you want a
solid P core box, Foundry MLX/XMR, Juniper MX, Cisco 7600s and CRS-1's
are ready now and at prices that really aren't all that bad. Oh yeah,
you wont scratch the hell out of your finger nails when removing the
compact flash on those boxes.
Drive slow, pinging 10().
On Wed, Nov 12, 2008 at 10:31 AM, devang patel [EMAIL PROTECTED] wrote:
I guess they have good lab in Plano, TX also!!!I worked on the same
routers
for IPTV deployment and really they are best!!!
regards
Devang Patel
On Wed, Nov 12, 2008 at 8:43 AM, Dan Snyder [EMAIL PROTECTED] wrote:
I think that the 7750SR routers are great and you won't be let down. We
used to have an all Cisco network and I was skeptical at first but they
have
been great.
As for nss and nsr when we tested this by failing a cpm we saw less than
50
ms of traffic loss. I would see if you could go to either California or
Canada to one of ALUs labs and have it demonstrated for you.
hth,
Dan
Sent from my iPhone
On Nov 12, 2008, at 7:40 AM, Raymond Macharia [EMAIL PROTECTED]
wrote:
Hello fellow nanogers,
I am a long time user of Cisco gear and currently evaluating an
alternative
for my network expansion. currently the one that looks like it will be
able
to do the job iare Alcatel-Lucent 7710/7750 service routers.
I am looking for real life experience of those who have used it and
what I
may need to watch out for (if anything) I have seen in some of their
documentation features like Non-stop Services (NSS) and Non-stop
Routing
(NSR). are these features real world deployable.
oh, just to add I want to use the routers as P routers in my IP/MPLS
core
Regards
--
Raymond Macharia
--
Raymond Macharia
Re: Router Choice
Raymondo .
I guess you are bringing everyone together on the achieving resilience and
efficient Load Balancing just in case the one path is temporarly unavailable
.. :-)
*commit/rollback
CISCO IOS
save a configuration to the NVRAM with the copy running-config startup -config
command
http://www-europe.cisco.com/en/US/docs/switches/wan/mgx/mgx_8850/software/mgx_r3/rpm/rpm_r1.1/configuration/guide/appc.html
JUNIPER JUNOS
You just have to send you syslog messages to /var/log/messages to a central
point of management and avoid /dev/null :-)
The best practice would be to follow the same in all Cisco devices Catos or IOS
based ones.
And again that is why management tools have their relevance and have cron jobs
in place to keep the latest changes -accounting included)
but yes you are right we can always grep something out and find what has
changed.
The commit concept is an interesting one and bring us back to the way they have
compiled and allowed us users to fiddle around w/ the OS. Some versions not
mentioned here
require the word comit to be typed after a stop/start of some services-PID.
Let us say a gracefull reestart of the process ..
And yes the old batle ethernet vs ATM interfaces gosh ATM just had a
credit crunch for the past years and ETHERNET standard knocked it down big
time! Yes, the argument still standands if we want to take this further to
the QoS/reliability I bet a lot of consultants would love an payed argument
on this :-)
As far as I am aware there are still a few interopability issues going on w/
some vendors and Eth-IEEE P802.3ba 40Gb/s, specially w/ having features
available such as 802.1q/vlans etc ...but the card is there and available for
everyone to work on
And the world is moving to the 100 Gb Eth .and so does IPv4 to IPv6.
.//ID
--- On Mon, 11/17/08, Raymond Macharia [EMAIL PROTECTED] wrote:
From: Raymond Macharia [EMAIL PROTECTED]
Subject: Re: Router Choice
To: nanog@nanog.org
Date: Monday, November 17, 2008, 7:20 PM
Hello,I appreciate all your feedback. I have also recieved
more research
material from independent research institutes that give the
products thumbs
up.
Best regards
Raymond
On Fri, Nov 14, 2008 at 2:30 PM, Paul Wall
[EMAIL PROTECTED] wrote:
Whoa, excessive use of !...this isn't
IOS ICMP output.
For those of you who want to have a chuckle, grep the
word exit on
any of these fine 7750/7450 router configurations.
Seeing a router
configuration that contains 10,000+ instances of the
word exit makes
me recall the fine book FINAL EXIT. Seems like a poor
mans version of
nesting with { }'s in JUNOS.
Some of my gripes on the Timetra (whens the last time
Alcatel built
something themselves instead of acquire it?) box are
that it really is
catered to installs where Alcatel is running the
design side of the
network as well. The CLI is somewhat non-intuitive for
IOS, IOS-XR or
JUNOS operations staff. Here are some examples:
Here in 2008, why are people buying boxes that do not
support
candidate configuration or commit/rollback? The only
thing you can
commit on the box is routing policy
changes. I thought this was a
service provider box?
For years (this might not be the case anymore), any
time you attempted
to use the short-form of the show command
by typing sh, you
received a syntax error. This is because there were
two commands that
began with sh: show and shell. The problem is that the
shell command
prompts you for a password that only Alcatel knows
(and won't share
with any customers that I'm aware of). So, if your
own customers cant
run the command, why give users a headache?
Its a router, why do I have to do show router
route to see a routing
table entry? For years, you also had to suffix the
command exact on
the end of every command as well.
Pricing wise...they're way above other boxes that
you can find
elsewhere that can do the jobs you need. Both the
Cisco 7600 and the
Juniper MX line both have a way better CLI and employ
a knowledgeable
staff of seasoned former service provider engineers.
Alcatel seems to
be comprised of failed router startup guys from
Caspian or Chiaro.
Feature wise, they're behind the curve when it
comes to competing with
Cisco and Juniper. I think this is also shown in how
they name their
software releases as Feature Groups
(telco-speak, anyone?).
The main thing I want to speak to is that this box is
not made for
your clueful IP operator. Alcatel is very insistent
that the customer
use their UNIX/Windows NMS (I believe they call the
SAM) to interface
with the routers. Sorry but...that might fly in
telcoland where
executives ooh and ahh over point-and-click network
management, but I
think most operators are going to find it a tad bit
useless.
Sure, they do have NSR, but so did Avici. Does NSR
make up for the
lack of
Re: Catalyst 6500 High Switch Proc
On Sat, Nov 15, 2008 at 04:35:28PM -0500, Philip L. wrote: One thing to note, is that our main ACL for ingress traffic is applied here due to historical reasons. It's roughly 5000 single host entries at present. We also use these devices for NDE. On a SUP7203BXL, if your ACL TCAM utilization is fine, this shouldn't impact performance unless you're logging too much. Since you've been over the CPU utilization doc, I'm guessing you know that. show platform hardware capacity acl will give you a breakdown on your ACL TCAM usage. I'm probably missing some other key details, but what could influence the SP like this? Any insight would be appreciated. Cisco says that Netflow-based features always handle the first packet of a flow in software, but I don't know if this is the RP or the SP. It would make sense if a first-flow packet that didn't need punting hit the SP and not the RP. In that case, your traffic level with netflow enabled could explain your high SP utilization. -- Ross Vandegrift [EMAIL PROTECTED] If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie
134.17.0.0/16
Media Breakaway and ARIN have cooperatively reached an agreement whereby Media Breakaway will be returning to ARIN the legacy address space 134.17.0.0/16 originally issued to San Francisco (SF) Bay Packet Radio. Media Breakaway will be returning this space upon completion of renumbering to a new IPv4 allocation made based on their qualification under existing policy. ARIN is grateful for Media Breakaway's cooperation in this matter. Regards, /John John Curran Chairman, ARIN Board of Trustees
IPv6 routing /48s
Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification. We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was they do not route network smaller than a /32. Fair enough... capacity planning for all the /48's would give a router a headache with today's hardware... so we requested address delegated from Verizon's larger block of addresses to be used for addressing. The response was that we could not receive new address space until we returned our ARIN provided address space... so in effect, go back and get a /32 from ARIN or give up on ever owning address space again. ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32. revo
Clueful FIDO contacts
It is not strictly netops but I am hoping someone in nanog-land can assist me. I am receiving bad callerID information (I get the BTN) from FIDO or FIDO's upstream. My SIP providers claim they are receiving the bad callerID from their upstreams. Though everyone I am a customer of agrees that it isn't their problem and that it's FIDO's they are all unwilling or unable to assist me in contacting FIDO. If anyone has a contact or a NOC number that you could contact me off-list i would greatly appreciate it. Thank you, Robin -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 [EMAIL PROTECTED] http://www.ifbyphone.com
Re: IPv6 routing /48s
On Tuesday 18 November 2008 06:46:08 [EMAIL PROTECTED] wrote: Are there any parties out there routing /48 IPv6 networks globally? We do. At present, our policy is to route up to /48. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: IPv6 routing /48s
[EMAIL PROTECTED] wrote: Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification. There are a bunch of IXPs around who have been announcing /48s for a some while. From a cursory glance around, it looks like Verizon is unreachable from these at least AS2128, which announces a single /48. This would seem to support your sales person's claim. It will be interesting to see how long this policy lasts - or at least it will be interesting to see at what stage carriers decide that the loss in sales revenues hurts more than the cost of carrying /48s from PI delegatin blocks. Nick
Re: IPv6 routing /48s
From: [EMAIL PROTECTED] Date: Mon, 17 Nov 2008 16:46:08 -0600 Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification. We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was they do not route network smaller than a /32. Fair enough... capacity planning for all the /48's would give a router a headache with today's hardware... so we requested address delegated from Verizon's larger block of addresses to be used for addressing. The response was that we could not receive new address space until we returned our ARIN provided address space... so in effect, go back and get a /32 from ARIN or give up on ever owning address space again. ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32. Lots of people have /48s from ARIN and many are routed. The global IPv6 table currently has about 200 of them. Among those using /48s are ARIN and at least three of the root name servers, so that policy would block access to rather important sites. :-) I'd say that someone at VZB is pretty clueless. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpiNvOz95si5.pgp Description: PGP signature
Re: IPv6 routing /48s
On 11/17/08 14:46, [EMAIL PROTECTED] wrote: ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32. You may want to post this issue to the ARIN PPML list (see http://www.arin.net/mailing_lists/index.html if you're not already subscribed), as that might be a useful venue for discussion as well. You're right in noting that this is a catch-22. ARIN and other RIRs are now giving out PI /48s, but there is still a notion that /32 is considered the maximum routable prefix length. However, UCB sees a lot of globally-routed /48s (and /35s, /40s, etc.) in our DFZ routing table. (I also see some /48s disaggregated from a /32 and announced in at least one non-ARIN region, but I am sure this is happening elsewhere. :-( ) So, I do think that /48 is beginning to be the new /32 when it comes to prefix filtering, but I can also understand those who want to hold to the more strict IPv6 filtering policies. I think in the end, we are going to end up generally accepting up to /48s. Basically, we're going to break the routing table anyway--the number of potential /32s is more than enough to do that, and forcing everyone who: a. needs to be multi-homed; and b. needs more than 1-2 subnets to get a /32 has to be a waste, no matter how big the potential address space is overall. One compromise would be to require that blocks that can be aggregated be aggregated, and then allow PI /48s. In theory, this could be enforced a number of ways, but I am sure we're all aware of how well that works... michael
Re: IPv6 routing /48s
On 2008-11-17, at 17:46, [EMAIL PROTECTED] wrote: Are there any parties out there routing /48 IPv6 networks globally? Yes. Some particularly visible examples are root and TLD server operators. There are some TLDs which are well-served by IPv6-capable nameservers, but which would be completely invisible to v6-only clients if their covering /48s were not accepted. ASes which refuse prefixes longer than 32 bits across the board as a matter of policy are broken. The last time I looked, the RIRs with v6 micro-assignment policies were all doing long-prefix assignments from an easy-to-identify range of addresses. Creating a general-purpose filter which lets through PI / 48s but drops PA/deaggregated /48s is not rocket science. I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification. I was once told by another large carrier I was trying to buy from in Miami that you are not allowed to announce your own addresses in IPv6; you have to use addresses from your upstream. While the goal of encouraging use of PA addresses and discouraging deaggregation may be noble and good, it seems more education is required in some areas. There is such a thing as PI in IPv6, for example, and perhaps just because it's a /48 doesn't mean it's not PI. Joe
Re: IPv6 routing /48s
On Nov 17, 2008, at 3:47 PM, Joe Abley wrote: The last time I looked, the RIRs with v6 micro-assignment policies were all doing long-prefix assignments from an easy-to-identify range of addresses. Creating a general-purpose filter which lets through PI /48s but drops PA/deaggregated /48s is not rocket science. As of June, 2008, at least, AfriNIC was not using a distinct range for these. There was discussion of converting to this due to these problems.
Re: Clueful FIDO contacts
On Mon, Nov 17, 2008 at 5:51 PM, Robin Rodriguez [EMAIL PROTECTED] wrote: It is not strictly netops but I am hoping someone in nanog-land can assist me. I am receiving bad callerID information (I get the BTN) Why is the BTN (billing top number) bad? That's a legitimate answer. -M
Re: IPv6 routing /48s
On 18/11/2008, at 11:46 AM, [EMAIL PROTECTED] wrote: We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was they do not route network smaller than a /32. I wish them good luck in reaching the DNS root servers. They are in critical infrastructure space, which is a single /32 with /48s assigned[1] from that - or something like that. IXP space was mentioned.. I'm not sure that needs to be globally reachable. Maybe to stop uRPF breaking ICMP messages if routers on the exchange respond from their interface address.. though.. I'd prefer to make my routers respond from loopback or something. -- Nathan Ward [1] Maybe I mean allocated, whatever. -- Nathan Ward References 1. mailto:[EMAIL PROTECTED]
Re: Catalyst 6500 High Switch Proc
Ross Vandegrift wrote: On Sat, Nov 15, 2008 at 04:35:28PM -0500, Philip L. wrote: One thing to note, is that our main ACL for ingress traffic is applied here due to historical reasons. It's roughly 5000 single host entries at present. We also use these devices for NDE. On a SUP7203BXL, if your ACL TCAM utilization is fine, this shouldn't impact performance unless you're logging too much. Since you've been over the CPU utilization doc, I'm guessing you know that. show platform hardware capacity acl will give you a breakdown on your ACL TCAM usage. I'm probably missing some other key details, but what could influence the SP like this? Any insight would be appreciated. Cisco says that Netflow-based features always handle the first packet of a flow in software, but I don't know if this is the RP or the SP. It would make sense if a first-flow packet that didn't need punting hit the SP and not the RP. In that case, your traffic level with netflow enabled could explain your high SP utilization. It is a Sup720-3BXL. Based on the suggestions here, I went ahead and did 'no ip flow ingress' on all the interfaces just to see, and surely enough, the SP went down to about 10-15%. My colleague implemented packet count-based NetFlow sampling to attempt to reduce the 100% NetFlow TCAM usage, and it appears to be partially effective. It still fills up frequently, so we'll have to do some more tweaking. I appreciate all the replies, public and private. -- Philip L.
Re: Clueful FIDO contacts
Should have been more specific I suppose, I believe I'm receiving the BTN of the trunk FIDO is delivering the calls to other carriers on. No the BTN of the subscriber (this is a mobile phone network) Thanks! Martin Hannigan wrote: On Mon, Nov 17, 2008 at 5:51 PM, Robin Rodriguez [EMAIL PROTECTED] wrote: It is not strictly netops but I am hoping someone in nanog-land can assist me. I am receiving bad callerID information (I get the BTN) Why is the BTN (billing top number) bad? That's a legitimate answer. -M -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 [EMAIL PROTECTED] http://www.ifbyphone.com
Re: Router Choice
On 15/11/2008, at 12:30 AM, Paul Wall wrote:
For those of you who want to have a chuckle, grep the word exit on
any of these fine 7750/7450 router configurations. Seeing a router
configuration that contains 10,000+ instances of the word exit makes
me recall the fine book FINAL EXIT. Seems like a poor mans version of
nesting with { }'s in JUNOS.
..stuff..
Try out the GUI thing.
I know people will go GUIs are for idiots! and all that.
Seriously, try it before you knock it, it's really very very good, and
doesn't try and hide things from you like traditional GUIs do. You can
do XML stuff in to it for automated service provisioning etc. etc.
etc. with templates, and so on. I've done quite a lot of this for
lawful intercept, automated debugging of VoIP stuff, service
provisioning, etc.
Switch out the hardware, and the GUI/mgmt system will give it the
config it should have. This is all configurable, so it doesn't annoy
you if you don't want it to.
Make changes in the CLI, and the GUI knows about it within a second or
so - it gets an SNMP trap or something and updates accordingly. None
of this periodic scan rubbish that you get with Dorado RMC etc.
The GUI product name is 5620SAM.
Also, before you try 7x50, do a training course so you understand how
things work - thinking is quite different to Cisco/Juniper.
For example, in the 7450, VLANs:
- VLANs are specific only to a physical port, they are not per-box
like Cisco etc.
- To build a L2 VLAN, you create a VLAN on each port that you want to
hook up (numbers can be whatever you want, do not have to be the same
on every port) and then create a L2 service[1], and add the VLANs on
each port in to the L2 service.
- L2VPNs
Because of this, VLAN tag re-write is not an extra feature - it is a
core component of how switching works across the platform.
They really seem to have thrown away a whole bunch of conventional
thinking, and the result is, in my opinion, really quite good.
--
Nathan Ward
[1] I believe that it's the same L2 service that you use when creating
a VPLS.
--
Nathan Ward
