BECNs and FECNs aren't just necessary to know to your Cisco CCNA and CCNP certification exams - they're an essential a part of detecting congestion on a Frame Relay community and allowing the community to dynamically alter its transmission fee when congestion is encountered. The Forward Express Congestion Notification (FECN, pronounced "feckon") bit is about to zero by default, and can be set to 1 if congestion was experienced by the frame in the path through which the body was traveling. A DCE (frame relay change) will set this bit, and a DTE (router) will obtain it, and see that congestion was encountered alongside the body's path. If network congestion exists in the other way wherein the frame was touring, the Backward Specific Congestion Notification (BECN, pronounced "beckon") shall be set to 1 by a DCE. If that is your first time working with BECNs and FECNs, you might wonder why the BECN even exists - after all, why send a "backwards" notification? The BECN is definitely crucial a part of this complete course of, since it is the BECN bit that signifies to the sender that it needs to slow down! For instance, frames sent from Kansas Metropolis to Inexperienced Bay encounter congestion in the FR cloud. A Body Swap sets the FECN bit to 1. With the intention to alert KC that it's sending data too fast, GB will ship return frames with the BECN bit set. When KC sees the BECN bit is set to 1, the KC router is aware of that the congestion occurred when frames have been sent from KC to GB. Body Relay BECN Adaptive Shaping permits a router to dynamically throttle back on its transmission fee if it receives frames from the remote host with the BECN bit set. google_ad_client = "pub-2311940475806896"; /* 300x250, created 1/6/11 */ google_ad_slot = "0098904308"; google_ad_width = 300; google_ad_height = 250; On this case, KC sees that the site visitors it's sending to GB is encountering congestion, as a result of the traffic getting back from GB has the BECN bit set. If BECN Adaptive Shaping is operating on KC, that router will regulate to this congestion by slowing its transmission rate. When the BECNs cease coming in from GB, KC will begin to ship at a quicker rate. BECN Adaptive Shaping is configured as follows: KC(config)int s0 KC(config-if)frame-relay adaptive-shaping becn To see what number of frames are coming in and going out with the BECN and FECN bits set, run present frame pvc. R3show body pvc input pkts 306 output pkts 609 in bytes 45566 out bytes 79364 dropped pkts zero in FECN pkts zero in BECN pkts zero out FECN pkts 0 out BECN pkts zero in DE pkts zero out DE pkts zero out bcast pkts 568 out bcast bytes 75128 pvc create time 01:26:27, final time pvc status changed 01:26:27 Just watch the "in"s and "out"s of BECN, FECN, and DE in both the exam room and your manufacturing networks! Earning your Cisco CCNA and CCNP is a tough proposition, and a part of that is the fact that you quickly study that there's often more than one option to do things with Cisco routers - and whereas that's usually a great thing, you higher know the ins and outs of all options in relation to check day and dealing on production networks. Working with Frame Relay subinterfaces and break up horizon is only one such situation. One cause for using subinterfaces is to avoid the rule of cut up horizon. You recall out of your CCNA studies that break up horizon dictates that a route can't be advertised out the same interface upon which it was learned within the first place. In the following instance, R1 is the hub and R2 and R3 are the spokes. All three routers are using their bodily interfaces for body relay connectivity, and they're additionally running RIPv2 172.12.123.zero /24. Every router can be promoting a loopback interface, using the router number for every octet. R1(config)int s0 R1(config-if)ip deal with 172.12.123.1 255.255.255.0 R1(config-if)no body inverse R1(config-if)body map ip 172.12.123.2 122 broadcast R1(config-if)frame map ip 172.12.123.three 123 broadcast R1(config-if)no shut R2(config)int s0 R2(config-if)encap body R2(config-if)no frame inver R2(config-if)frame map ip 172.12.123.1 221 broadcast R2(config-if)frame map ip 172.12.123.three 221 broadcast R2(config-if)ip address 172.12.123.2 255.255.255.0 R3(config)int s0 R3(config-if)encap body R3(config-if)no body inver R3(config-if)frame map ip 172.12.123.1 321 broadcast R3(config-if)frame map ip 172.12.123.2 321 broadcast R3(config-if)ip handle 172.12.123.3 255.255.255.0 R1show ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] through 172.12.123.2, 00:00:20, Serial0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.three [120/1] through 172.12.123.three, 00:00:22, Serial0 R2show ip route rip 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/1] through 172.12.123.1, 00:00:06, Serial0 R3show ip route rip 1.0.0.zero/32 is subnetted, 1 subnets R 1.1.1.1 [120/1] by way of 172.12.123.1, 00:00:04, Serial0 The hub router R1 has a path to each loopbacks, however neither spoke has a path to the other spoke's loopback. That's as a result of break up horizon prevents R1 from advertising a community via Serial0 if the route was realized on Serial0 to begin with. We have got two choices here, considered one of which is to disable spilt horizon on the interface. Whereas doing so could have the desired impact in our little community, disabling split horizon is not a good idea and must be prevented whenever possible. We're not going to do it in this lab, but right here is the syntax to do so: R1(config)interface serial0 R1(config-if)no ip break up-horizon A better resolution is to configure subinterfaces on R1. The IP addressing must be revisited, but that's no problem here. R1 and R2 will use 172.12.123.zero /24 to speak, whereas R1 and R3 will use 172.12.13.zero /24. R3's serial0 interface will should be renumbered, so let us take a look at all three router configurations: R1(config)interface serial0 R1(config-if)encap frame R1(config-if)no body inverse-arp R1(config-if)no ip address R1(config-if)interface serial0.12 multipoint R1(config-subif)ip handle 172.12.123.1 255.255.255.0 R1(config-subif)body map ip 172.12.123.2 122 broadcast R1(config-subif)interface serial0.31 level-to-level R1(config-subif)ip handle 172.12.13.1 255.255.255.0 R1(config-subif)body interface-dlci 123 R2(config)int s0 R2(config-if)ip tackle 172.12.123.2 255.255.255.zero R2(config-if)encap body R2(config-if)body map ip 172.12.13.3 221 broadcast R2(config-if)body map ip 172.12.123.1 221 broadcast R3(config)int s0 R3(config-if)ip handle 172.12.13.three 255.255.255.0 R3(config-if)encap body R3(config-if)body map ip 172.12.13.1 321 broadcast R3(config-if)body map ip 172.12.123.2 321 broadcast A frame map assertion always names the REMOTE IP handle and the LOCAL DLCI. Remember the printed possibility! Show body map shows us that every one the static mappings on R1 are up and running. Word the "static" output, which signifies these mappings are a result of utilizing the frame map command. Pings are usually not shown, but all three routers can ping each other at this point. R1show body map Serial0 (up): ip 172.12.123.2 dlci 122(0x7A,0x1CA0), static, broadcast, CISCO, standing outlined, active Serial0 (up): ip 172.12.13.3 dlci 123(0x7B,0x1CB0), static, broadcast, CISCO, standing outlined, lively After the 172.12.13.0 /24 network is added to R1 and R3's RIP configuration, R2 and R3 now have one another's loopback network of their RIP routing tables. R2show ip route rip 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/1] via
access point vs router
Niciun comentariu:
Trimiteți un comentariu