From Cisco.
NBAR requires ip cef.
NBAR configuration:
Router(config)#class-map match-any http-hacks
Router(config-cmap)#match protocol http url "*default.ida*"
Router(config-cmap)#match protocol http url "*cmd.exe*"
Router(config-cmap)#match protocol http url "*root.exe*"
Notes:
To block a traffic using NBAR, you have three choise:
1. Using ACL
Build a policy and use the set command to mark inbound "Code Red" hacks with a policy map. This document uses a DSCP value of 1 (in decimal) since it is unlikely that any other network traffic is carrying this value.
Router(config)#policy-map mark-inbound-http-hacks
Router(config-pmap)#class http-hacks
Router(config-pmap-c)#set ip dscp 1
Router(config)#interface serial 0/0 //ingress interface
Router(config-if)#service-policy input mark-inbound-http-hacks
Configure an ACL that matches on the DSCP value of 1, as set by the service policy.
Router(config)#access-list 105 deny ip any any dscp 1
Router(config)#access-list 105 permit ip any any
Router(config)#interface ethernet 0/1 //egress interface
Router(config-if)#ip access-group 105 out
2. Using Police-Based routing to route the traffic to Null0.
Use the service-policy command to apply the policy as an inbound policy on the input interface to mark arriving "Code Red" packets. See method 1.
Create an extended IP ACL that matches on the marked "Code Red" packets.
Router(config)#access-list 106 permit ip any any dscp 1
Use the route-map command to build a routing policy.
Router(config)#route-map null_policy_route 10
Router(config-route-map)#match ip address 106
Router(config-route-map)#set interface Null0
Apply the route-map to the input interface.
Router(config)#interface serial 0/0 //ingress interface.
Router(config-if)#ip policy route-map null_policy_route
We are able to make the discard decision at the ingress interface of the router, rather than needing an output ACL on every egress interface. Again, we recommend disabling the sending IP unreachable messages with the command no ip unreachables command.
3. Using Class-based Policy.
Router(config)#policy-map drop-inbound-http-hacks
Router(config-pmap)#class http-hacks
Router(config-pmap-c)#police 1000000 31250 31250 conform-action drop exceed-action drop violate-action drop
or new IOS supoort
Router(config-pmap-c)#drop
This will be the best solution of all.
Friday, November 28, 2008
RTP classification
Quote from Cisco.
Why nBAR RTP Payload Classification
While placing voice and video on a network, adequate bandwidth must exist to meet the service needs of these applications. Classification and Marking of the traffic should be performed as close to the edge of the network as possible. The marked DSCP values can then classify, condition, and define the per-hop behavior of each traffic class of traffic within the Diffserv domain.
Cisco IOS Software currently offers many methods for the classification of voice and video traffic. The advantages and disadvantages of each feature are listed below.
1. Match ip rtp
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
Notes: To match udp range from 16374 - 16574, use command "match ip rtp 16374 200"
2. Ip dscp and ip precedence
Various applications and end devices (ie: IP Phones and Polycom Video units) can set their DSCP values. The router can now use this specific DSCP, or Precedence, value as classification criteria for voice and video streams. However, a danger does always exist, because another end user or application could, deliberately or accidentally, mark their packets with the same DSCP or Precedence value.
3. Access lists
Access lists can classify RTP packets, based on source or destination IP addresses, and UDP port number range but do not provide a granular way to classify RTP streams. Again, there is a risk of another application inadvertently matching the access-list criteria for identification of voice and video traffic, resulting in potential theft of service for these service classes. Also, access-lists do not provide classification statistics that are available with nBAR. nBAR thus provides more granular and application-specific matching criteria than access lists.
Notes: To match udp range from 16374 - 16574, use command "ip access-list 110 permit udp any any range 16374 16574".
4. nBAR RTP Payload Classification
This feature expands the RTP traffic-matching capabilities of an nBAR-enabled router by looking deeper into the RTP header to check for RTP specific parameters instead of relying on even UDP port numbers alone
This feature also addresses the challenge of distinguishing RTP packets from different applications based on their payload types or CODECS. The space for payload types is limited, so only very common encodings are assigned static types. These are typically audio and video encodings that have been "blessed" by international standardization bodies, such as the G. series of ITU-T audio encodings (see Table 1). Dynamic payload types map an RTP payload type to an audio and video encoding for the duration of a session. Different members of a session could use different mappings if needed. As shown in the above table, Dynamic payload types use the PT range 96-127.
There are multiple encodings defined by the A/V profile that use dynamic payload types, including GSM-HR, RED, VDVI, L8, MP2P and BMPEG Codecs. nBAR RTP Payload type classification provides a powerful means of classifying the applications based on their static or dynamic payload type.
Why nBAR RTP Payload Classification
While placing voice and video on a network, adequate bandwidth must exist to meet the service needs of these applications. Classification and Marking of the traffic should be performed as close to the edge of the network as possible. The marked DSCP values can then classify, condition, and define the per-hop behavior of each traffic class of traffic within the Diffserv domain.
Cisco IOS Software currently offers many methods for the classification of voice and video traffic. The advantages and disadvantages of each feature are listed below.
1. Match ip rtp
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
Notes: To match udp range from 16374 - 16574, use command "match ip rtp 16374 200"
2. Ip dscp and ip precedence
Various applications and end devices (ie: IP Phones and Polycom Video units) can set their DSCP values. The router can now use this specific DSCP, or Precedence, value as classification criteria for voice and video streams. However, a danger does always exist, because another end user or application could, deliberately or accidentally, mark their packets with the same DSCP or Precedence value.
3. Access lists
Access lists can classify RTP packets, based on source or destination IP addresses, and UDP port number range but do not provide a granular way to classify RTP streams. Again, there is a risk of another application inadvertently matching the access-list criteria for identification of voice and video traffic, resulting in potential theft of service for these service classes. Also, access-lists do not provide classification statistics that are available with nBAR. nBAR thus provides more granular and application-specific matching criteria than access lists.
Notes: To match udp range from 16374 - 16574, use command "ip access-list 110 permit udp any any range 16374 16574".
4. nBAR RTP Payload Classification
This feature expands the RTP traffic-matching capabilities of an nBAR-enabled router by looking deeper into the RTP header to check for RTP specific parameters instead of relying on even UDP port numbers alone
This feature also addresses the challenge of distinguishing RTP packets from different applications based on their payload types or CODECS. The space for payload types is limited, so only very common encodings are assigned static types. These are typically audio and video encodings that have been "blessed" by international standardization bodies, such as the G. series of ITU-T audio encodings (see Table 1). Dynamic payload types map an RTP payload type to an audio and video encoding for the duration of a session. Different members of a session could use different mappings if needed. As shown in the above table, Dynamic payload types use the PT range 96-127.
There are multiple encodings defined by the A/V profile that use dynamic payload types, including GSM-HR, RED, VDVI, L8, MP2P and BMPEG Codecs. nBAR RTP Payload type classification provides a powerful means of classifying the applications based on their static or dynamic payload type.
Thursday, November 27, 2008
BGP tips
1. Timer
When a connection is started, BGP will negotiate the hold time (only) with the neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on the negotiated hold time/3 and the configured keepalive time, which one is lower.
By default, keepalive is 60 sec and hold time is 180 sec.
R1(Confg)# neighbor R2 timer 10 40
On R1, when you do a show ip bgp R2, it will show keepalive 10 sec and hold time 40 sec.
On R2, when you do a show ip bgp R1, it will show that the keepalive is 13 sec(40/3) and hold time is 40 sec.
R1(Confg)# neighbor R2 timer 80 180
On R1, when you do a show ip bgp R2, it will show keepalive 60 sec(180/3) and hold time 180 sec.
When a connection is started, BGP will negotiate the hold time (only) with the neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on the negotiated hold time/3 and the configured keepalive time, which one is lower.
By default, keepalive is 60 sec and hold time is 180 sec.
R1(Confg)# neighbor R2 timer 10 40
On R1, when you do a show ip bgp R2, it will show keepalive 10 sec and hold time 40 sec.
On R2, when you do a show ip bgp R1, it will show that the keepalive is 13 sec(40/3) and hold time is 40 sec.
R1(Confg)# neighbor R2 timer 80 180
On R1, when you do a show ip bgp R2, it will show keepalive 60 sec(180/3) and hold time 180 sec.
Tuesday, November 18, 2008
OSPF
1. VL and area 0 range.
If an area is capable of carrying transit traffic (i.e., its TransitCapability is set to TRUE), routing
information concerning backbone networks should not be condensed before being summarized into the area. Nor should the advertisement of backbone networks into transit areas be suppressed. In other words, the backbone’s configured ranges should be ignored when originating summary-LSAs into transit areas.
To show if the area is transitCapability, do
R1# show ip ospf
=================
Area 1
Number of interfaces in this area is 1
This area has transit capability: Virtual Link Endpoint
Area has no authentication
SPF algorithm last executed 01:29:49.932 ago
SPF algorithm executed 13 times
Area ranges are
Number of LSA 12. Checksum Sum 0x052BF3
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
========================================
After you enable the virtual link, the "area 0 range" won't works (only for backbone area0).
To fix it, do not use virtual link, instead you can create a GRE tunnel and set it to area 0.
2. VL and GRE Tunnel
Virtual-link:
-It is considered part of (Area 0) by default, without any additional configuration.
-It dose not require any kind of addressing.
-Configuration is only needed under the OSPF routing process.
-Only routing updates are tunneled into the virtual-link, but data traffic is not.
-Transit area can not be a stub area.
GRE tunnel:
-Tunnel interfaces must be created and addressing is required. (can be unnumbered).
-Tunnel Address must be advertised into (Area 0) using a network command.
-Both routing updates and data traffic are tunneled; this introduces more overhead.
-Transit area can be any type; this means its your only option if the transit is a stub area.
3. Default route. Link.
You can not redistribute default route into ospf. It can be inserted into the OSPF domain only as an external or inter-area (summary) route. There are only two ways to generator default-route into ospf by:
a. default-information originate
b. summary only in stub or nssa. (you cannot do 'area 0 range 0.0.0.0 0.0.0.0)
If an area is capable of carrying transit traffic (i.e., its TransitCapability is set to TRUE), routing
information concerning backbone networks should not be condensed before being summarized into the area. Nor should the advertisement of backbone networks into transit areas be suppressed. In other words, the backbone’s configured ranges should be ignored when originating summary-LSAs into transit areas.
To show if the area is transitCapability, do
R1# show ip ospf
=================
Area 1
Number of interfaces in this area is 1
This area has transit capability: Virtual Link Endpoint
Area has no authentication
SPF algorithm last executed 01:29:49.932 ago
SPF algorithm executed 13 times
Area ranges are
Number of LSA 12. Checksum Sum 0x052BF3
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
========================================
After you enable the virtual link, the "area 0 range" won't works (only for backbone area0).
To fix it, do not use virtual link, instead you can create a GRE tunnel and set it to area 0.
2. VL and GRE Tunnel
Virtual-link:
-It is considered part of (Area 0) by default, without any additional configuration.
-It dose not require any kind of addressing.
-Configuration is only needed under the OSPF routing process.
-Only routing updates are tunneled into the virtual-link, but data traffic is not.
-Transit area can not be a stub area.
GRE tunnel:
-Tunnel interfaces must be created and addressing is required. (can be unnumbered).
-Tunnel Address must be advertised into (Area 0) using a network command.
-Both routing updates and data traffic are tunneled; this introduces more overhead.
-Transit area can be any type; this means its your only option if the transit is a stub area.
3. Default route. Link.
You can not redistribute default route into ospf. It can be inserted into the OSPF domain only as an external or inter-area (summary) route. There are only two ways to generator default-route into ospf by:
a. default-information originate
b. summary only in stub or nssa. (you cannot do 'area 0 range 0.0.0.0 0.0.0.0)
Monday, November 17, 2008
RIP
1. RIP summary
RIP dose not support super net summary.
2. RIP default route
You can specific which interface should the default route sending out using "default-route originate route-map Interface".
route-map Interface
match ip address 1 //only when there is a route match access-list 10 will it create 0.0.0.0/0
set interface e0/0 //it will only send update 0.0.0.0/0 out e0/0
3. Filter routes
distribute-list 1 in e0/0
distribute-list prefix-list allow-nets in e0/0
distribute-list gateway all0w-source in e0/0 (Gateway is the ip address of the neighbor whom you receive a routing update).
The following prefix-list works with distribute-list gateway to only allow updates from 150.1.1.2.
ip prefix-list allow-source deny 150.1.1.1/32
ip prefix-list allow-source permit 150.1.1.2/32
4. Redistribute need to manually set the metric.
5. Troubleshooting tool
debug ip rip
will show you all the update sent and received.
RIP dose not support super net summary.
2. RIP default route
You can specific which interface should the default route sending out using "default-route originate route-map Interface".
route-map Interface
match ip address 1 //only when there is a route match access-list 10 will it create 0.0.0.0/0
set interface e0/0 //it will only send update 0.0.0.0/0 out e0/0
3. Filter routes
distribute-list 1 in e0/0
distribute-list prefix-list allow-nets in e0/0
distribute-list gateway all0w-source in e0/0 (Gateway is the ip address of the neighbor whom you receive a routing update).
The following prefix-list works with distribute-list gateway to only allow updates from 150.1.1.2.
ip prefix-list allow-source deny 150.1.1.1/32
ip prefix-list allow-source permit 150.1.1.2/32
4. Redistribute need to manually set the metric.
5. Troubleshooting tool
debug ip rip
will show you all the update sent and received.
PPP Authentication
1. PAP
Password Authentication Protocol (PAP) sends the username and password over the ISDN link in clear-text. Sending any passwords over any WAN link in clear-text is generally a bad idea, but it's important to know you have this option.
Regarding both PAP and CHAP, it's a common misunderstanding that each side must authenticate the other. PAP and CHAP both support bidirectional and unidirectional authentication; that is, R1 can authenticate R2 without R2 necessarily authenticating R1. It's more common to use unidirectional authentication in a lab environment than a production network, but keep in mind that bidirectional authentication is an option, not a requirement.
The configurations of PAP and CHAP do have their similarities. For both, you'll configure a username/password combination in global configuration mode. Newcomers to ISDN sometimes put the local router name in for the username; remember that the remote router name is the username.
The only real advantage of PAP over CHAP comes in the password configuration. Since PAP actually sends the password as a whole over the link, the two routers can send different passwords during authentication. The operation of CHAP requires that both routers use the same password, and we'll see why in tomorrow's article.
R1:
username R2 password CISCO
Int bri0
encapsulation ppp
ppp authentication pap
PAP requires an extra command at this point. The ppp pap sent-username command is required under the interface, indicating the username and password this router will be sending to the remote router.
R2:
Int bri0
encapsulation ppp
ppp pap sent-username R2 password CISCO
2. Chap
Unlike PAP, CHAP does not actually send a password over the line. Instead, a hash value made up of the password and magic number is sent. Unless the hash matches from both authenticating parties, authentication is not successful.
By default, the router sends it’s hostname for authentication when using chap. The router on the other side does a lookup in its local database, radius server, or tacacs server, and finds the password that is paired with that username. If there is no matching username in the database, the password specified with the interface level command ‘ppp chap password’ is used as the default password.
Here is the basic configuration for CHAP. This is one way authentication.
R1:
username Router2 password CISCO
int ser 1/0
encap ppp
ppp authentication chap
R2:
username R1 password CISCO
int ser 1/0
encap ppp
ppp chap hostname Router2 // match the user database in R1
Password Authentication Protocol (PAP) sends the username and password over the ISDN link in clear-text. Sending any passwords over any WAN link in clear-text is generally a bad idea, but it's important to know you have this option.
Regarding both PAP and CHAP, it's a common misunderstanding that each side must authenticate the other. PAP and CHAP both support bidirectional and unidirectional authentication; that is, R1 can authenticate R2 without R2 necessarily authenticating R1. It's more common to use unidirectional authentication in a lab environment than a production network, but keep in mind that bidirectional authentication is an option, not a requirement.
The configurations of PAP and CHAP do have their similarities. For both, you'll configure a username/password combination in global configuration mode. Newcomers to ISDN sometimes put the local router name in for the username; remember that the remote router name is the username.
The only real advantage of PAP over CHAP comes in the password configuration. Since PAP actually sends the password as a whole over the link, the two routers can send different passwords during authentication. The operation of CHAP requires that both routers use the same password, and we'll see why in tomorrow's article.
R1:
username R2 password CISCO
Int bri0
encapsulation ppp
ppp authentication pap
PAP requires an extra command at this point. The ppp pap sent-username command is required under the interface, indicating the username and password this router will be sending to the remote router.
R2:
Int bri0
encapsulation ppp
ppp pap sent-username R2 password CISCO
2. Chap
Unlike PAP, CHAP does not actually send a password over the line. Instead, a hash value made up of the password and magic number is sent. Unless the hash matches from both authenticating parties, authentication is not successful.
By default, the router sends it’s hostname for authentication when using chap. The router on the other side does a lookup in its local database, radius server, or tacacs server, and finds the password that is paired with that username. If there is no matching username in the database, the password specified with the interface level command ‘ppp chap password’ is used as the default password.
Here is the basic configuration for CHAP. This is one way authentication.
R1:
username Router2 password CISCO
int ser 1/0
encap ppp
ppp authentication chap
R2:
username R1 password CISCO
int ser 1/0
encap ppp
ppp chap hostname Router2 // match the user database in R1
Monday, November 10, 2008
NTP Authentication
1. NTP Peers don't need to be at the same stratum.
2. Without "ntp authentication"
NTP_client:
ntp authentication-key 1 md5 cisco
ntp server 101.1.1.1 key 1
NTP_server:
ntp master 3
ntp authentication-key 1 md5 cisco
2.1 the debug you can see both server and client send out packet with key 1. The time will be synch.
2.2 "show ntp assossiate detail" on client, it shows that server is authenticated.
3. With "ntp authentication"
Only change will be in client
NTP_client:
ntp authenticate
ntp authentication-key 1 md5 cisco
ntp server 101.1.1.1 key 1
3.1 The time won't sync because it does not trust any key.
3.2 The server is authenticated.
4. You need both 'ntp authenticate' and 'ntp trust-key 1' to enable the time sync.
5. Time information will also be accepted from an unauthenticated peer or server if the peer/server has no key identifier associated with it via the 'ntp peer server key' global configuration command.
6. This configuration is working too. The peers configure with different key number but as long as the other side configured with the right authentication-key it will accept the time information.
For ntp server, if it receives a request with key and key is valid, it will reply with time information with same key.
Router2(151.1.2.2)#
ntp authentication-key 1 md5 cisco
ntp authentication-key 2 md5 ibm
ntp authentication-key 3 md5 google
ntp authenticate
ntp trusted-key 1 #trust the time information from server 45.1.200.29
ntp trusted-key 2 #trust the time information from peer 150.1.3.3 using key 2. See note on R3)
ntp peer 150.1.3.3 key 3 source Loopback0
ntp server 45.1.200.29 key 1
Router3(151.1.3.3)#
ntp authentication-key 1 md5 cisco
ntp authentication-key 2 md5 ibm
ntp authentication-key 3 md5 google
ntp authenticate
ntp trusted-key 1 #trust the time information from server 216.16.234.10
ntp trusted-key 3 #trust the time information from peer 150.1.2.2 using key 3. (diff from the line below but match the configuration in Router2.
ntp peer 150.1.2.2 key 2 source Loopback0
ntp server 216.16.234.10 key 1
So basically when router receives a ntp packet from x.x.x.x with key number y, it will verify it with the configuration of 'ntp authentication-key y md5' regardless what the key number configured under 'ntp peer x.x.x.x key z'.
'ntp peer x.x.x.x key z' means the router will send a packet to x.x.x.x with key z. But for inbound packet from x.x.x.x it dose not need to use the same key.
What about only change Router3 to "ntp peer 150.1.2.2 source loopback0"(without key)? In this case, Router2 will not accept time information from Router3 because at Router2 we configure that Router3 should have key included. But Router3 will still trust Router2 as peer ntp. Please refer to point 5. To make this works, either change it back or change Router2 to 'ntp peer 150.1.3.3 source loopback 0'.
7. Reference: http://www.nil.com/ipcorner/SecTimeManagement/
Subscribe to:
Posts (Atom)