no ip address bridge-group 1 bridge-group 1 output-type-list 200 int tunnel 0 tunnel source interface loopback0 tunnel destination 192.168.200.254 access-list 200 permit 0x6000 0x600f Router B int e0 ip address 192.168.200.254 255.255.255.0 bridge-group 1 int loop0 no ip address bridge-group 1 bridge-group 1 output-type-list 200 int tunnel0 tunnel source interface loopback0 tunnel destination 192.168.100.254 access-list 200 permit 0x6000 0x600f ****************************************************************** ******** From: Question 50 Subject: Why is measuring collisions meaningless endeavour? > A more useful calculation would be to multiply collisions by > 704 and then divide that by 10000000 * t, to show the total overhead > percentage used by collision detection. 704 is the number of > bit-times consumed by a collision - 96 bittimes of interframe gap, > 512 bits of collision, an additional 96 bittimes of interframe gap, > next packet is ready to transmit. First of all, you shouldn't count the interframe gap twice. The collision event uses an interframe gap, but the next one actually belongs to the next frame; it would be there whether or not a collision occured. More important, 511 bit times is the MAXIMUM time consumed by a collision in the absolute worst-case. This requires a network with maximum extent longest possible cables, maximum repeaters, etc and devices with absolute worst-case timing parameters. In most small networks (e.g., a single 10BASE-T hub), nearly all collisions occur during the preamble, and the time consumed by the collision is just 96+64+32=192 bit-times (IFG+Preamble+Jam). Unless you know the precise instant in which each collision occurs, you cannot calculate the bandwidth "lost" to collisions. (By the way, the maximum collision fragment is 511 bits, not 512 at 512 bits, it becomes a valid frame.) In addition, while some Ethernet controllers do return a collision count as part of the transmit status for each frame, many do not provide the SNMP/RMON driver with the exact number of collisions. Instead, the status indicates one of: * OK (no deferral required, no collisions encountered) * Deferred (deferral required, but no collisions encountered) * 1 collision (one collision encountered, with or without deferral) * >1 collision (more than one collision encountered, with or without deferral) * Excessive collisions (16 collisions encountered) * Late collision (collision encountered after 511 bits transmitted) With this type of controller, you cannot distinguish a frame that encountered two collisions from one that encountered fifteen. so it is hard to estimate the bandwidth "lost" due to collisions. Finally, I will reiterate my position that collision rates are a virtually useless metric for determining network performance. (See my earlier post on this subject.) Seifert's Law of Networking #21: Measurements of unimportant parameters are meaningless. Note added by Hansang Bae In the WORST case scenario (i.e. the stations are at the maximum distance apart) a collision will take up to 84 byte-times to resolve itself. 64 bytes (minimum Ethernet size+FCS), 8 bytes for the preamble, and 12 bytes for the IFG. 84bytes is 672bits. It takes .1 microsecond to transmit one bit (10Mb/s =10,000,000bits/sec = 10,000bits/millisecond =10bits/microsecond = 1 bit/0.1microsecond) So the total time spent on one collision event is 67.2 microsecond (672bits * .1 microsecond) Now consider getting 100 collisions per second. So 100 X 67.2microsecond is 6,720 microsecond or 6.72 millisecond. 6.72ms/1sec comes out to .672% (6.72ms/1sec = .00672, in percentage, that's .672%) That means that 99.328% of the channel is still available for data. Here's another way to look at it. For every successful transmission, there was an equal number of collisions. This is 1:1 ratio or 100% collision rate. Or equivalently, 50% of the frames that goes out the NIC are collisions. Assume that we are talking about an FTP transfer. Typically, FTP will use the 1518 max size and there will be an ACK (Acknowledgement) for every two packets. So you would see two 1518 frames and one ACK for both. So in a collision free world, we would see 2 frames of 1518 bytes and one ACK of 64 bytes. Throw in the preamble/SFD and the IFG to the mix and you get 2*(1518 + 8Preamble + 12 IFG) + 1*(64) = 3,140 bytes. Now if we have 3 collisions (one collision for each successful frame) then you have to add another 3*84 (three frames taking up 84byte times - see #5 above). This comes out to 3,144 + (3*84) = 3,396. So the ratio is 3,140/3,396 = .9246 or 92.46%. That means even with 100% collision rate, we only lose about 7.53% of the bandwidth. Hardly anything to worry about In the real world, you can expect 33% collision rate for an FTP session. Also for smaller size frames, the % of wasted bandwidth would be much greater. But then again, only large transfers tax Ethernet networks. ****************************************************************** ******** From: Question 51 Subject: How do I stop password-recovery on my routers? "Password-recovery" might not be the best description. The feature locks out all access to the ROMMON. You can do this on a 2600/3600 with the global configuration command "no service password-recovery". The feature is indeed tied to the ROMMON. You must have a minimum ROMMON version 11.1(17)AA on the 3600, as well as minimum IOS 11.2(12)P or 11.3(3)T. All ROMMON versions on the 2600 support this feature. ****************************************************************** ******** From: Question 52 Subject: How can I prevent SYN-Flood attack using CAR? We are talking about all different kinds of floods (ICMP, SYN, UDP, etc) throughout this post. Actually he did say that Sprint can filter on their end. I included in a different post the link to configure CAR to limit SYN attacks using web traffic as an example. Your solution looks like it would work too as their are multiple ways to configure traffic shaping. Configure rate limiting for SYN packets. Refer to the following example: interface {int} rate-limit output access-group 153 45000000 100000 100000 conform-action transmit exceed-action drop rate-limit output access-group 152 1000000 100000 100000 conform-action transmit exceed-action drop access-list 152 permit tcp any host eq www access-list 153 permit tcp any host eq www established In the above example, replace: 45000000 with the maximum link bandwidth 1000000 with a value that is between 50% and 30% of the SYN flood rate burst normal and burst max rates with accurate values Note that if you set the burst rate greater than 30%, many legitimate SYNs may be dropped. To get an idea of where to set the burst rate, use the show interfaces rate- limit command to display the conformed and exceeded rates for the interface. Your objective is to rate-limit the SYNs as little as necessary to get things working again. WARNING: It is recommended that you first measure amount of SYN packets during normal state (before attacks occur) and use those values to limit. Review the numbers carefully before deploying this measure. If an SYN attack is aimed against a particular host, consider installing an IP filtering package on that host. One such package is IP Filter. This can be found on http://coombs.anu.edu.au/ipfilter/ Refer to IP Filter Examples for implementation details. ****************************************************************** ******** From: Question 53 Subject: How do I setup a Multilink PPP? You have to create a virtual-template interface with ip address information PPP then create an virtual-access interface whith that address multilink virtual-template 1 interface Virtual-Template1 ip unnumbered Loopback0 or ip address no ip mroute-cache ppp multilink interface Serial0 no ip address encapsulation ppp no fair-queue ppp multilink interface Serial1 no ip address encapsulation ppp no fair-queue ppp multilink ****************************************************************** ******** From: Question 54 Subject: How do I setup ppp callback with dialer-pool? This is a real hard stuff to do ppp callback with dialer-pool, there a some command are missing in your config, look at my example (also see: www.cisco.com/warp/public/cc/pd/ifaa/pa/much/tech/althb_wp.htm) username router1 callback-dialstring 749410 password 0 ect interface BRI0/0 no ip address no ip directed-broadcast encapsulation ppp dialer pool-member 1 isdn switch-type basic-net3 ppp callback accept ppp authentication chap interface BRI0/1 no ip address no ip directed-broadcast encapsulation ppp dialer pool-member 1 isdn switch-type basic-net3 ppp callback accept ppp authentication chap interface Dialer1 ip unnumbered FastEthernet0/0 no ip directed-broadcast encapsulation ppp dialer remote-name router1 dialer pool 1 dialer enable-timeout 2 dialer string 749410 class test1 dialer-group 1 ppp authentication chap map-class dialer test1 dialer callback-server username dialer-list 1 protocol ip permit ****************************************************************** ******** From: Question 55 Subject: My configs are too large. What can I do? The IOS configuration in the 2600 Series is stored in a 32 KB EEPROM. The ROMMON reserves 3 KB, leaving 29 KB for the IOS.You can use the "service compress-config" command to compress the configuration in the EEPROM. You can also load the configuration file from a TFTP server. ****************************************************************** ******** . worst-case. This requires a network with maximum extent longest possible cables, maximum repeaters, etc and devices with absolute worst-case timing parameters. In most small networks (e.g., a single. rates are a virtually useless metric for determining network performance. (See my earlier post on this subject.) Seifert's Law of Networking #21: Measurements of unimportant parameters. becomes a valid frame.) In addition, while some Ethernet controllers do return a collision count as part of the transmit status for each frame, many do not provide the SNMP/RMON driver with the