Giáo Trình CIs+ part 92 pps

complex. Every time interval (Tc) you get Bc tokens and Be tokens. In the case that you are not setting the DE on any frames, data received by the FR switch decrements credits from the Bc pool until exhausted. Suppose the FR switch now receives a frame but there are no Bc tokens left (you will get more Bc tokens in the next time interval) at the time. The FR switch will check for a Be token, and if you have one, it will mark the DE field and transmit the frame across the network and decrement tokens from the Be pool. Keep in mind that the Be pool represents your burst capabilities over and above the CIR. IOW, Be tokens keep track of the EIR and Bc tokens keep track of the CIR. Suppose the Be pool is exhausted and the Bc pool is exhausted and another frame arrives. It is dropped, period. At the next time interval you will get more Bc and Be tokens to use. What happens if you mark your own DE frames? Well, when the ingress FR switch receives a non DE-marked frame, it will subtract against the Bc token pool. If it receives a DE-marked frame, it will subtract against the Be token pool. If it receives a non DE-marked frame but there are no Bc tokens left, the FR switch will mark it DE, transmit it and subtract Be tokens. If it receives any frame (regardless of DE or non DE-marked) and there are no Bc or Be tokens left, the frame is dropped. So really the use of marking your own DE frames simply allows you to be the master of your own destiny by categorizing your own data intelligently instead of letting the FR switch do it based simply on the order of arrival. And the reason you want to mark your own packets has to do with how the network handles congestion (see below where I talk about BECN, etc.) A couple of points are worth making. First, you cannot accumulate tokens over time. There is a maximum amount which is the value of the committed burst (Bc) and this value has a mathematical relationship with the CIR (CIR = Bc/Tc also EIR = Be/Tc). In almost all cases Tc is set to 1 second, so the result is that CIR = Bc and EIR = Be. So if you have the maximum number of tokens in your Bc token pool (max amount = Bc), and you send no frames for the next hour, you will still only have Bc amount of tokens when you send the next frame. Second, the above description is not 100% accurate so don't use it to teach a class of newbie students. I simplified a number of things for the sake of getting the concepts across, and in the process I sacrificed the accuracy of some of the information. For instance, you don't get a lump of tokens all at once as I described in reality, your tokens replenish gradually over the Tc interval. Third, you only need a single token (which represents a byte of data) to transmit a frame. So if you are out of Bc tokens and you only have one Be token left, even if you send a 1500 byte frame, it will still be transmitted as DE and the last token will be subtracted. Ok, so how does the FR network handle DE or non-DE frames? Different vendors of FR switches may be designed to operate differently, but I believe the following is the normal behavior. If a node within the cloud starts to experience *mild* congestion, it starts setting the FECN, BECN, or both bits on frames traversing the node. Routers connected to the FR cloud that receive BECN bits should slow their transmission by buffering frames and sending them slightly later. Routers that receive FECN bits might (if there is a way) signal the sending router to slow transmission by buffering its frames. If a node starts experiencing moderate congestion, it will start dropping frames marked DE. At heavy and severe congestion levels, the node will start dropping other traffic as well. Depending on vendor, there may be many levels of priority traffic (i.e. gold vs. bronze customers) to determine exactly which frames to drop before others when experiencing heavy and severe levels of congestion. >> Say I have a CIR of 512 Kbps. Say the users in the site are generating 2 >> Mbps data (internet surfing, email, etc) and I'm not using Discard >> Eligible(because I wouldn't know how to set that up anyway) >> >> Hear is my guesswork. The routers may try to send more than 256kbps. The >> switches will start sending FECN's and BECN's. They shouldn't start generating FECNs and BECNs unless some FR switch along the path is overloaded, and this (in theory) shouldn't happen since you are well below your CIR. IOW, the network should be engineered to be able to handle everyone's CIR on a statistical basis. If this were to happen on a regular basis, I would configure my router to ignore BECNs/FECNs because I am paying for a CIR of 512k, and I'll be darned if I'll let my NSP force my routers to throttle back when I am only using half of my CIR. They are "committing" to 512k, so I want my 512k, not "256k if the network feels like it". >> The routers will slow down sending rates. If a user is sending data to >> a router faster than it can route, what will it do? Does TCP Window sizes >> and acknowledgements between the PC's limit the rate at which the router >> will receive data, so that it is unlikely ever to be too busy? Remember that TCP windowing is an end-to-end mechanism, so routers in between aren't part of the equation. PC's rarely send data *to* a router, but rather *through* a router. So if a user is sending data through a router faster than it can route, the buffers in the router fill up, overflow, and packets get dropped, resulting in retransmissions, and therefore the starting over of the TCP windowing size. >> If data is dropped by the router using DE, will the TCP resend process >> between the PC's be the normal recovery process? Routers don't drop DE frames. That is a FR switch function, not a router function. But, yes, ultimately TCP is the process by which lost packets will be retransmitted. ****************************************************************** ******** From: Question 70 Subject: How do I stop logging (generating snmp trap) for up/down interfaces? Use the interface commands: no logging event link-status no snmp trap link-status ****************************************************************** ******** From: Question 71 Subject: How do I setup the variables to do tftpdnld in rommon? You can use tftp, if available if not no luck xmodem using console or another flash. and I think you can upgrade boot rom to support the command tftpdlnd but not sure about it: IP_ADDRESS=10.1.1.16 IP_SUBNET_MASK=255.255.255.0 DEFAULT_GATEWAY=10.1.1.2 TFTP_SERVER=10.1.1.2 TFTP_FILE=ios.bin FE_SPEED_MODE=0 TFTP_VERBOSE=1 tftpdnld -d ****************************************************************** ******** From: Question 72 Subject: What is the order of operation in terms how a packet is processed? From the book "Inside Cisco IOS Architechture": 1) compression/decompression 2) Encryption 3) Inbound ACL 4) Unicast revese path checking 5) Input rate limiting 6) Broadcast handling (ip helpers) 7) Decrement TTL 8) Inspect sybstem (FW features) 9) Outside to Inside NAT 10) Handle router alert flags in the IP header 11) Search for outbound interface in the routing table 12) Policy routing 13) Handel web cache redirects 14) Inside to Outside NAT 15) Encryption 16) Output ACL 17) Final Inspect check 18) TCP Intercept processing. ****************************************************************** ******** From: Question 73 Subject: What are the differnt T1 jack type codes? RJ48-BLAH where BLAH == "C" Identifies a surface or flushmounted jack. "W" Identifies a wallmounted jack. "S" Identifies a single-line jack. "M" Identifies a multi-line jack. "X" Identifies a complex multi-line or series-type jack. "X" variety can automatically loop up the line if you pull out the cable so it's usually call a "smartjack" ****************************************************************** ******** From: Question 74 Subject: How do I show just one interface's configuration? My all time favourite "trick" is "show run int xx"" where x is the interface in question ****************************************************************** ******** From: Question 75 Subject: How can I script a network reachability test? Today a trouble ticket was elevated to our design team. It seems a bunch of users are locking up while using Outlook with OpenMail servers. Not sure if it was network, Outlook, OpenMail server, or combination of the above. Since the users were somewhat senior level folks, it was not realistic to have to jot down detailed notes about when it happened etc. Since the PCs were all Wintel based, I wrote this in a hurry to include in their "START" menu. Not being able to use Unix tools pretty much tied my hands, and I didn't put in a lot of error checking, but hey, I only had about 30 minutes to whip this up. Although it's a bit simple hope you find it somewhat useful. BEGIN BATCH FILE TITLE TESTING THE NETWORK @echo off cls echo. echo. echo. echo. echo. echo ********************************************************** echo ********************************************************** echo ********************************************************** echo * * echo * * echo * Running network test * echo * This windows will close automatically when * echo * the testing has been completed. * echo * * echo * Please call XYZ at XYZ if you have any questions * echo * * echo * * echo ********************************************************** echo ********************************************************** echo ********************************************************** : : Create a temp folder for our use and start with some flower : box delimeters : if not exist c:\mailte$t md c:\mailte$t echo ***************************************>> c:\mailte$t\%username%.txt echo ***************************************>> c:\mailte$t\%username%.txt : : Pipe in some blank lines and date time stamp. echo. >> c:\mailte$t\%username%.txt echo.|date | find /i "current" >> c:\mailte$t\%username%.txt echo.|time | find /i "current" >> c:\mailte$t\%username%.txt echo. >> c:\mailte$t\%username%.txt : : Start a trace route w/o Rev-DNS lookups to our servers. : The server name is given as a command line argument. echo TRACE ROUTING TO %1 >>c:\mailte$t\%username%.txt . busy? Remember that TCP windowing is an end-to-end mechanism, so routers in between aren't part of the equation. PC's rarely send data *to* a router, but rather *through* a router.