- Test - lists.nanog.org

Concurrent bridging & routing on a channelized interface.
by jeanlou.dupont＠na.marconicomms.com 10 Nov '99

10 Nov '99

Is it possible to concurrently do bridging & IP routing on a DS3 channelized interface on a cisco router? Suppose I have a bunch of customers with T1 coming in through a DS3 channelized interface and they want to be part of a layer 2 VLAN & concurrently have other customers with T1 coming in with IP feeds to the Internet. Any help is appreciated. jld. :))

1 0

Route Filtering by Network Size
by Marsh, Jerry 10 Nov '99

10 Nov '99

I've changed jobs and been off the NANOG list for some time, so please excuse the question. I know some providers (such as SPRINT) filter BGP routing announcements based on minimum announcement size. The questions are: 1) Who all has such policies? 2) What are the specific sizes and address blocks being filtered? 3) Do they affect "portable" (provider independent) and "non-portable (provider supplied) addressing in the same way. Thanks.

1 0

RE: ARIN's New E-commerce System
by Mark Persiko 10 Nov '99

10 Nov '99

As long as we are talking about ASN registrations, I have a question. How many ISP's currently use a Routing Registry to configure their routers to accept network annoucements from only the AS's in the registry? Thanks, Mark - Mark C. Persiko Network Analyst/Systems Programmer - - Email: persiko(a)bvsd.k12.co.us Boulder Valley School District - -----Original Message----- From: Kim Hubbard [mailto:kimh@arin.net] Sent: Tuesday, November 09, 1999 3:00 PM To: jim(a)reptiles.org Cc: memsvcs(a)arin.net; nanog(a)merit.edu Subject: Re: ARIN's New E-commerce System > > > On Tue, Nov 09, 1999 at 03:52:20PM -0500, Member Services wrote: > > ARIN is now offering its customers the option of submitting payment > > for the registration of Autonomous System Numbers (ASNs) by credit > > card. If your organization submits a request to ARIN and is approved > > to receive an ASN, you can select to either: 1) receive an invoice and > > pay by check, or 2) make your remittance on-line by providing your > > credit account number. > > is this in addition to the fees being levied per ASN by Merit? Merit isn't levying a per ASN fee, they are charging a per maintainer fee for their routing registry. ARIN's fees aren't changing, we're just offering additional payment options for ASNs. Regards, Kim Hubbard ARIN > > -- > [ Jim Mercer jim(a)reptiles.org +1 416 506-0654 ] > [ Reptilian Research -- Longer Life through Colder Blood ] > [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] >

2 1

Article of fiber rules for DC
by hardie＠equinix.com 10 Nov '99

10 Nov '99

http://www.washingtonpost.com/wp-dyn/articles/A43981-1999Nov9.html interesting article on new rules on permits for DC cable-layers. regards, Ted Hardie Equinix

1 0

BGP and Cogeco and @Home
by James Smith 10 Nov '99

10 Nov '99

Is anyone on this list involved with Cogeco in the Toronto Area, that would also be involved with BGP routing and the migration of Cogeco to @Home? We receive feed from Cogeco and I'm trying to get some information about when certain BGP services might be available. Please contact me off the list. -- James Smith, CCNA Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2140 Winston Park Drive, Suite 203 Oakville, ON, CA L6H 5V5 Tel: 905-829-3389 (email preferred) Fax: 905-829-5692 1-877-DXSTORM (1-877-397-8676)

1 0

bgp blackhole lists and transit providers
by Mike Tancsa 10 Nov '99

10 Nov '99

Lately, we have been running into this problem more and more. One of our upstreams AT&T buys transit from Teleglobe. Teleglobe it seems subscribes to the maps.vix.com realtime blackhole list via BGP. Now, I am all for limiting SPAM and such, but its starting to be an operational headache having to deal with customers asking our support staff why they cannot get to a certain web site. The one that hit our support lines the most was 24.0.0.200 which was members.home.com. It can be a challenge explaining the simplest of issues to end users, let alone upstream transit providers using bgp to blackhole a host. The customer just wants to get to the granny's knitting guild! At least with SMTP blocking, one end gets a message stating "their mail is unwelcome, see .... for details", where as when an intermediary is dropping all data, the end user just gets a vague error. My questions is, if you were buying transit from an upstream, and that upstream decided to partake in some sort of content filtering, how would you feel ? Do you think its right for transit providers to do so ? Its one thing if I choose to use this facility, but I feel a little helpless if two ASs away from me uses it... i.e. upstream says, "this way to 24.0.0.0/12", but then drops data going to 24.0.0.200/32. I dont want to have to fill me router with a bunch of /32s so I can exit out UUnet to get around this. Yes, sure I want a proactive upstream to stop network abuse... particularly abuse issues, where I need their cooperation such as smurf attacks and such. But on issues, where I have all the necessary tools and choice to deal with said issue (in this case SPAM), I would prefer it be left up to me on how I deal with foreign SPAM sites. ---Mike ********************************************************************** Mike Tancsa, Network Admin * mike(a)sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada *

2 1

Listserver Address
by Twan 10 Nov '99

10 Nov '99

Greetings, I hate posting this here, but I'm changing Email addresses and need to know the address to the list server so I can contact it and let it know my new address. Any help is appreciated. Thanks. (Email direct to me, btw) - Chris

1 0

ARIN's New E-commerce System
by Member Services 09 Nov '99

09 Nov '99

ARIN is now offering its customers the option of submitting payment for the registration of Autonomous System Numbers (ASNs) by credit card. If your organization submits a request to ARIN and is approved to receive an ASN, you can select to either: 1) receive an invoice and pay by check, or 2) make your remittance on-line by providing your credit account number. The on-line ASN Billing Account Form located on our web site has been revised to accommodate E-commerce transactions using secure protocols. Plus, a new ASN Maintenance Fee Payment Form has been developed for paying ASN annual maintenance fees specifically by credit card. Customers may choose to pay this fee for 1 or 2 years. We trust that this new service will simplify your invoicing and payment process. If you have any questions regarding any fees, please review ARIN's Fee Schedule. ARIN's ASN Billing Account Form can be found at: http://www.arin.net/asnform.htm ARIN's new ASN Maintenance Fee Payment Form can be found at: http://www.arin.net/maintpayform.htm If you have any further questions, comments, or concerns, please do not hesitate to contact member-services(a)arin.net Regards, David R Huberman, Membership Services Coordinator American Registry for Internet Numbers

3 2

Re: Possible DoS attack (?)
by Martin Cooper 09 Nov '99

09 Nov '99

Ron Buchalski <rbuchals(a)hotmail.com> wrote: > Clifton, I wrote that stuff. Clifton wrote the question about 'no ip directed-broadcast' - I think maybe he's not on nanog-post, which is why the original hasn't appeared (yet?). > Have you verified that operation on the router? I used 'debug ip icmp' both with and without 'ip route-cache same-interface', and saw significantly fewer redirects when it was on. > I believe that if the > stupid or malicious host continued to send packets to the router when they > are really destined for another host (or router) on the subnet, that the > router would continue to send ICMP redirects back to the sending host, and > wouldn't cache this response for future packets, even with 'ip route-cache > same-interface' enabled. The router should only populate it's forwarding > table with next hop information for real data flows, and an ICMP redirect > (which is telling the host that this (through the router) isn't the correct > path for a specific data flow) shouldn't be cached. I haven't verified > this, though... But there is a real data flow (in that the router will actually switch the data packets back out of the same interface, as well as sending redirects). The IOS docs for 11.1 through 12.0 have this to say on the subject... -- quote -- ip redirects To enable the sending of redirect messages if the Cisco IOS software is forced to resend a packet through the same interface on which it was received, use the ip redirects interface configuration command. To disable the sending of redirect messages, use the no form of this command. ip route-cache To control the use of a high-speed switching cache for IP routing as well as the use of autonomous switching, use the ip route-cache interface configuration command. To disable fast switching and autonomous switching, use the no form of this command. ip route-cache [cbus] no ip route-cache [cbus] ip route-cache same-interface no ip route-cache same-interface ip route-cache sse no ip route-cache sse ip route-cache [optimum | flow] no ip route-cache [optimum | flow] ip route-cache distributed no ip route-cache distributed Syntax Description [...] same-interface Enables fast switching packets back out the interface on which they arrived. [...] You can enable IP fast switching when the input and output interfaces are the same interface, using the ip route-cache same-interface command. This normally is not recommended, though it is useful when you have partially meshed media, such as Frame Relay. You could use this feature on other interfaces, although it is not recommended because it would interfere with redirection. -- unquote -- Although there is an 'ip route-cache cef' command in 12.0, it doesn't appear to have any options, so maybe redirects just work under CEF (good news for people who use it on their border routers maybe). M.

1 0

Re: Possible DoS attack (?)
by Ron Buchalski 09 Nov '99

09 Nov '99

Clifton, Have you verified that operation on the router? I believe that if the stupid or malicious host continued to send packets to the router when they are really destined for another host (or router) on the subnet, that the router would continue to send ICMP redirects back to the sending host, and wouldn't cache this response for future packets, even with 'ip route-cache same-interface' enabled. The router should only populate it's forwarding table with next hop information for real data flows, and an ICMP redirect (which is telling the host that this (through the router) isn't the correct path for a specific data flow) shouldn't be cached. I haven't verified this, though... -rb ----Original Message Follows---- From: Martin Cooper <mjc(a)cooper.org.uk> To: "Clifton D. McKinney" <clift(a)alltel.net> CC: nanog(a)merit.edu Subject: Re: Possible DoS attack (?) Date: Tue, 09 Nov 1999 15:03:52 +0000 "Clifton D. McKinney" <clift(a)alltel.net> wrote: > Is this something that the "no ip directed-broadcast" command > would prevent? Nope (unfortunately)... I think I should clarify what the problem is again, since I've had a few private emails that suggest that what I originally wrote was confusing. The route-cache (fast-switching) speeds up switching by building a simple lookup table of IP-prefix/output-interface pairs by doing a routing table lookup (process-switching) for the first packet it sees that is addressed to any destination prefix. The problem is that to implement ICMP redirects, Ciscos have to do process-switching to figure out that the source and destination addresses are both out of the same interface and can therefore talk to each other directly (i.e. without pointlessly bouncing traffic off the router and causing the same traffic to go over the same network twice, wasting bandwidth). This would be fine and dandy if when they sent a redirect, the host that received it listened to it, and stopped bouncing traffic off the router, but if it doesn't (either stupidly or maliciously) then all traffic that is being bounced off the router has to carry on being process-switching, burning CPU cycles like it's going out of fashion. If you turn on 'ip route-cache same-interface' the router will still send a redirect for the first packet addressed to a particular prefix that it sees because it has to process-switch it to figure out what to put in the route- cache, but after that it will use the cache, and not look at the source addresses of packets to that destination at all (try turning on 'debug ip icmp' to see this behaviour). Whether you use the command or not is a trade-off based on whether you want redirects to work properly (stopping traffic being bounced off the router unnecessarily if other hosts listen to them), or if you would rather not burn CPU when other hosts don't listen to them and you have to switch the traffic back out of the same interface anyway. M. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0