OOB core router connectivity wish list
I have together with some other people, collected a wish list for OOB support, mainly aimed for core routers. This is to replace the legacy serial port usually present on core routing equipment and to move/collapse all its functionality to an ethernet only port. Some equipment already have an mgmt ethernet port, but usually this can't do everything, meaning today one has to have OOB ethernet *and* OOB serial which just brings more pain than before. I would like to post it here to solicit feedback on it. Feel free to use it to tell your vendor account teams you want this if you feel it useful. I've already sent it to one vendor. http://swm.pp.se/oob.txt Priorities: [P1] - must have, otherwise not useful [P2] - would be very useful, to most operators [P3] - nice to have, useful to some From the OOB ethernet port it should be possible to: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). [P1]: Connect to manage the RP(s) and linecards (equivalent of todays connect on GSR and ASR9k or connecting to RP serial port). [P2]: It should be possible to connect to the OOB from the RP as well (to diagnose OOB connectivity problems). [P2]: Upload software to the RP or otherwise make information available to the RP (for later re-install/turboboot for example). RP should have access to local storage on the OOB device to transfer configuration or software from the OOB device to the RP). [P2]: Read logs and other state of the components in the chassis (displays and LEDs) plus what kind of card is in each slot. [P1]: The OOB port should support (configurable), telnet, ssh and optionally [P3] https login (with a java applet or equivalent to give CLI access in the browser) with ACLs to limit wherefrom things can be done. OOB should support ssh key based logins to admin account. [P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only. [P1]: It should be possible to transfer data using tftp, ftp and scp (ftp client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server). [P2]: OOB device should have tacacs and radius and [P1] local user/password database support for authentication. [P3] OOB should support ssh-key based authentication. [P3] Chassis should have a character display or LEDs with configurable blink pattern from OOB, to aid remote hands identification. [P3] OOB should have two USB ports, one to use to insert storage to transfer files to/from device. The other should be USB port that presents itself as ether USB serial port, or USB ethernet port, where the OOB device would have built in DHCP/DHCPv6 server to give IPv4v6 access to a laptop connected to the OOB so the onsite engineer can then use ssh/telnet to administrate the OOB. Optionally this port could be ethernet port (compare todays CON and AUX ports). [P2] OOB should have procedure to factory default its configuration, perhaps physical button that can be pressed and held for duration of time. The fact that this is done should be logged to the RP. [P3] OOB should have possibility to show power supply and environmental state. [P3] The factory default configuration should not include an empty or obvious login password. The factory-default login password should be the MAC address (without punctuation) of the OOB ethernet interface, which should be printed on the chassis next to the OOBE port. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Multicast over GRE between Linux server and Cisco Router
I am trying to set up multicast between a Linux server and Router using GRE. The GRE tunnel is up fine and I can see traffic go across it, but the router is not indicating it is receiving the IGMP joins that the server is sending. I have identical setting with another server attached to fastethernet0/1 and it is joined to the group fine, but I am not able to get the server to link to the router via GRE interface. Note that I have another server behind another router where the two routers do GRE and PIM and that on is working fine. Is there some reason that IGMP joins would not work across the GRE link, but another router using PIM would? -- Brian Christopher Raaen Network Architect Zcorum
Re: OOB core router connectivity wish list
On (2013-01-09 15:37 +0100), Mikael Abrahamsson wrote: equipment already have an mgmt ethernet port, but usually this can't do everything, meaning today one has to have OOB ethernet *and* OOB serial which just brings more pain than before. The key difference is, that those are not OOB at all, they are on-band as they fate-share the control-plane. Having real OOB port is demand everyone should put in their RFQ/RFP. http://swm.pp.se/oob.txt Fully support. In essence, all CSCO needs to do, is bring CMP back that they had in Nexus7k/SUP1 and SUP2T but removed again in Nexus7k/SUP2 citing thermal, pintcount and lack of customer adoption. Other vendors need to check out CMP and copy it. I emailed freescale, since they are the ones who can solve the thermal and pincount problem by implementing mgmt board directly. They replied 'something similar will be implemented in the next generation of our multicore processors' (big kudos to large semi to replies quickly and cluefully to non-customer queries) Once there is hardware for this, getting vendors to implement software should be easy peasy. -- ++ytti
Re: Multicast over GRE between Linux server and Cisco Router
My guess is that this is because IGMP is a host-to-router protocol while PIM is for router-to-router signaling. IGMP joins typically flow from a multicast receiver to its local router. A GRE tunnel emulates a router-to-router connection, so you need PIM running on it for signaling. An IGMP join is really just a first hop host-to-router message and isn't intended to be routed, which is what would be necessary to get it over a GRE tunnel. HTH, John On Wed, Jan 9, 2013 at 8:51 AM, Brian Christopher Raaen mailing-li...@brianraaen.com wrote: I am trying to set up multicast between a Linux server and Router using GRE. The GRE tunnel is up fine and I can see traffic go across it, but the router is not indicating it is receiving the IGMP joins that the server is sending. I have identical setting with another server attached to fastethernet0/1 and it is joined to the group fine, but I am not able to get the server to link to the router via GRE interface. Note that I have another server behind another router where the two routers do GRE and PIM and that on is working fine. Is there some reason that IGMP joins would not work across the GRE link, but another router using PIM would? -- Brian Christopher Raaen Network Architect Zcorum
Re: Who's the hostmaster for .fl.us?
This seems much harder to find out than I would have expected. RFC 1480 is, sadly, dated, and it's really hard to google for .fl.us usably. And www.fl.us goes nowhere. Off-list is fine; I don't expect this is a high-interest question. Neustar has been successful in getting RFC1480-style domain names effectively discontinued as of maybe a decade ago (we're responsible for mil.wi.us here) and so any locality stuff under .fl.us is probably legacy stuff. They'd much rather sell people foo.us ... Anyways, whois information is available via www.nic.us which points at www.whois.us, but if your question is about the .fl.us zone itself, that's almost certainly handled directly by Neustar. www.whois.us appears to be functional, or, at least, showed me current data for our zones. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: OOB core router connectivity wish list
On Wed, Jan 9, 2013 at 9:37 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: I have together with some other people, collected a wish list for OOB support, mainly aimed for core routers. Hi Mikael, I generally agree but have several quibbles: [P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only. (a) This is a P2 not a P1. Asking the OOB to be critically dependent on an external network element is dubious to begin with but even if desired it's usable without. About the only time you'd strictly *need* dynamic configuration in an OOB is when directly connecting it to a commodity Internet link. If you're willing to give your poorly secured and rarely updated OOB a public IP address, you're a braver man than I am. If you are that brave then you'll need a more robust set of dynamic configuration tools than just the ones you've listed and you'll also need a dynamic dns client or some other mechanism for the the OOB to let you know what addresses it ended up on. (b) IPv6-only in an OOB won't be broadly acceptable for at least another 5 years if then. You'd be foolish not to include IPv6 support in a greenfield design -- the writing is on the wall -- but there are today very few scenarios in which an IPv4 only OOB would not be usable. [P1]: It should be possible to transfer data using tftp, ftp and scp (ftp client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server). For security and performance reasons, FTP has no place in a modern network. If you're still using it anywhere, you're borrowing grief. Replace with an http/https client. TFTP has such a strong legacy of use on routers that its presence remains just barely tolerable. For now. Have a look at how HP iLO3 makes use of http to implement virtual media. You can upload an ISO image to a web server somewhere and then instruct ilo to mount the URL as a virtual dvdrom. Best of all, if your management session disconnects, the virtual media remains mounted via the web server. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: OOB core router connectivity wish list
On Wed, 9 Jan 2013, Mikael Abrahamsson wrote: I would like to post it here to solicit feedback on it. Feel free to use it to tell your vendor account teams you want this if you feel it useful. I've already sent it to one vendor. Ethernet/Serial/USB management is useful, but I would not be in favor of eliminating the serial port entirely, because having an OOB serial console connection has saved me more than a few times. Plus, having working connectivity from something like a terminal server or a headless Linux box has proven its value countless times in the past. I would also add the following to your list: If $vendor's device provides an IP-based management interface over an ethernet port, it should provide both a web-based interface and a CLI. The web interface should be as platform-agnostic as possible (not restrict people to specific platforms and browsers), and be as gentle as possible in requiring things like Java. Being forced to deal with Java runtime version dependency hell in a critical situation would not fill my heart with joy. jms
Re: OOB core router connectivity wish list
On Wed, Jan 9, 2013 at 11:18 AM, William Herrin b...@herrin.us wrote: About the only time you'd strictly *need* dynamic configuration in an OOB is when directly connecting it to a commodity Internet link. If you're willing to give your poorly secured and rarely updated OOB a public IP address, you're a braver man than I am. If you are that brave then you'll need a more robust set of dynamic configuration tools than just the ones you've listed and you'll also need a dynamic dns client or some other mechanism for the the OOB to let you know what addresses it ended up on. it's possible that he's thinking of a world where your dhcp is not 'dynamic' but a management system which can keep all the other bits of information updated (and easily updatable!) for the remote nodes: ip address def-gw dns servers for instance.
Re: OOB core router connectivity wish list
On Wed, Jan 9, 2013 at 11:21 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Jan 9, 2013 at 11:18 AM, William Herrin b...@herrin.us wrote: About the only time you'd strictly *need* dynamic configuration in an OOB is when directly connecting it to a commodity Internet link. If you're willing to give your poorly secured and rarely updated OOB a public IP address, you're a braver man than I am. If you are that brave then you'll need a more robust set of dynamic configuration tools than just the ones you've listed and you'll also need a dynamic dns client or some other mechanism for the the OOB to let you know what addresses it ended up on. it's possible that he's thinking of a world where your dhcp is not 'dynamic' but a management system which can keep all the other bits of information updated (and easily updatable!) for the remote nodes: ip address def-gw dns servers for instance. Sure, but in that scenario you don't *need* a dhcp system, it's merely a nice to have. Hence a P2 not a P1. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Who's the hostmaster for .fl.us?
Neustar has been successful in getting RFC1480-style domain names effectively discontinued as of maybe a decade ago (we're responsible for mil.wi.us here) and so any locality stuff under .fl.us is probably legacy stuff. They'd much rather sell people foo.us ... If you're wondering about something in k12.fl.us, do a WHOIS and you'll find the Florida Dep't of Education. For other fl.us names, do a WHOIS on the name, and you'll find out what Neustar's got. I have a few place.ny.us delegations, but there's no new ones. There was a big kerfuffle in which Neustar demanded in the agreement that subregistries provide unlimited indemnification for their legal costs. It turned out that you could just cross out that clause and Neustar would accept it, but that news was not widely disseminated and many local registries just gave up. The .us zone still has some very crufty legacy stuff. The name iecc.cambridge.ma.us is still there as a CNAME, left over from something I registered in about 1991. There's no WHOIS for it, Neustar probably has no idea that I was the original registrant, and I have no idea how I'd even ask them to get rid of it. It's a dandy spamtrap, though. R's, John
Re: OOB core router connectivity wish list
On Wed, 9 Jan 2013, Christopher Morrow wrote: On Wed, Jan 9, 2013 at 11:18 AM, William Herrin b...@herrin.us wrote: About the only time you'd strictly *need* dynamic configuration in an OOB is when directly connecting it to a commodity Internet link. If you're willing to give your poorly secured and rarely updated OOB a public IP address, you're a braver man than I am. If you are that brave then you'll need a more robust set of dynamic configuration tools than just the ones you've listed and you'll also need a dynamic dns client or some other mechanism for the the OOB to let you know what addresses it ended up on. it's possible that he's thinking of a world where your dhcp is not 'dynamic' but a management system which can keep all the other bits of information updated (and easily updatable!) for the remote nodes: Well, I was actually thinking more about initial factory default configuration. After I can reach the device, I would like to be able to set a static address. I'll consider adding this to the document. My grief with this is that if we're going to go into that kind of level, we need a RFC style document with a lot of detail, and that wasn't what I was initially aiming for. I wanted more to spark the discussion and see what came out of it. If there indeed is a lot of interest in this, I'd gladly like to try to create a more detailed document. I would be very happy if multiple vendors could standardise on a functionality and software though, perhaps even with API. Don't know which standards body would be right for this though. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: OOB core router connectivity wish list
On (2013-01-09 11:18 -0500), William Herrin wrote: (a) This is a P2 not a P1. Asking the OOB to be critically dependent on an external network element is dubious to begin with but even if desired it's usable without. Agreed that P2 suffices. Usage scenario is installing fresh router. You order router from vendor to remote location, notsosmarthands plug it to wires, boom you configure it remotely. About the only time you'd strictly *need* dynamic configuration in an OOB is when directly connecting it to a commodity Internet link. If you're willing to give your poorly secured and rarely updated OOB a public IP address, you're a braver man than I am. If you are that This is not absolute truth, but depends on what hat you wear. If you are DC guy, you have handful of POPs, arranging proper OOB network there is a breeze. If you are incumbent, you can't buy anything externally, as everyone buys from you, so you need to build separate network just for OOB. All other service providers may have hundreds of pops, you're not going to build non-revenue generating network to reach all those hundreds of pops, just to build OOB. You get cheapest connection you can get there, maybe competitor ADSL, cable model, 3G, public WLAN, ISDN what ever is available which is not fate-sharing with your network. Then plug in say cisco CPE to the OOB port, which offers address via DHCP and connect over IPSEC DMVPN to your own network. 0 touch installation of new router. Some might be ghetto and omit the CPE and use IPSEC from the management plane to openswan linux. (b) IPv6-only in an OOB won't be broadly acceptable for at least another 5 years if then. You'd be foolish not to include IPv6 support in a greenfield design -- the writing is on the wall -- but there are today very few scenarios in which an IPv4 only OOB would not be usable. Agreed. IPv4 would be priority for most. For security and performance reasons, FTP has no place in a modern network. If you're still using it anywhere, you're borrowing grief. Replace with an http/https client. http(s), scp would be my picks. Hell with FTP. TFTP has such a strong legacy of use on routers that its presence remains just barely tolerable. For now. There is no standard way to send arbitrary size files over TFTP, not worth the pain. -- ++ytti
Re: OOB core router connectivity wish list
On Wed, 9 Jan 2013, Saku Ytti wrote: Agreed. IPv4 would be priority for most. Today yes. In 2-4 years when this might be a reality, I don't want IPv4 only device. I rather go for IPv6 only immediately. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: OOB core router connectivity wish list
I think this list goes too far, and has a decent chance of introducing other fun failure modes as a result. The goal of OOB is generally to gain control of a misbehaving device. Now, misbehaving can take many forms, from the device actually being ok and all of it's circuits going down (fiber cut isolating it), to the device being very much not ok with a bad linecard trying to lock up the bus, core dumps, etc. I'm going to pick on one specific example: In a message written on Wed, Jan 09, 2013 at 03:37:16PM +0100, Mikael Abrahamsson wrote: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). Most Cisco high end devices can do this today from the CLI (test mbus power off on a GSR, for example). Let's consider what it would take to move that functionality from the live software to some sort of etherent oob as proposed... The first big step is that some sort of computer to operate the ethernet oob is required. I think where you're going with this is some sort of small SoC type thing connected to the mangement buss of the device, not unlike an IPMI device on a server. Using IPMI devices on servers as an example this is now another device that must be secured, upgraded, and has the potential for bugs of its own. Since only a small fraction of high end users will use the OOB at all (inband is fine for many, many networks), there will not be a lot of testing of this code, or demand for features/fixes. So while I agree with the list of features in large part, I'm not sure I agree with the concept of having some sort of ethernet interface that allows all of this out of band. I think it will add cost, complexity, and a lot of new failure modes. The reality is the current situation on high end gear, a serial console plus ethernet management port is pretty close to a good situation, and could be a really good situation with a few minor modifications. My list would be much simpler as a result: 1) I would like to see serial consoles replaced with USB consoles. They would still appear to be serial devices to most equipment, but would enable much faster speeds making working on the console a much more reasonable option. For bonus points, an implementation that presents 2-4 serial terminals over the same USB cable would allow multiple people to log into the device without the need for any network connectivity. This would also allow USB hubs to be used to connect multiple devices in a colo, rather than the serial terminal servers needed today. 2) I would like to see manangement ethernets that live in their own walled off world out of the box. Yes, I know with most boxes you can put them in a VRF or similar, but that should be the default. I should be able to put an IP and default route on a management ethernet and still have a 100% empty (main) routing table. This would allow the management port to be homed to a separate network simply and easily. 3) I would like to see legacy protocols dumped. TFTP, bye bye. FTP, bye bye. rcp, bye bye. HTTP, HTTPS, and SCP should be supported for all operations at all levels of the OS. In this ideal world, the deployment model is simple. A small OOB device would be deployed (think like a Cisco 1900, or Juniper SRX 220), connected to a separate network (DSL, cable modem, cell modem, ethernet to some other provider, or gasp, even an old school analog modem). Each large router would get an ethernet port and usb console to that device. SSH to the right port would get the USB console, ideally with the 2-4 consoles exposed where hitting the same port just cycles through them. At that point all of the functionality described in the original post should be available in the normal CLI on the device. File transfer operations should be able to specify the management port copy [mangement]http://1.2.3.4/newimage.code flash: to use that interface/routing table. I also think on most boxes this would require no hardware changes. The high end boxes have Ethernet, they have USB...it's just updating the software to make them act in a much more useful way, rather than the half brain-dead ways they act now... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpPBJXXdWsPu.pgp Description: PGP signature
Re: OOB core router connectivity wish list
On (2013-01-09 09:12 -0800), Leo Bicknell wrote: So while I agree with the list of features in large part, I'm not sure I agree with the concept of having some sort of ethernet interface that allows all of this out of band. I think it will add cost, complexity, and a lot of new failure modes. It already exists, CMP is its name, and it is great. Server people woke up to this over decade ago, so should networking people. Failure modes are somewhat uninteresting, as long as it does not fate-share with control-plane. Having RS232 or USB console on forwarding-plane is not OOB. And even OOB version of these is of limited value, you can't send images over them, you can't multiplex over them and RS232 OOB 'server' costs more than switch. So you get less and you pay more. HW + SW wise it's extremely simple contraption, all the code and HW needed is proven. RS232 on-band management is case of 'well it's always done like this, so it must be the right way to do it' -- ++ytti
Re: OOB core router connectivity wish list
On Wed, 9 Jan 2013, Leo Bicknell wrote: of the device, not unlike an IPMI device on a server. Using IPMI IPMI is exactly what we're going for. In this ideal world, the deployment model is simple. A small OOB device would be deployed (think like a Cisco 1900, or Juniper SRX 220), connected to a separate network (DSL, cable modem, cell modem, ethernet to some other provider, or gasp, even an old school analog modem). Each large router would get an ethernet port and usb console to that device. SSH to the right port would get the USB console, ideally with the 2-4 consoles exposed where hitting the same port just cycles through them. This is added cost and complexity. Sometimes there is only 1-2 devices in the pop, and now there is need to install a serial console router with DC (limits options) just to connect to the serial console, which might not work anyway because the control plane might be so screwed up that it actually needs power cycling. So I want to retire serial ports in the front to be needed for normal operation. Look at the XR devices from Cisco for instance. For normal maintenance you pretty much require both serial console (to do rommon stuff one would imagine shouldn't be needed) and also mgmt ethernet (to use tftp for downloading software when you need to turbo-boot because the system is now screwed up because the XR developer (install) team messed up the SMUs *again*). For instance, if you have single RP the upgrade instructions for 4.2.1 lists going into rommon and doing boot -s, *or* power cycling the box, after FPGA upgrade. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: OOB core router connectivity wish list
On 1/9/2013 9:12 AM, Leo Bicknell wrote: I think this list goes too far, and has a decent chance of introducing other fun failure modes as a result. The goal of OOB is generally to gain control of a misbehaving device. Now, misbehaving can take many forms, from the device actually being ok and all of it's circuits going down (fiber cut isolating it), to the device being very much not ok with a bad linecard trying to lock up the bus, core dumps, etc. I'm going to pick on one specific example: In a message written on Wed, Jan 09, 2013 at 03:37:16PM +0100, Mikael Abrahamsson wrote: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). Most Cisco high end devices can do this today from the CLI (test mbus power off on a GSR, for example). Let's consider what it would take to move that functionality from the live software to some sort of etherent oob as proposed... Install an Embedded Peer (a Bus Level Peering Card like a SlotServer or the Fuji Module and provide console level access through the peer. Then the Peer itself becomes the controller interface. Todd The first big step is that some sort of computer to operate the ethernet oob is required. I think where you're going with this is some sort of small SoC type thing connected to the mangement buss of the device, not unlike an IPMI device on a server. Using IPMI devices on servers as an example this is now another device that must be secured, upgraded, and has the potential for bugs of its own. Since only a small fraction of high end users will use the OOB at all (inband is fine for many, many networks), there will not be a lot of testing of this code, or demand for features/fixes. So while I agree with the list of features in large part, I'm not sure I agree with the concept of having some sort of ethernet interface that allows all of this out of band. I think it will add cost, complexity, and a lot of new failure modes. The reality is the current situation on high end gear, a serial console plus ethernet management port is pretty close to a good situation, and could be a really good situation with a few minor modifications. My list would be much simpler as a result: 1) I would like to see serial consoles replaced with USB consoles. They would still appear to be serial devices to most equipment, but would enable much faster speeds making working on the console a much more reasonable option. For bonus points, an implementation that presents 2-4 serial terminals over the same USB cable would allow multiple people to log into the device without the need for any network connectivity. This would also allow USB hubs to be used to connect multiple devices in a colo, rather than the serial terminal servers needed today. 2) I would like to see manangement ethernets that live in their own walled off world out of the box. Yes, I know with most boxes you can put them in a VRF or similar, but that should be the default. I should be able to put an IP and default route on a management ethernet and still have a 100% empty (main) routing table. This would allow the management port to be homed to a separate network simply and easily. 3) I would like to see legacy protocols dumped. TFTP, bye bye. FTP, bye bye. rcp, bye bye. HTTP, HTTPS, and SCP should be supported for all operations at all levels of the OS. In this ideal world, the deployment model is simple. A small OOB device would be deployed (think like a Cisco 1900, or Juniper SRX 220), connected to a separate network (DSL, cable modem, cell modem, ethernet to some other provider, or gasp, even an old school analog modem). Each large router would get an ethernet port and usb console to that device. SSH to the right port would get the USB console, ideally with the 2-4 consoles exposed where hitting the same port just cycles through them. At that point all of the functionality described in the original post should be available in the normal CLI on the device. File transfer operations should be able to specify the management port copy [mangement]http://1.2.3.4/newimage.code flash: to use that interface/routing table. I also think on most boxes this would require no hardware changes. The high end boxes have Ethernet, they have USB...it's just updating the software to make them act in a much more useful way, rather than the half brain-dead ways they act now... -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: OOB core router connectivity wish list
In a message written on Wed, Jan 09, 2013 at 06:39:28PM +0100, Mikael Abrahamsson wrote: IPMI is exactly what we're going for. For Vendors that use a PC motherboard, IPMI would probably not be difficult at all! :) I think IPMI is a pretty terrible solution though, so if that's your target I do think it's a step backwards. Most IPMI cards are prime examples of my worries, Linux images years out of date, riddled with security holes and universally not trusted. You're going to need a firewall in front of any such solution to deploy it, so you can't really eliminate the extra box I proposed just change its nature. I also still think there's a lot of potential here to take gigantic steps backwards. Replacing a serial console with a Java applet in a browser (a la most IPMI devices) would be a huge step backwards. Today it's trival to script console access, in a Java applet world, not so much. Having a IPMI like device with dedicated ethernet and connection to the management bus would allow it to have a web interface to do things like power cycle individual line cards and may be a win, but I would posit these things are to work around horribly broken upgrade procedures that vendors have not given enough thought. They could be solved with more intelligent software in the ROM and on the main box without needing any add on device. So I want to retire serial ports in the front to be needed for normal operation. Look at the XR devices from Cisco for instance. For normal maintenance you pretty much require both serial console (to do rommon stuff one would imagine shouldn't be needed) and also mgmt ethernet (to use tftp for downloading software when you need to turbo-boot because the system is now screwed up because the XR developer (install) team messed up the SMUs *again*). Your vendor is going to hire those same developers to write the code for your OOB device. The solution here is not bad developers writing and deploying even more code, it's to demand your vendors uplevel their developers and software. Ever have these problems on Vendor J? No, the upgrade process there is smooth as silk. Not to say that vendor is perfect, they just have different warts. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpyNw9nxqeU1.pgp Description: PGP signature
Re: OOB core router connectivity wish list
On (2013-01-09 10:18 -0800), Leo Bicknell wrote: I also still think there's a lot of potential here to take gigantic steps backwards. Replacing a serial console with a Java applet in a browser (a la most IPMI devices) would be a huge step backwards. Today it's trival to script console access, in a Java applet world, not so much. P1 requirement was ssh. Ever have these problems on Vendor J? No, the upgrade process there is smooth as silk. Not to say that vendor is perfect, they just have different warts. I'm getting maybe bit too far from topic. We have different opinion of smooth or silk. I hate how in J once you do the upgrade, current config is stored with it, so when you finally boot, you're using that configuration. So this means, you can't install new image to all boxes at once you decide new standard release and then reload then when you get maint window, without having any extra work during expensive maint hours. Also I've seen very poor hit-miss ratio with ISSU, so I can't use it at all. -- ++ytti
Re: OOB core router connectivity wish list
It might help clarify things if you added two (hopefully) short sections: One discussing how to get off the ground. How do I get my ssh key on a factory-reset box? Another discussing security. There may be conflicting requirements for different usage scenarios. -- These are my opinions. I hate spam.
Re: OOB core router connectivity wish list
On Jan 9, 2013, at 9:37 AM, Mikael Abrahamsson wrote: http://swm.pp.se/oob.txt Flow telemetry export - many of these so-called 'management' ports can't be used to export flow, oddly enough. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
[SHAME] Spam Rats
Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are mass-listed the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
Re: OOB core router connectivity wish list
My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) 2. Something that is standard across everything, and can be aggregated easily onto a console server or the like I don't really see what is wrong with with keeping the serial port as the standard. Things like servers and RAID cards and such are coming with BIOSes that are graphical and even require a mouse to use. What use is that when I need to get into the BIOS from a remote site that is completely down? Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) It might be nice to have a management-only port of some sort to do more advanced things that serial cannot do, but the serial port is ubiquitous already, and I don't see any reason to remove it as the very low-level access method. thanks, -Randy - Original Message - I have together with some other people, collected a wish list for OOB support, mainly aimed for core routers. This is to replace the legacy serial port usually present on core routing equipment and to move/collapse all its functionality to an ethernet only port. Some equipment already have an mgmt ethernet port, but usually this can't do everything, meaning today one has to have OOB ethernet *and* OOB serial which just brings more pain than before. I would like to post it here to solicit feedback on it. Feel free to use it to tell your vendor account teams you want this if you feel it useful. I've already sent it to one vendor. http://swm.pp.se/oob.txt Priorities: [P1] - must have, otherwise not useful [P2] - would be very useful, to most operators [P3] - nice to have, useful to some From the OOB ethernet port it should be possible to: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). [P1]: Connect to manage the RP(s) and linecards (equivalent of todays connect on GSR and ASR9k or connecting to RP serial port). [P2]: It should be possible to connect to the OOB from the RP as well (to diagnose OOB connectivity problems). [P2]: Upload software to the RP or otherwise make information available to the RP (for later re-install/turboboot for example). RP should have access to local storage on the OOB device to transfer configuration or software from the OOB device to the RP). [P2]: Read logs and other state of the components in the chassis (displays and LEDs) plus what kind of card is in each slot. [P1]: The OOB port should support (configurable), telnet, ssh and optionally [P3] https login (with a java applet or equivalent to give CLI access in the browser) with ACLs to limit wherefrom things can be done. OOB should support ssh key based logins to admin account. [P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only. [P1]: It should be possible to transfer data using tftp, ftp and scp (ftp client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server). [P2]: OOB device should have tacacs and radius and [P1] local user/password database support for authentication. [P3] OOB should support ssh-key based authentication. [P3] Chassis should have a character display or LEDs with configurable blink pattern from OOB, to aid remote hands identification. [P3] OOB should have two USB ports, one to use to insert storage to transfer files to/from device. The other should be USB port that presents itself as ether USB serial port, or USB ethernet port, where the OOB device would have built in DHCP/DHCPv6 server to give IPv4v6 access to a laptop connected to the OOB so the onsite engineer can then use ssh/telnet to administrate the OOB. Optionally this port could be ethernet port (compare todays CON and AUX ports). [P2] OOB should have procedure to factory default its configuration, perhaps physical button that can be pressed and held for duration of time. The fact that this is done should be logged to the RP. [P3] OOB should have possibility to show power supply and environmental state. [P3] The factory default configuration should not include an empty or obvious login password. The factory-default login password should be the MAC address (without punctuation) of the OOB ethernet interface, which should be printed on the chassis next to the OOBE port. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [SHAME] Spam Rats
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing? That said, it is best practice to set ptr records even for your unassigned ip space --srs (htc one x) On 10-Jan-2013 8:30 AM, Julian DeMarchi jul...@jdcomputers.com.au wrote: Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are mass-listed the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
Re: [SHAME] Spam Rats
On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote: Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing? Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue. That said, it is best practice to set ptr records even for your unassigned ip space Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts. --julian
RE: [SHAME] Spam Rats
I wouldn't flame you.. I think this forum lacks this kind of discussion. At least we can move on from the LinkedIn email saga earlier this week? From my Galaxy Note II, please excuse any mistakes. Original message From: Julian DeMarchi jul...@jdcomputers.com.au Date: 01/09/2013 7:00 PM (GMT-08:00) To: NANOG nanog@nanog.org Subject: [SHAME] Spam Rats Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are mass-listed the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
RE: [SHAME] Spam Rats
We had issues and similar behavior from SORBS.net and TrendMicro ERS but have never dealt with Spam Rats. It was our second direct allocation from ARIN last year that was apart of a larger block that got split up. Our block was listed in their DUL. It was a pain to remove. They wanted our PTR records to say static and provide a longer TTL. Others on this list have shared similar stories. This is crazy but it's their service and seem to be a common practice amongst some RBLs. I hope you get your issue fixed. FYI - I have a PTR for all IPs. Just general practice. Otis -Original Message- From: Julian DeMarchi [mailto:jul...@jdcomputers.com.au] Sent: Wednesday, January 09, 2013 8:59 PM To: NANOG Subject: [SHAME] Spam Rats Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are mass-listed the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
Re: OOB core router connectivity wish list
Once upon a time, Randy Carpenter rcar...@network1.net said: Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) RHEL installs with a serial console just fine. You also don't have to make your own boot image to get a non-graphical boot. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: [SHAME] Spam Rats
Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing. Also it is your choice whether or not to follow best practices, it is spam rats choice to block mail based on whatever they like, and it is the choice of some random email Admin or the other to block mail based on spam rats.. Which is something I wouldn't recommend to people running a production mail system, but we'll.. --srs (htc one x) On 10-Jan-2013 8:40 AM, Julian DeMarchi jul...@jdcomputers.com.au wrote: On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote: Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing? Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue. That said, it is best practice to set ptr records even for your unassigned ip space Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts. --julian
Re: [SHAME] Spam Rats
Once upon a time, Suresh Ramasubramanian ops.li...@gmail.com said: That said, it is best practice to set ptr records even for your unassigned ip space [citation needed] -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: OOB core router connectivity wish list
Uplogix has a pretty rad solution.. From my Galaxy Note II, please excuse any mistakes. Original message From: Randy Carpenter rcar...@network1.net Date: 01/09/2013 7:07 PM (GMT-08:00) To: Mikael Abrahamsson swm...@swm.pp.se Cc: nanog@nanog.org Subject: Re: OOB core router connectivity wish list My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) 2. Something that is standard across everything, and can be aggregated easily onto a console server or the like I don't really see what is wrong with with keeping the serial port as the standard. Things like servers and RAID cards and such are coming with BIOSes that are graphical and even require a mouse to use. What use is that when I need to get into the BIOS from a remote site that is completely down? Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) It might be nice to have a management-only port of some sort to do more advanced things that serial cannot do, but the serial port is ubiquitous already, and I don't see any reason to remove it as the very low-level access method. thanks, -Randy - Original Message - I have together with some other people, collected a wish list for OOB support, mainly aimed for core routers. This is to replace the legacy serial port usually present on core routing equipment and to move/collapse all its functionality to an ethernet only port. Some equipment already have an mgmt ethernet port, but usually this can't do everything, meaning today one has to have OOB ethernet *and* OOB serial which just brings more pain than before. I would like to post it here to solicit feedback on it. Feel free to use it to tell your vendor account teams you want this if you feel it useful. I've already sent it to one vendor. http://swm.pp.se/oob.txt Priorities: [P1] - must have, otherwise not useful [P2] - would be very useful, to most operators [P3] - nice to have, useful to some From the OOB ethernet port it should be possible to: [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they might be totally dead and I want to cut power to it via the back plane. Also useful for FPGA upgrades). [P1]: Connect to manage the RP(s) and linecards (equivalent of todays connect on GSR and ASR9k or connecting to RP serial port). [P2]: It should be possible to connect to the OOB from the RP as well (to diagnose OOB connectivity problems). [P2]: Upload software to the RP or otherwise make information available to the RP (for later re-install/turboboot for example). RP should have access to local storage on the OOB device to transfer configuration or software from the OOB device to the RP). [P2]: Read logs and other state of the components in the chassis (displays and LEDs) plus what kind of card is in each slot. [P1]: The OOB port should support (configurable), telnet, ssh and optionally [P3] https login (with a java applet or equivalent to give CLI access in the browser) with ACLs to limit wherefrom things can be done. OOB should support ssh key based logins to admin account. [P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only. [P1]: It should be possible to transfer data using tftp, ftp and scp (ftp client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server). [P2]: OOB device should have tacacs and radius and [P1] local user/password database support for authentication. [P3] OOB should support ssh-key based authentication. [P3] Chassis should have a character display or LEDs with configurable blink pattern from OOB, to aid remote hands identification. [P3] OOB should have two USB ports, one to use to insert storage to transfer files to/from device. The other should be USB port that presents itself as ether USB serial port, or USB ethernet port, where the OOB device would have built in DHCP/DHCPv6 server to give IPv4v6 access to a laptop connected to the OOB so the onsite engineer can then use ssh/telnet to administrate the OOB. Optionally this port could be ethernet port (compare todays CON and AUX ports). [P2] OOB should have procedure to factory default its configuration, perhaps physical button that can be pressed and held for duration of time. The fact that this is done should be logged to the RP. [P3] OOB should have possibility to show power supply and environmental state. [P3] The factory default configuration should not include an empty or obvious login password. The factory-default login password should be the MAC address (without punctuation) of the OOB
Re: [SHAME] Spam Rats
On 01/10/2013 01:16 PM, Suresh Ramasubramanian wrote: Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing. They are yes. Emails are being blocked due to the listing on spamrats. For our colo ranges we do not set PTRs by default. I do for the hosts I run. I do beleive in BCP. :)
Re: [SHAME] Spam Rats
One $GENERATE in bind should take care of that, and save what looks like the usual extra long nanog thread? What does it cost you not to do it? On Thursday, January 10, 2013, Julian DeMarchi wrote: On 01/10/2013 01:16 PM, Suresh Ramasubramanian wrote: Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing. They are yes. Emails are being blocked due to the listing on spamrats. For our colo ranges we do not set PTRs by default. I do for the hosts I run. I do beleive in BCP. :) -- --srs (iPad)
Re: [SHAME] Spam Rats
On Jan 9, 2013, at 8:58 PM, Julian DeMarchi wrote: This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well. I tried SpamRats a few years ago, but found them to have too many false positives. Then, they were trying to be early detectors of spam orginiating from static IP cable/DSL customers. Good idea, but poorly executed in operation. --Chris
Re: [SHAME] Spam Rats
On Thu, 10 Jan 2013, Julian DeMarchi wrote: Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue. That frequently just means they've subscribed to one of the monitoring services that notifies you if your IPs have turned up on any DNSBL the monitoring service has ever heard of, sometimes including ones that have been shut down, domain snatched up by speculators, and wildcard A record installed pointing at an ads landing page. Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts. If they're not mail servers, how is the DNSBL listing impacting them (assuming anyone even uses spamrats)? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [SHAME] Spam Rats
On Thu, Jan 10, 2013 at 12:58:59PM +1000, Julian DeMarchi wrote: This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? First, this would be better on mailop. Second, they're running a DNSBL, not *the* RBL. Third, anyone may run any DNSBL with any policy they wish: listing IP addresses whose octets are primes, domains with the letter j in their names, etc. Provide they comply with RFC 6471, this isn't a problem. What *might* be a problem is how they're used and by whom, but one of the nice features of DNSLs in operational practice is that those with suboptimal listing policies aren't used much. Fourth, one of the hundreds of DNSBLs may be the least of your problems. For roughly a decade now, it's been a very good idea to refuse/defer all mail traffic from anything which doesn't have matching PTR and A records. (The refuse/defer depends on whether the problem appears to be a permanent misconfiguration or the temporary consequence of a DNS oops.) But again: mailop would be better for this. ---rsk
Re: [SHAME] Spam Rats
Personal experience is that I have had a large telco, which I won't name since they immediately unblocked, blocked exactly such a range once, for the exact same reason. RFCs and best practices often aren't a 100 % exact match so sorry, I can't dig up a cite. --srs (htc one x) On 10-Jan-2013 9:00 AM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Suresh Ramasubramanian ops.li...@gmail.com said: That said, it is best practice to set ptr records even for your unassigned ip space [citation needed] -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: [SHAME] Spam Rats
On 01/10/2013 01:30 PM, Jon Lewis wrote: Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts. If they're not mail servers, how is the DNSBL listing impacting them (assuming anyone even uses spamrats)? Here[0] is the only message they give you. All mail servers have PTRs. At least one company uses spamrats. That's how it got escalated to me. --julian 0 - http://pastebin.com/dBSncSaV
Re: [SHAME] Spam Rats
On 01/10/2013 01:27 PM, Chris Boyd wrote: We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well. This is the normal pratice. I would never run a mail server without a PTR. --julian
Re: OOB core router connectivity wish list
- Original Message - Once upon a time, Randy Carpenter rcar...@network1.net said: Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) RHEL installs with a serial console just fine. You also don't have to make your own boot image to get a non-graphical boot. Probably a bit off topic for this thread, but... If I boot the default install disc/image on any of my servers (mostly Supermicro), it hangs at a blank screen when isolinux loads. If you get rid of the splash screen, it works fine. This has been an issue since RHEL4, I think. Maybe other server manufacturers handle the video a little differently, and are able to get past the splash screen. -Randy
RE: [SHAME] Spam Rats
On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring them anyway. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Re: [SHAME] Spam Rats
On 10/01/13 17:15, Karl Auer wrote: On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring them anyway. Regards, K. $GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) I though the point of doing so was to establish with some degree of accuracy that there were 'real people' behind the administration of said IP, and that there was a somewhat increased level of accountability as a result - which suggests there is infact a point.
Re: [SHAME] Spam Rats
In message 50ee4113.2000...@blakjak.net, Mark Foster writes: On 10/01/13 17:15, Karl Auer wrote: On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring them anyway. Regards, K. $GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes. I though the point of doing so was to establish with some degree of accuracy that there were 'real people' behind the administration of said IP, and that there was a somewhat increased level of accountability as a result - which suggests there is infact a point. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [SHAME] Spam Rats
Any moron can run a DNSBL. Many morons do. But that doesn't mean that anyone actually uses them. They are yes. Emails are being blocked due to the listing on spamrats. Please show us a copy of one of the failure messages. Feel free to redact any private information, but please leave the IP addresses and reject messages visible. R's, John PS: In my experience, customers who think that their mail is being rejected due to a DNSBL we never heard of are almost always mistaken. A message bounces due to some random reason, they look up their IP on one of those bazillion DNSBL lookup pages, find some obscure DNSBL that lists them, and leap to the conclusion that's the problem.
Re: [SHAME] Spam Rats
On 1/9/2013 11:41 PM, Mark Andrews wrote: $GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes. Can you wildcard it? (Still an IPv6 implementation virgin, just curious :) ) Jeff
Re: [SHAME] Spam Rats
In message 50ee471c.7010...@utc.edu, Jeff Kell writes: On 1/9/2013 11:41 PM, Mark Andrews wrote: $GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes. Can you wildcard it? No point. address - name - address doesn't work with wildcards. (Still an IPv6 implementation virgin, just curious :) ) Jeff -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [SHAME] Spam Rats
On Thu, Jan 10, 2013 at 12:58:59PM +1000, Julian DeMarchi wrote: This is the first RBL I have seen list a /24 for lack of PTRs. Maybe because it's redundant: a PTR check should be automatic on any incoming SMTP connection. Just think of all the traffic their survey tool generated in compiling this totally useless list. The humanity! Nicolai
Re: [SHAME] Spam Rats
On 1/9/2013 9:58 PM, Julian DeMarchi wrote: There is an anti-spam company called Spam Rats[1] They have listed a /24 of my companies for lack of PTRs in the range I find SpamRats' lists helpful in spam filtering as a low scoring list because it puts some new emitters which haven't had time to build up bad reputation over the top. Having said that, they actually have 3 lists, and only one of those 3 lists involves listing IPs ONLY based on no PTR. They also have an all list, but they document on their web site how to query the all list, but then ignore those return codes indicating the no PTR list. That is how I use them because I didn't need their no PTR list since it would be redundant for me since I was already checking for no PTR myself... and I didn't want to score twice on that one attribute. But if your information is accurate and I understand you correctly, then I agree that they shouldn't list the whole /24 in their PTR list if SOME of those IPs *do* have PTRs. (Actually, I wasn't aware that any of their lists involved /24 blocks. They should probably be more clear about that on their web site.) On their web site, on the http://www.spamrats.com/about.php page, under the heading, NEW - SpamRats All, they describe this method of querying their all list, but ignoring their PTR list's particular return code. I think they made THAT suggestion FOR VERY GOOD REASON. Therefore, you could use this to your advantage by going back to whichever recipient blocked your mail and say... hey, you're NOT using spamRATS in a manner that they suggested, then point them to the section I referenced and explain that many don't use their no PTR list since most spam filters already do that. Maybe that could be a short term solution for you? (probably better than nothing) -- Rob McEwen http://dnsbl.invaluement.com/ r...@invaluement.com +1 (478) 475-9032
Re: [SHAME] Spam Rats
On 01/10/2013 02:55 PM, Rob McEwen wrote: But if your information is accurate and I understand you correctly, then I agree that they shouldn't list the whole /24 in their PTR list if SOME of those IPs *do* have PTRs. My information is correct. The /24 is listed _only_ on the no-ptr list. --- List Status RATS-Dyna - Not on the list RATS-NoPtr - On the list. Worst Offender Alert RATS-Spam - Not on the list --- --julian
Re: [SHAME] Spam Rats
No point. address - name - address doesn't work with wildcards. (Still an IPv6 implementation virgin, just curious :) ) If you want to do generic IPv6 rDNS for all your hosts, you're stuck with a variety of less than great possibilities. One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.) Another is instrumenting the routers so that when they notice a new host on their network, they somehow send an update to the DNS servers to install rDNS for that host. If I had to guess, I would say that we'll eventually agree than on IPv6 networks, mail servers and other hosts who have reputations that matter will have fixed addresses assigned statically or via DHCP and rDNS, random client hosts won't. Teeth will gnash at how this makes some hosts second class and it violates the end to end principle, but tough noogies. R's, John
Re: [SHAME] Spam Rats
In message 20130110053429.55493.qm...@joyce.lan, John Levine writes: No point. address - name - address doesn't work with wildcards. (Still an IPv6 implementation virgin, just curious :) ) If you want to do generic IPv6 rDNS for all your hosts, you're stuck with a variety of less than great possibilities. One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.) NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -100 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers. Another is instrumenting the routers so that when they notice a new host on their network, they somehow send an update to the DNS servers to install rDNS for that host. If I had to guess, I would say that we'll eventually agree than on IPv6 networks, mail servers and other hosts who have reputations that matter will have fixed addresses assigned statically or via DHCP and rDNS, random client hosts won't. Teeth will gnash at how this makes some hosts second class and it violates the end to end principle, but tough noogies. R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: OOB core router connectivity wish list
On Wed, 9 Jan 2013, Randy Carpenter wrote: My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) I don't understand this at all. Why can't an OOB network be ethernet based towards the equipment needing management? 2. Something that is standard across everything, and can be aggregated easily onto a console server or the like Yes, ethernet is the proposed management standard interface. I don't really see what is wrong with with keeping the serial port as the standard. Because it's slow and can't be multiplexed, and it's expensive, only does short distance (20 meters or so), uses different cabling, requires separate planning etc. There are lot of reasons to drop serial port support. Things like servers and RAID cards and such are coming with BIOSes that are graphical and even require a mouse to use. What use is that when I need to get into the BIOS from a remote site that is completely down? My email stated https was way down on the priorities, and ssh and telnet was the prime way of managing the OOB part. It might be nice to have a management-only port of some sort to do more advanced things that serial cannot do, but the serial port is ubiquitous already, and I don't see any reason to remove it as the very low-level access method. An ethernet port is generally a lot cheaper compared to a serial port. Your OOB network would consist of a switch or router with ethernet towards the equipment needing management. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [SHAME] Spam Rats
One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.) NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -100 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers. I know, but figuring out on the fly what order the hashes are would be quite a coding feat. R's, John
Re: [SHAME] Spam Rats
In message alpine.bsf.2.00.1301100106560.55...@joyce.lan, John R. Levine wr ites: One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.) NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -100 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers. I know, but figuring out on the fly what order the hashes are would be quite a coding feat. subtract labels until you have one which fits the namespace pattern. that is the closest encloser ce. hash that name for the closest encloser. hash label.ce add/subtact one for the second half of the noqname proof. hash *.ce add/subtact one for the no wildcard proof. R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: OOB core router connectivity wish list
- Original Message - On Wed, 9 Jan 2013, Randy Carpenter wrote: My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) I don't understand this at all. Why can't an OOB network be ethernet based towards the equipment needing management? How do I connect to it from many miles away when the network is down? I have connected to a misbehaving border device at a remote network via dial-up before, and was able to get it back up and running. I would not have been able to do that if the only options were ethernet or ethernet. 2. Something that is standard across everything, and can be aggregated easily onto a console server or the like Yes, ethernet is the proposed management standard interface. I don't really see what is wrong with with keeping the serial port as the standard. Because it's slow and can't be multiplexed, agreed. Although, I generally don't care if it is slow, as the only need is to get the real network connected features back up and running. and it's expensive, only does short distance (20 meters or so), I completely disagree. The ability for serial to go over POTS makes it ridiculously cheap compared to building a reliable ethernet connection over hundreds or thousands of miles. uses different cabling, requires separate planning etc. There are lot of reasons to drop serial port support. The separate part is what makes it useful. The only reason you should need to access the serial port is because the network is not functioning. If you move the last resort access to be network, how do you access it when you have network issues? An ethernet port is generally a lot cheaper compared to a serial port. Your OOB network would consist of a switch or router with ethernet towards the equipment needing management. But having a console-serial is significantly less complex than console-IP_Stack-ethernet. So many more things to go wrong. I've never had a device that had a faulty serial port. I have seen numerous faulty or misbehaving network ports. I like the current trend of vendors like Juniper. Dedicated management ethernet, *and* serial console port. Best of both worlds. -Randy
Re: OOB core router connectivity wish list
On (2013-01-09 23:17 +), Dobbins, Roland wrote: Flow telemetry export - many of these so-called 'management' ports can't be used to export flow, oddly enough. That is task for on-band interfaces, which attach to your forwarding-logic. OOB is separate component, really only relying on same powersupply, it's key value that it is not fate-sharing any more than absolutely must with host. To export flow, you need port to be connected to your forwarding hardware, not control-plane and certainly not OOB management-plane. The port sole purpose is disaster recovery, it's like NG RS232 port, it would not be used as your day to day port to configure the box. Cheack Cisco's CMP this is what we need. -- ++ytti
Re: OOB core router connectivity wish list
On (2013-01-09 22:05 -0500), Randy Carpenter wrote: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) No. This is not what OOB means. Out-of-band means not fate-sharing your production network. OOB networks are networks, running ethernet, frame-relay, ATM or something else. Just that they are broken at different time to production network, so if you fuck up your production network, you can still access your device via OOB network. The serial port you have in your router is not OOB port, it's fate-sharing the control-plane, if your OS breaks down, your serial port. Think IPMI, if you break your linux installation, you can't login to linux to reload the linux, you need IPMI/DRAC/vPro for that, which is normal ethernet. 2. Something that is standard across everything, and can be aggregated easily onto a console server or the like 'console server' costs more than ethernet switch. So you get less and you pay more. You can't you use RS232 to send images. I don't really see what is wrong with with keeping the serial port as the standard. Then you don't have to use one, you're welcome to use existing solutions, this is not robbing that that on-band RS232 from you. It's adding something new. Cisco devices which have CMP still have legacy on-band RS232, because not all people will realise immediately why and even if they do, not all people can migrate it day1 in non-greenfield. -- ++ytti
Re: OOB core router connectivity wish list
I completely disagree. The ability for serial to go over POTS makes it ridiculously cheap compared to building a reliable ethernet connection over hundreds or thousands of miles. This is identical to ethernet. You need external device then, dial-up modem or CPE, no difference. The separate part is what makes it useful. The only reason you should need to access the serial port is because the network is not functioning. If you move the last resort access to be network, how do you access it when you have network issues? Or because device is not functioning, and if OS is broken, so is your 'OOB'. Or maybe you fucked up upgrade and corrupted image? No way to recover over RS232 (RS232 image upload not supported anymore, even if it would be, Juniper is hard set to 9600bps, even if it would support 115200 it would take 12h to upload image, faster to fly with usb key). But having a console-serial is significantly less complex than console-IP_Stack-ethernet. So many more things to go wrong. I've never had a device that had a faulty serial port. I have seen numerous faulty or misbehaving network ports. Only thing matters is that it fails at different time to production network. I like the current trend of vendors like Juniper. Dedicated management ethernet, *and* serial console port. Best of both worlds. This is fully on-band port ethernet-port, relies 100% on the host OS being up and running. Replace this port with true OOB ethernet, keep RS232 for people who can't migrate day1. You never introduce new thing and kill old thing day1, this is not how things work. You add new thing, then after good amount of time phase-out old thing. -- ++ytti
Re: OOB core router connectivity wish list
On Thu, 10 Jan 2013, Randy Carpenter wrote: How do I connect to it from many miles away when the network is down? I have connected to a misbehaving border device at a remote network via dial-up before, and was able to get it back up and running. I would not have been able to do that if the only options were ethernet or ethernet. You have the same kind of console router, but instead of having lots of serial ports, you have ethernet ports on it. Or you use your DWDM system OOB channel (if available). There are a lot of options. agreed. Although, I generally don't care if it is slow, as the only need is to get the real network connected features back up and running. With modern routers the software is a big image so if you need to re-install, serial is dysfunctional (if it even works, on XR devices it doesn't). I completely disagree. The ability for serial to go over POTS makes it ridiculously cheap compared to building a reliable ethernet connection over hundreds or thousands of miles. RS232 doesn't go hundreds of thousands of miles. A modem connected to a POTS port does this though. The separate part is what makes it useful. The only reason you should need to access the serial port is because the network is not functioning. If you move the last resort access to be network, how do you access it when you have network issues? You seem to be totally misreading everything I'm saying. Did you even read my initial email? This proposed port is OOB, it's completely separate, it's like having a built in serial console router into the chassis with connections to line cards and other devices within the chassis. I like the current trend of vendors like Juniper. Dedicated management ethernet, *and* serial console port. Best of both worlds. No it isn't, because if you want to be able to cut power to the device to power cycle it, you need yet another device to do that that sits inline with the power feed and if it's DC then I would imagine there aren't that many options (=expensive). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [SHAME] Spam Rats
Subject: Re: [SHAME] Spam Rats Date: Thu, Jan 10, 2013 at 03:50:37PM +1100 Quoting Mark Andrews (ma...@isc.org): In message 50ee471c.7010...@utc.edu, Jeff Kell writes: Can you wildcard it? No point. address - name - address doesn't work with wildcards. OTOH, if the requirement is must have PTR and/or organisation fwd domain name should show up in PTR RDATA then wildcards have a place. And yes, BIND loads and answers, as expected. *.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se. ...will work just fine, for instance. I did it for a 200+ segment LAN party, couple years ago. And as is usual with wildcards, if you do need to insert a real record, it will take over just as expected. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ... signature.asc Description: Digital signature
