- NANOG - lists.nanog.org

Level3
by Robert Mathews 23 Jun '05

23 Jun '05

Good morning.. Have any noted significant performance issues (routing loops etc.) in interconnects with Level3 infrastructure - particularly in Chicago, New York or Seattle within the last 4 days? Any feedback offline would be great. Thank you.

1 0

Re: Localized mail servers, global scope
by Dave Stewart 23 Jun '05

23 Jun '05

>how many different bandaids are applied. It is time >to re-engineer with the benefit of hindsight. However desirable this may be, don't you agree that no matter what mechanism comes along, there's a huge inertia to overcome. We can debate the correct way to handle email forever. But of greater interest would be how you're going to get everyone to go along and change.

1 0

RE: md5 for bgp tcp sessions
by Barry Greene (bgreene) 23 Jun '05

23 Jun '05

> my understanding is that md5 is still checked before the > ttl-hack check takes place on cisco (and perhaps most router > platforms). new attack vector for less security than you had > before. oh well. ras: > can you confirm that it is possible to implement ttl-hack and > have it check *before* md5 signature checks? You do not have a correct understanding of how GPTM is suppose to work. If you can, you need to do this check as close to the punt out of the data plane as possible. Optimally in the ASIC (if the ASIC can be coded to do a TTL check). On Cisco gear we're coding from inside out - doing GPTM in the routing code (BGP) - then in the receive path wrapper (rACL and CoPP) - then in the ASIC raw queue (if it can) - then in the ASIC's receive path primitives. The GPTM was all about dropping the packet before they got near the route process. If you want more details, let me know and I'll send them privately.

1 0

openning party on 06/25/2005 11pm Coordinated Universal Time
by codewarrior＠cuseeme.de 23 Jun '05

23 Jun '05

morning all , experts i am proud to announce a european cuseeme test reflector cuseeme was a free available peer 2 peer multiconferencing videoconferencing application for mac and pc more info about installation and history: http://www.cuseeme.de/ its open now cuseeme.dyndns.tv CID 0 64/150 regards the the cu-team *********************************** join its free http://www.isabel.de/ and support free cuseeme

1 0

Re: OSPF -vs- ISIS
by Dan Evans 23 Jun '05

23 Jun '05

Thanks to everyone who offered advice and links to resources. The information I've gathered with your help will greatly assist me moving forward, regardless of our decision on which protocol to use. Regards, Daniel

1 0

RE: OSPF -vs- ISIS
by Barry Greene (bgreene) 22 Jun '05

22 Jun '05

> For more information, see the talk by Dave Katz at > http://www.nanog.org/mtg-0006/katz.html > > Also, AOL's experience in switching from OSPF to ISIS is > covered at http://www.nanog.org/mtg-0310/gill.html > the PDF on that page is actually an older version. The full > version I used at NANOG is available at > http://www.vijaygill.com/oi.pdf Add Ryan's talk about other security benefits of ISIS: Implications of Securing Backbone Router Infrastructure http://www.nanog.org/mtg-0405/mcdowell.html Also look at the other ISIS talks and tutorials here: http://www.nanog.org/subjects.html#I

2 1

Shared bandwidth and QoS
by Eric Gauthier 22 Jun '05

22 Jun '05

Heya, We have a situation where multiple organizations are all going to be sharing a gigabit ethernet based Internet feed. We've each agreed to "purchase" a percentage of the cost of the feed. The topology is roughly: (Inbound GigE 802.1q Trunk) ----------------------------------->Collective Router w/eBGP to ISP------>ISP | --Org #1, eBGP Peer 1, SubInt 1 | --Org #2, eBGP Peer 2, SubInt 2 | | .. etc What we'd like to do is to set things up so that each institution always has access to their percentage of the ISP link bandwidth and, if there is additional bandwidth available, provide that everyone. The only way I can think to accomplish this is via rate limits and priority queuing, but it looks as though I'll need to mark and/or rewrite the TOS bits in everyone's packets to do so. Does anyone have a better way of accomplishing this? Eric :)

1 0

Re: OSPF -vs- ISIS
by Eric Gauthier 22 Jun '05

22 Jun '05

On Tue, Jun 21, 2005 at 03:16:06PM +0100, Richard Dumoulin wrote: > Hi Eric, what's the reason for migrating to ISIS? There are currently a few projects that we're doing which prompted us to take a look at how we're doing routing, both IGP and EGP. We're altering our border connectivity by spreading our multiple commodity Internet and Internet2 peers across multiple routers that connect into our core at multiple locations. As a result, we're likely to bring iBGP into our core and, clearly, this is going to alter our IGP setup. We're also looking into MPLS layer 2 VPNs to solve certain traffic classification issues (e.g. limiting I2 access, allowing "guest wireless" etc), which also means that we'd likely need to make modifications to our IGP/EGP setup. Though we filter OSPF multicast traffic, we wanted to add in MD5 passwords to our neighbors. We're deploying IPv6 within our campus, so we needed to look for an IGP to support this. Since we're going to have to make changes, some significant, to our IGP setup (currently multi-area OSPF) no matter what, we felt it made sense to review our options. It looks like IS-IS and OSPF are pretty much the same in terms of functionality. IS-IS, though, looks like it handles IPv6 networks more efficiently, its area scheme seems to match a little more to our topology, and the "security' element (i.e. you can't inject packets) of the adjacencies seems interesting. Also, as I said, we're likely going to move to an iBGP-based core, which seems to run parrallel to what service providers are doing, so I have to admit that "follow the leader" also played into the decision as larger ISP seem to be doing the iBGP/IS-IS combo. Eric :)

1 0

IANA IPv4 allocations and bogon updates: 74/8, 75/8, 76/8, 189/8, 190/8
by Rob Thomas 22 Jun '05

22 Jun '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, all. The numerous Team Cymru bogon projects have been updated as of 17 JUN 2005 to reflect the following IANA allocation made on 17 JUN 2005: 074/8 Jun 05 ARIN (whois.arin.net) 075/8 Jun 05 ARIN (whois.arin.net) 076/8 Jun 05 ARIN (whois.arin.net) 189/8 Jun 05 LACNIC (whois.lacnic.net) 190/8 Jun 05 LACNIC (whois.lacnic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQrjLPlkX3QAo5sgJAQFHwAP/Z8KrLp9id6PD51KNEjAlveJCxRnvP4ev RofqRMex1SB5itogkB4O6JmrpSqIjqgM2GsnAUREZr5/r2ekdAZwejT85zHftl92 3ExvEec3P2PVDdfWF5v9TSVWfzwwbMW2HWwymzUYT7klWpjblcUUPdAWl+khD+FU /C8cCA2b8qk= =JvMq -----END PGP SIGNATURE-----

1 0

Re: Email peering
by Ben Hubbard 21 Jun '05

21 Jun '05

Michael.Dillon(a)btradianz.com said: > That's strange because you just finished describing how > SOME companies are already engaging in email peering on > a piecemeal basis. And how these companies ARE finding > this to be beneficial in reducing costs. So please explain > why my suggestion about widespread email peering agreements > won't work? Because I don't think "some companies" == "the entire population of email users", or even a sizable (ie widespread) part of that population. A large number of people are fine with the current system, and thus won't pay more for something else. Me, for example. Those who are unhappy will pay more for a better solution, and some small number with really deep pockets may be at that point where they will pay for something like "business class" email, in addition to the "tourist class" email they already have. You seem to repeatedly describe a solution that becomes so big that it (at least substantially) replaces 25/SMTP. That's what I don't think will work, or is needed. > And please don't suggest that webs of trust are not > scalable. Given the techniques of scaling that we have > in the 21st century, I simply don't believe that. I don't think either are relevant to this discussion. In the utility model you seem to talk about (and that I was talking about) all you care about is the provider. If you contract with them for traceable, trusted spam free email, and they give you something less than that, they pay a penalty. The utility knows, and has a contractual relationship with, each endpoint, and presumably can keep track of traffic in its own network. Problem solved. And the whole thing doesn't need to scale, because there are a severely limited number of companies that would be willing to pay the costs for such a service. But they are out there, and one might be able to make a business out of it. Best, Ben

3 2