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>
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.
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 ªªªªªªªªªª
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.
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.
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.
</sugarRush>