- Test - lists.nanog.org

Sprint/Verizon BGP
by Edward Brookhouse 05 Aug '09

05 Aug '09

Hi all, Any Sprint BGP admins on this list can offer any thoughts on why Sprint connected networks are preferring my Sprint connection when they should be preferring my Verizon? I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and 63.78.31.0/24, being announced by sprint and Verizon, preferred to Verizon(DS3) over Sprint 3MB. Verizon BGP admins think everything is ok, have not heard back from BGP4 at sprint. Any thoughts appreciated, off-list contact welcome. Edward ebroo(a)healthydirections.com

5 4

cisco.com
by R. Benjamin Kessler 05 Aug '09

05 Aug '09

Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com) any ideas on the cause and ETR? Thanks, Ben

34 38

IM based BGP route-server interface
by mkarir 05 Aug '09

05 Aug '09

All, We have been experimenting with Instant Messaging as an interface for providing easier access to a route-server. (no longer need to telnet xyz or use annoying web forms). We have essentially created a BGP chat bot. You can reach it by adding AIM: bgpbotz ( or Jabber: bgpbotz(a)jabber.merit.edu) to your buddy list. Just type 'help' or '?' to get started or 'examples'. Most normal route-server queries are supported. You should be able to view routes from Merit's perspective by querying bgpbotz. We would really appreciate any feedback on this project. The website is at: http://software.merit.edu/bgpbotz As bgpbotz is essentially just a query interface to an underlying route-server we would be happpy to add your BGP feeds to our installation and make them available as "views" for other people to query. Please feel free to contact us if you are interested in setting this up. Alternately you can download the chat bot code from the website and run it yourself. In that case please let us know so that we can add your bot to the project website. All comments are welcome. Thanks Eric Wustrow Manish Karir (Merit Network Inc.)

1 0

RE: cisco.com
by Matthew Huff 04 Aug '09

04 Aug '09

Disregard. This was from 2 years ago. Copied the link and verbage without verifying it. My bad. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// <http://www.otaotr.com/> www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Matthew Huff Sent: Tuesday, August 04, 2009 11:19 AM To: 'Myke Lyons' Cc: 'nanog(a)nanog.org' Subject: RE: cisco.com http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to Cisco.com <http://www.cisco.com> has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused Cisco.com <http://www.cisco.com> and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by <http://blogs.cisco.com/authors/bio/46> Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// <http://www.otaotr.com/> www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Myke Lyons [mailto:Myke.Lyons@cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog(a)nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 Disregard. This was from 2 years ago. Copied the link and verbage without verifying it. My bad. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[1]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg@01CA14F5.A289E6D0] From: Matthew Huff Sent: Tuesday, August 04, 2009 11:19 AM To: 'Myke Lyons' Cc: 'nanog(a)nanog.org' Subject: RE: cisco.com [2]http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to [3]Cisco.com has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused [4]Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by [5]Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[6]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg@01CA14F5.A289E6D0] From: Myke Lyons [mailto:Myke.Lyons@cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog(a)nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 References 1. http://www.otaotr.com/ 2. http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ 3. http://www.cisco.com/ 4. http://www.cisco.com/ 5. http://blogs.cisco.com/authors/bio/46 6. http://www.otaotr.com/

1 0

Re: cisco.com
by deleskie＠gmail.com 04 Aug '09

04 Aug '09

So cisco has no BGP is that what I'm hearing... Oh the irony :) ------Original Message------ From: Aaron Millisor To: R. Benjamin Kessler Cc: nanog(a)nanog.org Subject: Re: cisco.com Sent: Aug 4, 2009 10:45 AM Not sure the ETA but the network that the address for cisco.com resolves to (198.133.219.0/24) is no longer in BGP. -- ----------------------------------------------------- Aaron Millisor R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com) any ideas on the cause and ETR? > > Thanks, > > Ben > > Sent from my BlackBerry device on the Rogers Wireless Network

9 8

Re: cisco.com
by deleskie＠gmail.com 04 Aug '09

04 Aug '09

Facebook up. Cisco down. From eastern canada ------Original Message------ From: Alex Nderitu To: R. Benjamin Kessler Cc: nanog(a)nanog.org Subject: Re: cisco.com Sent: Aug 4, 2009 10:42 AM Facebook seems to also be affected. -----Original Message----- From: R. Benjamin Kessler <rbk(a)mnsginc.com> To: nanog(a)nanog.org Subject: cisco.com Date: Tue, 4 Aug 2009 09:34:46 -0400 Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com) any ideas on the cause and ETR? Thanks, Ben -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Sent from my BlackBerry device on the Rogers Wireless Network

3 2

Smart hands in NYC area
by Elmar K. Bins 04 Aug '09

04 Aug '09

Hello friendly NANOGers, we'll have to move out of a colo in the NYC area (Verizon DC Elmsford) soon and I need two guys to disassemble half a rack full of equipment, pack the stuff securely and send it away in two batches (one within the US, one to Germany). Packing material needs to be brought, I suppose. The setup has been there for a while - unlikely Verizon kept the material. Can anyone refer me to a company that can help me there, or offer their own services? Thanks for your help, Elmar.

1 0

Re: caches for peer-to-peer trafic
by Murtaza 04 Aug '09

04 Aug '09

Guys! Thank you very much for your responses. Anymore responses will also be very much appreciated. On Fri, Jul 31, 2009 at 6:00 PM, Charles Gucker <cgucker(a)onesc.net> wrote: > Sandvine Thanks and Regards, Ghulam Murtaza PhD Student, Lahore University of Management Sciences

2 1

Fwd: Weekly Routing Table Report
by Zartash Uzmi 03 Aug '09

03 Aug '09

A response I received from Mark Tinka on afnog mailing list. Reposting for the nanog community: ---------- Forwarded message ---------- From: Mark Tinka <mtinka(a)globaltransit.net> Date: Mon, Aug 3, 2009 at 7:55 AM Subject: Re: Weekly Routing Table Report To: Zartash Uzmi <zartash(a)gmail.com> Cc: pfs(a)cisco.com, afnog(a)afnog.org On Monday 03 August 2009 07:29:28 am Zartash Uzmi wrote: <deleting other mailing lists and such> > Apologies if this is too naive to ask... Any question is a good question. > but is there some > detail available about the items listed in the summary? This is probably the link you seek: http://thyme.apnic.net/about.html > 1) In particular, what exactly is the difference between > the "BGP routing table entries examined (292961)" and > "Unique aggregates announced to Internet (145391)"? What this tells us is, assuming all routing entries "currently" present in the routing table (as seen by the infrastructure that enables this weekly CIDR report) were aggregated, the maximum number of routing entries, as at the point this report was generated, would be 145,391; just a little shy of half what we're seeing today. > 2) I believe 292961 is the worst case routing table size > for any router. Well, different networks will see slightly different views (more or less), but yes, the average number each DFZ (default-free zone) is seeing would be just about there. But if you mean the number of routing entries each router can support, then that's a different issue. This depends on a number of factors, particularly, the router's architecture. <At the risk of massively derailing this thread, little primer on routing architectures follows, for perspective> Software-based routers will, generally, hold as many routing entries as the amount of RAM they have can support. A number of software-based routers today support 2GB of RAM, e.g., Cisco's 7201 or 7206-VXR/NPE-G2, or Juniper's J4350 and J6350 routers. The limitation, obviously, is because packet forwarding occurs in the CPU path (a software Interrupt process, hence the name, "software-based routers"), there is a finite amount of traffic software-based platforms can forward, especially with other features enabled, before they run out of ideas, so to speak :-). Hardware-based routers, on the other hand, segment the process of handling routing entries and forwarding traffic, in a somewhat distributed fashion. Hardware-based routers typically have what are known as control planes and data planes. Control planes handle management and such house- keeping functions, which includes BGP. This function is generally similar to what you see in software-based routers, in that RAM is abundant (up to 4GB in today's largest systems) to hold as many routing entries from as many paths as possible. Where hardware-based routers differ from their software- based cousins is how routing entries are used to forward traffic. Once BGP has chosen the best path to all destinations in the control plane, those best paths are then "downloaded", if you will, to the router's data plane, which is normally a special chip that has a single function - forward traffic as quickly as possible. Dumb, but very efficient. The vendors call these ASIC's (Application Specific Integrated Circuits) or Programmable Chips. These ASIC's or Programmable Chips usually hold only one routing entry at a time, even though the control plane can have several copies of the same routing entry, as seen from multiple BGP paths. These ASIC's/Programmable Chips use expensive, specialized memory to hold these entries; it could be TCAM (Ternary Content Addressable Memory), SSRAM (Synchronous Static RAM), RLDRAM (Reduced Latency DRAM), e.t.c. These are high-speed types of memory that are built, in most cases, for networking applications, e.g., routers, switches, e.t.c., and work at very high bandwidths, supporting high-speed route entry look-ups, which allows hardware-based routers to forward traffic at the speeds they do, e.g, 1Gbps, 10Gbps, 40Gbps, e.t.c. The reason I brought this up is because the explosion of the IPv4 Internet routing table is putting pressure on routers, more specifically, hardware-based routers. This is because TCAM, SSRAM, RLDRAM, e.t.c., is very expensive, and as such, has a finite number of entries they can hold (I say entries because on some platforms, entries includes IPv4 routes, IPv6 routes, MPLS LSP's, ACL's, NetFlow data, e.t.c.). Upgrading these means swapping out expensive data plane infrastructure, which many service providers would like to avoid, if at all possible. </At the risk of massively derailing this thread, little primer on routing architectures follows, for perspective> > If the unique aggregates announced to the > Internet is 145391, how does the routing table size > anywhere may exceeds this number? For the very reasons we receive this report on a regular basis, to remind us of what we could do to reduce the pollution of the routing table, and hence, increase the lifetime of the (powerful?) routers we have in the network that can no longer serve us because they can't hold anymore routing entries without falling over. I wouldn't do Philip Smith's live presentation of the state of the Internet routing table any justice by trying to explain it here :-), but basically, we see about 50% more routing entries than we should mainly due to de-aggregation. This happens for a number of reasons, but one of the main ones is traffic engineering, where networks announce longer versions of their prefixes in order to balance inbound traffic to their network. This is usually a noble, commercially-driven decision, but with the side effects explained above. Cake, eat, both... :-). > 3) Is aggregation done at a particular router for (i) > reducing the table size in that router, or (ii) reducing > the number of announced prefixes by that router, or (iii) > both? Border and peering routers are generally the ones that face the world. They connect to the Internet either by purchasing transit from upstream providers, or peering with other networks privately or at public exchange points. Aggregation is typically done inside your network, but whatever the case, the prefixes that these routers announce to the outside should, ideally, be aggregates of the allocations a network receives from its RIR. Different networks implement this differently, e.g., some networks configure and announce aggregates on their border and peering routers, while others, like us, do the same on the route reflectors, which I think scales better if you have multiple border and peering routers spread across the network. But as you can tell, this is an internal design issue - the end goal is to announce to the world only what you need to announce to the world, and hopefully, keep the Internet routing table lean & mean. Hope this helps. Cheers, Mark.

1 0

Verizon Wireless Engineer
by Chandler Bassett 03 Aug '09

03 Aug '09

Greetings, Can a Verizon Engineer contact me off list in regards to their 3G Air Cards? Thanks much. - Chandler

1 0