RE: Filter on IXP
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. And that's a really nice side effect. However in case of transit providers the problem is that RaDB /RIPE lists what prefixes you are allowed to advertise. But that does not necessarily fully match with what source IPs can leave your network. I mean ISP-A can have a customer that uses PA range of other ISP-B and only has a static route towards ISP-A for some TE purposes. I'm not well versed with RIPE myself so I'm not sure whether there's a way to handle this situation. adam -Original Message- From: Jérôme Nicolle [mailto:jer...@ceriz.fr] Sent: Friday, February 28, 2014 6:03 PM To: Nick Hilliard; nanog@nanog.org Subject: 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: Filter on IXP
On 02/03/2014 12:45, Vitkovský Adam wrote: 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. And that's a really nice side effect. and it only works for leaf networks. The moment your ixp supports larger networks, it will break things horribly. It also assumes that: - all your IXP members use route servers (not generally true) - the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true) - the IXP port ASICs can handle large L2 access lists (not generally true) - there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain) - there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement) - the IXP participants keep their IRRDB information fully up-to-date (not generally true) - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Last but not least: - there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case) There are many places where automated RPF makes a lot of sense. An IXP is not one of them. Nick
Re: Filter on IXP
On Sun, Mar 2, 2014 at 4:00 AM, Nick Hilliard n...@foobar.org wrote: There are many places where automated RPF makes a lot of sense. An IXP is not one of them. That make sense. Everyone is rightly resistant to automated filtering. But could we automate getting the word out instead? Can obvious BCP38 cluelessness be measured? Maybe as a ratio of advertised to unadvertised egressing ASes, etc. ? If so, then if your downstream/peer is even *partially* BCP38, give them a pass. They are at least somewhat aware of the problem. Otherwise: - Visually red-flag their BCP38 stats/percentage in RADb; - Send them an automatic email once a week; - Let upstreams *optionally* not automatically update their routes via RADb until they call to ask why; etc. Can we combat the awareness problem in bulk -- without *filtering* in bulk? Royce
Re: Managing IOS Configuration Snippets
On 2/28/2014 9:19 PM, Dale W. Carder wrote:
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.
Dale
I'm digging the idea of your command. Along the same lines I've got
this awk snippet that I made and then forgot about. It functions like
the cisco pipe begin/end commands:
#!/bin/sh
if [ x${2} = x ]; then
awk /${1}/{temp=1}; temp==1{print}
else
awk /${1}/{temp=1};/${2}/{temp=0}; temp==1{print}
fi
Usage:
cat router-confg | begin_regex 'line vty' '!'
If you omit the second argument it just shows you from your match until
the end of file.
Re: Managing IOS Configuration Snippets
Robert,
sgrep can dump out a stanza of ios-like config, then you can rcsdiff
that to your master, per 'chunk' of config.
Dale
I'm digging the idea of your command. Along the same lines I've got this
awk snippet that I made and then forgot about. It functions like the cisco
pipe begin/end commands:
The clever part comes when you write something to tweak sgrep to spit out files
with the commands you need to run to reconfigure multiple devices, and then use
the make command to invoke clogin in parallel to push those changes. Showing
a complete example would get tedious, I have a tarball of the minimum fileset
needed to do this lying around somewhere. Dale probably has one as well.
The basic workflow is as follows:
1) Given a set of configuration files named device.conf, generate a set of
configuration changes to be made, and place those changes in a set of files
named device.cmd. Device is the valid hostname of a router/switch you need to
configure. Device.conf is the configuration file for that device, for example
from rancid. The contents of device.cmd are valid config commands including
config term, exit and write mem, that you intend to run on the device.
We will talk about what to do with those command files in a later step.
So if you wanted to edit the name of vlan100 on all of your routers, you might
do this:
for device in `ls r-*.conf | cut -d. -f1`;
do sgrep -is ^vlan 10\n $device.conf | sed -e 's/name .*/name
new-name/' | grep -v Found $device.cmd;
done
r-myrouter-100.cmd might contain:
vlan 10
name new-name
!
So you would need to make your loop more complex to add the conf t, exit
and wr mem parts, or just use a script. I write a script called mkcmdfile to
wrap sgrep every time I need to do work like this. mkcmdfile means make
command file. If you want to work from the command line, add a second sed
rule to look for Found and replace it with conf t, eliminate the trailing
grep -v Found and edit the original sed to replace vlan new-name with vlan
new-name\nexit\nwr mem/. I don't recommend doing that, but you could. I put
that into a wrapper script, or I post process the cmd files with a second for
loop.
Now that is the less hard way to change 4,000 devices. Except for made up
examples like renaming a vlan on 4,000 devices, that is only a little less
complicated than just doing it by hand, but hopefully you get the idea.
One huge win though, even when doing it by hand as above, I can generate the
files ahead of time, ensure they are correct, and then when I push them at 4AM
I do not have to worry about typographic errors. If you have change approval
boards, the CAB can examine the .cmd files if they choose to, this is a great
way to sanity check your work at 2PM when your mind is clear.
Loops are cool, but in reality, I am far more likely to edit sgrep with some
reasonable defaults, hand it a list of filenames, and then rely on $ARGV
changing to reflect the name of the file it is currently working on, so I know
that when I have a diamond loop (for () { do stuff }) in my Perl, $ARGV.conf
is what sgrep is reading from, and $ARGV.cmd is the file sgrep should be
writing to. In fact, I have something I call mkcmdfile that does pretty much
that.
Writing a custom sgrep for each change allows me to consider the entire
contents of the router, including its name, the business rules associated with
it, anything I keep in a database, etc, when making configuration changes to it.
Don't worry too much about how to do step 1. The lesson you must understand,
is that step 1 is finished when you have a directory full of files, all named
device.cmd, where device is the name of the device to work on, and the contents
are the commands to execute.
2) Given a directory full of command files (named device.cmd) invoke clogin on
each file:
The hard way would be another for loop:
for device in `ls *.cmd | cut -d. -f1`;
do clogin -s $device.cmd $device $device.log;
done
I go into how to do this easily using make later.
3) Look at the resulting $device.log files you generated, and make sure nothing
crazy happened.
It really is that simple. I can create cmd files for 4,000 devices, ensure
the cmd files are changing the correct interface properties, ntp server names
or whatever, and push them to all 4,000 devices, in a few hours. Doing that by
hand would take a week. In some cases, I can push them in 30 minutes.
I have the minimum fileset you need to do that lying around somewhere, but
basically that is it.
When I wrote sgrep, I was asking myself, what would happen if I make a tool
that had more computing power than a tool that works on regular expressions?
grep gets its name from: global - 'regular expression' - print. But regular
expressions are limited in the computing complexity they can reflect. I really
wanted something turing complete. But I never found a way to do it, that
Re: Verizon FIOS IPv6?
On Thu, Feb 27, 2014 at 8:03 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I've heard all sorts of BS answers as to why there is no v6 for FIOS, Step 1. Ask an ALU sales droid about their IPv6 support on PON Step 2. Be disappointed by the answer Step 3. Stroke chin or beard thoughtfully while enjoying the epiphany about why FiOS doesn't do IPv6 yet Bonus - enjoy complementary epiphany about why ATT uVerse uses 6RD Drive Slow, Paul
