- Test - lists.nanog.org

MAE-West Ames (Gigaswitch)
by Sean Donelan 21 Jul '00

21 Jul '00

It appears its the Gigaswitch on the Ames side of Mae-west this afternoon. Multiple ISPs reported the Gigaswitch is having problems, but most said they are using alternate routes and customers should see little impact. In other news, PacBell Internet is reporting problems with northern california connectivity.

1 0

Re: someone RBL'd a reserveD-8 number from IANA
by Simon Leinen 20 Jul '00

20 Jul '00

>>>>> "pv" == Paul Vixie <vixie(a)mibh.net> writes: > I've also thought that if routers could filter based on lookup up > source addresses in a BGP-made RIB, rather than just destination > addresses, that the whole filtering-by-remote-control industry would > appreciate the hell out of it. I'm pretty sure that both the 12016 > and M160 have the hardware it would take to do this at wire speed, > but I'm also pretty sure that the market for this feature is > perceived by both vendors as "small." Cisco's "QoS Policy Propagation via BGP" could almost be used to implement this. The feature is described in http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/bgppr… You can map packets to a service policy according by source(!) or destination address, using an index (the "qos-group") that is stored in the FIB by a route-map action in BGP. The only problem is to define a service policy that drops such packets unconditionally. I haven't found a solution for that, but if there's enough demand, Cisco could easily come up with such a service policy I guess. Otherwise I think the following configuration should do it, given a sufficiently recent IOS: class-map illegal-source-addresses match qos-group 78 ! policy-map drop-illegal-source-addresses class illegal-source-addresses !!! note: the following doesn't work because the bandwidth has to be !!! at least 8 (kbps). Maybe Cisco could be talked into !!! implementing a "drop" command that could be used instead. bandwidth 0 ! interface POS2/1/0 description Evil Outside World bgp-policy source ip-qos-map ! router bgp 1234 table-map mark-illegal-source-addresses neighbor 5.6.7.8 description Vixie's BGP Feed Of Illegal Prefixes neighbor 5.6.7.8 remote-as 5678 ! ip as-patch access-list 56 permit ^5678_ ! route-map mark-illegal-source-addresses match as-path 56 set ip qos-group 78 -- Simon.

1 0

Re: someone RBL'd a reserveD-8 number from IANA
by Richard A. Steenbergen 20 Jul '00

20 Jul '00

On 20 Jul 2000, Paul Vixie wrote: > I've also thought that if routers could filter based on lookup up source > addresses in a BGP-made RIB, rather than just destination addresses, that > the whole filtering-by-remote-control industry would appreciate the hell > out of it. I'm pretty sure that both the 12016 and M160 have the hardware > it would take to do this at wire speed, but I'm also pretty sure that the > market for this feature is perceived by both vendors as "small." Paul I'm pretty sure we're not the only ones who have been asking for this. A dedicated protocol for managing filters would be even nicer, but perhaps a little too difficult to put together. Actually I think you might be very close to being able to put something like this together with some of Juniper's policying routing features, with either slight changes or upcoming software features. Congratulations to those who created an ASIC with enough functionality and generic design to do these kind of things. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: More on black-holed reserved/8 block.
by Paul Vixie 20 Jul '00

20 Jul '00

Valdis.Kletnieks(a)vt.edu writes: > Is it the case that above.net is black-holing packets with a *destination* > in the RBL, but *not* filtering packets with a *source* address from > the RBL? Please tell me how to automatically rebuild an ACL in real time based on advertisements and withdrawals in a BGP feed, and I'll recommend that everybody to that. Meanwhile, the RBL BGP feed only affects destinations. > If so, this would still allow RPC-based attacks (and TCP as well, > if the victim's box had bad sequence number prediction). Yes.

1 0

Re: someone RBL'd a reserveD-8 number from IANA
by Paul Vixie 20 Jul '00

20 Jul '00

jlewis(a)lewis.org writes: > I thought they had put all reserved IP space on the RBL to prevent it from > being announced and used by spammers, then unannounced to make it harder > to track the source. Yup. And every time IANA hands another /8 to some RIR, MAPS has to unblock it. Has that happened with 98.0.0.0/8? Doesn't appear so: IANA (RESERVED-8) Netname: RESERVED-8 Netblock: 96.0.0.0 - 126.255.255.255 Coordinator: Internet Assigned Numbers Authority (IANA-ARIN) iana(a)IANA.ORG (310) 823-9358 Fax- (310) 823-8649 Record last updated on 03-Nov-1998. Database last updated on 20-Jul-2000 06:58:05 EDT. I've thought sometimes that a BGP feed that only included iana-reserved and rfc1918 space, not spammers or other policy violators, would be a popular thing. I've also thought that if routers could filter based on lookup up source addresses in a BGP-made RIB, rather than just destination addresses, that the whole filtering-by-remote-control industry would appreciate the hell out of it. I'm pretty sure that both the 12016 and M160 have the hardware it would take to do this at wire speed, but I'm also pretty sure that the market for this feature is perceived by both vendors as "small."

1 0

Re: More on black-holed reserved/8 block.
by Richard A. Steenbergen 20 Jul '00

20 Jul '00

On Thu, 20 Jul 2000 Valdis.Kletnieks(a)vt.edu wrote: > (And yes, I understand that many routers can route to a blackhole destination > a lot faster than they can apply an ACL on the source). With CEF, you can route to a down interface faster then you can get to Null0. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

someone RBL'd a reserveD-8 number from IANA
by Henry R. Linneweh 20 Jul '00

20 Jul '00

98.100.32.32 traceroute to 98.100.32.32 (98.100.32.32): 1-30 hops, 38 byte packets 1 main.bungi.com (207.126.97.9) 2.15 ms 1.73 ms 1.86 ms 2 above-gw2.above.net (207.126.96.217) 4.41 ms 4.88 ms 3.67 ms 3 core5-main2-oc3.sjc.above.net (216.200.0.205) 3.62 ms 4.56 ms 7.53 ms 4 core3-core5-oc48.sjc2.above.net (208.184.102.206) 6.34 ms 5.7 ms 5.3 ms 5 iad-sjc2-oc48.iad.above.net (216.200.127.25) 73.0 ms 79.7 ms 72.6 ms 6 hat.address.is.on.the.rbl.see.www.mail-abuse.org.for.more.information.above… (208.185.0.26) 72.7 ms 73.6 ms 105 ms 7 * * * -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh

5 4

Re: someone RBL'd a reserveD-8 number from IANA
by Richard A. Steenbergen 20 Jul '00

20 Jul '00

On Thu, 20 Jul 2000, Henry R. Linneweh wrote: > 98.100.32.32 > > traceroute to 98.100.32.32 (98.100.32.32): 1-30 hops, 38 byte packets > 1 main.bungi.com (207.126.97.9) 2.15 ms 1.73 ms 1.86 ms > 2 above-gw2.above.net (207.126.96.217) 4.41 ms 4.88 ms 3.67 ms > 3 core5-main2-oc3.sjc.above.net (216.200.0.205) 3.62 ms 4.56 ms 7.53 ms > 4 core3-core5-oc48.sjc2.above.net (208.184.102.206) 6.34 ms 5.7 ms 5.3 ms > 5 iad-sjc2-oc48.iad.above.net (216.200.127.25) 73.0 ms 79.7 ms 72.6 ms > 6 that.address.is.on.the.rbl.see.www.mail-abuse.org.for.more.information.abov… (208.185.0.26) 72.7 ms 73.6 ms 105 ms > 7 * * * RBL lists everything you shouldn't be getting packets from, including reserved IANA-reserved IP space, and AboveNet subscribes to a full BGP feed. If you could null route based on source using this information it would actually be a pretty effective method of maintaining a network wide filter setup with little to no maintenence. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

route-reflector hierachies
by Lavelle, Neil 20 Jul '00

20 Jul '00

Hi All, I have a debate raging with one of my co-workers as to how one should deploy route-reflectors that has reached the point where I need some help from people that know lots about it ;-) If I have a number of clusters each with its own route-reflector(s) how should I peer between clusters ? >From reading RFC1966 ( and common sense ) it seems that the clusters should be fully meshed, and this is my opinion, however another opionion is that one should build a tree of route-reflectors with some route-reflectors not serving clusters but solely existing to reflect to other route-reflectors. Now I think the second idea would work and might be useful in some very specific cases, but would be madness given that each of the route-reflectors that form nodes of the tree represent single points of failure and that a failure of the root node would have catastophic results .... Any comments ? Thanks in advance Neil -- Neil Lavelle Orchestream Avon House Tel: +44 (0)20 7348 1500 Kensington Village Fax: +44 (0)20 7348 1501 Avonmore Road http://www.orchestream.com/ London W14 8TS, UK

1 0

Sendmail 8.11.0 is released.
by Valdis.Kletnieks＠vt.edu 20 Jul '00

20 Jul '00

OK.. I know a lot of you are running Sendmail, so.. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech

1 0