http://www.msnbc.com/news/954985.asp?0dm=C12MT Associated Press Scientists say they have identified an ocean sponge living in the darkness of the deep sea that grows thin glass fibers capable of transmitting light at least as well as industrial fiber optic cables used for telecommunication. The natural glass fibers also are much more flexible than manufactured fiber optic cable that can crack if bent too far. "YOU CAN ACTUALLY tie a knot in these natural biological fibers and they will not break -- it's really quite amazing," said Joanna Aizenberg, who led the research at Bell Laboratories.
Yea I saw that yesterday. Wasnt sure that was nanog material. But the most interesting fact left out on this summery was the ability to "dope" the fiber with elements like sodium. It seems the little creatures can do things naturally that was havent a clue how to do in the lab. Also they seem to have absolute QoS and zero packet loss ;-) </sugarRush> d At 9:11 -0700 8/21/03, Eric Kuhnke wrote:
http://www.msnbc.com/news/954985.asp?0dm=C12MT
Associated Press
Scientists say they have identified an ocean sponge living in the darkness of the deep sea that grows thin glass fibers capable of transmitting light at least as well as industrial fiber optic cables used for telecommunication. The natural glass fibers also are much more flexible than manufactured fiber optic cable that can crack if bent too far. "YOU CAN ACTUALLY tie a knot in these natural biological fibers and they will not break -- it's really quite amazing," said Joanna Aizenberg, who led the research at Bell Laboratories.
And just think of the potential here for Sponge Bob episodes! On Thu, 21 Aug 2003, David Diaz wrote:
Yea I saw that yesterday. Wasnt sure that was nanog material. But the most interesting fact left out on this summery was the ability to "dope" the fiber with elements like sodium. It seems the little creatures can do things naturally that was havent a clue how to do in the lab.
Also they seem to have absolute QoS and zero packet loss ;-) </sugarRush>
d
At 9:11 -0700 8/21/03, Eric Kuhnke wrote:
http://www.msnbc.com/news/954985.asp?0dm=C12MT
Associated Press
Scientists say they have identified an ocean sponge living in the darkness of the deep sea that grows thin glass fibers capable of transmitting light at least as well as industrial fiber optic cables used for telecommunication. The natural glass fibers also are much more flexible than manufactured fiber optic cable that can crack if bent too far. "YOU CAN ACTUALLY tie a knot in these natural biological fibers and they will not break -- it's really quite amazing," said Joanna Aizenberg, who led the research at Bell Laboratories.
On Thu, Aug 21, 2003 at 12:47:28PM -0400, David Diaz wrote:
Yea I saw that yesterday. Wasnt sure that was nanog material. But the most interesting fact left out on this summery was the ability to "dope" the fiber with elements like sodium. It seems the little creatures can do things naturally that was havent a clue how to do in the lab.
Who lays the fiber under the sea? SPONGE BOB SQUARE PANTS Transparent and yellow and single mode is he SPONGE BOB SQUARE PANTS ... -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
I do believe this email thread might have stayed off-course when we start chanting the intro to SBSQ... scott On Thu, 21 Aug 2003, Richard A Steenbergen wrote: : : On Thu, Aug 21, 2003 at 12:47:28PM -0400, David Diaz wrote: : > : > Yea I saw that yesterday. Wasnt sure that was nanog material. But : > the most interesting fact left out on this summery was the ability to : > "dope" the fiber with elements like sodium. It seems the little : > creatures can do things naturally that was havent a clue how to do in : > the lab. : : Who lays the fiber under the sea? : : SPONGE BOB SQUARE PANTS : : Transparent and yellow and single mode is he : : SPONGE BOB SQUARE PANTS : : ... : : -- : Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras : GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) :
UGH! Fat fingers. Corrections: "strayed off-course" and "SBSP" scott On Thu, 21 Aug 2003, Scott Weeks wrote: : : : : I do believe this email thread might have stayed off-course when we start : chanting the intro to SBSQ... : : scott : : : : On Thu, 21 Aug 2003, Richard A Steenbergen wrote: : : : : : On Thu, Aug 21, 2003 at 12:47:28PM -0400, David Diaz wrote: : : > : : > Yea I saw that yesterday. Wasnt sure that was nanog material. But : : > the most interesting fact left out on this summery was the ability to : : > "dope" the fiber with elements like sodium. It seems the little : : > creatures can do things naturally that was havent a clue how to do in : : > the lab. : : : : Who lays the fiber under the sea? : : : : SPONGE BOB SQUARE PANTS : : : : Transparent and yellow and single mode is he : : : : SPONGE BOB SQUARE PANTS : : : : ... : : : : -- : : Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras : : GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) : : : :
I'm still waiting for the discovery of its natural enemy, the Backhoeiosaur. apl Eric Kuhnke wrote:
http://www.msnbc.com/news/954985.asp?0dm=C12MT
Associated Press
Scientists say they have identified an ocean sponge living in the darkness of the deep sea that grows thin glass fibers capable of transmitting light at least as well as industrial fiber optic cables used for telecommunication. The natural glass fibers also are much more flexible than manufactured fiber optic cable that can crack if bent too far. "YOU CAN ACTUALLY tie a knot in these natural biological fibers and they will not break -- it's really quite amazing," said Joanna Aizenberg, who led the research at Bell Laboratories.
I'm still waiting for the discovery of its natural enemy, the Backhoeiosaur.
All kidding aside, my concern is that it's natural enemy has just found it.
It's such a wonderful example of how exquisite nature is as a designer and builder of complex systems," said Geri Richmond, a chemist and materials scientist at the University of Oregon who wasn't involved in the study.
"We can draw it on paper and think about engineering it but we're in the stone age compared to nature," she said.
That much seems clear. Dave
The natural enemy in this case would be the filefish or the angelfish who eat the sponges... Scott C. McGrath On Thu, 21 Aug 2003, David Meyer wrote:
I'm still waiting for the discovery of its natural enemy, the Backhoeiosaur.
All kidding aside, my concern is that it's natural enemy has just found it.
It's such a wonderful example of how exquisite nature is as a designer and builder of complex systems," said Geri Richmond, a chemist and materials scientist at the University of Oregon who wasn't involved in the study.
"We can draw it on paper and think about engineering it but we're in the stone age compared to nature," she said.
That much seems clear.
Dave
or the naturally occuring coral that can switch multiple oc-192 at line rate and give you accurate counter results ?
I'm still waiting for the discovery of its natural enemy, the Backhoeiosaur.
Eric Kuhnke wrote:
http://www.msnbc.com/news/954985.asp?0dm=C12MT
Associated Press
Scientists say they have identified an ocean sponge living in the darkness of the deep sea that grows thin glass fibers capable of transmitting light at least as well as industrial fiber optic cables used for telecommunication. The natural glass fibers also are much more flexible than manufactured fiber optic cable that can crack if bent too far. "YOU CAN ACTUALLY tie a knot in these natural biological fibers and they will not break -- it's really quite amazing," said Joanna Aizenberg, who led the research at Bell Laboratories.
Perhaps one of you router experts can answer this question. When using the cisco specified filter access-list 199 permit icmp any any echo access-list 199 permit icmp any any echo-reply route-map nachi-worm permit 10 ! --- match ICMP echo requests and replies (type 0 & 8) match ip address 199 ! --- match 92 bytes sized packets match length 92 92 ! --- drop the packet set interface Null0 interface <incoming-interface> ! --- it is recommended to disable unreachables no ip unreachables ! --- if not using CEF, enabling ip route-cache flow is recommended ip route-cache policy ! --- apply Policy Based Routing to the interface ip policy route-map nachi-worm why would it not stop this packet 15 1203.125000 0003E3956600 AMERIC6625D4 ICMP Echo: From 216.144.20.69 To 216.144.00.27 216.144.20.69 216.144.0.27 IP FRAME: Base frame properties FRAME: Time of capture = 8/22/2003 11:54:16.859 FRAME: Time delta from previous physical frame: 0 microseconds FRAME: Frame number: 15 FRAME: Total frame length: 106 bytes FRAME: Capture frame length: 106 bytes FRAME: Frame data: Number of data bytes remaining = 106 (0x006A) ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol ETHERNET: Destination address : 00C0B76625D4 ETHERNET: .......0 = Individual address ETHERNET: ......0. = Universally administered address ETHERNET: Source address : 0003E3956600 ETHERNET: .......0 = No routing information present ETHERNET: ......0. = Universally administered address ETHERNET: Frame Length : 106 (0x006A) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 92 (0x005C) IP: ID = 0x848; Proto = ICMP; Len: 92 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Precedence = Routine IP: Type of Service = Normal Service IP: Total Length = 92 (0x5C) IP: Identification = 2120 (0x848) IP: Flags Summary = 0 (0x0) IP: .......0 = Last fragment in datagram IP: ......0. = May fragment datagram if necessary IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 124 (0x7C) IP: Protocol = ICMP - Internet Control Message IP: Checksum = 0x70D8 IP: Source Address = 216.144.20.69 IP: Destination Address = 216.144.0.27 IP: Data: Number of data bytes remaining = 72 (0x0048) ICMP: Echo: From 216.144.20.69 To 216.144.00.27 ICMP: Packet Type = Echo ICMP: Echo Code = 0 (0x0) ICMP: Checksum = 0x82AA ICMP: Identifier = 512 (0x200) ICMP: Sequence Number = 7680 (0x1E00) ICMP: Data: Number of data bytes remaining = 64 (0x0040) 00000: 00 C0 B7 66 25 D4 00 03 E3 95 66 00 08 00 45 00 .À·f%Ô..ã•f...E. 00010: 00 5C 08 48 00 00 7C 01 70 D8 D8 90 14 45 D8 90 .\.H..|.pØØ.EØ 00020: 00 1B 08 00 82 AA 02 00 1E 00 AA AA AA AA AA AA ....‚ª....ªªªªªª 00030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªªªªªªªª 00040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªªªªªªªª 00050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªªªªªªªª 00060: AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªª
Geo, Look at your set interface Null0 command the rest is correct you want to set the next hop to be Null0. How to do this is left as an exercise for the reader. Scott C. McGrath On Fri, 22 Aug 2003, Geo. wrote:
Perhaps one of you router experts can answer this question. When using the cisco specified filter
access-list 199 permit icmp any any echo access-list 199 permit icmp any any echo-reply
route-map nachi-worm permit 10 ! --- match ICMP echo requests and replies (type 0 & 8) match ip address 199
! --- match 92 bytes sized packets match length 92 92
! --- drop the packet set interface Null0
interface <incoming-interface> ! --- it is recommended to disable unreachables no ip unreachables
! --- if not using CEF, enabling ip route-cache flow is recommended ip route-cache policy
! --- apply Policy Based Routing to the interface ip policy route-map nachi-worm
why would it not stop this packet
15 1203.125000 0003E3956600 AMERIC6625D4 ICMP Echo: From 216.144.20.69 To 216.144.00.27 216.144.20.69 216.144.0.27 IP FRAME: Base frame properties FRAME: Time of capture = 8/22/2003 11:54:16.859 FRAME: Time delta from previous physical frame: 0 microseconds FRAME: Frame number: 15 FRAME: Total frame length: 106 bytes FRAME: Capture frame length: 106 bytes FRAME: Frame data: Number of data bytes remaining = 106 (0x006A) ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol ETHERNET: Destination address : 00C0B76625D4 ETHERNET: .......0 = Individual address ETHERNET: ......0. = Universally administered address ETHERNET: Source address : 0003E3956600 ETHERNET: .......0 = No routing information present ETHERNET: ......0. = Universally administered address ETHERNET: Frame Length : 106 (0x006A) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 92 (0x005C) IP: ID = 0x848; Proto = ICMP; Len: 92 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Precedence = Routine IP: Type of Service = Normal Service IP: Total Length = 92 (0x5C) IP: Identification = 2120 (0x848) IP: Flags Summary = 0 (0x0) IP: .......0 = Last fragment in datagram IP: ......0. = May fragment datagram if necessary IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 124 (0x7C) IP: Protocol = ICMP - Internet Control Message IP: Checksum = 0x70D8 IP: Source Address = 216.144.20.69 IP: Destination Address = 216.144.0.27 IP: Data: Number of data bytes remaining = 72 (0x0048) ICMP: Echo: From 216.144.20.69 To 216.144.00.27 ICMP: Packet Type = Echo ICMP: Echo Code = 0 (0x0) ICMP: Checksum = 0x82AA ICMP: Identifier = 512 (0x200) ICMP: Sequence Number = 7680 (0x1E00) ICMP: Data: Number of data bytes remaining = 64 (0x0040) 00000: 00 C0 B7 66 25 D4 00 03 E3 95 66 00 08 00 45 00 .÷f%Ã..ãâ¢f...E. 00010: 00 5C 08 48 00 00 7C 01 70 D8 D8 90 14 45 D8 90 .\.H..|.pÃÃÂ.Eà00020: 00 1B 08 00 82 AA 02 00 1E 00 AA AA AA AA AA AA ....âª....ªªªªªª 00030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªªªªªªªª 00040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªªªªªªªª 00050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªªªªªªªª 00060: AA AA AA AA AA AA AA AA AA AA ªªªªªªªªªª
Scott McGrath wrote:
Geo,
Look at your set interface Null0 command the rest is correct you want to set the next hop to be Null0. How to do this is left as an exercise for the reader.
Interface Null0 works fine. Here's a quick check. Inbound (from peers) policy matches route-map nachi-worm, permit, sequence 10 Match clauses: ip address (access-lists): 199 length 92 92 Set clauses: interface Null0 Policy routing matches: 10921 packets, 1048416 bytes Outbound (to internal network) accesslist matches Extended IP access list 181 deny tcp any any eq 135 (1994 matches) permit icmp any any echo (757 matches) permit icmp any any echo-reply (381 matches) permit ip any any (381370 matches) I cleared 181 first, then cleared route-map counters. I then checked route-map counters first before checking access-list counters. This means the access-list has more time to accrue maches yet it is considerably smaller. The checks were a matter of seconds. I'd say the policy is working. The echo/echo-reply could easily be everyday pings which are up abit due to various networks having performance issues. IOS Versioning can sometimes have issues. There's also the question of if the packet came in the inbound interface that had the policy applied. -Jack
Geo, Not sure if I want to answer. is this OT for NANOG? :) the key is: IP: Total Length = 92 (0x5C) normal ICMP packets are not 92 bytes in length.... our friend Nachi does use 92 byte packets. BTW: good luck trying the route-map on 2948G-L3s... ;) Thanks, Paul On Fri, 2003-08-22 at 12:55, Jack Bates wrote:
Scott McGrath wrote:
Geo,
Look at your set interface Null0 command the rest is correct you want to set the next hop to be Null0. How to do this is left as an exercise for the reader.
Interface Null0 works fine. Here's a quick check.
Inbound (from peers) policy matches route-map nachi-worm, permit, sequence 10 Match clauses: ip address (access-lists): 199 length 92 92 Set clauses: interface Null0 Policy routing matches: 10921 packets, 1048416 bytes
Outbound (to internal network) accesslist matches Extended IP access list 181 deny tcp any any eq 135 (1994 matches) permit icmp any any echo (757 matches) permit icmp any any echo-reply (381 matches) permit ip any any (381370 matches)
I cleared 181 first, then cleared route-map counters. I then checked route-map counters first before checking access-list counters. This means the access-list has more time to accrue maches yet it is considerably smaller. The checks were a matter of seconds. I'd say the policy is working. The echo/echo-reply could easily be everyday pings which are up abit due to various networks having performance issues.
IOS Versioning can sometimes have issues. There's also the question of if the packet came in the inbound interface that had the policy applied.
-Jack -- Paul A Bradford Senior Network Engineer Adelphia Cable Communications 814-274-1353
Geo, OK Time for me to get coffee.... I missed the "not stop". it might not stop a packet if the route-map isn't applied to the interface..... Pablo On Fri, 2003-08-22 at 12:58, Paul A. Bradford wrote:
Geo, Not sure if I want to answer. is this OT for NANOG? :)
the key is:
IP: Total Length = 92 (0x5C)
normal ICMP packets are not 92 bytes in length.... our friend Nachi does use 92 byte packets.
BTW: good luck trying the route-map on 2948G-L3s... ;)
Thanks, Paul
On Fri, 2003-08-22 at 12:55, Jack Bates wrote:
Scott McGrath wrote:
Geo,
Look at your set interface Null0 command the rest is correct you want to set the next hop to be Null0. How to do this is left as an exercise for the reader.
Interface Null0 works fine. Here's a quick check.
Inbound (from peers) policy matches route-map nachi-worm, permit, sequence 10 Match clauses: ip address (access-lists): 199 length 92 92 Set clauses: interface Null0 Policy routing matches: 10921 packets, 1048416 bytes
Outbound (to internal network) accesslist matches Extended IP access list 181 deny tcp any any eq 135 (1994 matches) permit icmp any any echo (757 matches) permit icmp any any echo-reply (381 matches) permit ip any any (381370 matches)
I cleared 181 first, then cleared route-map counters. I then checked route-map counters first before checking access-list counters. This means the access-list has more time to accrue maches yet it is considerably smaller. The checks were a matter of seconds. I'd say the policy is working. The echo/echo-reply could easily be everyday pings which are up abit due to various networks having performance issues.
IOS Versioning can sometimes have issues. There's also the question of if the packet came in the inbound interface that had the policy applied.
-Jack -- Paul A Bradford Senior Network Engineer Adelphia Cable Communications 814-274-1353
point a route to null0 and set the next hop to be down that route On Fri, 22 Aug 2003, Jack Bates wrote:
Scott McGrath wrote:
Geo,
Look at your set interface Null0 command the rest is correct you want to set the next hop to be Null0. How to do this is left as an exercise for the reader.
Interface Null0 works fine. Here's a quick check.
Inbound (from peers) policy matches route-map nachi-worm, permit, sequence 10 Match clauses: ip address (access-lists): 199 length 92 92 Set clauses: interface Null0 Policy routing matches: 10921 packets, 1048416 bytes
Outbound (to internal network) accesslist matches Extended IP access list 181 deny tcp any any eq 135 (1994 matches) permit icmp any any echo (757 matches) permit icmp any any echo-reply (381 matches) permit ip any any (381370 matches)
I cleared 181 first, then cleared route-map counters. I then checked route-map counters first before checking access-list counters. This means the access-list has more time to accrue maches yet it is considerably smaller. The checks were a matter of seconds. I'd say the policy is working. The echo/echo-reply could easily be everyday pings which are up abit due to various networks having performance issues.
IOS Versioning can sometimes have issues. There's also the question of if the packet came in the inbound interface that had the policy applied.
-Jack
point a route to null0 and set the next hop to be down that route
makes no difference, the problem isn't that the packets aren't being routed to null0, the problem is that the packets don't match the route-map for some reason. Only difference I see is the fragment flag is set to allow fragment on the ones that are getting thru. Geo.
participants (13)
-
Alex Lambert
-
David Diaz
-
David Meyer
-
Eric Kuhnke
-
Geo.
-
Jack Bates
-
Martin J. Levy
-
Paul A. Bradford
-
Richard A Steenbergen
-
Scott Granados
-
Scott McGrath
-
Scott Weeks
-
Stephen J. Wilcox