RE: IPv6 on SOHO routers?
> -Original Message- > From: Petri Helenius [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 3:49 PM > To: Michael K. Smith - Adhost > Cc: Mohacsi Janos; Matthew Moyle-Croft; [EMAIL PROTECTED]; > nanog@merit.edu > Subject: Re: IPv6 on SOHO routers? > > Michael K. Smith - Adhost wrote: > > > > It's not that bad. You can attach a v6 address to the 802.11 > interface and the FastEthernet interface, but you can't put one on a > BVI which means you need two /64's if you want v6 on wireless and > wired. > > > That workaround does not work on the models with the 4 port switch > integrated. (running 12.4T) > > Pete Check out: http://www.andbobsyouruncle.net and my wiki post on a v6 config. I *think* this has the module you're talking about and is running flash:c870-advipservicesk9-mz.124-15.XY.bin. Cisco 871W (MPC8272) processor (revision 0x200) with 118784K/12288K bytes of memory. Processor board ID FHK1109132B MPC8272 CPU Rev: Part Number 0xC, Mask Number 0x10 5 FastEthernet interfaces 1 802.11 Radio 128K bytes of non-volatile configuration memory. 24576K bytes of processor board System flash (Intel Strataflash) Regards, Mike PGP.sig Description: PGP signature
RE: IPv6 on SOHO routers?
> > > The IPv6 "support" on 87x Cisco is nothing to write home about. It's > not supported on most physical interfaces that exist on the devices. > But > it does work over tunnel interfaces if you have something on your lan > to > tunnel to. > > Pete It's not that bad. You can attach a v6 address to the 802.11 interface and the FastEthernet interface, but you can't put one on a BVI which means you need two /64's if you want v6 on wireless and wired. Regards, Mike PGP.sig Description: PGP signature
RE: Cost per prefix [was: request for help w/ ATT and terminology]
Hello Bill: > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > William Herrin > Sent: Tuesday, January 22, 2008 7:55 AM > To: nanog@merit.edu > Subject: Re: Cost per prefix [was: request for help w/ ATT and > terminology] > > > On Jan 21, 2008 10:28 PM, Jon Lewis <[EMAIL PROTECTED]> wrote: > > Is there really any point in trying to put a $ figure on each route? > > Jon, > > Emphatically Yes! > > Right now we rely on ARIN and the RIRs to artificially suppress the > growth of the prefix count and with it the availability of PI space. > This is a Really Bad Thing on so many levels, but absent a viable > market-based solution to the problem, authority-based rationing is > really the only thing we can do. > > If we can determine the cost to announce a prefix then we could > develop a market-based solution to the problem... One where instead of > suppressing the prefix count and dealing with it as business overhead, > we GET PAID for announcing and propagating prefixes. > > There are several market models that could work, but they all depend > on having a reliable metric for the cost of announcing a prefix. So, > if you think you'd like to get paid for announcing routes instead of > continuing to give the service away for free then yes, there is a > point to determining the cost of a prefix. > Hmm, who gets paid? It sounds like your hinting around a telco-type reciprocal payment model (correct me if I'm wrong). Do I pay my upstreams who in turn pay there upstreams and so on and so on? Or, is there some central, uber-authority that gets paid by all of us? It seems to me that there are many billing models that accommodate point-to-point relationships, but I'm having a hard time coming up with a mental model of payment in the many-to-many environment in the DFZ. Regards, Michael Smith PGP.sig Description: PGP signature
Cisco Downloads Down?
Hello All: I hope this is operational for at least some of us. It appears the Cisco website is experiencing technical difficulties. Of particular interest is the fact that the downloads section is also apparently fubar. On a positive note, when the page does partially load, I see lots of pretty new icons! Regards, Mike
Straw Poll - Multipoint Ethernet Connections Best Practices
Hello All: As more and more providers move towards Ethernet as a common connection type in Data Centers, Metro Areas and beyond, I am curious to know what people are using for Best Practices regarding customer connectivity into your Layer 2 networks. Most importantly, how do you handle customers that want redundant Ethernet connections? I've put together the following list of questions and I'd be happy to summarize to the list if there's any interest. Also, if individuals have any other pertinent questions they feel I've left out, please don't hesitate to let me know. 1) Do you allow redundant Ethernet (Layer 2) connections into your network? 2) Do you allow customers to connect at Layer 2? And, if so: a) What, if any, port-based limitations on protocols? (Root Guard, BPUD-filtering, etc.?) b) What, if any, MAC restrictions do you have on the ports? 3) Do you allow customers to transmit HSRP/VRRP/GLBP state information across your Layer 2 infrastructure? 4) Do you require Layer 3 terminations for customers with redundant connections? 5) Do you provide OSPF "peering" to customers with redundant connections? 6) Do you provide BGP peering to customers with redundant connections? Regards, Michael K. Smith (my real, given name) :-) Adhost
RE: NOC Personel Question (Possibly OT)
Hello Todd: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Christell Sent: Wednesday, March 14, 2007 6:47 PM To: NANOG Subject: NOC Personel Question (Possibly OT) Greetings, Sorry if this is OT but we are having a discussion with our HR department. We are in the process of getting a 24 X 7 NOC in place and HR has a problem with calling them NOC Specialist. What is the generally accepted title? Thanks in advance, Todd Christell SpringNet Network Manager 417.831.8688 --- I know it's blasé, but how about: - Technical Support Representative - Network Administrator - Senior Network Administrator Or, you could just call them all "booger eaters" and be done with it. Mike
Re: ISP wants to stop outgoing web based spam
Title: Re: ISP wants to stop outgoing web based spam Hello Hank: On 8/9/06 3:28 AM, "Hank Nussbacher" <[EMAIL PROTECTED]> wrote: > > Back in 2002 I asked if anyone had a solution to block or rate limit > outgoing web based spam. Nothing came about from that thread. I have an > ISP that *wants* to stop the outgoing spam on an automatic basis and be > a good netizen. I would have hoped that 4 years later there would be > some technical solution from some hungry startup. Perhaps I have missed > it. What I have found so far is: > > Detecting Outgoing Spam and Mail Bombing > http://www.brettglass.com/spam/paper.html > SMTP based mitigation - thing on HTTP/HTTPS > > Stopping Outgoing Spam > http://research.microsoft.com/~joshuago/outgoingspam-final-submit.pdf > Research paper - nothing practical > > Throttling Outgoing SPAM for Webmail Services > http://www.ceas.cc/papers-2005/164.pdf > Research paper - nothing practical > > ISPs look inward to stop spam - Network World > http://www.networkworld.com/news/2004/071204carrispspam.html > Bottom line - no solution > > So I am trying once again. Hopefully someone has some magic dust > this time around. > > Thanks, > Hank Nussbacher > http://www.interall.co.il > My answer is based on the word "startup" so I'm assuming "no money" but I could be "wrong". :-) We use the standard SpamAssassin, ClamAV setup both on ingress and egress. On egress we set the detection levels and divert and save anything that is marked as Spam rather than sending it on with headers and subject modifications. We've found this to be very effective in reducing our scores with Comcast and AOL in particular and it's pretty much stopped our being blocked by those services, even using a fairly loose setting for SpamAssassin. As a service provider that forwards tons of mail to addresses on those networks (previously un-scanned so we forwarded everything, including Spam) we've found it essential to put these filters in place to guarantee (as much as anyone can) service for our email customers. Regards, Mike
