AI, ML, Development + Cisco Learning Blog Learning about Machine Learning, Artificial Intelligence, related devlopment topics and formerly Routing and Switching, Datacenter, Security and other topics, CCIE #23664, Frank Wagner

12. August 2006

A simple explanation FECN / BECN

Filed under: Frame-Relay — ocsic @ 12:51

These are technices used for congestion control within frame-relay.

A Bit marking 0 or 1 in the BECN oder FECN field, telling there is congestion.

Frame-relay is a layer 2 protocol and does no error checking. Another layer 3 protocol has to do this. But Frame-relay can send congestion notifications on the links, informing there is congestion and to slow down the sending device. It depends on the implementation of the remote device, if these notifications are noted.
Here is what can happen and when one of these are used. If congestion occurs, there are two possible ways of notifying this.

With FECN it’s possbile to send a notifcation to the receiving router, that congestion occured. If in case the receiving router does not have the bandwidth and would be overwhelmed.
With BECN it’s possible to send a notification to the sending local router, that congestion occured.

Source:

http://www.groupstudy.com/archives/ccielab/200209/msg01962.html

http://www.delmar.edu/Courses/ITSC1391/Sem4/6FrameRelay.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/ch05/h_afrts.htm#wp1015437

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm#wp1020620

Frame-Relay and traffic shaping (FRTS)

Filed under: Frame-Relay — ocsic @ 12:32

Frame-Relay congestion control can be done on a DLCI basis. Real flow control is done by upper layer protocols. Remember frame-relay is just a layer 2 protocol. So frame-relay just throws packets away and only notifies about congestion. This could be done, for example, by TCP.

So with frame-relay the mechanisms are called congestion-notification. So if a sender is sending to quick, frame-relay is sending a congestion-notification to the sender to slow down. Frame-relay in the meantime, just throws away packets. If a packet is lost, the receiving device has to request e retransmition.
The following terms are important.

  • FECN – Forward-explicit congestion notification
  • BECN – Backward-explicit congestion notification
  • DE – Discard Eligibility
  • CIR – Committed Information Rate

Both informations FECN and BECN, are carried as single bit in the frame-relay header.

The header also includes a DE bit, which is responsible for dropping and marking no to important traffic in times of congestion. A frame with the DE bit set, has low priority and can be dropped in case of congestion.

CIR is an agreement about the normal transmission rate over a link in a certain time.

BECN – indicates to the receiving device that frames sent in the opposite direction may experience congestion.

FECN – indicates to the receiving device that the frame has experienced congestion.

DE – discard eligible, which mean, when the DE bit is set in a frame, the packet could be selected for discarding, it’s even possible to set this DE bit, for certain protocols

Terms to know about frame-relay traffic shaping and you can configure them on an interface dlci with a map-class command:

  • EIR is the rate that you can exceed CIR before the ingress port will discard your frames.
  • CIR – Committed information rate

is the average rate that you can transmit at measured over a time period Tc without having the ingress port on the Frame network flag your frames as over contract by setting the DE bit. If you have multiple connections, the aggregated total of the CIR for all PVC’s should not exceed the physical port speed.

  • BC – committed burst

is the maximum amount of data that a network will transfer in one interval of time (Tc) or in other words is the total number of bits that you can send in period Tc and not have the frames marked with DE.

  • BE – Burst in excess

is the maximum amount of data that the network will transfer above Bc in one interval of time. When transmitting data at excess burst (Be) these frames would either be dropped by the network at ingress or marked discard eligible (DE) and potentially dropped somewhere else in the network if congestion is experienced

or you can say is the total number of bits in addition to Bc that you can send in period Tc that the switch will allow before discarding any excess traffic at the ingress port to the Frame network.

  • MINCIR – minimum committed information rate

The actual guaranteed rate obtained from service provider in bps. This value should be the minimum rate you should drop to in the event of congestion (dropping below this rate implies you are not getting the bandwidth you are paying for). In certain cases the mincir and cir values must be the same. The value of mincir is half of the CIR value in bps by default.

  • TC the default is 1/8 = 0.125 seconds, BC=CIR*TC

For example, if you have a CIR of 64000 Bits per second and want for voice a TC of 10 ms (0,01) or 1/100, than BC would be 640 bits. 10 ms is the smallest value for TC.

Parameters you configure:

Example 1.

1. setup the interface for shaping

interface Serial0/0
ip address 152.2.0.1 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 103
class to-router3

2. define a map class containing shaping parameters

map-class frame-relay to-router3
frame-relay cir 32000

32000 Bits per second is the average amount of data on the agreed rate with the service provider. The default an an interface is 57000 bps. Make sure, that the sum of all cir’s configured for one interface does not exceed the bandwidth of the interface. If your remote router does only 16000 Bits per seconds, this CIR rate would be „frame-relay cir 16000“.

Example 2.

1. Setup the interface for frame-relay traffic-shaping

interface Serial0/0
ip address 152.2.0.1 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 103
class to-router3

2. define a map class containig shaping parameters

map-class frame-relay to-router3
frame-relay cir 32000
frame-relay bc 320

So here i use a TC of 10 ms or 0,01 seconds for the configured BC. The advantage is that the router is more able to prioritize certain traffic, would be needed for voice. Because the shorter choosen intervals per second.

CIR = BC/TC

32000=BC/0,01

=> 320=BC

Example 3.

Your Frame-Relay provider gives you a line with a 512k circuit and a CIR of 384k to your network. You would configure it like this.

interface Serial0/0
ip address 152.2.0.1 255.255.255.0
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 103
class to-router3

map-class frame-relay to-router3
frame-relay cir 512000
frame-relay mincir 384000
frame-relay bc 64000
frame-relay be 128000

Whitch calculates as follows:

CIR = port speed
mincir = commited rate from prvider
be= port – commited rate
bc = port speed / 8

These parameters are inter-related.

CIR = Bc/Tc

BC = CIR * Tc

TC = BC / CIR

BE = Portspeed – CIR

EIR = Be/Tc

Source:

http://www.groupstudy.com/archives/ccielab/200209/msg01962.html

http://www.cisco.com/warp/public/125/traffic_shaping_6151.html

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm#wp1020620

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hwan_c/ch05/h_afrts.htm#wp1015437

11. August 2006

How to setup Multicast on a cisco router

Filed under: Multicast — ocsic @ 11:21
  1. enable ip multicast routing with „ip multicast-routing“
  2. enable PIM on an interface
  3. configure a rendezvous point

Here for example you use sparse-mode
# ip multicast-routing

# int e0/0

# ip pim sparse-mode

# ip igmp join-group 224.0.33.0

Dense Mode – Sparse Mode

Filed under: Multicast — ocsic @ 11:10
Dense Mode
You should use Dense Mode for dense population of hosts and plentiful bandwidth
  • DVMRP Distance Vector Multicast Routing Protocol
    • Used frequently on the MBONE
    • Uses reverse path flooding
    • Periodic floodings to offer groups to new hosts
    • Unicast path based on hop counts
    • Cisco routers use PIM to unteract with DVMRP routers, but do not directly implement DVMRP
  • PIMDM
Sparse Mode
  • Use for a sparse distribution of multicast members
  • assumes specific requests are used to join
  • used when crossing WANs
Source:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/himc_c/mcbcncpt.htm#wp1077054

Multicast, RFC 112, then RFC 2236

Filed under: Multicast — ocsic @ 09:49
  • sending ip packets to a group of hosts in the network, RFC 2236 Internet Group Management Protocol v2
  • delivery of IP datagramms to multiple hosts using a single destination address
  • dynamic membership to groups, clients can dynamicly join groups
  • supports all size of groups

single group address for registred applications, that means multiple applications can stream to a single group address

Addressing

Address range:

Multicast uses Class D

224.0.0.0 – 239.255.255.255

Well-known Addresses:

  • 224.0.0.1 All hosts on a subnet
  • 224.0.0.2 All routers on a subnet
  • 224.0.0.4 All distance vector multicast routing protocol routers
  • 224.0.0.5 All OSPF routers
  • 224.0.0.6 All OSPF designated routers
  • 224.0.0.9 All RIP designated routers
  • 224.0.0.10 IGRP router
  • 224.0.0.13 All Protocl independent Multicast (PIM) routers

To configure a router supporting PIM, the cisco way of supporting multicast, you have to enable ip multicast-routing

Different types of traffic flow

Filed under: Bridging + Switching — ocsic @ 09:23
  • Unicast, packets to every requesting address, traffic may be carried multiple times, the primary concern is the number of network connections versus the available bandwidth. Each session requires the the full bandwidth required by the application.
  • Broadcast, one copy of a packet is send out to a broadcast address. Broadcast are stoped by layer 3 devices unless allowed to be forwarded. So evyer device with the same broadcast address receives the packet.
  • Multicast, for transporting multimedia data, a media server sends a single copy to a predetermined multicast address, replications occurs only, when necessary

CCIE Lab exam in december

Filed under: Lab — ocsic @ 01:29

I have booked now a seat in Brussel on december the 14 th. Hopefully i will pass it. It’s quite some time, and will take a lot of hours for testing and learning. But i think it’s worth it. You have to be very fast, to configure all the tasks.

9. August 2006

How does ppp CHAP authentication work (RFC 1994)?

Filed under: Security — ocsic @ 08:26

PPP authentication is a bit tricky. Well, maybe just for me to understand. I had to follow the path on configured examples that have to be set on both sides. I show this in the following example and explain how both ends have to be configured.

PPP Auth

R1 is configured like this:

Hostname: R1
Alias hostname: ROUTER1
Password: secret1

username ROUTER2 password secret1
interface s0/0
encapsulation ppp
ppp authentication chap
ppp chap hostname ROUTER2

R2 is configured like this:

Hostname: R2
Alias hostname: ROUTER2
Password: secret2

username ROUTER1 password secret1
interface s0/0
encapsulation ppp
ppp authentication chap
ppp chap hostname ROUTER2

CHAP is doing a three way handshake (RFC 1994). PAP is also possible as an authentication protocol, but it’s less secure. PAP uses a two way handshake and it send’s it’s password in clear text.

So here it goes like this.

  • R1 want to connect to R2. R1 is initiating a call.
  • LCP negotiates the Authentication protocol, CHAP in this case
  • So now R2 is going to challenge R1. And it’s preparing a packet with challenge informations. This depend on his configuration. If no hostname is configured with „ppp chap hostname name„, then the hostname of the router R2 itself for the challenge is used, otherwise the configured name, in this case ROUTER2.
  • R2 is sending a challenge packet back to R1, which means, R2 asks for authentication for a certain hostname „ROUTER2“ here.
  • R1 receives the challenge and looks, if it has a local user configured matching the hostname/username ROUTER2.
  • R1 find’s the username ROUTER2 in it’s local database and the password „secret1“
  • R1 is now answering the challenge for username ROUTER2 with the configured password. But R1 uses hostname ROUTER1 in it’s answer packet to R2, because it’s configured with „ppp chap hostname ROUTER1“. Otherwise R1 would use his hostname R1 only to answer.
  • Now R2 receives the answer from R1 and looks himself into his local password database and finds a matching entry for ROUTER1 with password „secret1“. R2 compares the passwords and grants access to R1 and authentication is successfull.

Debuging PPP authentication with:

debug ppp negotiation

debug ppp authentication

Source:

http://www.cisco.com/en/US/tech/tk713/tk507/technologies_configuration_example09186a0080094333.shtml

http://www.ietf.org/rfc/rfc1994.txt

http://www.cisco.com/warp/public/471/understanding_ppp_chap.html

CCIE Lab change 3550 to 3560

Filed under: Lab — ocsic @ 04:26

Below is a list of the features that are supported on the 3560
(c3560-advipservicesk9-mz.12.2-25.SEC.bin) but not on the 3550
(c3550-ipservicesk9-mz.12.2-25.SEC.bin).

CEFv6/dCEFv6 – Cisco Express Forwarding
Flex Links
IEEE 802.1X Port-Based Authentication
IEEE 802.3af Power over Ethernet
IGMP Throttling
IPv6 (Internet Protocol Version 6)
IPv6 Data Link: VLANs using Cisco Inter-Switch Link (ISL)
IPv6 Data Link: VLANs using IEEE 802.1Q Encapsulation
IPv6 MTU Path Discovery
IPv6 Neighbor Discovery
IPv6 Routing: OSPF for IPv6 (OSPFv3)
IPv6 Routing: RIP for IPv6 (RIPng)
IPv6 Routing: Static Routing
IPv6 Services: AAAA DNS Lookups over an IPv4 Transport
IPv6 Services: DNS Lookups over an IPv6 Transport
IPv6 Services: Extended Access Control Lists
IPv6 Services: Standard Access Control Lists
IPv6 Stateless Auto-configuration
IPv6 Switching: CEF/dCEF Support
IPv6: ICMPv6
IPv6: ICMPv6 Redirect
IPv6: Neighbor Discovery Duplicate Address Detection
ISL VLAN
Private VLANs
QoS Policy Propagation via Border Gateway Protocol (QPPB)

8. August 2006

freeradius for authenticating over EAPOL

Filed under: Security — ocsic @ 10:20

In this configuration i use a 2950 Catalyst switch and i’m setting up a Radius server for testing purposes. Just to find out how it works together. A quick google search showed, that i should work together.

802.1x Authentication

I’m using a SuSE 10.0 distribution. I know certainly there are probably many other distributions out there and many of them are better. For me and my purpous it’s good enough, of course i have some things, that cold do better, but i‘ using this distribution already since 1996 and i’m just to lazy to change to another one. So please don’t bother me, with this is better than that or that is better than this. In my opinion it does not matter that much which distribution you chooos. But to get further on i will keep up with the topics.

I installed the actual freeradiu package named: freeradius-1.0.4-4.

So now, i can start to configure the Radius server. Here is the setup, i added this to /etc/raddb/radiusd.conf

modules {
pap {
encryption_scheme = crypt
}
chap {
authtype = CHAP
}
pam {
pam_auth = radiusd
}
unix {
cache = no
cache_reload = 600
radwtmp = ${logdir}/radwtmp
}
eap {
default_eap_type = md5
timer_expire = 60

md5 {
}
leap {
}
}
mschap {
}
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
compat = no
}
}

And in the authorize section you should add „eap“ as type in /etc/raddb/radiusd.conf:

authorize {
preprocess
chap
mschap
suffix
eap
files
}

That’s all for the first time. You can add a user now, who should authenticate himself.

A line in /etc/raddb/users:

peter User-Password == „passwd“

You can now try to authenticate your client. Just make sure you have set up your switch to proxy the clients request to the right server. Look here http://blog.sazza.de/?p=126 how to setup your switch to answer these requests.
Source:

http://security.fi.infn.it/TRIP/802.1x-wired/802.1x-wired.html

« Newer Posts — Older Posts »

Powered by WordPress