HuuHoa
05-03-2005, 06:51 AM
From: Question 61
Subject: How do I setup a VPN tunnel using pre-shared keys?
Dror-John is right. There is a LOT to know about when you get into encryption, and like any other branch of this industry knowing the hows & whys will help your configs and troubleshooting enormously. The CCO IPSec Product Support page has a wealth of useful info and examples. www.cisco.com/pcgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
RFCs 2401-2412 are not too taxing either. I've added below a very basic example using pre-shared keys, DES encryption and SHA-1 hashing algorithm. Site 1 is 10.0.1.0/24, site 2 10.0.2.0/24 and the serial i/fs 10.0.4.0/30 (& assumes you have sub-i/fs). Names and things in capitals.
Router1(config)#
!
crypto isakmp policy 1
! Define your ISAKMP policy settings
group 2
! 'group' defines the modulus for Diffie-Hellman calculation.
! Default is group 1, less CPU work, but less secure.
authentication pre-share
crypto isakmp key SHARED_KEY_HERE address 10.0.4.2
! Your shared key, and what peer i/f it's used for.
!
crypto ipsec transform-set TS1 ah-sha-hmac esp-des
! Define what happens to the traffic. AH & ESP are two IPSec protocols.
!
crypto map TO_SITE_2 10 ipsec-isakmp
! Define crypto-map
set peer 10.0.4.2
! The other side
set transform-set TS1
! Which transform-set to use
match address 150
! What traffic to include
!
interface Serial1/0.0
ip address 10.0.4.1 255.255.255.252
crypto map TO_SITE_2
! Apply the crypto-map to the i/f
!
access-list 150 permit ip 10.0.1.0 0.0.0.255 any
! Include traffic coming from here. I've said anything going out, for
! there may be places beyond Site 2, but Cisco says this can cause
! problems for multicast traffic. This also assumes no traffic will be
! going to Site 2 from somewhere else _through_ Site 1. Perhaps
! best to err on the more specific side. However it is a good idea
! to not include your serial i/fs, so you can still get at the far router
! if there's a problem.
Router2(config)#
!
crypto isakmp policy 1
group 2
authentication pre-share
crypto isakmp key SHARED_KEY_HERE address 10.0.4.1
!
crypto ipsec transform-set TS1 ah-sha-hmac esp-des
!
crypto map TO_SITE_1 10 ipsec-isakmp
set peer 10.0.4.1
set transform-set TS1
match address 150
!
interface Serial1/0.0
ip address 10.0.4.2 255.255.255.252
crypto map TO_SITE_1
!
access-list 150 permit ip 10.0.2.0 0.0.0.255 any
************************************************** ************************
From: Question 62
Subject: Why does one packet always get dropped on the last hop of traceroute?
And the winner is ... Max. Inspired by (I think) sec. 4.3.2.8 in RFC-1812, we rate-limit our ICMP message generation to 1/sec/destination. This can be adjusted by the "ip icmp rate-limit unreachable" command. More interesting than simply causing an oddity for traceroute, ICMP rate-limiting can cause intermittent PMTUD blackholes (or I should say perhaps "PMTUD brownholes".) If you're doing PMTUD (as alas anyone running Windows defaults to), then you might want to ease the rate limit on DF unreachables.
************************************************** ************************
From: Question 63
Subject: How to setup NATing based on outgoing interface to two different ISPs.
> ISP1 CableModem
> \ /
> \ /
> --------------
> Cisco 2621
> |
---------------------------------
> | |
> Firewall Mail Server
> |
> --------------------
> Company LAN
> > We just installed a T1 to the Internet to co-exist with our Cablemodem. I
> am looking at ways to implement this. We currently have a Cisco 2621 with
> the T1 connection and a Linux Box Masqing cablemodem Internet access now.
> My question is, what would be the best way to implement this?
>
> I proposed we connect the Cablemodem into the 2621 (FEthernet interface)
> next to the T1 connection (separate ISP's btw) and NAT.
That will work. But you need to use route-maps to match the outgoing interface (or next-hop) when you define your NAT pool. In a nutshell:
int fa0/0
ip addr blah
ip nat outside
!
int fa0/1
ip addr blah
ip nat outside
!
ip nat poop ISP1 ISP1_Valid_range_here prefix-length blah
ip nat pool Cable Cable_Valid_range_here prefix-length blah
!
! These uses below are allowed to use the NAT service.
access-list 1 permit 10.0.0.0 0.255.255.255
!
route-map ISP1 perm 10
match ip addr 1
match interface fa0/0
!
route-map Cable perm 10
match ip addr 1
match interfa fa0/1
************************************************** ************************
From: Question 64
Subject: Sample config of using VIC BRI interfaces as an ISDN switch.
Enter this under stupid router tricks (it's got to be more expensive than an ISDN emulator, but not if you've got the parts lying around).
Switch: Cisco 2600 or 3600 with NM-2V and VIC-2BRI-S/T-TE (NT should work too), IOS 12.1.5T9 R1, R2: Cisco with ISDN BRI S/T interface. IOS 12.x
R1----S/T crossover cable----Switch----S/T crossover----R2
These configs let you do ISDN BRI dialup between two routers, using a third router as an ISDN switch. Call setup is flakey but otherwise it seems to work once the call is up.
Switch config, for ISDN dial (and X.25 over ISDN D-channel thrown in too)
!
isdn switch-type basic-net3
x25 routing
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255 ! whatever
!
interface BRI1/0
description to R1
no ip address
isdn switch-type basic-net3
isdn overlap-receiving
isdn protocol-emulate network
isdn layer1-emulate network
isdn incoming-voice voice
isdn x25 dchannel
isdn skipsend-idverify
!
! Basic X.25 over D channel, so you can run pad commands
! For always on, see the Cisco docs
!
interface BRI1/0:0
no ip address
ip mtu 1514
no ip mroute-cache
x25 address 5552000
clns mtu 1514
!
interface BRI1/1
description to R2
no ip address
isdn switch-type basic-net3
isdn protocol-emulate network
isdn layer1-emulate network
isdn incoming-voice voice
isdn skipsend-idverify
!
interface BRI1/1:0
no ip address
ip mtu 1514
no ip mroute-cache
x25 address 5551000
clns mtu 1514
!
x25 route 5551111 interface BRI1/1:0
x25 route 5552222 interface BRI1/0:0
!
voice-port 1/0/0
!
voice-port 1/0/1
!
dial-peer voice 1 pots
incoming called-number 6045551111
destination-pattern 6045552222
direct-inward-dial
port 1/0/0
!
dial-peer voice 2 pots
incoming called-number 6045552222
destination-pattern 6045551111
direct-inward-dial
port 1/0/1
!
dial-peer voice 10 voip
destination-pattern 6045552222
session target ipv4:10.0.0.1
codec clear-channel
!
dial-peer voice 20 voip
destination-pattern 6045551111
session target ipv4:10.0.0.1
codec clear-channel
!
R1, R2 config (just reverse the 5551111/5552222 and 1.1.1.1/1.1.1.2)
!
isdn switch-type basic-net3
!
interface BRI0/0
ip address 1.1.1.1 255.255.255.0
encapsulation ppp
dialer string 6045552222 class DOV
dialer-group 1
isdn switch-type basic-net3
isdn incoming-voice data
isdn calling-number 6045551111
isdn x25 dchannel
!
interface BRI0/0:0
no ip address
ip mtu 1514
no ip mroute-cache
x25 address 5551111
!
map-class dialer DOV
dialer voice-call
dialer-list 1 protocol ip permit
!
************************************************** ************************
From: Question 65
Subject: What kind of memory does the 2500 use?
Parity. 70ns, 72-pin FPM w/ tin leads.
************************************************** ************************
From: Question 66
Subject: How do I make an Ethernet Cross-over cable?
Try this as a crossover cable.
1 to 3
2 to 6
3 to 1
6 to 2
4 to 7
5 to 8
7 to 4
8 to 5
Basically in a traditional cross-over, which is a 10 BaseT and a 100 BaseTX, you are swapping the Green Pair with the Orange Pair, but not so commonly, you have a 100 BaseT4 cross-over cable (which just happens to also be a 1000 BaseT cross-over cable), not only do you swap over the Green and Orange Pair, but you also swap over the Blue and Brown Pair.
The silly part is that in Cisco's Documentation, it show the schematic on a traditional cross-over cable, but you will see the pin-outs of the 1000BaseT Interface.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2950/2950_wc/hig
/hgcable.htm#xtocid42327
I have just made comment to Cisco About this.
************************************************** ************************
From: Question 67
Subject: How do I use NBAR to block NIMDA?
See: http://www.cisco.com/warp/customer/63/nbar_acl_codered.shtml
> Here's my working config (with thanks to John Kaberna and Chris
> Martin) on a 2610 router:
>
>
> ip cef
>
> class-map match-any http-hacks
> match protocol http url "*default.ida*"
> match protocol http url "*x.ida*"
> match protocol http url "*.ida*"
> match protocol http url "*cmd.exe*"
> match protocol http url "*root.exe*"
> match protocol http url "*_vti_bin*"
> match protocol http url "*_mem_bin*"
> match protocol http mime "*readme.exe*"
> match protocol http mime "*readme.eml*"
>
> policy-map mark-inbound-http-hacks
> class http-hacks
> set ip dscp 1
>
> interface Serial0/0
> ip access-group 101 in
> service-policy input mark-inbound-http-hacks
>
> interface Ethernet0/0
> ip access-group 101 out
>
> access-list 101 deny ip any any dscp 1 log
> access-lst 101 permit ip any any
************************************************** ************************
From: Question 68
Subject: What is a FECN/BECN and does it mean anything?
First, when you use FR, it is not over a host to router connection. FR is going to be router to ingress-FR-switch through cloud to egress-FR-switch to destination-router. With that in mind, what you have to worry about with exceeding your CIR is the ingress FR switch.
FECN and BECNs are different mechanisms which I will explain in a minute.
Let me explain the algorithm that FR switches use to police your bandwidth usage. It is a token/credit system that is implemented on the *ingress* FR switch (so the ingress switch is the traffic cop). Keep in mind that everything that I am about to describe occurs entirely within the FR switch, so when I say that you are given tokens to transmit, I mean that in the software of the FR switch these tokens are kept track of, not that the FR switch transmits tokens to your router to use for each frame. I'm going to start with a simple scenario in which you only have a CIR and an EIR of 0. Anyway, every second (which is the default interval, or Tc for those that want the real term) you get Bc tokens which is essentially permission to transmit that many tokens worth of data over the time of that second.
Bc tokens decrement against the CIR, which is to say that Bc tokens are used to regulate the CIR not the EIR (I will describe Be tokens later). At the end of the second you are given more tokens for use during the next second. Every time the FR switch receives data from the router, it subtracts tokens. What happens if you run out of tokens is that every frame will be discarded until the next interval at which point you get more tokens. If it receives a frame marked with a DE bit, it should discard it automatically.
However, most people don't buy FR service with a EIR of zero. In this case where you have a CIR and an EIR, the token credit system is a little more 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
Subject: How do I setup a VPN tunnel using pre-shared keys?
Dror-John is right. There is a LOT to know about when you get into encryption, and like any other branch of this industry knowing the hows & whys will help your configs and troubleshooting enormously. The CCO IPSec Product Support page has a wealth of useful info and examples. www.cisco.com/pcgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
RFCs 2401-2412 are not too taxing either. I've added below a very basic example using pre-shared keys, DES encryption and SHA-1 hashing algorithm. Site 1 is 10.0.1.0/24, site 2 10.0.2.0/24 and the serial i/fs 10.0.4.0/30 (& assumes you have sub-i/fs). Names and things in capitals.
Router1(config)#
!
crypto isakmp policy 1
! Define your ISAKMP policy settings
group 2
! 'group' defines the modulus for Diffie-Hellman calculation.
! Default is group 1, less CPU work, but less secure.
authentication pre-share
crypto isakmp key SHARED_KEY_HERE address 10.0.4.2
! Your shared key, and what peer i/f it's used for.
!
crypto ipsec transform-set TS1 ah-sha-hmac esp-des
! Define what happens to the traffic. AH & ESP are two IPSec protocols.
!
crypto map TO_SITE_2 10 ipsec-isakmp
! Define crypto-map
set peer 10.0.4.2
! The other side
set transform-set TS1
! Which transform-set to use
match address 150
! What traffic to include
!
interface Serial1/0.0
ip address 10.0.4.1 255.255.255.252
crypto map TO_SITE_2
! Apply the crypto-map to the i/f
!
access-list 150 permit ip 10.0.1.0 0.0.0.255 any
! Include traffic coming from here. I've said anything going out, for
! there may be places beyond Site 2, but Cisco says this can cause
! problems for multicast traffic. This also assumes no traffic will be
! going to Site 2 from somewhere else _through_ Site 1. Perhaps
! best to err on the more specific side. However it is a good idea
! to not include your serial i/fs, so you can still get at the far router
! if there's a problem.
Router2(config)#
!
crypto isakmp policy 1
group 2
authentication pre-share
crypto isakmp key SHARED_KEY_HERE address 10.0.4.1
!
crypto ipsec transform-set TS1 ah-sha-hmac esp-des
!
crypto map TO_SITE_1 10 ipsec-isakmp
set peer 10.0.4.1
set transform-set TS1
match address 150
!
interface Serial1/0.0
ip address 10.0.4.2 255.255.255.252
crypto map TO_SITE_1
!
access-list 150 permit ip 10.0.2.0 0.0.0.255 any
************************************************** ************************
From: Question 62
Subject: Why does one packet always get dropped on the last hop of traceroute?
And the winner is ... Max. Inspired by (I think) sec. 4.3.2.8 in RFC-1812, we rate-limit our ICMP message generation to 1/sec/destination. This can be adjusted by the "ip icmp rate-limit unreachable" command. More interesting than simply causing an oddity for traceroute, ICMP rate-limiting can cause intermittent PMTUD blackholes (or I should say perhaps "PMTUD brownholes".) If you're doing PMTUD (as alas anyone running Windows defaults to), then you might want to ease the rate limit on DF unreachables.
************************************************** ************************
From: Question 63
Subject: How to setup NATing based on outgoing interface to two different ISPs.
> ISP1 CableModem
> \ /
> \ /
> --------------
> Cisco 2621
> |
---------------------------------
> | |
> Firewall Mail Server
> |
> --------------------
> Company LAN
> > We just installed a T1 to the Internet to co-exist with our Cablemodem. I
> am looking at ways to implement this. We currently have a Cisco 2621 with
> the T1 connection and a Linux Box Masqing cablemodem Internet access now.
> My question is, what would be the best way to implement this?
>
> I proposed we connect the Cablemodem into the 2621 (FEthernet interface)
> next to the T1 connection (separate ISP's btw) and NAT.
That will work. But you need to use route-maps to match the outgoing interface (or next-hop) when you define your NAT pool. In a nutshell:
int fa0/0
ip addr blah
ip nat outside
!
int fa0/1
ip addr blah
ip nat outside
!
ip nat poop ISP1 ISP1_Valid_range_here prefix-length blah
ip nat pool Cable Cable_Valid_range_here prefix-length blah
!
! These uses below are allowed to use the NAT service.
access-list 1 permit 10.0.0.0 0.255.255.255
!
route-map ISP1 perm 10
match ip addr 1
match interface fa0/0
!
route-map Cable perm 10
match ip addr 1
match interfa fa0/1
************************************************** ************************
From: Question 64
Subject: Sample config of using VIC BRI interfaces as an ISDN switch.
Enter this under stupid router tricks (it's got to be more expensive than an ISDN emulator, but not if you've got the parts lying around).
Switch: Cisco 2600 or 3600 with NM-2V and VIC-2BRI-S/T-TE (NT should work too), IOS 12.1.5T9 R1, R2: Cisco with ISDN BRI S/T interface. IOS 12.x
R1----S/T crossover cable----Switch----S/T crossover----R2
These configs let you do ISDN BRI dialup between two routers, using a third router as an ISDN switch. Call setup is flakey but otherwise it seems to work once the call is up.
Switch config, for ISDN dial (and X.25 over ISDN D-channel thrown in too)
!
isdn switch-type basic-net3
x25 routing
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255 ! whatever
!
interface BRI1/0
description to R1
no ip address
isdn switch-type basic-net3
isdn overlap-receiving
isdn protocol-emulate network
isdn layer1-emulate network
isdn incoming-voice voice
isdn x25 dchannel
isdn skipsend-idverify
!
! Basic X.25 over D channel, so you can run pad commands
! For always on, see the Cisco docs
!
interface BRI1/0:0
no ip address
ip mtu 1514
no ip mroute-cache
x25 address 5552000
clns mtu 1514
!
interface BRI1/1
description to R2
no ip address
isdn switch-type basic-net3
isdn protocol-emulate network
isdn layer1-emulate network
isdn incoming-voice voice
isdn skipsend-idverify
!
interface BRI1/1:0
no ip address
ip mtu 1514
no ip mroute-cache
x25 address 5551000
clns mtu 1514
!
x25 route 5551111 interface BRI1/1:0
x25 route 5552222 interface BRI1/0:0
!
voice-port 1/0/0
!
voice-port 1/0/1
!
dial-peer voice 1 pots
incoming called-number 6045551111
destination-pattern 6045552222
direct-inward-dial
port 1/0/0
!
dial-peer voice 2 pots
incoming called-number 6045552222
destination-pattern 6045551111
direct-inward-dial
port 1/0/1
!
dial-peer voice 10 voip
destination-pattern 6045552222
session target ipv4:10.0.0.1
codec clear-channel
!
dial-peer voice 20 voip
destination-pattern 6045551111
session target ipv4:10.0.0.1
codec clear-channel
!
R1, R2 config (just reverse the 5551111/5552222 and 1.1.1.1/1.1.1.2)
!
isdn switch-type basic-net3
!
interface BRI0/0
ip address 1.1.1.1 255.255.255.0
encapsulation ppp
dialer string 6045552222 class DOV
dialer-group 1
isdn switch-type basic-net3
isdn incoming-voice data
isdn calling-number 6045551111
isdn x25 dchannel
!
interface BRI0/0:0
no ip address
ip mtu 1514
no ip mroute-cache
x25 address 5551111
!
map-class dialer DOV
dialer voice-call
dialer-list 1 protocol ip permit
!
************************************************** ************************
From: Question 65
Subject: What kind of memory does the 2500 use?
Parity. 70ns, 72-pin FPM w/ tin leads.
************************************************** ************************
From: Question 66
Subject: How do I make an Ethernet Cross-over cable?
Try this as a crossover cable.
1 to 3
2 to 6
3 to 1
6 to 2
4 to 7
5 to 8
7 to 4
8 to 5
Basically in a traditional cross-over, which is a 10 BaseT and a 100 BaseTX, you are swapping the Green Pair with the Orange Pair, but not so commonly, you have a 100 BaseT4 cross-over cable (which just happens to also be a 1000 BaseT cross-over cable), not only do you swap over the Green and Orange Pair, but you also swap over the Blue and Brown Pair.
The silly part is that in Cisco's Documentation, it show the schematic on a traditional cross-over cable, but you will see the pin-outs of the 1000BaseT Interface.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2950/2950_wc/hig
/hgcable.htm#xtocid42327
I have just made comment to Cisco About this.
************************************************** ************************
From: Question 67
Subject: How do I use NBAR to block NIMDA?
See: http://www.cisco.com/warp/customer/63/nbar_acl_codered.shtml
> Here's my working config (with thanks to John Kaberna and Chris
> Martin) on a 2610 router:
>
>
> ip cef
>
> class-map match-any http-hacks
> match protocol http url "*default.ida*"
> match protocol http url "*x.ida*"
> match protocol http url "*.ida*"
> match protocol http url "*cmd.exe*"
> match protocol http url "*root.exe*"
> match protocol http url "*_vti_bin*"
> match protocol http url "*_mem_bin*"
> match protocol http mime "*readme.exe*"
> match protocol http mime "*readme.eml*"
>
> policy-map mark-inbound-http-hacks
> class http-hacks
> set ip dscp 1
>
> interface Serial0/0
> ip access-group 101 in
> service-policy input mark-inbound-http-hacks
>
> interface Ethernet0/0
> ip access-group 101 out
>
> access-list 101 deny ip any any dscp 1 log
> access-lst 101 permit ip any any
************************************************** ************************
From: Question 68
Subject: What is a FECN/BECN and does it mean anything?
First, when you use FR, it is not over a host to router connection. FR is going to be router to ingress-FR-switch through cloud to egress-FR-switch to destination-router. With that in mind, what you have to worry about with exceeding your CIR is the ingress FR switch.
FECN and BECNs are different mechanisms which I will explain in a minute.
Let me explain the algorithm that FR switches use to police your bandwidth usage. It is a token/credit system that is implemented on the *ingress* FR switch (so the ingress switch is the traffic cop). Keep in mind that everything that I am about to describe occurs entirely within the FR switch, so when I say that you are given tokens to transmit, I mean that in the software of the FR switch these tokens are kept track of, not that the FR switch transmits tokens to your router to use for each frame. I'm going to start with a simple scenario in which you only have a CIR and an EIR of 0. Anyway, every second (which is the default interval, or Tc for those that want the real term) you get Bc tokens which is essentially permission to transmit that many tokens worth of data over the time of that second.
Bc tokens decrement against the CIR, which is to say that Bc tokens are used to regulate the CIR not the EIR (I will describe Be tokens later). At the end of the second you are given more tokens for use during the next second. Every time the FR switch receives data from the router, it subtracts tokens. What happens if you run out of tokens is that every frame will be discarded until the next interval at which point you get more tokens. If it receives a frame marked with a DE bit, it should discard it automatically.
However, most people don't buy FR service with a EIR of zero. In this case where you have a CIR and an EIR, the token credit system is a little more 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