Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
I'm wondering how many operators don't have systems in place to quickly and efficiently filter problem host systems. I see a lot of talk of ACL usage, but not much about uRPF and black hole filtering. There are a few white papers that are worth a read: http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf http://www.cisco.com/web/about/security/intelligence/urpf.pdf If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. This prevents you from having to maintain ACLs or even give out access to routers. Instead, you can use a small router or daemon that disables hosts by advertising them as a route (for example, we just use a pair of small ISR 1841 routers for this); this in turn can be tied into IPS or a web UI allowing your NOC to disable a problem host at the first hop and prevent its traffic from propagating throughout the network without having to know the overall architecture of the network or determine the best place to apply an ACL. I've seen a lot of talk on trying to filter specific protocols, or rate-limit, etc. but I really feel that isn't the appropriate action to take. I think disabling a system that is a problem and notifying its maintainer that they need to correct the issue is much more sustainable. There are also limitations on how much can be done through the use of ACLs. uRPF and black hole routing scale much better, especially in response to a denial of service attack. When the NTP problems first started popping up, we saw incoming NTP of several Gb, without the ability to quickly identify and filter this traffic a lot of our users would have been dead in the water because the firewalls they use just can't handle that much traffic; our routers, on the other hand, have no problem throwing those packets out. I only comment on this because one of the comments made to me was Can't we just use a firewall to block it?. It took me over an hour to explain that the firewalls in use didn't have the capacity to handle this level of traffic -- and when I tried to discuss hardware vs. software filtering, I got a deer-in-the-headlights look. :-) On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley no.s...@comcast.net wrote: It depends on how many customers you have and what sort of contract you have with them if any. A significant amount of attack traffic comes from residential networks where a one-size-fits-all policy is definitely best. On Feb 26, 2014, at 4:01 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Brandon Galbraith brandon.galbra...@gmail.com On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley no.s...@comcast.net wrote: More politely stated, it's not the responsibility of the operator to decide what belongs on the network and what doesn't. Users can run any services that's not illegal or even reuse ports for other applications. Blocking chargen at the edge doesn't seem to be outside of the realm of possibilities. All of these conversations are variants of how easy is it to set up a default ACL for loops, and then manage exceptions to it?. Assuming your gear permits it, I don't personally see all that much Bad Actorliness in setting a relatively tight bidirectional ACL for Random Edge Customers, and opening up -- either specific ports, or just to a less-/un-filtered ACL on specific request. The question is -- as it is with BCP38 -- *can the edge gear handle it*? And if not: why not? (Protip: because buyers of that gear aren't agitating for it) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
You mean, like Bcp38(.info)? On February 28, 2014 9:02:03 AM EST, Ray Soucy r...@maine.edu wrote: I'm wondering how many operators don't have systems in place to quickly and efficiently filter problem host systems. I see a lot of talk of ACL usage, but not much about uRPF and black hole filtering. There are a few white papers that are worth a read: http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf http://www.cisco.com/web/about/security/intelligence/urpf.pdf If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. This prevents you from having to maintain ACLs or even give out access to routers. Instead, you can use a small router or daemon that disables hosts by advertising them as a route (for example, we just use a pair of small ISR 1841 routers for this); this in turn can be tied into IPS or a web UI allowing your NOC to disable a problem host at the first hop and prevent its traffic from propagating throughout the network without having to know the overall architecture of the network or determine the best place to apply an ACL. I've seen a lot of talk on trying to filter specific protocols, or rate-limit, etc. but I really feel that isn't the appropriate action to take. I think disabling a system that is a problem and notifying its maintainer that they need to correct the issue is much more sustainable. There are also limitations on how much can be done through the use of ACLs. uRPF and black hole routing scale much better, especially in response to a denial of service attack. When the NTP problems first started popping up, we saw incoming NTP of several Gb, without the ability to quickly identify and filter this traffic a lot of our users would have been dead in the water because the firewalls they use just can't handle that much traffic; our routers, on the other hand, have no problem throwing those packets out. I only comment on this because one of the comments made to me was Can't we just use a firewall to block it?. It took me over an hour to explain that the firewalls in use didn't have the capacity to handle this level of traffic -- and when I tried to discuss hardware vs. software filtering, I got a deer-in-the-headlights look. :-) On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley no.s...@comcast.net wrote: It depends on how many customers you have and what sort of contract you have with them if any. A significant amount of attack traffic comes from residential networks where a one-size-fits-all policy is definitely best. On Feb 26, 2014, at 4:01 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Brandon Galbraith brandon.galbra...@gmail.com On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley no.s...@comcast.net wrote: More politely stated, it's not the responsibility of the operator to decide what belongs on the network and what doesn't. Users can run any services that's not illegal or even reuse ports for other applications. Blocking chargen at the edge doesn't seem to be outside of the realm of possibilities. All of these conversations are variants of how easy is it to set up a default ACL for loops, and then manage exceptions to it?. Assuming your gear permits it, I don't personally see all that much Bad Actorliness in setting a relatively tight bidirectional ACL for Random Edge Customers, and opening up -- either specific ports, or just to a less-/un-filtered ACL on specific request. The question is -- as it is with BCP38 -- *can the edge gear handle it*? And if not: why not? (Protip: because buyers of that gear aren't agitating for it) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Managing IOS Configuration Snippets
On Feb 28, 2014, at 9:11 AM, Ryan Shea ryans...@google.com wrote: Keegan, don't get me wrong, I am not suggesting that even if version numbers were happily encoded in robust comments that this would be the same as actually digesting the configuration. If the function of checking using 'fancy versioning' is not an operational best practice, what do you suggest (all-knowing/singing/dancing tool which understands the configuration and your intent aside)? You say IF NTP or CPP were configured differently - with a large enough network there will always be configurations which have differences. With that as an operational constant, how do you determine which devices have the latest iteration of your line vty configuration. That’s what I mean. The things that lend well to to version tracking don’t tend to change much. How many ways are there to configure VTY lines, or NTP, or CPP, or even OSPF and if we’re talking about an access ACL why not just audit the configs to make sure that all the entries are there. Am I really going to care that one router has version 1.0 versus another router that has version 2.2.12 build9? It’s not source code.. How often will a change not be rolled out to every router. This is again related to the size and churn of the network, but my practical estimation is that once you get into thousands of routers there will almost always be some that get missed. Again, a router that was missed is a reason for audit and remediation not versioning. If you find a router with config missing does it really matter what version it’s on and when that version was valid? Not in my experience. Comprehensive auditing is very important, and arguably more useful than version checking - but it requires that you make knowledgeable and complete assertions. I assert the my snmp config should look like the snmp snippet version 77 is easier to grok than make sure our community string is not set to public (and repeat hand-crafted audit logic for every segment of the config). There may be some differences, but those are normally due to equipment lifecycle, mergers/consolidations and such. It’s easy to refer to something as the config for a particular platform or company than a version number. This can be tracked in GIT or SVN. Even then there will not be constant changes. I’d lean towards standardization. So the equipment that cannot adhere to the defined standards probably won’t evolve much on it’s own. What if some of the configs don't match the defined versions? This is why it may make sense to break snippets into functional areas. Just fix it might be sane for a banner, but squashing an interface mtu change that was put there for a reason could end in tears. I consider this bit out of the scope of the question, but yes it is another important problem. I wasn’t saying just fix it. I was saying that router configs don’t lend well to versioning. With software for example, if something is different it might be a different version of that application with compatibility issues, dependencies, library issues, etc. When it’s a router config chances are someone fat-fingered something. Most of the time the best thing to do is to fix or at least alert on the error, not to record it as a valid config version. Again, this is for things that lend themselves to snippets. ACL’s, NTP, SNMP, CPP, even Spanning-tree. Not for things like interface IP’s or static routes that may be different across different boxes or location. If you’re referring to the latter I may have misunderstood your question.. On Thu, Feb 27, 2014 at 10:03 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley no.s...@comcast.net wrote: Putting aside the fact that snippets aren't a good way to conceptualize deployed router code, my gut still tells me to question the question here. The first is does this stuff change often enough to warrant a fancy versioning solution? I have yet to see NTP deployed in a different way than when I first learned to configure it. Next, when it does change how often is it not rolled out to every router. If NTP or CPP or SNMP or some other administrative option were configured differently across my sure, so you're saying that a large bit (maybe) of the router config is 'one size fits all' and 'never changes' where 'never' is really 'very infrequently'. sure, agreed... but there are parts of the config that do change more frequently (depending on the network perhaps)... how do you go about seeing which version / setup is deployed EXCEPT by building a home-grown 'config parser' and seeing that 'what is deployed matches mostly what I have in my config store for this router/class-of-router/network' ? It's a shame that vendors of network equipment don't have to manage large networks of their own equipment under constrained opex environments (no
Re: Managing IOS Configuration Snippets
On Feb 27, 2014, at 7:38 PM, Keegan Holley no.s...@comcast.net wrote: Putting aside the fact that snippets aren’t a good way to conceptualize deployed router code, my gut still tells me to question the question here. What I have always wanted is a way to group configuration, in particular by customer. Ideally with the ability to see it both as a unified view, and also as a per-customer view. For instance: customer A interface GigabitEthernet1/2/3.10 description A ip address 10.0.1.1 255.255.255.0 router bgp 1 neighbor 10.0.1.2 prefix-list A-in in ip prefix-list A-in 10.1.0.0/24 end customer B interface GigabitEthernet1/2/3.11 description B ip address 10.0.2.1 255.255.255.0 router bgp 1 neighbor 10.0.2.2 prefix-list B-in in ip prefix-list B-in 10.2.0.0/24 end Then I should be able to do: show run - Normal output like we see today, the device view. customer A show run - Same format as I have above, just config relevant to customer A. I can even see extending the tag to work with some other commands: customer A show int customer A show bgp ipv4 uni sum customer A show ip prefix-list The same functionality would work for snippets: customer ntp-servers-v1.0 ntp server 1.2.3.4 ntp server 1.2.3.5 ntp server 1.2.3.6 end Basically this follows the two modes in which engineers look at a device. Most of the time is configuring a specific customer, and wanting to be sure they are configured right; including the hard case of no customer A, that is making sure all configuration for a specific customer is removed. The rest of the time is typically troubleshooting a network level problem where you want the device view we have today, I see interface Gig1/2/3 is dropping packets, show run to see who's configure on it sort of operations. I don't know of any platform that has implemented this sort of config framework though. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
When I was looking at the website before I didn't really see any mention of uRPF, just the use of ACLs, maybe I missed it, but it's not encouraging if I can't spot it quickly. I just tried a search and the only thing that popped up was a how-to for a Cisco 7600 VXR. http://www.bcp38.info/index.php/HOWTO:CISCO:7200VXR On Fri, Feb 28, 2014 at 9:04 AM, Jay Ashworth j...@baylink.com wrote: You mean, like Bcp38(.info)? On February 28, 2014 9:02:03 AM EST, Ray Soucy r...@maine.edu wrote: I'm wondering how many operators don't have systems in place to quickly and efficiently filter problem host systems. I see a lot of talk of ACL usage, but not much about uRPF and black hole filtering. There are a few white papers that are worth a read: http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf http://www.cisco.com/web/about/security/intelligence/urpf.pdf If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. This prevents you from having to maintain ACLs or even give out access to routers. Instead, you can use a small router or daemon that disables hosts by advertising them as a route (for example, we just use a pair of small ISR 1841 routers for this); this in turn can be tied into IPS or a web UI allowing your NOC to disable a problem host at the first hop and prevent its traffic from propagating throughout the network without having to know the overall architecture of the network or determine the best place to apply an ACL. I've seen a lot of talk on trying to filter specific protocols, or rate-limit, etc. but I really feel that isn't the appropriate action to take. I think disabling a system that is a problem and notifying its maintainer that they need to correct the issue is much more sustainable. There are also limitations on how much can be done through the use of ACLs. uRPF and black hole routing scale much better, especially in response to a denial of service attack. When the NTP problems first started popping up, we saw incoming NTP of several Gb, without the ability to quickly identify and filter this traffic a lot of our users would have been dead in the water because the firewalls they use just can't handle that much traffic; our routers, on the other hand, have no problem throwing those packets out. I only comment on this because one of the comments made to me was Can't we just use a firewall to block it?. It took me over an hour to explain that the firewalls in use didn't have the capacity to handle this level of traffic -- and when I tried to discuss hardware vs. software filtering, I got a deer-in-the-headlights look. :-) On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley no.s...@comcast.net wrote: It depends on how many customers you have and what sort of contract you have with them if any. A significant amount of attack traffic comes from residential networks where a one-size-fits-all policy is definitely best. On Feb 26, 2014, at 4:01 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Brandon Galbraith brandon.galbra...@gmail.com On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley no.s...@comcast.net wrote: More politely stated, it's not the responsibility of the operator to decide what belongs on the network and what doesn't. Users can run any services that's not illegal or even reuse ports for other applications. Blocking chargen at the edge doesn't seem to be outside of the realm of possibilities. All of these conversations are variants of how easy is it to set up a default ACL for loops, and then manage exceptions to it?. Assuming your gear permits it, I don't personally see all that much Bad Actorliness in setting a relatively tight bidirectional ACL for Random Edge Customers, and opening up -- either specific ports, or just to a less-/un-filtered ACL on specific request . The question is -- as it is with BCP38 -- *can the edge gear handle it*? And if not: why not? (Protip: because buyers of that gear aren't agitating for it) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Filter on IXP
Hi Chris, Le 23/02/2014 01:43, Chris Laffin a écrit : It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. Wasting ASIC ressources on IXP's dataplanes is a wet-dream for anyone willing to kill the network. IXP's neutrality is a key factor to maintain reasonable interconnexion density. Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. By the way, would anyone know how to generate OpenFlow messages to push such filters to member ports ? Would there be any smat way to do that on non-OpenFlow enabled dataplanes (C6k...) ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter NTP traffic by packet size?
Hi Royce, Le 23/02/2014 20:48, Royce Williams a écrit : Newb question ... other than retrofitting, what stands in the way of making BCP38 a condition of peering? Good point ! And simple answer : most peers wouldn't support the hassle yet, thus reducing peering density and interest. I operate a small IXP in southern France and none of my members is currently BCP38 compliant. Of 16 members only one is known to work on the issue. Funny thing beeing that most active members are also switching to Juniper routers and all had been contributing as NTP reflectors because of JunOS bugs. I'd rather consider implementing ACLs on member ports to filter-out illegitimate prefixes (cannot do OpenFlow on cheap L2 switches :( ) rather than making BCP38 compliance mandatory. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter on IXP
- Original Message - From: Jérôme Nicolle jer...@ceriz.fr Le 23/02/2014 01:43, Chris Laffin a écrit : It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. Wasting ASIC ressources on IXP's dataplanes is a wet-dream for anyone willing to kill the network. IXP's neutrality is a key factor to maintain reasonable interconnexion density. Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. Interesting. Are you doing this? Planning it? Or at least researching how well it would work? A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. Don't they do this already? If you get something practical implemented on this topic, we'd be more than pleased to see it show up on bcp38.info; exchange points are the one major construct I hadn't included there, cause I didn't think it was actually practical to do it there. But then, I don't run one. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Filter NTP traffic by packet size?
* ra...@psg.com (Randy Bush) [Thu 27 Feb 2014, 06:10 CET]: is there any modern utility in chargen? No. But as we're not Apple, we don't get to decide what's good for the end user. Who knows, when CGNs become commonplace we'll start to run out of ephemeral ports and we'll have to start using ports 1024 too. Would be a shame if their use were impeded by old ACLs lying around. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
- Original Message - From: Ray Soucy r...@maine.edu When I was looking at the website before I didn't really see any mention of uRPF, just the use of ACLs, maybe I missed it, but it's not encouraging if I can't spot it quickly. I just tried a search and the only thing that popped up was a how-to for a Cisco 7600 VXR. Well, I do mention it, right there on the home page: BCP38 filtering to block these packets is most easily handled right at the very edge of the Internet: where customer links terminate in the first piece of provider 'aggregation' gear, like a router, DSLAM, or CMTS. Much to most of this gear already has a 'knob' which can be turned on, which simply drops these packets on the floor as they come in from the customer's PC. I simply didn't *name* the knob, cause the detail seemed out-of-scope for that context. Where it would get named would be on the information for Audience pages relevant to access providers, which I have not written because -- not being a provider -- I have insufficient background to be accurate. We welcome contributions from people in those positions... you, perhaps? Be bold! :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Managing IOS Configuration Snippets
On 2/28/14, 10:24 , Leo Bicknell wrote: What I have always wanted is a way to group configuration, in particular by customer. Ideally with the ability to see it both as a unified view, and also as a per-customer view. For instance: customer A interface GigabitEthernet1/2/3.10 description A ip address 10.0.1.1 255.255.255.0 router bgp 1 neighbor 10.0.1.2 prefix-list A-in in ip prefix-list A-in 10.1.0.0/24 end ... Basically this follows the two modes in which engineers look at a device. Most of the time is configuring a specific customer, and wanting to be sure they are configured right; including the hard case of no customer A, that is making sure all configuration for a specific customer is removed. The rest of the time is typically troubleshooting a network level problem where you want the device view we have today, I see interface Gig1/2/3 is dropping packets, show run to see who's configure on it sort of operations. I don't know of any platform that has implemented this sort of config framework though. It's not the cleanest, but in junos you can pretty much get this by defining a configuration group per customer and applying them all. Your RE may hate you at commit time, but I've seen this approach work quite well. -e
Re: Filter on IXP
It would be really cool if peering exchanges could police ntp on their connected members. Well, THIS looks like the worst idea ever. while i agree that this is an extremely stupid idea, clearly you have not been reading this list for very long randy
Re: Filter NTP traffic by packet size?
is there any modern utility in chargen? Who knows, when CGNs become commonplace we'll start to run out of ephemeral ports and we'll have to start using ports 1024 too. Would be a shame if their use were impeded by old ACLs lying around. woah! i did not suggest acls. i was assuming that one just disables the 'service'. randy
Re: Filter on IXP
Le 28/02/2014 17:00, Jay Ashworth a écrit : From: Jérôme Nicolle jer...@ceriz.fr Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. Interesting. Are you doing this? Planning it? Or at least researching how well it would work? Juste seriously considering it on TOUIX. I'd propose it to Lyonix and France-IX too. A noticeable side-effect is that members would be encouraged to announce their entire customer-cones to ensure egress trafic from a non-exchanged prefix would not be dropped on the IX's port. Don't they do this already? Not to my knowledge. Some members are only announcing regional prefixes on smaller IXs. They could however exchange trafic originaing from any region of their networks. Best would be to differentiate announced prefixes from legitimately announcable prefixes, as registered to RIPEdb (as far as we're concerned). In a more global perspective, the extended best-practice could be to set ACLs as we generate prefix-lists, route-maps and route-filters for BGP downlinks and PNIs too. If you get something practical implemented on this topic, we'd be more than pleased to see it show up on bcp38.info; exchange points are the one major construct I hadn't included there, cause I didn't think it was actually practical to do it there. But then, I don't run one. I think the idea worth investigating, but I run a very small IXP and will most certainly be unable to fully investigate every potential side-effects on my own. I'll be reaching out to bigger ones in my next email. -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter on IXP
Hi Randy, Le 28/02/2014 17:15, Randy Bush a écrit : clearly you have not been reading this list for very long Well... Busted. All things considered, there surelly has been more stupid proposals. -- Jérôme Nicolle +33 6 19 31 27 14
Re: Filter NTP traffic by packet size?
is there any modern utility in chargen? Who knows, when CGNs become commonplace we'll start to run out of ephemeral ports and we'll have to start using ports 1024 too. Would be a shame if their use were impeded by old ACLs lying around. * ra...@psg.com (Randy Bush) [Fri 28 Feb 2014, 17:23 CET]: woah! i did not suggest acls. i was assuming that one just disables the 'service'. Oh, I'm sorry! I honestly thought this thread was about filtering as a way of mitigating abuse. Yes, of course one should not run the service, especially not UDP. -- Niels.
Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy r...@maine.edu wrote: If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. note that 'in hardware' is dependent upon the model used... note that stuffing 2k (or 5 or 10 or...) extra routes into your edge device could make it super unhappy. your points are valid for your designed network... they may not work everywhere. making the features you point out work better or be more widely known seems like a great idea though :)
Re: Filter on IXP
On 28/02/2014 15:42, Jérôme Nicolle wrote: Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. Nick
Re: Filter on IXP
On Feb 28, 2014, at 11:52 , Nick Hilliard n...@foobar.org wrote: On 28/02/2014 15:42, Jérôme Nicolle wrote: Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's received routes to ingress _and_ egress ACLs on IXP ports would mitigate the role of BCP38 offenders within member ports. It's almost like uRPF in an intelligent and useable form. this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. Or to anyone who doesn't announce their full downstream table to the route servers. Or to people who don't use route servers. Or to someone who does traffic engineering. Or -- TTFN, patrick
Peering issue - Possible Juniper to Cisco issue
To all, I (ASR1001) had an experience recently where the Telco (Juniper) told me that I was sending them 1000+ routes when I attempted to re-establish a BGP session; subsequently they would not allow this and they refused the session. I had no sync on and a prefix list so I was advertising only one route. Even though I hard reset the session on my end the Telco for some reason kept seeing me send the routes. I finally called them and had them reset their end and the session came up right away. What the ... thx Philip
Re: Filter on IXP
Le 28/02/2014 17:52, Nick Hilliard a écrit : this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. It could break if filters are based on announced prefixes. That's preciselly why uRPF is often useless. On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. -- Jérôme Nicolle +33 6 19 31 27 14
Re: Peering issue - Possible Juniper to Cisco issue
On Fri Feb 28, 2014 at 08:58:02AM -0800, Philip Lavine wrote: I had no sync on and a prefix list so I was advertising only one route. Even though I hard reset the session on my end the Telco for some reason kept seeing me send the routes. I finally called them and had them reset their end and the session came up right away. This sounds like you tripped a Max-Prefix limit by advertising too many prefixes at some point (maybe when you first configured the session, when it's easy for the session to come up before you've configured the prefix list). Once you've tripped Max-Prefix, you won't be able to establish a new connection to them until they reset their end. Simon
Re: Peering issue - Possible Juniper to Cisco issue
On Fri, Feb 28, 2014 at 8:58 AM, Philip Lavine source_ro...@yahoo.com wrote: To all, I (ASR1001) had an experience recently where the Telco (Juniper) told me that I was sending them 1000+ routes when I attempted to re-establish a BGP session; subsequently they would not allow this and they refused the session. I had no sync on and a prefix list so I was advertising only one route. Even though I hard reset the session on my end the Telco for some reason kept seeing me send the routes. I finally called them and had them reset their end and the session came up right away. What the ... If you leaked once and they have a teardown setup on the Juniper end w/o a timeout, it won't let the neighbor reconnect until the session is cleared. I've seen in IOS 15.x just a few days ago where it had stuck advertising routes that it shouldn't be, though that was between two Sup720 based pieces of gear, so probably unrelated (just a data point that it can/does happen in IOS in general where it's advertising routes that it insists it isn't) thx Philip -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 01 Mar, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 484203 Prefixes after maximum aggregation: 191504 Deaggregation factor: 2.53 Unique aggregates announced to Internet: 239504 Total ASes present in the Internet Routing Table: 46226 Prefixes per ASN: 10.47 Origin-only ASes present in the Internet Routing Table: 35597 Origin ASes announcing only one prefix: 16401 Transit ASes present in the Internet Routing Table:6037 Transit-only ASes present in the Internet Routing Table:168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1858 Unregistered ASNs in the Routing Table: 487 Number of 32-bit ASNs allocated by the RIRs: 6020 Number of 32-bit ASNs visible in the Routing Table:4592 Prefixes from 32-bit ASNs in the Routing Table: 14841 Number of bogon 32-bit ASNs visible in the Routing Table: 4 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:397 Number of addresses announced to Internet: 2656597764 Equivalent to 158 /8s, 88 /16s and 119 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.8 Total number of prefixes smaller than registry allocations: 169116 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 114986 Total APNIC prefixes after maximum aggregation: 34485 APNIC Deaggregation factor:3.33 Prefixes being announced from the APNIC address blocks: 117592 Unique aggregates announced from the APNIC address blocks:49413 APNIC Region origin ASes present in the Internet Routing Table:4895 APNIC Prefixes per ASN: 24.02 APNIC Region origin ASes announcing only one prefix: 1226 APNIC Region transit ASes present in the Internet Routing Table:855 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table:848 Number of APNIC addresses announced to Internet: 731200640 Equivalent to 43 /8s, 149 /16s and 60 /24s Percentage of available APNIC address space announced: 85.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:165723 Total ARIN prefixes after maximum aggregation:82909 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 167138 Unique aggregates announced from the ARIN address blocks: 77636 ARIN Region origin ASes present in the Internet Routing Table:16149 ARIN
Any experience with Comcast digital voice for OOB (offlist is fine)
Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222
The Cidr Report
This report has been generated at Fri Feb 28 21:13:43 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
21-02-14490117 276717
22-02-14490278 276399
23-02-14490404 276168
24-02-14490498 276712
25-02-14491489 276513
26-02-14491118 276545
27-02-14491390 276447
28-02-14491597 276393
AS Summary
46405 Number of ASes in routing system
19025 Number of ASes announcing only one prefix
3500 Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.
119657728 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 28Feb14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 491516 276325 21519143.8% All ASes
AS28573 3500 108 339296.9% NET Serviços de Comunicação
S.A.
AS6389 3021 56 296598.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS17974 2755 190 256593.1% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS4766 2988 904 208469.7% KIXS-AS-KR Korea Telecom
AS18881 1907 25 188298.7% Global Village Telecom
AS1785 2164 411 175381.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS10620 2772 1200 157256.7% Telmex Colombia S.A.
AS36998 1638 99 153994.0% SDN-MOBITEL
AS18566 2048 565 148372.4% MEGAPATH5-US - MegaPath
Corporation
AS4323 2932 1513 141948.4% TWTC - tw telecom holdings,
inc.
AS7303 1751 450 130174.3% Telecom Argentina S.A.
AS4755 1839 624 121566.1% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7545 2189 1037 115252.6% TPG-INTERNET-AP TPG Telecom
Limited
AS7552 1260 158 110287.5% VIETEL-AS-AP Viettel
Corporation
AS22561 1287 227 106082.4% AS22561 - CenturyTel Internet
Holdings, Inc.
AS9829 1593 663 93058.4% BSNL-NIB National Internet
Backbone
AS22773 2324 1394 93040.0% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4808 1181 398 78366.3% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS35908 871 104 76788.1% VPLSNET - Krypt Technologies
AS18101 917 163 75482.2% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS24560 1108 375 73366.2% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS701 1492 763 72948.9% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business
AS4788 978 259 71973.5% TMNET-AS-AP TM Net, Internet
Service Provider
AS6983 1301 582 71955.3% ITCDELTA - ITC^Deltacom
AS8151 1384 666 71851.9% Uninet S.A. de C.V.
AS7738 846 148 69882.5% Telemar Norte Leste S.A.
AS855754 57 69792.4% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS4780 1028 361 66764.9% SEEDNET Digital United Inc.
AS9808 941 286 65569.6% CMNET-GD Guangdong Mobile
Communication Co.Ltd.
AS6147
BGP Update Report
BGP Update Report Interval: 20-Feb-14 -to- 27-Feb-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS982941608 1.8% 41.4 -- BSNL-NIB National Internet Backbone 2 - AS840234531 1.5% 39.3 -- CORBINA-AS OJSC Vimpelcom 3 - AS28573 25671 1.1% 14.0 -- NET Serviços de Comunicação S.A. 4 - AS755223689 1.0% 18.6 -- VIETEL-AS-AP Viettel Corporation 5 - AS453823548 1.0% 42.4 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS10620 23159 1.0% 9.1 -- Telmex Colombia S.A. 7 - AS60349 22167 1.0% 335.9 -- PBL-KIEV-AS Partners. Business Law Ltd. 8 - AS13118 20859 0.9% 496.6 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS45169 19710 0.9%1314.0 -- GLOBAL-DESCON-AS-AP Descon Limited 10 - AS41691 19286 0.8% 964.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 11 - AS477519115 0.8% 490.1 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS29571 16738 0.7% 91.5 -- CITelecom-AS 13 - AS11976 15440 0.7%1403.6 -- FIDN - Fidelity Communication International Inc. 14 - AS815114745 0.6% 14.1 -- Uninet S.A. de C.V. 15 - AS17974 14283 0.6% 5.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS36998 13986 0.6% 8.6 -- SDN-MOBITEL 17 - AS50710 13831 0.6% 61.5 -- EARTHLINK-AS EarthLink Ltd. CommunicationsInternet Services 18 - AS28024 13013 0.6% 41.6 -- Nuevatel PCS de Bolivia S.A. 19 - AS23893 12031 0.5% 308.5 -- BPL-BD House No:03, Road no: 23/A 20 - AS27738 12012 0.5% 20.8 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS6459 7758 0.3%7758.0 -- TRANSBEAM - I-2000, Inc. 2 - AS6629 8669 0.4%4334.5 -- NOAA-AS - NOAA 3 - AS165613354 0.1%3354.0 -- ARIBANETWORK Ariba Inc. Autonomous System 4 - AS395752583 0.1%2583.0 -- SIBINTEK-SAMARA-AS Siberian Internet Company 5 - AS544657439 0.3%2479.7 -- QPM-AS-1 - QuickPlay Media Inc. 6 - AS2899 2169 0.1%2169.0 -- SPRO-NET - SOLUTION PRO 7 - AS14287 10364 0.5%1727.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 8 - AS11976 15440 0.7%1403.6 -- FIDN - Fidelity Communication International Inc. 9 - AS45169 19710 0.9%1314.0 -- GLOBAL-DESCON-AS-AP Descon Limited 10 - AS564881075 0.1%1075.0 -- E-GROUP-AS OOO E-GROUP 11 - AS41691 19286 0.8% 964.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 12 - AS62431 816 0.0% 816.0 -- NCSC-IE-AS National Cyber Security Centre 13 - AS11054 11515 0.5% 719.7 -- LIVEPERSON LivePerson, Inc 14 - AS249331371 0.1% 685.5 -- MINXS-AS MILLENNIUMS.NET GmbH 15 - AS22688 644 0.0% 644.0 -- DOLGENCORP - Dollar General Corporation 16 - AS603451204 0.1% 602.0 -- NBITI-AS Nahjol Balagheh International Research Institution 17 - AS37367 582 0.0% 582.0 -- CALLKEY 18 - AS52069 581 0.0% 581.0 -- VCT-AS Vladivostok Container Terminal Ltd. 19 - AS498472839 0.1% 567.8 -- RAYAZMA-AS Pardazeshgar Rayazma Ltd. 20 - AS114863371 0.1% 561.8 -- COLO-PREM-VZB - Verizon Online LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 20547 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 89.221.206.0/24 19175 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 5 - 192.58.232.0/248667 0.3% AS6629 -- NOAA-AS - NOAA 6 - 67.210.190.0/238261 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 7 - 205.247.12.0/247758 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 8 - 206.152.15.0/247437 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 9 - 67.210.188.0/237166 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 10 - 78.109.192.0/207011 0.3% AS25184 -- AFRANET AFRANET Co. Tehran, Iran 11 - 103.11.61.0/24 6741 0.3% AS9387 -- AUGERE-PK AUGERE-Pakistan 12 - 216.109.107.0/24 6707 0.3% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 13 - 200.23.126.0/246339 0.3% AS8151 -- Uninet S.A. de C.V. 14 - 199.187.118.0/24 5361 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 15 - 113.11.132.0/244538 0.2% AS17658 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 16 - 216.57.5.0/24 4263 0.2% AS12006 -- BROADVIEWNET-AS-12006 - Broadview Networks, Inc. 17 - 69.38.178.0/24 3898 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 18 -
Are DomainKeys for e-mail signing dead?
Apologies if I slept through prior discussions on the topic. E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the following error: #@YAHOO.COM Last error: 5.7.9 554 5.7.9 Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html I note: 1. The e-mail error (5.7.9) references the link http://postmaster.yahoo.com/errors/postmaster-28.html. 2. That Yahoo page does not mention error 5.7.9, but references a similar error 5.7.4 Message not accepted for policy reasons. 3. It appears that Yahoo wants inbound messages signed using DomainKeys technology. 4. Yahoo is the lead inventor of DomainKeys, along with Cicso, PGP, and Sendmail. 5. L-Soft LISTSERV manuals and Yahoo both refer to the website http://domainkeys.sourceforge.net/. 6. When I click on the Documentation and DomainKeys Implementors Mailing List links on that page, I get page not found. 7. A 2007 USA Today Article (http://usatoday30.usatoday.com/tech/products/cnet/2007-05-23-domainkeys-anti-spam_N.htm) mentions that DomainKeys have not been widely adopted. 8. A basic Google search for DomainKeys comes up with no recent articles. One website (http://blog.wordtothewise.com/2011/09/dkim-is-done/) says that DKIM/DomainKeys are dead. Are the rumors of the death of DomainKeys premature? If not, is anyone from Yahoo listening? matthew black california state university, long beach
Re: Are DomainKeys for e-mail signing dead?
On Saturday, March 1, 2014, Matthew Black matthew.bl...@csulb.edu wrote: Apologies if I slept through prior discussions on the topic. E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the following error: Alive and well after the standard evolved. Google DKIM and then DMARC. I doubt anything as antique as listserv supports either, so route its inbound / outbound mail through a gateway running postfix / sendmail etc. --srs -- --srs (iPad)
Re: Are DomainKeys for e-mail signing dead?
In article ed78b1c68b84a14fa706d13a230d7b431e2b9...@its-mail02.campus.ad.csulb.edu you write: Apologies if I slept through prior discussions on the topic. Regardless of what various aging web pages and un-upgraded mail software might say, Domainkeys is as dead as a doornail, even at Yahoo. Use DKIM, you'll be happier, even at Yahoo. R's, John
IANA AS Numbers registry update
The IANA AS Numbers registry has been updated to reflect the allocation of 2 blocks to the RIPE NCC in 2014-02-28: 200192-201215 201216-202239 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Selina Harrington *** Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 ***
Re: Are DomainKeys for e-mail signing dead?
5.7.4 means you told us not to accept your mail unless it was validly signed and it is not. The solution for this is to make sure that mail with a From: in a domain that requires this is validly signed. Yahoo does not care whether you use DKIM or DomainKeys for this purpose; other people may well like DKIM better, making it more fun. I note that the help page you reference mentions DKIM and DomainKeys together every time. If your LISTSERV -- gets mail from somebody with a domain that requires their mail to be validly signed (for instance, via DMARC) -- leaves that sender's address in the From: line -- and breaks the DKIM signature then the mail will not deliver to recipients at Yahoo. Your choices are: -- ask (or force) the sender to join the LISTSERV from a sending domain that does not do this -- modify the From: to not be in the sender's domain -- avoid breaking the DKIM signature -- let the mail fail Elizabeth On 2/28/14 2:51 PM, Matthew Black matthew.bl...@csulb.edu wrote: Apologies if I slept through prior discussions on the topic. E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the following error: #@YAHOO.COM Last error: 5.7.9 554 5.7.9 Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html I note: 1. The e-mail error (5.7.9) references the link http://postmaster.yahoo.com/errors/postmaster-28.html. 2. That Yahoo page does not mention error 5.7.9, but references a similar error 5.7.4 Message not accepted for policy reasons. 3. It appears that Yahoo wants inbound messages signed using DomainKeys technology. 4. Yahoo is the lead inventor of DomainKeys, along with Cicso, PGP, and Sendmail. 5. L-Soft LISTSERV manuals and Yahoo both refer to the website http://domainkeys.sourceforge.net/. 6. When I click on the Documentation and DomainKeys Implementors Mailing List links on that page, I get page not found. 7. A 2007 USA Today Article (http://usatoday30.usatoday.com/tech/products/cnet/2007-05-23-domainkeys-a nti-spam_N.htm) mentions that DomainKeys have not been widely adopted. 8. A basic Google search for DomainKeys comes up with no recent articles. One website (http://blog.wordtothewise.com/2011/09/dkim-is-done/) says that DKIM/DomainKeys are dead. Are the rumors of the death of DomainKeys premature? If not, is anyone from Yahoo listening? matthew black california state university, long beach
Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
+1 in my experience uRPF get’s enabled, breaks something or causes confusion (usually related to multi-homing) and then get’s disabled. On Feb 28, 2014, at 11:49 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy r...@maine.edu wrote: If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. note that 'in hardware' is dependent upon the model used... note that stuffing 2k (or 5 or 10 or...) extra routes into your edge device could make it super unhappy. your points are valid for your designed network... they may not work everywhere. making the features you point out work better or be more widely known seems like a great idea though :)
Re: Are DomainKeys for e-mail signing dead?
On 2/28/2014 18:36, Suresh Ramasubramanian wrote: On Saturday, March 1, 2014, Matthew Black matthew.bl...@csulb.edu wrote: Apologies if I slept through prior discussions on the topic. E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the following error: Alive and well after the standard evolved. Google DKIM and then DMARC. I doubt anything as antique as listserv supports either, so route its inbound / outbound mail through a gateway running postfix / sendmail etc. --srs opendkim[0] does this job beautifully. [0] - http://www.opendkim.org/ -- staticsafe
Re: Managing IOS Configuration Snippets
Thus spake Ryan Shea (ryans...@google.com) on Thu, Feb 27, 2014 at 09:38:33AM -0500: Now, I hand you the 'show run' output and ask you if version 77 of the vty config is on this device. Can you answer the question? Now I hand you the 'show run' from 10,000 more device configs - and 100 more configuration chunks from revision control. Can you still answer the question? Assume a magical revision-history-aware configuration cross reference parser (while a noble and lovely goal) is not available. Hi Ryan, If I'm understanding what you're trying to do, you could script around our rather unsophisticated 'sgrep' (stanza grep) tool combined with scripting around rancid rcs to do what I think you are looking for. http://net.doit.wisc.edu/~dwcarder/scripts/sgrep sgrep can dump out a stanza of ios-like config, then you can rcsdiff that to your master, per 'chunk' of config. ex: sgrep -s vty r-cssc-b280c-1-core.conf Found stanza in r-cssc-b280c-1-core.conf size:9 line vty 0 4 access-class G-A-AdminAccess in exec-timeout 30 0 ipv6 access-class G-A-v6AdminAccess in line vty 5 24 access-class G-A-AdminAccess in exec-timeout 30 0 ipv6 access-class G-A-v6AdminAccess in ! See the -s and -e options for our sgrep. Add 'xargs -P' around your glue, and I think you'd be in luck. If you were building configs around this model, you could use m4. Dale
Re: Managing IOS Configuration Snippets
Thus spake Keegan Holley (no.s...@comcast.net) on Fri, Feb 28, 2014 at 09:49:19AM -0500: I wasn’t saying just fix it. I was saying that router configs don’t lend well to versioning. Um, what? $ rlog r-cssc-b280c-1-core.conf | grep 'total revision' total revisions: 2009; selected revisions: 2009 When it’s a router config chances are someone fat-fingered something. Most of the time the best thing to do is to fix or at least alert on the error, not to record it as a valid config version. We have our operators manually check in revisions (think in rcs terms: co -l router, go do work, verify it, ci -u router) rather than unsolicited / cron-triggered checkins. Then the check-in message contains the operator's description text of the change and often a ticket number. So there slightly fewer fat-finger configs checked in. Dale
Re: Are DomainKeys for e-mail signing dead?
If your LISTSERV -- gets mail from somebody with a domain that requires their mail to be validly signed (for instance, via DMARC) -- leaves that sender's address in the From: line -- and breaks the DKIM signature Ah, that problem. I'd strongly suggest a shim in front of LISTSERV that checks for DMARC policies other than p=none and rejects the incoming mail, simply to protect other members of the list. Otherwise people who follow DMARC advice will reject list mail and get bounced off the list. Yes, this actually happens. R's, John
Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
On Mar 1, 2014, at 9:14 AM, Keegan Holley no.s...@comcast.net wrote: +1 in my experience uRPF get’s enabled, breaks something or causes confusion (usually related to multi-homing) and then get’s disabled. Enabling loose-check - even with allow-default - is useful solely for S/RTBH, if nothing else. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Managing IOS Configuration Snippets
On Feb 28, 2014, at 9:35 PM, Dale W. Carder dwcar...@wisc.edu wrote: Thus spake Keegan Holley (no.s...@comcast.net) on Fri, Feb 28, 2014 at 09:49:19AM -0500: I wasn’t saying just fix it. I was saying that router configs don’t lend well to versioning. Um, what? $ rlog r-cssc-b280c-1-core.conf | grep 'total revision' total revisions: 2009;selected revisions: 2009 I wish you were here to see my eyes rolling.. 2009 versions of something are no more grok-able than one current version. Congrats, you have a config backup system. When it’s a router config chances are someone fat-fingered something. Most of the time the best thing to do is to fix or at least alert on the error, not to record it as a valid config version. We have our operators manually check in revisions (think in rcs terms: co -l router, go do work, verify it, ci -u router) rather than unsolicited / cron-triggered checkins. Then the check-in message contains the operator's description text of the change and often a ticket number. So there slightly fewer fat-finger configs checked in. That’s not what the OP was looking for AFAIK. This is just change management. Dale
Re: Any experience with Comcast digital voice for OOB (offlist is fine)
- Original Message - From: eric-l...@truenet.com Subject: Any experience with Comcast digital voice for OOB (offlist is fine) You're asking if a VoIP link could be used with traditional modems to do OOB management? I'm pretty sure the answer is a flat no: any modems faster than 1200 bps depend on phase change modulations that VoIP codecs can't begin to deal with; FoIP is implemented by spoofing: the TA detects CNG tone, and spoofs a datalink. I don't know of any TAs that will do that with regular data modems. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
