Re: Surcharge for providing Internet routes?

[Alex H. Ryu]

Do you mean "Full routes" for BGP ?

Sometimes there are extra charge for BGP, but never heard about full
routes or not.

How can they guarantee whether they provide Full routes or not ?
If some routes are missing, are they going to provide the credit for it ?

Full routes from BGP is always best-effort basis.
So I don't think they can charge it based on whether it is full routes
or not.
They may charge for running BGP with you, but not for full routes or not.

Alex



ML wrote:
> Has anyone here heard of or do they themselves charge extra for
> providing a complete internet table to customers?
> 
> Waive the surcharge for sufficiently large commits?
> 
> 
> 
> 

Re: two interfaces one subnet

[Alex H. Ryu]

Unless you configure Layer 2 for two interfaces, it's not going to work.
It is invalid from networking principle.
If you have to send the traffic for host in same subnet you configured,
which interface it should send out ?
Basically it may create broadcast storm loop by putting two ip addresses
in same subnet in different interface.
It may be allowed from host-level, but from router equipment, I don't
think it was allowed at all.

Alex


Chris Meidinger wrote:
> Hi,
>
> This is a pretty moronic question, but I've been searching RFC's
> on-and-off for a couple of weeks and can't find an answer. So I'm
> hoping someone here will know it offhand.
>
> I've been looking through RFC's trying to find a clear statement that
> having two interfaces in the same subnet does not work, but can't find
> it that statement anywhere.
>
> The OS in this case is Linux. I know it can be done with clever
> routing and prioritization and such, but this has to do with vanilla
> config, just setting up two interfaces in one network.
>
> I would be grateful for a pointer to such an RFC statement, assuming
> it exists.
>
> Thanks!
>
> Chris
>
>
>

Re: NPE-G2 vs. Sup720-3BXL

[Alex H. Ryu]

Cisco 7304 may not adequate for service provider.
It's CPU/IO-controller is tied together, and doesn't provide much of
benefit.

Cisco 7200/7300 is enterprise solution pretty much, and doesn't support
distributed CEF.

If you are considering SUP720-3BXL, why not considering RSP720-3CXL ?

Alex


Aaron Millisor wrote:
> We ran into a similar quandary and have about the same amount of
> traffic as your network. When purchasing gear a year ago we decided
> against 7200's with an NPE-G2 as insufficient for the load. Have you
> looked at the 7304?
>
> The Cisco 7304 with an NSE-150 processing engine on it offloads a lot
> of the packet processing to dedicated hardware, and doesn't have TCAM
> limitations for routes. You can hold several full feeds and do the
> amount of traffic you're talking about without breaking a sweat.
>
> http://www.cisco.com/en/US/prod/collateral/routers/ps352/prod_bulletin0900aecd8060aac5.html
>
>
> It is capable of supporting both legacy port adapters (from your
> Flexwan or 7200 routers) and SPA cards with the right add-in modules,
> which IIRC is only a few hundred dollars.
>
> I'd be glad to answer any questions you have about our implementation.
>
> --am
>
> David Storandt wrote:
>> We're stuck in an engineering pickle, so some experience from this
>> crew would be useful in tie-breaking...
>>
>> We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of
>> Internet traffic, currently using 6509/Sup2s for core routing and port
>> aggregation. The MSFC2s are under stress from 3x full route feeds,
>> pared down to 85% to fit the TCAM tables. One system has a FlexWAN
>> with an OC3 card and it's crushing the CPU on the MSFC2. System tuning
>> (stable IOS and esp. disabling SPD) helped a lot but still doesn't
>> have the power to pull through. Hardware upgrades are needed...
>>
>> We need true full routes and more CPU horsepower for crunching BGP
>> (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory,
>> one each at two locations. Oh yeah, we're still a larger startup
>> without endless pockets. Power, rack space, and SmartNet are not
>> concerns at any location (on-site cold spares). We may need an
>> upstream OC12 in the future but that's a ways out and not a concern
>> here.
>>
>> Our engineering team has settled on three $20k/node options:
>> - Sup720-3BXLs with PS and fan upgrades
>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing
>> off to NPE-G2s across a 2-3Gbps port-channel
>> - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing
>> off to a 12008 with E3 engines across a 2-3Gbps port-channel.
>>
>> Ideas and constructive opinions welcome, especially software and
>> stability-related.
>>
>> Many thanks,
>> -Dave
>
>
>

Re: NPE-G2 vs. Sup720-3BXL

[Alex H. Ryu]

ASR is embedded linux solution with Quantum Processor architect if I
remember correctly.
So it uses IOS-XE, which is a little bit different from standard IOS.


If you have some room for budget, you can check Foundry MLX/XMR series
router.
It is more geared toward Ethernet Service Router.
But if you need OC3/12/48, you can have those with additional license fee.
Foundry router price is a lot lower than Juniper MX series router.

Alex


David Storandt wrote:
> So I figure a summary is an order, with a whole array of choices
> pitched so far...
>
> - Sup720-3BXL works for light-duty premium ISP services, decent CPU
> for BGP and an Ethernet hardware throughput monster. Decent enough for
> our deployment scenario at least. No obvious solution for the
> FlexWAN/OC3 but could easily be re-integrated with a stronger MSFC CPU
> to back it up, assuming the IOS-of-the-week doesn't have issues. The
> pesky OC3 could be pawned off to a dedicated G1/G2 router too along
> with any oddball <=OC3 stuff our sales guys dream up.
> - RSP720-3CXL is the best of all worlds option, if we had double the
> budget to work with. Meh.
> - ASR1002 is a hardware-assisted overhaul to the 7200/G2. Telco
> interface options are much better than 7200s, good for OC12s and
> OC48s. Using GoogleFu product pricing... a ASR1002 router with a SPA
> OC3, 5Gbps ESP, and base software runs in the $28-30k range +
> SmartNet. Beware the modular licensing model in addition to IOS
> editions. Maybe a bit early yet as a core router as some of the
> software is still getting bugs ironed out.
> - Vyatta was proposed as an alternative system, probably best
> architected out of the mainstream traffic flows (no hardware
> forwarding), say a BGP route reflector or GBE edge router, similar
> argument to a 7200/G[1|2]. I can't say I'm familiar with the software,
> but the cost savings of premium x86/x64 hardware and 8x PCI-x serving
> a few 10GBE interfaces + built-in GBEs is intriguing, especially
> paired against our budget and relative Cisco costs. A spec'd out 1U
> Dell box with dual power, 8x cores, 4GB, RAID1 SATA, and 2x 10GBE
> XFP+2x GBE built-in came in under $7k with CPU headroom to burn.
> Vyatta doesn't support ISIS though, best I can tell, but may not have
> to... Maybe yet-another Linux router distro doomed to fail? Worth a
> lab test internally on some demo hardware.
> - Mixed thoughts about 7304 hardware. Hardware forwarding quality vs.
> software and interface selection.
> - Lots of fans for the 12000 series. Stick with the E3 (~2.5Gbps) and
> E5 (~10Gbps) line cards for compatibility with XR software and best
> line card performance. Our team liked the variety of SONET options
> available too for our central office deployments, even though the
> systems are power and space hungry. ...and if you can afford them (the
> 12008/GRP-B being the relative exception).
> - 7200/G2s are great for <1Gbps throughput. Premium services cut into
> the performance dramatically, being a fully software-based forwarding
> platform. Don't bond interfaces looking for more throughput,
> architecture limitations actually decrease throughput.
> - Juniper MX series? A budget wildcard but indeed a worthy platform
> engineering-wise.
>
> You could break this list into "routers" and "switches", which in
> itself spurs the philosophical/pragmatic architecture discussion that
> got us the impasse to start with. Many thanks to all who've responded
> with real-life successes, battle wounds, and horror stories. All very
> helpful.
>
> -Dave
>
>
>
>   

Re: MX Record Theories

[Alex H. Ryu]

I don't think there is no real answer for your question.
It depends on each company's business objective, the cost, network
topology, and their policy.
MX record is the the mechanism for mail delivery procotol.
It doesn't dictate how to implement.
Depending on mail volume, and network policy, you can implement actual
mail servers within DNS/SMTP protocol.

There are multiple ways to get things done.
Depending on budget, business objective, network resource/policy,
you can choose the way that fits to your need.

It is same as Microsoft Windows operating system.
Microsoft release the Windows, but it doesn't say you have to run it as
cluster or not.
Depending on your need, and your own analysis/decision, you can run
whatever you like.


Alex


gb10hkzo-na...@yahoo.co.uk wrote:
> Hello all,
>
> First, I hope this is not off-topic for NANOG, please be gentle with me as 
> this is my first post.
>
> I
> would be most interested to hear NANOG theories on the variety of MX
> record practices out there, namely, how come there seem to be so many
> ways employed to achieve the same goal ?  Do you have experience in
> more than one of these methods and which do you favour ?
>
> To illustrate my question :
>
> (1)
> If you query the MX records for, Hotmail or AOL you will receive 4
> equal weight MX records, each of the MX records having a round-robin
> set of IPs.
> e.g.
> hotmail.com.2706INMX5 mx4.hotmail.com.
> hotmail.com.2706INMX5 mx1.hotmail.com.
> hotmail.com.2706INMX5 mx2.hotmail.com.
> hotmail.com.2706INMX5 mx3.hotmail.com.
> -and-
> mx3.hotmail.com.1926INA65.xxx
> mx3.hotmail.com.1926INA65.xxx
> mx3.hotmail.com.1926INA65.xxx
> etc.etc.
>
> (2)
> Alternatively, some people, particularly the ones that use hosted
> filtering, tend to have one MX record, which as multiple round robin
> IPs.
> e.g.
> microsoft.com.780INMX10 mail.global.frontbridge.com.
> -and-
> mail.global.frontbridge.com. 1728 INA65.xxx
> mail.global.frontbridge.com. 1728 INA207.xxx
> etc. etc.
>
> (3) And others simply have a more traditional setup using multiple MX records 
> and only one IP per MX record with no round robin
> apple.com.931INMX10 mail-in14.apple.com.
> apple.com.931INMX20 mail-in3.apple.com.
> apple.com.931INMX20 eg-mail-in2.apple.com.
> etc.etc.
>
>
> So
> what's the big deal ?  Please note I'm not asking which is "better" ...
> I am just curious and interested to hear your professional opinions and
> experiences.
>
> Personally, I favour the simple option 3, multiple MX records.
>
> Thanks y'all.
>
>
>   
>
>
>
>
>   

Re: Why choose 120 volts?

[Alex H. Ryu]

Also, adding followings.

5) availability from local power provider(s)

6) local regulation such as fire department safety rules...

7) for your own safety... (120V may not kill people, but 240V can do...)


If you want better, why not just have everything to DC power ?
Something like 48V...

Alex


Wayne E. Bouchard wrote:
> 1) Equipment used to not be dual voltage
>
> 2) For smaller scale, 120V UPS and distribution equipment is usually
> cheaper
>
> 3) 120V embedded itself into operations as a result.
>
> 4) We're all lazy and hate change.
>
> On Tue, May 26, 2009 at 12:39:10PM -0700, Seth Mattinen wrote:
>   
>> I have a pure curiosity question for the NANOG crowd here. If you run
>> your facility/datacenter/cage/rack on 120 volts, why?
>>
>> I've been running my facility at 208 for years because I can get away
>> with lower amperage circuits. I'm curious about the reasons for using
>> high-amp 120 volt circuits to drive racks of equipment instead of
>> low-amp 208 or 240 volt circuits.
>>
>> ~Seth
>> 
>
> ---
> Wayne Bouchard
> w...@typo.org
> Network Dude
> http://www.typo.org/~web/
>
>
>
>   

Re: Why choose 120 volts?

[Alex H. Ryu]

I still have a couple of Ethernet cards for 10Base2, and cables. ^.^
Yes, if someone unplug or it is loosen in the middle/end, it will be fun.
I guess it's going to be another bagel/coffee time except network
support people.

Alex


Ray Sanders wrote:
> Ugh, please don't remind me of the hell that was coax. 
>
> On Tue, 2009-05-26 at 13:45 -0700, Owen DeLong wrote:
>   
>> On May 26, 2009, at 1:34 PM, Ray Sanders wrote:
>>
>> 
>>> So when one server fails, all the rest fail too?
>>>
>>> Sorting out holiday lighting is bad enough
>>>
>>> could you imagine having to go through rack after rack finding the one
>>> "burned out" server?
>>>
>>>   
>> Who has to imagine?  Some of us remember thinnet (10base2).
>>
>> Owen
>>
>> 

Re: AT&T and having two BGP peers

[Alex H. Ryu]

If it is the way AT&T have designed their product, there may be no other
way around.

>From AT&T's viewpoint, it will add more complexity to troubleshoot.

If you pay extra, AT&T may have some solution for you.


Alex


Antonio Querubin wrote:
> On Fri, 10 Jul 2009, Jay Nakamura wrote:
>
>> We are getting an Ethernet DIA circuit from AT&T but they insist that
>> they can't BGP peer with 2 routers on our side. The WAN circuit can
>> only have /30 they say. Has anyone been able to successfully talk
>> them in to bending their rule? If so, how?
>
> Sounds odd. They do IPv6 tunnels using 2 tunnels/routers. The /30
> reason is even more odd for an ethernet circuit.
>
> Antonio Querubin
> whois: AQ7-ARIN
>
>
>

Re: Cisco 7600 (7609) as a core BGP router.

[Alex H. Ryu]

Because of nowadays network scalability demands, Cisco is preparing ASR
14000 series to replace this one, I think. ^^
Basically ASR 14000 is downgrade version of CRS-1, but I consider it is
still developing or beta product.

Alex


Paul Stewart wrote:
> Agreed... we migrated away from GSR to 7600 and now looking at migrating
> back...;)  GSR was 100% rock solid for us with PRP-2 processors
> sup720-3bxl has been good but no comparison...
>
> -Original Message-
> From: Neil J. McRae [mailto:n...@domino.org] 
> Sent: Monday, July 20, 2009 6:26 AM
> To: nanog@nanog.org
> Subject: RE: Cisco 7600 (7609) as a core BGP router.
>
> Personally I'd avoid this platform given 6+ years of trying to make it
> work
> reliably. GSR is far better platform.
>
>
>
>
>  
>
> 
>
> "The information transmitted is intended only for the person or entity to 
> which it is addressed and contains confidential and/or privileged material. 
> If you received this in error, please contact the sender immediately and then 
> destroy this transmission, including all attachments, without copying, 
> distributing or disclosing same. Thank you."
>
>
>
> .
>
>   

Re: Cisco 7600 (7609) as a core BGP router.

[Alex H. Ryu]

About 3 months ago, Cisco Account Team was recommending AS14000 for our
company, and we rejected it.
Poor product development management!


Alex


Mohacsi Janos wrote:
>
>
>
> On Mon, 20 Jul 2009, Alex H. Ryu wrote:
>
>>
>> Because of nowadays network scalability demands, Cisco is preparing ASR
>> 14000 series to replace this one, I think. ^^
>> Basically ASR 14000 is downgrade version of CRS-1, but I consider it is
>> still developing or beta product.
>
>
> As far as I know Cisco cancelled ASR14000 platform, but the developed
> supervisor will be available to CRS-1 platform
>
> Janos Mohacsi
> Network Engineer, Research Associate, Head of Network Planning and
> Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
>
>>
>> Alex
>>
>>
>> Paul Stewart wrote:
>>> Agreed... we migrated away from GSR to 7600 and now looking at
>>> migrating
>>> back...;) GSR was 100% rock solid for us with PRP-2 processors
>>> sup720-3bxl has been good but no comparison...
>>>
>>> -Original Message-
>>> From: Neil J. McRae [mailto:n...@domino.org]
>>> Sent: Monday, July 20, 2009 6:26 AM
>>> To: nanog@nanog.org
>>> Subject: RE: Cisco 7600 (7609) as a core BGP router.
>>>
>>> Personally I'd avoid this platform given 6+ years of trying to make it
>>> work
>>> reliably. GSR is far better platform.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>> "The information transmitted is intended only for the person or
>>> entity to which it is addressed and contains confidential and/or
>>> privileged material. If you received this in error, please contact
>>> the sender immediately and then destroy this transmission, including
>>> all attachments, without copying, distributing or disclosing same.
>>> Thank you."
>>>
>>>
>>>
>>> .
>>>
>>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: Opensource or Low Cost NMS for Server Hardware / Application Monitoring

[Alex H. Ryu]

It really depends on your application server configuration.
Most people just uses SNMP for this purpose.
Something like net-snmp installed in servers, then monitor the info via
SNMP MIB polling.

Alex


Matthew Huff wrote:
> I think all of these comments are useful. but we are looking for NMS for
> server/application monitoring, not snmp/dmi based polling. We will need a
> system that runs custom scripts to monitor our servers (CPU, OS syslogs,
> Windows Event logs, hardware, memory, etc) and our in-house applications
> running on these servers (100+). Native agents for windows 2003, 2008, Linux
> and Solaris (both Sparc and x86) with custom scripting is a minimum
> requirements. There are a lot of good network router/switch solutions, but
> we are looking for some that are more focused on server based management. We
> used to use BMC patrol which was a very good system. We moved away from it
> because it was extremely pricey per-node and BMC absolute rejection of
> Solaris X86 as a supported platform (We went back and forth between Sun and
> BMC regarding that for over a year).
>
> 
> Matthew Huffㅤㅈㅔㄽㅤㅈㅔㄽㅤㅈㅔㄽ | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> http://www.ox.com  | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:ㅤㅈㅔㄽ 914-460-4139
>
>
>
>   
>> -Original Message-
>> From: Will Clayton [mailto:wclay...@corenap.com]
>> Sent: Wednesday, July 22, 2009 12:58 PM
>> To: nanog@nanog.org
>> Subject: Re: Opensource or Low Cost NMS for Server Hardware /
>> Application Monitoring
>>
>> Eric Gauthier wrote:
>> 
>>> Hello,
>>>
>>>
>>>   
 As for server / application / random other stuff (like printers and
 ups's and IP camera and the like), Zenoss is great -- its clean,
 simple, fast(ish), easy  and pretty -- the last one happens to be
 important for some folks (esp in the enterprise world...)

 
>>> We've looked at ZenOSS but couldn't get it to model the network.
>>> >From what we can tell, it couldn't handle the full routing table
>>> on our core routers (there are six).  If someone has successfully
>>> done this, can you contact me off list?
>>>
>>> Eric :)
>>>   
>> I like NMIS. Fast, scalable, flexible and really hackable. It doesn't
>> take much time to get it up and running but selling others on it can be
>> challenging. It works off of flat tab delimited text files making
>> populating the node base pretty easy. There are plans for NMIS5 to use
>> database connectivity for this which will be even more fun. There are
>> external contributions that do everything from RANCID to Flash maps of
>> your network. The home page is here:
>>
>> http://sins.com.au/nmis/
>>
>> But has since moved to sourceforge:
>>
>> http://sourceforge.net/projects/nmis/files/
>>
>> With the gang being here:
>>
>> http://tech.groups.yahoo.com/group/nmis_users/
>>
>> While not for everyone and not as popular or pretty as some of the
>> others, it is a network monitoring system built by engineers for
>> engineers. With a combination of SNMP data collection and ping/service
>> tests, bandwidth utilization alerts, alert groups, thresholds etc. can
>> be adjusted on a per-device basis and just a week of utilization can
>> really help you identify points on the network that need to be cleaned
>> up.
>>
>> I guess my favorite part is the ability to write device interface
>> descriptions to trigger actions in the Perl script since that data is
>> collected via SNMP.
>>
>> --
>> Will Clayton
>>
>> 
>
>   

Re: Single router for P/PE functions

[Alex H. Ryu]

What if there is a problem from software, filter, mis-configuration from
one of the routers ?
It will affect whole ring network, not just that problem router.

Also if there is routing protocol bounce because of link flapping, it
will be propagate through the ring forever.

Alex

Serge Vautour wrote:
> We're trying to save on Transport links. Instead of multi-homing each PE to 2 
> Ps, we're considering building a ring: P-PE-PE-PE-P. This ring follows the 
> transport ring. Each link would be engineering to make sure it can handle all 
> of the traffic from all 3PEs in case of a failure. As the network grows, we 
> could get individual transport links from PE-P.
>
> Apart from bandwidth, I was curious if there were other problems I related to 
> doing this that I wasn't thinking of. Thanks for all the replies. Much 
> appreciated.
>
> Serge
>
>
>
>
> 
> From: William McCall 
> To: Serge Vautour 
> Cc: nanog@nanog.org
> Sent: Friday, September 4, 2009 1:07:40 AM
> Subject: Re: Single router for P/PE functions
>
> Kinda depends on what you're doing exactly, but like Erik said, it certainly 
> possible and depending on your particular needs, it might not be much of an 
> issue at all.
>
> Can you describe your scenario a bit more?
>
> --WM
>
>
> On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour  wrote:
>
>   
>> Hello,
>>
>> 
>>> I'm pretty confident that a router can be used to perform P & PE functions 
>>> simultaneously. What about from a best practice perspective? Is this 
>>> something that should be completely avoided? Why? We're considering doing 
>>> this as a temporary workaround but we all know temporary usually lasts a 
>>> long time. I'd like to know what kind of mess awaits if we let this one go.
>>>   
>>> Thanks,
>>>   
>> Serge
>>
>>
>>
>>
>> 
>>>  __
>>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
>>> favourite sites. Download it now
>>>   
>> http://ca.toolbar.yahoo.com.
>>
>>
>> 
>
>
>   

Re: Cisco 7600 vs ASR 9000

[Alex H. Ryu]

What about 7600-S models ?
I think Cisco is claiming that Cisco 7600-S (7606S, etc...) chassis is
ready for less than 50 ms switching time with right software.
For routing, you can setup graceful restart or something like that.


For Cisco ASR9000, I couldn't say much, because it is new product.
When I checked Cisco product lines around January 2009, it wasn't there.
So I consider it as still beta test product at customer's expense. :-)


Alex


Nick Colton wrote:
> I work for a small CLEC, we have been doing FTTP for 5 years now but are
> getting ready to update our core network and introduce IPTV services.  Cisco
> has been recommending the Cisco 7600 as our core router.  My concern is that
> cisco told us that in the event of an RSP failover the 7600 could take up to
> 30 seconds to begin routing packets again, this seems wrong to me since my
> old Extreme Networks BD 6808 can do failovers and rebuild route tables in
> under 5 seconds but??  More recently I have been reading up on the ASR 9000
> however and it appears that it would be better sized for our company than
> the 7600.  A few questions I have for the group.
> 1.  Has anyone used the ASR 9000 in place of a Cisco 7600?
>
> 2.  Is the ASR 9000 Carrier ready?  Meaning 5x9's of availability, few
> component failures, solid software...etc
>
> 3.  Has anyone had issues where it took the 7600 30 seconds to start routing
> again after an RSP failover?
>
> Thanks,
>
> Nick
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   

Re: Cogent leaking /32s?

[Alex H. Ryu]

If there is DDoS attack going on from/to specific /32, sometimes they do
that to avoid too much overload for the network.
Cogent should give the answer for what's going on.

Alex

Zak Thompson wrote:
> We had a problem with cogent about a year ago.  Somehow.. cymru was
> announcing a /32 of ours and black holing it for whatever reason.  It
> was removed but wasn't happy that cogent was allowing cymru to do this
> sort of action.  To this date we do not have a valid reason from cogent
> on why they allowed this to happen.
>
> Cheers,
> Zak Thompson
>
>
>
> -Original Message-
> From: ML [mailto:m...@kenweb.org] 
> Sent: Friday, October 02, 2009 7:23 AM
> To: nanog@nanog.org
> Subject: Cogent leaking /32s?
>
> I received an alert from Cyclops telling me a probe in AS513 had seen a 
> /32 that I announce to Cogent for one of our BGP sessions.
>
> Did anyone else see this?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   

Re: No route to verizon

[Alex H. Ryu]

It may be.
If the customer is BGP customer, and they have connectivity problem,
your traffic will flow into Verizon since Verizon have supernet.
But within Verizon network, Verizon router doesn't have specific route
info to route into.
So you may see time-out as soon as it hit Verizon network.

Alex


Sharlon R. Carty wrote:
> Ok thanks everyone.
> I'll be contacting Verizon. 
>
> I do not believe the issue lies with the customer not paying their bills.
>
> -Original Message-
> From: Justin M. Streiner [mailto:strei...@cluebyfour.org] 
> Sent: Monday, December 15, 2008 3:21 PM
> To: nanog@nanog.org
> Subject: Re: No route to verizon
>
> On Mon, 15 Dec 2008, Sharlon R. Carty wrote:
>
>   
>> This is my first post.
>>
>> Can anyone provide some info or Verizon why there is no connectivity to
>> Verizon CA(Verizon Business UUNETCA8-A)?
>> Can not reach the following net range: 66.48.66.160 - 66.48.66.175
>> 
>
> Your best bet might be to call Verizon directly, as a range this small is 
> not likely to be seen in the global routing table as a free-standing 
> route.  I see 66.48.0.0/16 from my transit providers, originated from 
> AS701, which is what I'd expect to see.
>
> Beyond that, your post doesn't contain enough information to do much more 
> troubleshooting.
>
> jms
>
>
>
>
>
>   

begin:vcard
fn:Alex Ryu
n:Ryu;Alex
org:Norlight Large Enterprise / KDL, Inc. ;IP Engineering
adr:;;13935 Bishops Drive;Brookfield;WI;53005;USA
email;internet:r.hyuns...@ieee.org
title:Senior Network Engineer
tel;work:+1-262-792-7965
tel;fax:+1-812-206-4682
tel;cell:+1-262-389-0638
x-mozilla-html:FALSE
url:www.kdlinc.com
version:2.1
end:vcard

Re: What is the most standard subnet length on internet

[Alex H. Ryu]

Also one of the reason why not putting default route may be because of
recursive lookup from routing table.
If you have multi-homed site within your network with static route, and
if you use next-hop IP address instead of named interface, you will see
the problem when you have default route in routing table.
For an example, if you have "ip route 1.0.0.0 255.0.0.0 2.2.2.2".
If the interface for 2.2.2.2 is down, 1.0.0.0/8 will be still be in the
routing table because 2.2.2.2 can be reached via default route
(0.0.0.0/0) from routing table recursive lookup.
Therefore the traffic for 1.0.0.0/8 will be forwarded to "0.0.0.0/0"
next-hop ip address, and customer fail-over scenario will not be working
at all.

Only way to resolve this problem is... Actually three...
1) Use named interface such as "serial 1/0" instead of "x.x.x.x" IP
next-hop address.
But sometimes this is not an option if you use ethernet circuit or
something like Broadcast or NBMA network.

2) Use BGP with private ASN...

3) Do not install default route in your routing table





Grzegorz Janoszka wrote:
> Nathan Ward wrote:
 Let me rephrase; Are there people who are filtering /24s received from
 eBGP peers who do not have a default route?
>>>
>>> of course.
>>
>> Curiously, it was really meant as a rhetorical question where the
>> answer was "no".
>>
>> Why are people doing this? Are they lacking clue, or, is there some
>> reasonable purpose?
>
> Memory mostly I think. /24 prefixes are ~ the half of all prefixes,
> but they cover only a small percent of the address space.
> If your router has > 6 full BGP sessions, you can filter /24 on half
> of them, your memory usage will drop significantly.
>

begin:vcard
fn:Alex Ryu
n:Ryu;Alex
org:Norlight Large Enterprise / KDL, Inc. ;IP Engineering
adr:;;13935 Bishops Drive;Brookfield;WI;53005;USA
email;internet:r.hyuns...@ieee.org
title:Senior Network Engineer
tel;work:+1-262-792-7965
tel;fax:+1-812-206-4682
tel;cell:+1-262-389-0638
x-mozilla-html:FALSE
url:www.kdlinc.com
version:2.1
end:vcard

Re: Level 3 issues

[Alex H. Ryu]

It seems that there was fiber cut because of train derailment around NY
area.

Alex



Blake Pfankuch wrote:
> Any word on the actual cause of the issue?
>
> From: Derek Bodner [mailto:subscribedli...@derekbodner.com]
> Sent: Sunday, December 28, 2008 11:53 AM
> To: Blake Pfankuch
> Cc: Jon Wolberg; Jason Cheslock; nanog@nanog.org
> Subject: Re: Level 3 issues
>
> Looks like most providers here in the east coast are routing through level3 
> again, and I'm not seeing any packet loss or latency anymore.
> On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch 
> mailto:bpfank...@cpgreeley.com>> wrote:
> Seems to be normalizing here in Colorado as well, however still having 
> occasional packet loss to NY.
>
> -Original Message-
> From: Jon Wolberg 
> [mailto:j...@defenderhosting.com]
> Sent: Sunday, December 28, 2008 11:40 AM
> To: Jason Cheslock
> Cc: nanog@nanog.org
> Subject: Re: Level 3 issues
>
> Confirmed here as well.
>
>
> Jon
>
>
> - Original Message -
> From: "Jason Cheslock" mailto:sangrevie...@gmail.com>>
> To: "marco" mailto:ma...@zero11.com>>
> Cc: nanog@nanog.org
> Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Level 3 issues
>
> According to L3, this issue should be fixed and we should start seeing
>
>   
>> the traffic normalizing.
>> Can anyone confirm?
>> 
>
> Here in Richmond Virginia, everything seems to be back to normal now.
>  Traffic coming from my Comcast connection can get through L3 now.
>
>
>  7 11 ms 13 ms 11 ms 
> te-0-3-0-0-cr01.mclean.va.ibone.comcast.net
>  [68.
> 86.91.121]
>  8 10 ms 11 ms 12 ms 
> xe-11-1-0.edge1.Washington1.Level3.net
>  [4.79.231
> .9]
>  9 12 ms 17 ms 18 ms 
> vlan89.csw3.Washington1.Level3.net 
> [4.68.17.190]
>
>  10 12 ms 17 ms 17 ms 
> ae-84-84.ebr4.Washington1.Level3.net
>  [4.69.134.1
> 85]
>  11 16 ms 26 ms 16 ms 
> ae-3-3.ebr1.NewYork1.Level3.net 
> [4.69.132.94]
>  12 32 ms 30 ms 17 ms 
> ae-81-81.csw3.NewYork1.Level3.net 
> [4.69.134.74]
>
>  13 15 ms 19 ms 16 ms 
> ae-3-89.edge1.NewYork1.Level3.net 
> [4.68.16.142]
>
>
>
> --
> Derek Bodner
> subscribedli...@derekbodner.com
>
>
>
>   

Re: Circuit numbering scheme - best practice?

[Alex H. Ryu]

I think it is really depending on what kind of provisioning system you
have.
Circuit ID is determined by your provisioning system for CLR/DLR reference.
As long as you can find circuit info quickly, it doesn't matter that much.

Alex


Jay Hennigan wrote:
> We've grown to the point that "The MCI T-1 in Ontario" or "Bob's
> ethernet to port 6/23 on switch 7" aren't scaling. Also in working
> with carriers we are frequently asked to provide our internal circuit
> number.
>
> I've seen a lot of the the LEC scheme NN--NN where  has
> some significance with regard to the speed and type of circuit. The
> leading NN seems to be a mystery and the trailing NN is a serial
> number.
>
> I've also seen DS1-NNN as a straight speed-serial number type of
> thing and horrendously long circuit numbers including CLLI codes such
> as 101/T3/SNLOCAGTH07/SNLOCA01K15 .
>
> Any suggestions from those who have been down this road as to a schema
> that makes sense and is scalable? Are there documented best practices?
>
> -- 
> Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
> Impulse Internet Service - http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
>
>
>

Re: APNIC offline

[Alex H. Ryu]

Website www.apnic.net is not accessable from my desktop, either.

But it is responded with ping, so it may be the issue with specific
application such as web server daemon?

Alex


manolo wrote:
> All,
>
> Is anyone else seeing www.apnic.net offline? I have tried from two
> locations and the website does not respond. whois is working as
> expected though.
>
>
>
> Manolo
>
>
>

Re: Redundant AS's

[Alex H. Ryu]

Not all of Cisco IOS supports 4-byte ASN.

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html

Alex


Nick Hilliard wrote:
> On 21/03/2009 16:36, bmann...@vacation.karoshi.com wrote:
>> er... 'parm me sir, but aren't -all- ASNs 4 bytes?
>>
>> i mean, for lo these many years we cheated and only
>> used the first two bytes... but the spec always
>> called out four bytes.
>
> There seems to be a bug in my router:
>
>> router(config)#router bgp 196641
>> ^
>> % Invalid input detected at '^' marker.
>>
>> router(config)#
>
> Do you know of anyone I could call who can fix this?
>
> Nick
>
>
>

Re: Fiber cut in SF area

[Alex H. Ryu]

Hey Chris,

Yes. outa...@outages.org is the one.

Alex


Christopher Morrow wrote:
> isn't there a mailing list for this sort of thing? outages@ I think it is?
>
> (not that I mind, just a little advert for the appropriate forum, and
> a place that MAY have some useful info on this topic)
> -chris
>
> On Thu, Apr 9, 2009 at 1:51 PM, Ravi Pina  wrote:
>   
>> News coverage:
>>
>> http://cow.org/r/?5459
>> http://cow.org/r/?545a
>>
>> And not that I expect any useful updates:
>>
>> http://twitter.com/attnews
>>
>> -r
>>
>> On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote:
>> 
>>> Just dropping a note that there is a fiber cut in the SF area (I have a
>>> metro line down). ㅤㅈㅐㄽboveNet is reporting issues and I've heard unconfirmed
>>> reports that ATT and VZW are affected as well.
>>>
>>> Rgs,
>>> craig
>>>
>>>
>>>   
>> 
>
>
>
>
>   

Re: Level3 funkiness

[Alex H. Ryu]

maybe host problem?
I can reach to www.level3.com, but not www.level3.net.
It seems both are belonging to same subnet.



Brandon Galbraith wrote:
> In Chicago, traceroutes are dying in the same place (Denver). Peered out of
> 350 Cermak.
>
> -brandon
>
> On Wed, Apr 15, 2009 at 2:45 PM, Charles Mills  wrote:
>
>   
>> Can't get to level3.net 63.211.236.36 or www.level3.net 4.68.95.28 from
>> Pittsburgh either and I peer directly with level3 with a full BGP feed.
>>
>>
>>
>> On Wed, Apr 15, 2009 at 3:35 PM, J. Oquendo  wrote:
>>
>> 
>>> Anyone else experience sporadic funkiness via
>>> Level3? I can't even reach the main website from who
>>> knows how many networks I've tried. Also friends
>>> and former colleagues have tried to reach the site
>>> to no avail.
>>>
>>> One of my machines on AT&T:
>>> # traceroute level3.net
>>> traceroute to level3.net (63.211.236.36), 30 hops max, 40 byte packets
>>>
>>>  4  cr1.n54ny.ip.att.net (12.122.105.58)  11.285 ms  21.702 ms  21.477
>>>   
>> ms
>> 
>>>  5  ggr2.n54ny.ip.att.net (12.122.131.141)  12.712 ms  10.194 ms  16.393
>>> ms
>>>  6  so-8-0-0.car3.NewYork1.Level3.net (4.68.127.149)  9.975 ms  10.019
>>>   
>> ms
>> 
>>>  10.833 ms
>>>  7  vlan79.csw2.NewYork1.Level3.net (4.68.16.126)  10.162 ms  10.189 ms
>>>  14.474 ms
>>>  8  ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69)  15.763 ms  11.166
>>>   
>> ms
>> 
>>>  9.725 ms
>>>  9  ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93)  16.139 ms  30.616
>>>   
>> ms
>> 
>>>  16.275 ms
>>> 10  ae-64-64.csw1.Washington1.Level3.net (4.69.134.178)  15.684 ms
>>> ae-74-74.csw2.Washington1.Level3.net (4.69.134.182)  21.870 ms
>>> ae-84-84.csw3.Washington1.Level3.net (4.69.134.186)  28.729 ms
>>> 11  ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157)  17.035 ms
>>> ae-62-62.ebr2.Washington1.Level3.net (4.69.134.145)  17.041 ms
>>> ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149)  21.940 ms
>>> 12  ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69)  31.671 ms  42.407 ms
>>>  45.774 ms
>>> 13  ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113)  31.922 ms  32.115
>>>   
>> ms
>> 
>>>  38.135 ms
>>> 14  ae-3.ebr2.Denver1.Level3.net (4.69.132.61)  75.265 ms  67.528 ms
>>>  67.937 ms
>>> 15  ge-9-0.hsa1.Denver1.Level3.net (4.68.107.35)  62.587 ms !H
>>> ge-9-1.hsa1.Denver1.Level3.net (4.68.107.99)  62.543 ms !H
>>> ge-9-2.hsa1.Denver1.Level3.net (4.68.107.163)  75.797 ms !H
>>>
>>>
>>> (From Texas through Above.net)
>>> $ traceroute level3.net|tail -n 1
>>> traceroute to level3.net (63.211.236.36), 64 hops max, 40 byte packets
>>> 11  ge-6-2.hsa1.Denver1.Level3.net (4.68.107.131)  21.473 ms !H *
>>> ge-6-0.hsa1.Denver1.Level3.net (4.68.107.3)  21.547 ms !H
>>>
>>> Confirmed it can't be reached from Travelers Ins, The
>>> Hartford, none of my connections. Anyone else seeing
>>> issues? I'm seeing drop off from clients going through
>>> their Atlanta interconnects with Charter and two other
>>> providers, which I can't make sense of. I DO KNOW they
>>> experienced some sort of issue with a TDM switch or so
>>> they said... Very broad statements: "We know teh
>>> interwebs are down please stand by"
>>>
>>> I know websites are one thing, but the chances of the
>>> website going down, a TDM switch being wacky and now
>>> clients traversing their networks complaining all at
>>> once seems a little out of the ordinary.
>>>
>>> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>>> J. Oquendo
>>> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP
>>>
>>> "It takes 20 years to build a reputation and five minutes to
>>> ruin it. If you think about that, you'll do things
>>> differently." - Warren Buffett
>>>
>>> 227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
>>>
>>>
>>>
>>>   
>> --
>>
>> 
>
>
>
>   

Re: IXP

[Alex H. Ryu]

Theorically it's doable.
But mostly No to your questions.

IXP means Internet eXchange Point.
So it is public Internet. Why do you want to use private IP address ?

Most RIR allocate /24 unit for IXP.
For troubleshooting purpose, it is better to use public IP address as it
is designed.
Unless you want to have MPLS/VPN only connections, and use private IP
Addr/ASN between them.



Sharlon R. Carty wrote:
> Hello NANOG,
>
> I like would to know what are best practices for an internet exchange. I
> have some concerns about the following;
> Can the IXP members use RFC 1918 ip addresses for their peering?
> Can the IXP members use private autonomous numbers for their peering?
>
> Maybe the answer is obviuos, but I like to know from any IXP admins what
> their setup/experiences have been.
>
>   

1.0.0.0/8 route from MERIT ?

[Alex H. Ryu]

Today I jumped into one of our routers, and I found that 1.0.0.0/8 is
announced from AS237, which is MERIT.


NetworkNext HopMetric LocPrf Weight Path
*>  1.0.0.0/8  4.59.200.5  0  60 0  (65001
65105) 3356 7018 237 i

Is this supposed to be?
I thought 1.0.0.0/8 is allocated to APNIC.


Alex