12/23/2011
OER/PFR
This actually turns to be one of the most complicated topics that people who are currently preparing for the CCIE R&S lab must understand.
Written by: Brian Dennis
This blog post is the first in a series covering Performance Routing (PfR) formerly known as Optimized Edge Routing (OER) that I will be publishing over the coming weeks. I decided to cover PfR in a series of blog posts contrary to a single post as PfR is a very powerful and useful feature that leverages the power of Cisco’s IOS but at the same time PfR is potentially very complicated and often confusing feature to configure and troubleshoot. Trying to cover PfR in a single blog post would be the equivalent of trying to cover OSPF in a single blog post. In fact if you compare the IOS 12.4T OSPF Configuration Guide against the Optimized Edge Routing (OER) Configuration Guide you will notice that OER documentation is nearly 35% larger.
...
http://blog.ine.com/2011/11/01/cisco-performance-routing-pfr-optimized-edge-routing-oer/#comment-476083
apple mouse
12/17/2011
mac book pro
I am not a fan of Apple but I just bought brand new mac book pro 15" with quad core i7 and I can say that Apple changed to way you can use your personal computer. After 15+ years using Windows and Linux as a desktop - its time for some change.
11/20/2011
new job
I went through few technical interviews and looks like I am about to sign up a contract. Next week I will be in UK looking for a house and eventually stay in it.
wish me luck with the new job
21DEC: If you have to chose between SPEEDY and DHL for courier. Chose DHL. Speedy simply suck.
15DEC: I got approval for my UK working visa. Preparing the BR3 form for the border agency.
25NOV:Looks like during the test period I will be living in the hotel - Thanks to Stefan for pointing me to right place :)
20NOV: I got the job offer and now I applied for work permit in UK. I hope everything will be fine with that. The company I applied is one of the service integration leaders in UK who have really nice cisco,juniper and F5 labs. The start date is around 15th of Jan 2012.
wish me luck with the new job
21DEC: If you have to chose between SPEEDY and DHL for courier. Chose DHL. Speedy simply suck.
15DEC: I got approval for my UK working visa. Preparing the BR3 form for the border agency.
25NOV:Looks like during the test period I will be living in the hotel - Thanks to Stefan for pointing me to right place :)
20NOV: I got the job offer and now I applied for work permit in UK. I hope everything will be fine with that. The company I applied is one of the service integration leaders in UK who have really nice cisco,juniper and F5 labs. The start date is around 15th of Jan 2012.
9/23/2011
NTP access control
Important trick I found on INE forum that should be remembered about NTP when you are using NTP access-control.
One of the important things that are not mentioned in the INE post is that by default no one will be rejected from the NTP master if it's not trying to authenticate that's why you will restrict those stations with ACL.
"If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:"
reating an Access Group and Assign a Basic IP Access List to It
To control access to NTP services, you can create an NTP access group and apply a basic IP access list to it. To do so, use the following command in global configuration mode:
Command
Purpose
ntp access-group {query-only | serve-only | serve| peer} access-list-number
Creates an access group and applies a basic IP access list to it.
The access group options are scanned in the following order, from least restrictive to most restrictive:
1. peer—Allows time requests and NTP control queries and allows the system to synchronize itself to a system whose address passes the access list criteria.
2. serve—Allows time requests and NTP control queries, but does not allow the system to synchronize itself to a system whose address passes the access list criteria.
3. serve-only—Allows only time requests from a system whose address passes the access list criteria.
4. query-only—Allows only NTP control queries from a system whose address passes the access list criteria.
If the source IP address matches the access lists for more than one access type, the first type is granted. If no access groups are specified, all access types are granted to all systems. If any access groups are specified, only the specified access types will be granted.
For details on NTP control queries, see RFC 1305 (NTP version 3).
192.168.2.24 configured, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (02:00:00.000 GMT Mon Jan 1 1900)
our mode client, peer mode unspec, our poll intvl 512, peer poll intvl 512
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 3774813.461
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time 00000000.00000000 (02:00:00.000 GMT Mon Jan 1 1900)
rcv time 00000000.00000000 (02:00:00.000 GMT Mon Jan 1 1900)
xmt time CEE8139F.D5044C0D (08:24:31.832 GMT Fri Jan 1 2010)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
127.127.7.1 configured, our_master, sane, valid, stratum 4
ref ID 127.127.7.1, time CEE813A4.D3F3A778 (08:24:36.827 GMT Fri Jan 1 2010)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time CEE813A4.D3F3A778 (08:24:36.827 GMT Fri Jan 1 2010)
rcv time CEE813A4.D3F3A778 (08:24:36.827 GMT Fri Jan 1 2010)
xmt time CEE813A4.D3F38B82 (08:24:36.827 GMT Fri Jan 1 2010)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 0.99 1.97 2.94 3.92 4.90 5.87 6.85
Reference clock status: Running normally
Timecode:
9/02/2011
Ethernet over SDH. It's interesting topic though, I got such question on job interview few days ago and I think I was too stressed to give the answer straight away but after I left the interview I came out with few answers about that and I used such solution few years ago in Iceland.
So, you want to carry native Ethernet over SDH but for some historical reasons you have a huge SDH/PDH network which carry mainly IP - so what you can do about it? I was thinking of Ethernet-over-IP-over SDH? why not? I tried something like that couple of years back and it works.
The Telco way is to convert the SDH to ethernet with pseudo-wire (tunnelling) and Axerra networks and Tellabs have such solutions or using the so well advertised rfc4448 (ethernet-over-mpls)
So, you want to carry native Ethernet over SDH but for some historical reasons you have a huge SDH/PDH network which carry mainly IP - so what you can do about it? I was thinking of Ethernet-over-IP-over SDH? why not? I tried something like that couple of years back and it works.
The Telco way is to convert the SDH to ethernet with pseudo-wire (tunnelling) and Axerra networks and Tellabs have such solutions or using the so well advertised rfc4448 (ethernet-over-mpls)
7/11/2011
7/02/2011
dynamic access-list - the small trick
short note about the dynamic ACLs:
if you are going to use dynamic ACL to allow some kind of access to service/server with absolute timer it's very important to remember that you need to enable the "absolute timer" extensive of the ACL's
R1(config)#access-list dynamic-extended
and the rest that you have to remember is to put autocommand sub option but if you cannot remember what should be options after that they are available in exec mode
R1(config)#username ENABLE autocommand ?
LINE Command to be automatically issued after the user logs in
R1#access-enable ?
host Enable a specific host only
timeout Maximum idle time to expire this entry
example acl with dynamic statement
ip access-list extended DYN
permit tcp any any eq telnet
permit tcp any any eq 7001
permit udp any any eq rip
dynamic ACCESS timeout 15 permit tcp any any eq www
deny ip any any
deny ip any any log
vty configuration
R1(config-line)#autocommand access-enable timeout 5
One very important note from the INE technology workbook is to be careful with the AAA authorization when you are using dynamic ACL - the reason of that is you must using local exec authorization with non or if-authenticated
if you are going to use dynamic ACL to allow some kind of access to service/server with absolute timer it's very important to remember that you need to enable the "absolute timer" extensive of the ACL's
R1(config)#access-list dynamic-extended
and the rest that you have to remember is to put autocommand sub option but if you cannot remember what should be options after that they are available in exec mode
R1(config)#username ENABLE autocommand ?
LINE Command to be automatically issued after the user logs in
R1#access-enable ?
host Enable a specific host only
timeout Maximum idle time to expire this entry
example acl with dynamic statement
ip access-list extended DYN
permit tcp any any eq telnet
permit tcp any any eq 7001
permit udp any any eq rip
dynamic ACCESS timeout 15 permit tcp any any eq www
deny ip any any
deny ip any any log
vty configuration
R1(config-line)#autocommand access-enable timeout 5
One very important note from the INE technology workbook is to be careful with the AAA authorization when you are using dynamic ACL - the reason of that is you must using local exec authorization with non or if-authenticated
6/27/2011
Private VLANs
Introduction
To begin with, recall that VLAN is essentially a broadcast domain. Private VLANs (PVANs) allow splitting the domain into multiple isolated broadcast “subdomains”, introducing sub-VLANs inside a VLAN. As we know, Ethernet VLANs can not communicate directly with each other – they require a L3 device to forward packets between separate broadcast domains. The same restriction applies to PVLANS – since the subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device – such as router.
In reality, different VLANs normally map to different IP subnets. When we split a VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, yet now they need to use a router (L3 device) to talk to each other (for example, by using Local Proxy ARP). In turn, the router may either permit or forbid communications between sub-VLANs using access-lists. Commonly, these configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.
more ->
http://blog.ine.com/2008/07/14/private-vlans-revisited/
To begin with, recall that VLAN is essentially a broadcast domain. Private VLANs (PVANs) allow splitting the domain into multiple isolated broadcast “subdomains”, introducing sub-VLANs inside a VLAN. As we know, Ethernet VLANs can not communicate directly with each other – they require a L3 device to forward packets between separate broadcast domains. The same restriction applies to PVLANS – since the subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device – such as router.
In reality, different VLANs normally map to different IP subnets. When we split a VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, yet now they need to use a router (L3 device) to talk to each other (for example, by using Local Proxy ARP). In turn, the router may either permit or forbid communications between sub-VLANs using access-lists. Commonly, these configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.
more ->
http://blog.ine.com/2008/07/14/private-vlans-revisited/
blog mobile template enabled
google just rocks. You can enable mobile view for your blog from the blog settings menu.
6/24/2011
Brussels lab location (IPexpert)
http://www.youtube.com/watch?v=9bRbL_SOYfo&feature=player_embedded#at=202
6/23/2011
MLPPP LFI
Looks like this is one of the tricky small topics which every ccie r&s candidate should know.
So imagine the following scenario. You have two routers R4 and R5 with serial interface and you have to configure multilink interleaving and fragmentation. One of the most important thing you should remember is that the interleaving is working only on "fair-queue" enabled interfaces. So usually the tricky question is when you are asked to configure frame relay traffic shaping and enable the ppp multilink interleaving and fragmentation(which will be automatically configured for you if you don't specify it)
so, the first thing that you have to remember is if you have frame relay traffic-shaping it will disable the fair queue on the interface. So what we should do is to configure the interleaving on the Multilink interface. So there is the configuration output example:
[I am using Internetwork Expert R&S Workbook 1, task 10.55, version of the document 5.019]
Also in this particular INE task they are asking to configure back-to-back frame-relay with single p2p interface using DLCI 100 - if you ever have this case don't forget to enable the frame-frame relay switching.
[R4 Serial1/0] --- [Serial 1/0 R5]
R4#sh running-config interface serial 0/1
Building configuration...
Current configuration : 199 bytes
!
interface Serial0/1
no ip address
encapsulation frame-relay
no keepalive
clock rate 2000000
frame-relay traffic-shaping
frame-relay interface-dlci 100 ppp Virtual-Template1
class FRTS
end
R4#sh running-config interface multilink 1
Building configuration...
interface Multilink1
ip address 10.77.45.4 255.255.255.0
fair-queue
ppp multilink
ppp multilink interleave
ppp multilink group 1
ppp multilink fragment delay 10
end
R4#sh running-config interface virtual-template 1
Building configuration...
!
interface Virtual-Template1
bandwidth 512
no ip address
ppp multilink
ppp multilink group 1
end
and there is the verification
R4#show ppp multilink
Multilink1
Bundle name: R5
Remote Endpoint Discriminator: [1] R5
Local Endpoint Discriminator: [1] R4
Bundle up for 00:03:16, total bandwidth 512, load 1/255
Receive buffer limit 12000 bytes, frag timeout 1000 ms
Interleaving enabled
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x9 received sequence, 0x9 sent sequence
Member links: 1 active, 1 inactive (max not set, min not set)
Vi1, since 00:03:16, 640 weight, 630 frag size
Vt1 (inactive)
No inactive multilink interfaces
R4#
You can disable the fair-queue on the multilink interface and see the difference.
So imagine the following scenario. You have two routers R4 and R5 with serial interface and you have to configure multilink interleaving and fragmentation. One of the most important thing you should remember is that the interleaving is working only on "fair-queue" enabled interfaces. So usually the tricky question is when you are asked to configure frame relay traffic shaping and enable the ppp multilink interleaving and fragmentation(which will be automatically configured for you if you don't specify it)
so, the first thing that you have to remember is if you have frame relay traffic-shaping it will disable the fair queue on the interface. So what we should do is to configure the interleaving on the Multilink interface. So there is the configuration output example:
[I am using Internetwork Expert R&S Workbook 1, task 10.55, version of the document 5.019]
Also in this particular INE task they are asking to configure back-to-back frame-relay with single p2p interface using DLCI 100 - if you ever have this case don't forget to enable the frame-frame relay switching.
[R4 Serial1/0] --- [Serial 1/0 R5]
R4#sh running-config interface serial 0/1
Building configuration...
Current configuration : 199 bytes
!
interface Serial0/1
no ip address
encapsulation frame-relay
no keepalive
clock rate 2000000
frame-relay traffic-shaping
frame-relay interface-dlci 100 ppp Virtual-Template1
class FRTS
end
R4#sh running-config interface multilink 1
Building configuration...
interface Multilink1
ip address 10.77.45.4 255.255.255.0
fair-queue
ppp multilink
ppp multilink interleave
ppp multilink group 1
ppp multilink fragment delay 10
end
R4#sh running-config interface virtual-template 1
Building configuration...
!
interface Virtual-Template1
bandwidth 512
no ip address
ppp multilink
ppp multilink group 1
end
and there is the verification
R4#show ppp multilink
Multilink1
Bundle name: R5
Remote Endpoint Discriminator: [1] R5
Local Endpoint Discriminator: [1] R4
Bundle up for 00:03:16, total bandwidth 512, load 1/255
Receive buffer limit 12000 bytes, frag timeout 1000 ms
Interleaving enabled
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x9 received sequence, 0x9 sent sequence
Member links: 1 active, 1 inactive (max not set, min not set)
Vi1, since 00:03:16, 640 weight, 630 frag size
Vt1 (inactive)
No inactive multilink interfaces
R4#
You can disable the fair-queue on the multilink interface and see the difference.
6/15/2011
basic MPLS VPN scenario
It's really basic topology with two VPN clients. I decided to use VRF CLIENT_A and VRF CLIENT_B; CLIENT_A is running OSPF and CLIENT_B is running BGP. There is another link between SW3 and SW2. I have configured sham-link to avoid it.
Something interesting and maybe a common mistake is when you configure the sham-links to use wrong "area id" and what would happen is that the routes in your fib table will appear as INTER-AREA routes instead of INTRA-AREA routes.
There is nothing specific about VRF CLIENT_B, anyway, if someone is digging and looking for some scenario maybe this picture will be useful.
Something interesting and maybe a common mistake is when you configure the sham-links to use wrong "area id" and what would happen is that the routes in your fib table will appear as INTER-AREA routes instead of INTRA-AREA routes.
There is nothing specific about VRF CLIENT_B, anyway, if someone is digging and looking for some scenario maybe this picture will be useful.
4/11/2011
eem sync or no sync
When you use the sync yes option in the event cli command, the EEM applet runs before the CLI command is executed. The EEM applet should set the _exit_status variable to indicate whether the CLI command should be executed (_exit_status set to one) or not (_exit_status set to zero). A sample applet using the _exit_status variable in described in my “Schedule reload before configuring the router” post.
With the sync no option, the EEM applet is executed in background in parallel with the CLI command. As the CLI command starts at the same time as the EEM applet, you cannot use the _exit_status variable anymore; you have to specify whether you want the CLI command to execute with the skip yes|no option of the event cli command. A sample applet using sync no skip yes options is described in my “Can you disable the reload command?” post.
original post
http://blog.ioshints.info/2011/01/eem-event-cli-command-options-and.html
With the sync no option, the EEM applet is executed in background in parallel with the CLI command. As the CLI command starts at the same time as the EEM applet, you cannot use the _exit_status variable anymore; you have to specify whether you want the CLI command to execute with the skip yes|no option of the event cli command. A sample applet using sync no skip yes options is described in my “Can you disable the reload command?” post.
original post
http://blog.ioshints.info/2011/01/eem-event-cli-command-options-and.html
4/09/2011
optimized edge routing
it's part of the new r&s lab. Some of the examples looks very useful
http://www.ine.com/petr/IEWB-RS-VOL-I-V5.OER.0.01.pdf
update: this topic is headache..
http://www.ine.com/petr/IEWB-RS-VOL-I-V5.OER.0.01.pdf
update: this topic is headache..
3/26/2011
sla udp-jitter
important point if you have to do UDP-JITTER SLA:
Time synchronization, such as that provided by NTP, is required between the source and the target device in order to provide accurate one-way delay (latency) measurements. To configure NTP on the source and target devices, perform the tasks in the "Performing Basic System Management" chapter of the Cisco IOS Network Manageent Configuration Guide. Time synchronization is not required for the one-way jitter and packet loss measurements, however. If the time is not synchronized between the source and target devices, one-way jitter and packet loss data will be returned, but values of "0" will be returned for the one-way delay measurements provided by the UDP jitter operation.
You must configure NTP between the routers you are measuring the jitter (under question, confirming that with the INE guys right now)
R5#show ntp as
R5#show ntp associations
address ref clock st when poll reach delay offset disp
*~172.16.101.1 127.127.7.1 3 40 128 377 8.2 -0.82 6.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R5#show ntp stat
R5#show ntp status
Clock is synchronized, stratum 4, reference is 172.16.101.1
nominal freq is 250.0000 Hz, actual freq is 249.9997 Hz, precision is 2**18
reference time is C0297209.88DEA666 (03:20:41.534 UTC Fri Mar 1 2002)
clock offset is -0.8210 msec, root delay is 8.22 msec
root dispersion is 7.39 msec, peer dispersion is 6.53 msec
R5#
R5#show ip sla statistics 1
Round Trip Time (RTT) for Index 1
Latest RTT: 11 milliseconds
Latest operation start time: 03:19:21.163 UTC Fri Mar 1 2002
Latest operation return code: OK
RTT Values:
Number Of RTT: 100 RTT Min/Avg/Max: 3/11/39 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 0
Number of DS Jitter Samples: 0
Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 100
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever
Time synchronization, such as that provided by NTP, is required between the source and the target device in order to provide accurate one-way delay (latency) measurements. To configure NTP on the source and target devices, perform the tasks in the "Performing Basic System Management" chapter of the Cisco IOS Network Manageent Configuration Guide. Time synchronization is not required for the one-way jitter and packet loss measurements, however. If the time is not synchronized between the source and target devices, one-way jitter and packet loss data will be returned, but values of "0" will be returned for the one-way delay measurements provided by the UDP jitter operation.
You must configure NTP between the routers you are measuring the jitter (under question, confirming that with the INE guys right now)
R5#show ntp as
R5#show ntp associations
address ref clock st when poll reach delay offset disp
*~172.16.101.1 127.127.7.1 3 40 128 377 8.2 -0.82 6.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R5#show ntp stat
R5#show ntp status
Clock is synchronized, stratum 4, reference is 172.16.101.1
nominal freq is 250.0000 Hz, actual freq is 249.9997 Hz, precision is 2**18
reference time is C0297209.88DEA666 (03:20:41.534 UTC Fri Mar 1 2002)
clock offset is -0.8210 msec, root delay is 8.22 msec
root dispersion is 7.39 msec, peer dispersion is 6.53 msec
R5#
R5#show ip sla statistics 1
Round Trip Time (RTT) for Index 1
Latest RTT: 11 milliseconds
Latest operation start time: 03:19:21.163 UTC Fri Mar 1 2002
Latest operation return code: OK
RTT Values:
Number Of RTT: 100 RTT Min/Avg/Max: 3/11/39 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 0
Number of DS Jitter Samples: 0
Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 100
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever
3/13/2011
lab 7; area border router election
how to push one of the routers in the broadcast ospf segment to be elected as a ABR; it's simple, based on rfc 1587 the only thing you should do is to make more preferable RID (higher RID)
linkedin vs facebook
I am quite sure I am able to explain what I think about the social networking and things like facebook but have you think about what would be if networks like linkedin extend their capabilities so you can actually chat with your business network or people interested in the same things as you. So, why facebook ? :) What facebook can offer you if you are looking for pro connections and people with common interests.
- my 1 cent thought
- my 1 cent thought
NMC labs 1 - 25
Looks like the recommendation from the most of people I asked is to skip the very first labs and jump on 26-35 (the version 4),however, still the very first labs are great in terms of building strong knowledge on things like redistribution,route filtering and troubleshooting. I am about to finish lab 7 and jump to lab 26.
3/10/2011
3/09/2011
2/27/2011
IRDP/ICMP
Router R3 is connected on it's ethernet interface to SW3 (working only as a l2 switch) and we have to send him default gateway via IRDP. This how such configuration would looks like:
R3
R3#sh run int fast 0/0.50
Building configuration...
Current configuration : 262 bytes
!
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 172.16.30.3 255.255.255.128
ip irdp
ip irdp multicast
ip irdp maxadvertinterval 20
ip irdp minadvertinterval 20
ip irdp holdtime 60
ip irdp preference 100
ip irdp address 0.0.0.0 100
end
R3#
and
SW3#sh run int vlan 50
Building configuration...
Current configuration : 93 bytes
!
interface Vlan50
ip address 172.16.30.10 255.255.255.128
ip irdp
ip irdp multicast
end
SW3#
however, to make it work you'd need to enable it by entering
ip gdp irdp
SW3#show ip route
Gateway Using Interval Priority Interface
172.16.30.3 IRDP 20 100 Vlan50
Default gateway is 172.16.30.3
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
SW3#
R3
R3#sh run int fast 0/0.50
Building configuration...
Current configuration : 262 bytes
!
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 172.16.30.3 255.255.255.128
ip irdp
ip irdp multicast
ip irdp maxadvertinterval 20
ip irdp minadvertinterval 20
ip irdp holdtime 60
ip irdp preference 100
ip irdp address 0.0.0.0 100
end
R3#
and
SW3#sh run int vlan 50
Building configuration...
Current configuration : 93 bytes
!
interface Vlan50
ip address 172.16.30.10 255.255.255.128
ip irdp
ip irdp multicast
end
SW3#
however, to make it work you'd need to enable it by entering
ip gdp irdp
SW3#show ip route
Gateway Using Interval Priority Interface
172.16.30.3 IRDP 20 100 Vlan50
Default gateway is 172.16.30.3
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
SW3#
2/25/2011
DHCP Authorized ARP::Really nice feature available in 12.3T
The DHCP Authorized ARP feature enhances the Dynamic Host Configuration Protocol (DHCP) and Address Resolution Protocol (ARP) components of the Cisco IOS software to limit the leasing of IP addresses to mobile users to authorized users. This feature enhances security in public wireless LANs (PWLANs) by blocking ARP responses from unauthorized users at the DHCP server.
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtautarp.html
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtautarp.html
2/22/2011
re-patching the lab for netmaster
In this topology I have 4 switches (2x3560 and 2x3550) and 6 virtual routers 3725 with Tbased IOS (pc with 12 network cards).I haven't tested the configuration against the netmasterclas workbooks,yet. Some features are missing on this platform or at least on this version of IOS like "object track" in ACL. The first visible difference is that there is no backbone routers as we used to have on INE labs.
This is my configuration:
"netmasterclass.net"
autostart = False
[localhost:7200]
workingdir = /home/nabromov/dynamips/working
udp = 11000
[[3725]]
image = /home/nabromov/dynamips/images/c3725-adventerprisek9-mz.124-15.T14.bin
ram = 256
nvram = 256
ghostios = True
idlepc = 0x60c06028
[[Router R1]]
model = 3725
console = 2001
# R1 e0/0 to SW1 fa0/1
f0/0 = NIO_linux_eth:eth0
# R1 f0/1 to SW2 fa0/1
f0/1 = NIO_linux_eth:eth1
s1/0 = FRSW 1
s1/1 = R3 s1/1
[[ROUTER R2]]
model = 3725
console = 2002
# R2 e0/0 to SW1 fa0/2
f0/0 = NIO_linux_eth:eth3
# R2 e0/1 to SW2 fa0/2
f0/1 = NIO_linux_eth:eth4
s1/0 = FRSW 2
s1/1 = FRSW 22
[[ROUTER R3]]
model = 3725
console = 2003
# R3 e0/0 to SW1 fa0/3
f0/0 = NIO_linux_eth:eth5
# R3 00/1 to SW2 fa0/3
f0/1 = NIO_linux_eth:eth6
s1/0 = FRSW 3
[localhost:7201]
workingdir = /home/nabromov/dynamips/working
udp = 11000
[[3725]]
image = /home/nabromov/dynamips/images/c3725-adventerprisek9-mz.124-15.T14.bin
ram = 256
nvram = 256
ghostios = True
idlepc = 0x60c06028
[[Router R4]]
model = 3725
console = 2004
# R4 e0/0 to SW1 fa0/4
f0/0 = NIO_linux_eth:eth7
# R4 e0/1 to SW2 fa0/4
f0/1 = NIO_linux_eth:eth8
s1/0 = FRSW 4
s1/1 = R5 s1/1
[[Router R5]]
model = 3725
console = 2005
# R5 e0/0 to SW1 fa0/5
f0/0 = NIO_linux_eth:eth9
# R5 e0/1 to SW2 fa1/5
f0/1 = NIO_linux_eth:eth10
s1/0 = FRSW 5
[[Router R6]]
model = 3725
console = 2006
# R6 f0/0 to SW1 fa0/6
f0/0 = NIO_linux_eth:eth11
# R6 f0/1 to SW2 fa0/6
f0/1 = NIO_linux_eth:eth12
s1/0 = FRSW 6
s1/1 = FRSW 66
[[FRSW FRSW]]
# R1 to FRSW
1:102 = 2:201
1:103 = 3:301
1:104 = 4:401
1:105 = 5:501
1:106 = 6:601
1:112 = 22:211
1:116 = 66:611
# R2 to FRSW
2:203 = 3:302
2:204 = 4:402
2:205 = 5:502
2:206 = 6:602
22:213 = 3:312
22:214 = 4:412
22:215 = 5:512
22:216 = 66:612
# R3 to FRSW
3:304 = 4:403
3:305 = 5:503
3:306 = 6:603
3:316 = 66:613
# R4 to FRSW
4:405 = 5:504
4:406 = 6:606
4:416 = 66:614
# R5 to FRSW
5:506 = 6:605
5:516 = 66:615
# R6 to FRSW
This is my configuration:
"netmasterclass.net"
autostart = False
[localhost:7200]
workingdir = /home/nabromov/dynamips/working
udp = 11000
[[3725]]
image = /home/nabromov/dynamips/images/c3725-adventerprisek9-mz.124-15.T14.bin
ram = 256
nvram = 256
ghostios = True
idlepc = 0x60c06028
[[Router R1]]
model = 3725
console = 2001
# R1 e0/0 to SW1 fa0/1
f0/0 = NIO_linux_eth:eth0
# R1 f0/1 to SW2 fa0/1
f0/1 = NIO_linux_eth:eth1
s1/0 = FRSW 1
s1/1 = R3 s1/1
[[ROUTER R2]]
model = 3725
console = 2002
# R2 e0/0 to SW1 fa0/2
f0/0 = NIO_linux_eth:eth3
# R2 e0/1 to SW2 fa0/2
f0/1 = NIO_linux_eth:eth4
s1/0 = FRSW 2
s1/1 = FRSW 22
[[ROUTER R3]]
model = 3725
console = 2003
# R3 e0/0 to SW1 fa0/3
f0/0 = NIO_linux_eth:eth5
# R3 00/1 to SW2 fa0/3
f0/1 = NIO_linux_eth:eth6
s1/0 = FRSW 3
[localhost:7201]
workingdir = /home/nabromov/dynamips/working
udp = 11000
[[3725]]
image = /home/nabromov/dynamips/images/c3725-adventerprisek9-mz.124-15.T14.bin
ram = 256
nvram = 256
ghostios = True
idlepc = 0x60c06028
[[Router R4]]
model = 3725
console = 2004
# R4 e0/0 to SW1 fa0/4
f0/0 = NIO_linux_eth:eth7
# R4 e0/1 to SW2 fa0/4
f0/1 = NIO_linux_eth:eth8
s1/0 = FRSW 4
s1/1 = R5 s1/1
[[Router R5]]
model = 3725
console = 2005
# R5 e0/0 to SW1 fa0/5
f0/0 = NIO_linux_eth:eth9
# R5 e0/1 to SW2 fa1/5
f0/1 = NIO_linux_eth:eth10
s1/0 = FRSW 5
[[Router R6]]
model = 3725
console = 2006
# R6 f0/0 to SW1 fa0/6
f0/0 = NIO_linux_eth:eth11
# R6 f0/1 to SW2 fa0/6
f0/1 = NIO_linux_eth:eth12
s1/0 = FRSW 6
s1/1 = FRSW 66
[[FRSW FRSW]]
# R1 to FRSW
1:102 = 2:201
1:103 = 3:301
1:104 = 4:401
1:105 = 5:501
1:106 = 6:601
1:112 = 22:211
1:116 = 66:611
# R2 to FRSW
2:203 = 3:302
2:204 = 4:402
2:205 = 5:502
2:206 = 6:602
22:213 = 3:312
22:214 = 4:412
22:215 = 5:512
22:216 = 66:612
# R3 to FRSW
3:304 = 4:403
3:305 = 5:503
3:306 = 6:603
3:316 = 66:613
# R4 to FRSW
4:405 = 5:504
4:406 = 6:606
4:416 = 66:614
# R5 to FRSW
5:506 = 6:605
5:516 = 66:615
# R6 to FRSW
2/21/2011
netmasterclass workbooks
I am planning to try another training provider so I found netmasterclass who are working with Cisco based on Cisco 360 training program. I will post some impressions after I go through few of the labs.
Juniper networks bootcamp in March
Registration: JUNOS Bootcamp UK March 28th - April 1st 2011 (Mar 28, 2011 - Apr 01, 2011)
2/20/2011
CBAC concurrent sessions
another trick that I just learned. If you want to limit the number of the concurrent sessions going through the inspect rules you can use:
"RouterXXX(config)#ip inspect hashtable number"
Usage Guidelines
Use the ip inspect hashtable command to increase the size of the hash table when the number of concurrent sessions increases or to reduce the search time for the session. Collisions in a hash table result in poor hash function distribution because many entries are hashed into the same bucket for certain patterns of addresses. Even if a hash function distribution evenly dispenses the input across all of the buckets, a small hash table size will not scale well if there are a large number of sessions. As the number of sessions increase, the collisions increase, which increases the length of the linked lists, thereby, deteriorating the throughput performance.
"RouterXXX(config)#ip inspect hashtable number"
Usage Guidelines
Use the ip inspect hashtable command to increase the size of the hash table when the number of concurrent sessions increases or to reduce the search time for the session. Collisions in a hash table result in poor hash function distribution because many entries are hashed into the same bucket for certain patterns of addresses. Even if a hash function distribution evenly dispenses the input across all of the buckets, a small hash table size will not scale well if there are a large number of sessions. As the number of sessions increase, the collisions increase, which increases the length of the linked lists, thereby, deteriorating the throughput performance.
tclsh connectivity check example
this is one of the most important parts, the verification.
labXXX#tclsh
foreach i {
130.1.17.1
150.1.1.1
130.1.124.1
130.1.234.2
} { ping $i }
labXXX#tclsh
foreach i {
130.1.17.1
150.1.1.1
130.1.124.1
130.1.234.2
} { ping $i }
INE lab 15 task task 1.2
okey, everyone will configure the bba-groups in the right way to make the task working.For me the tricky bit was that I used the wrong identifier for this task and the static host map in the dhcp pool didn't work. If yo don't configure the right client identifier it want work.
so, what I did was to start the debug of the pppoe session and get the identifier from the dump in the log.
*Mar 1 00:13:42.243: Retry count: 1 Client-ID: cisco-c203.03d1.0000-Di1
*Mar 1 00:13:42.243: Client-ID hex dump: 636973636F2D633230332E303364312E
*Mar 1 00:13:42.247: 303030302D446931
we should keep in mind that we need to add 00 of front of the first two digits for the client-id and it will looks like 6369.xxxx.xxxx.xxxx.xxxx
so, what I did was to start the debug of the pppoe session and get the identifier from the dump in the log.
*Mar 1 00:13:42.243: Retry count: 1 Client-ID: cisco-c203.03d1.0000-Di1
*Mar 1 00:13:42.243: Client-ID hex dump: 636973636F2D633230332E303364312E
*Mar 1 00:13:42.247: 303030302D446931
we should keep in mind that we need to add 00 of front of the first two digits for the client-id and it will looks like 6369.xxxx.xxxx.xxxx.xxxx
dynamips and CDP annoying messages
*Mar 1 01:41:22.403: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/0 (not full duplex), with Rack1SW2 FastEthernet0/2 (full duplex).
to stop these messages you can type
LabXXX(config)#no cdp log mismatch duplex
to stop these messages you can type
LabXXX(config)#no cdp log mismatch duplex
annoying cisco features during the labs
Use the access-list hardware program nonblocking global configuration command to cause the system to continue to forward frames even while a new security access-control list (ACL) configuration is being programmed into the hardware. Use the no form of this command to return to the default behavior, where traffic is blocked on affected interfaces when changes are made to the security ACL configuration while the hardware is updated with the new configuration.
access-list hardware program nonblocking
no access-list hardware program nonblocking
access-list hardware program nonblocking
no access-list hardware program nonblocking
2/18/2011
some time to study
the company I work for gave me two months to prepare for the lab exam. So next couple of months I will be concentrated on this topic.
2/17/2011
IPv6overIP vs GRE
I just found this nice tutorial about the v6 tunnels and the ip over-head in particular.
http://ardenpackeer.com/routing-protocols/tutorial-ipv6-tunnels-part-1-manual-gre-ipv6ip-tunnels/
http://ardenpackeer.com/routing-protocols/tutorial-ipv6-tunnels-part-1-manual-gre-ipv6ip-tunnels/
2/13/2011
object group tracking for ACLs
First Published: July 11, 2008
Last Updated: September 6, 2010
The Object Groups for ACLs feature lets you classify users, devices, or protocols into groups and apply those groups to access control lists (ACLs) to create access control policies for those groups. This feature lets you use object groups instead of individual IP addresses, protocols, and ports, which are used in conventional ACLs. This feature allows multiple access control entries (ACEs), but now you can use each ACE to allow an entire group of users to access a group of servers or services or to deny them from doing so.
In large networks, the number of ACLs can be large (hundreds of lines) and difficult to configure and manage, especially if the ACLs frequently change. Object group-based ACLs are smaller, more readable, and easier to configure and manage than conventional ACLs, simplifying static and dynamic ACL deployments for large user access environments on Cisco IOS routers.
Cisco IOS Firewall benefits from object groups, because they simplify policy creation (for example, group A has access to group A services).
http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_object_group_acl.html#wp1132576
Last Updated: September 6, 2010
The Object Groups for ACLs feature lets you classify users, devices, or protocols into groups and apply those groups to access control lists (ACLs) to create access control policies for those groups. This feature lets you use object groups instead of individual IP addresses, protocols, and ports, which are used in conventional ACLs. This feature allows multiple access control entries (ACEs), but now you can use each ACE to allow an entire group of users to access a group of servers or services or to deny them from doing so.
In large networks, the number of ACLs can be large (hundreds of lines) and difficult to configure and manage, especially if the ACLs frequently change. Object group-based ACLs are smaller, more readable, and easier to configure and manage than conventional ACLs, simplifying static and dynamic ACL deployments for large user access environments on Cisco IOS routers.
Cisco IOS Firewall benefits from object groups, because they simplify policy creation (for example, group A has access to group A services).
http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_object_group_acl.html#wp1132576
1/31/2011
IOS on Unix (IOU)
source http://evilrouters.net/2011/01/18/cisco-iou-faq/
What is IOU?
From the Cisco Engineering Education web site (a long time ago):
IOS on Unix (IOU) is a fully working version of IOS that runs as a user mode UNIX (Solaris) process. IOU is built as a native Solaris image and run just like any other program. IOU supports all platform independent protocols and features.
What operating systems does IOU run on?
It is my understanding that, initially, IOU was Solaris (SPARC) only. Nowadays, however, there are also builds for OS X and Linux. Similar to dynamips, IOU allows you to build out a network topology on a computer, without the need for physical routers. This is useful for validating designs, proof-of-concept testing, and certification self-study.
Is my system compatible with IOU?
You will need to be running the operating system that your IOU image were built for, obviously. Other than that, there are no special requirements to run IOU. It is not very CPU- or memory-intensive, unlike dynamips.
What skills do I need to run IOU?
You will need to be comfortable on the command-line of your operating system. Knowledge of vi (or other text editors) and shell scripting would definitely be useful. If you’ve only ever used Windows, you might want to look into GNS3 instead.
Warnings
Is this legal?
Usage of IOU outside of Cisco (and trusted partners) is a potentially legal gray area. From an old internal-only Cisco web page:
Cisco IOS on Unix is a tool intended for internal use only. Distribution of IOU images to customers or external persons, or discussion of IOU with customers or external persons, is prohibited. Don’t do it or we’ll have to come and kill you.
Does IOU attempt to call home?
Yes. At startup, IOU images will attempt to make an HTTP POST of some XML data to xml.cisco.com. The data includes your (short) hostname (e.g. not the FQDN), the username of the user running IOU, the version, etc. It appears that xml.cisco.com is not reachable from the Internet, however, so the connection will not be made. This could change in the future, though, so you may want to do the following:
# echo '127.0.0.1 xml.cisco.com' >> /etc/hosts
I can’t find it, will you send me a copy?
No, don’t even ask. Seriously.
Features
What features does IOU support?
Pretty much everything, depending upon the image you’re using. The major exception is layer 2 switching, which L2IOU should take care of.
What version of IOS does it use?
I have seen a few Linux images floating around. One appears to be built on the “ipbase” featureset and another appears to be built with the “adventerpisek9″ featureset.
Are there pagent images?
Yes, in addition to “standard” IOU images, there are pagent images.
Licensing
Do I need a license to use IOU?
It does not seem that older IOU images needed a license to be used, while newer IOU images (including the Linux ones I have seen) do require a valid license.
How do I get a license?
Unfortunately, licenses are only able to be acquired inside of Cisco. An individual license code is generated, based upon the machine’s hostname and IP address.
Will you post your script to “crack” it?
Although I initially said I would, I have decided against this after careful thought. You may do this on your own, if you are so inclined.
Pre-requisites
What is the IOURC file?
The IOURC file is where IOU looks for your license code at startup.
Where does the IOURC file go?
IOU will look for the following:
A file named “iourc” in the current working directory
A file named “.iourc” in the user’s home directory
The file pointed to by the IOURC environment variable
What is the format of the IOURC file?
For licensing, your IOURC file needs to look like this:
[license]
hostname = 4242424242424242;
Replace “hostname” with your computer’s (short) hostname — not the fully-qualified domain name — and “4242424242424242″ with your license code. Make sure the line ends with a semi-colon. Your hostname can be found from the error IOU spits out or by running the following at a command-line:
# hostname -s
What is the NETMAP file?
The network topology map, or NETMAP, file is similar to a .net file for dynagen. It is used for controlling the layout of the “virtual cabling”.
Where does the NETMAP file go?
IOU will look for the following:
A file named “NETMAP” in the current working directory
A file named “.NETMAP” in the user’s home directory
The file pointed to by the NETIO_NETMAP environment variable
What is the format of the NETMAP file?
I’ve posted an example topology and NETMAP file that might be helpful.
Using IOU
How do I run IOU?
Usage: [options]
: unix-js-m | unix-is-m | unix-i-m | ...
: instance identifier (0 < id <= 1024)
Options:
-e Number of Ethernet interfaces (default 2)
-s Number of Serial interfaces (default 2)
-n Size of nvram in Kb (default 16K)
-c Configuration file name
-d Generate debug information
-t Netio message trace
-q Suppress informational messages
-h Display this help
-C Turn off use of host clock
-m Megabytes of router memory (default 64)
-L Disable local console, use remote console
-u UDP port base for distributed networks
How do I stop IOU?
Simply hit CTRL-C and the process will exit.
What is the “wrapper”?
When you run an IOU image, it will stay in the foreground and you’ll be connected to the “console”. This may not always be the desired behavior, especially if you wish to telnet to the console from another host on the network (a la dynamips). The wrapper program can be used to redirect a TCP port to the “console” of the router so that you can do exactly this.
How do I use the wrapper?
$ ./wrapper
Usage: ./wrapper [-v] -m -p -- [iou options]
where is in the range <1024-65550>
all options after the '--' are passed to iou
[-v] Display version
Instead of just running “./imagename”, you would use something like this:
$ ./wrapper -m ./imagename -p 2000 -- -e0 -s1 -m 64 100
This would tell the wrapper to start the image named “./imagename” and listen ton TCP port 2000. Any options after “–” are passed off to the executable, so in this case our IOU instance would start up with zero ethernet interfaces (“-e0″), one serial interface (“-s1″) — which actually means four in newer images, due to something called “Wide Port Adapters” — and 64 MB of RAM. The “application ID”, which we’ll use to refer to this instance in the NETMAP file, is 100.
The wrapper is most useful in a shell script to start up and background a number of IOU instances at once.
How do I stop IOU when using the wrapper?
If you are using the wrapper and have backgrounded the IOU instance, you’ll need to find the process ID and kill it. The following will find all running instances and kill them:
$ ps -ef | grep [w]rapper | awk '{ print $2 }' | xargs kill
IOUlive
What is IOUlive?
IOUlive is a separate application that allows one to bridge an IOU instance to the real world. This is similar to using dynagen’s NIO_linux_eth descriptor. By connecting an IOU instance to IOUlive, your virtual routers can talk to devices on your physical network.
How do I use IOUlive?
I’ve posted an example topology and NETMAP file that might be helpful.
Errors
What does “UNIX ERR:tcgetattr:Invalid argument” mean?
No idea, but it doesn’t seem to hurt anything. it appears that it can be safely ignored.
I’m getting an error about libcrypto.so.4.
These images were compiled against an older version of the libcrypto shared library than what your Linux distribution may have. For me, creating a symbolic link from /lib/libcrypto.so.0.9.8 to /lib/libcrypto.so.4 took care of the error.
I’m getting a “host not found in iourc file” error.
Fix your IOURC file. See above.
How can I add an NM-16ESW module?
You can’t.
There must be some way to add ATM or NM-16ESW modules!
There’s not.
When running “./wrapper-linux -m i86bi_linux-adventerprisek9-ms …” I get “No such file or directory”.
Provide the path to the IOU image. If it’s in the working directory, refer to it as “./i86bi_linux-adventerprisek9-ms”, for example.
I’ve tried everything and I can’t get it to work. What should I do?
Google “gns3″ and follow a tutorial on how to download and install it. Seriously.
If
What is IOU?
From the Cisco Engineering Education web site (a long time ago):
IOS on Unix (IOU) is a fully working version of IOS that runs as a user mode UNIX (Solaris) process. IOU is built as a native Solaris image and run just like any other program. IOU supports all platform independent protocols and features.
What operating systems does IOU run on?
It is my understanding that, initially, IOU was Solaris (SPARC) only. Nowadays, however, there are also builds for OS X and Linux. Similar to dynamips, IOU allows you to build out a network topology on a computer, without the need for physical routers. This is useful for validating designs, proof-of-concept testing, and certification self-study.
Is my system compatible with IOU?
You will need to be running the operating system that your IOU image were built for, obviously. Other than that, there are no special requirements to run IOU. It is not very CPU- or memory-intensive, unlike dynamips.
What skills do I need to run IOU?
You will need to be comfortable on the command-line of your operating system. Knowledge of vi (or other text editors) and shell scripting would definitely be useful. If you’ve only ever used Windows, you might want to look into GNS3 instead.
Warnings
Is this legal?
Usage of IOU outside of Cisco (and trusted partners) is a potentially legal gray area. From an old internal-only Cisco web page:
Cisco IOS on Unix is a tool intended for internal use only. Distribution of IOU images to customers or external persons, or discussion of IOU with customers or external persons, is prohibited. Don’t do it or we’ll have to come and kill you.
Does IOU attempt to call home?
Yes. At startup, IOU images will attempt to make an HTTP POST of some XML data to xml.cisco.com. The data includes your (short) hostname (e.g. not the FQDN), the username of the user running IOU, the version, etc. It appears that xml.cisco.com is not reachable from the Internet, however, so the connection will not be made. This could change in the future, though, so you may want to do the following:
# echo '127.0.0.1 xml.cisco.com' >> /etc/hosts
I can’t find it, will you send me a copy?
No, don’t even ask. Seriously.
Features
What features does IOU support?
Pretty much everything, depending upon the image you’re using. The major exception is layer 2 switching, which L2IOU should take care of.
What version of IOS does it use?
I have seen a few Linux images floating around. One appears to be built on the “ipbase” featureset and another appears to be built with the “adventerpisek9″ featureset.
Are there pagent images?
Yes, in addition to “standard” IOU images, there are pagent images.
Licensing
Do I need a license to use IOU?
It does not seem that older IOU images needed a license to be used, while newer IOU images (including the Linux ones I have seen) do require a valid license.
How do I get a license?
Unfortunately, licenses are only able to be acquired inside of Cisco. An individual license code is generated, based upon the machine’s hostname and IP address.
Will you post your script to “crack” it?
Although I initially said I would, I have decided against this after careful thought. You may do this on your own, if you are so inclined.
Pre-requisites
What is the IOURC file?
The IOURC file is where IOU looks for your license code at startup.
Where does the IOURC file go?
IOU will look for the following:
A file named “iourc” in the current working directory
A file named “.iourc” in the user’s home directory
The file pointed to by the IOURC environment variable
What is the format of the IOURC file?
For licensing, your IOURC file needs to look like this:
[license]
hostname = 4242424242424242;
Replace “hostname” with your computer’s (short) hostname — not the fully-qualified domain name — and “4242424242424242″ with your license code. Make sure the line ends with a semi-colon. Your hostname can be found from the error IOU spits out or by running the following at a command-line:
# hostname -s
What is the NETMAP file?
The network topology map, or NETMAP, file is similar to a .net file for dynagen. It is used for controlling the layout of the “virtual cabling”.
Where does the NETMAP file go?
IOU will look for the following:
A file named “NETMAP” in the current working directory
A file named “.NETMAP” in the user’s home directory
The file pointed to by the NETIO_NETMAP environment variable
What is the format of the NETMAP file?
I’ve posted an example topology and NETMAP file that might be helpful.
Using IOU
How do I run IOU?
Usage:
Options:
-e
-s
-n
-c
-d Generate debug information
-t Netio message trace
-q Suppress informational messages
-h Display this help
-C Turn off use of host clock
-m
-L Disable local console, use remote console
-u
How do I stop IOU?
Simply hit CTRL-C and the process will exit.
What is the “wrapper”?
When you run an IOU image, it will stay in the foreground and you’ll be connected to the “console”. This may not always be the desired behavior, especially if you wish to telnet to the console from another host on the network (a la dynamips). The wrapper program can be used to redirect a TCP port to the “console” of the router so that you can do exactly this.
How do I use the wrapper?
$ ./wrapper
Usage: ./wrapper [-v] -m
where
all options after the '--' are passed to iou
[-v] Display version
Instead of just running “./imagename
$ ./wrapper -m ./imagename -p 2000 -- -e0 -s1 -m 64 100
This would tell the wrapper to start the image named “./imagename” and listen ton TCP port 2000. Any options after “–” are passed off to the executable, so in this case our IOU instance would start up with zero ethernet interfaces (“-e0″), one serial interface (“-s1″) — which actually means four in newer images, due to something called “Wide Port Adapters” — and 64 MB of RAM. The “application ID”, which we’ll use to refer to this instance in the NETMAP file, is 100.
The wrapper is most useful in a shell script to start up and background a number of IOU instances at once.
How do I stop IOU when using the wrapper?
If you are using the wrapper and have backgrounded the IOU instance, you’ll need to find the process ID and kill it. The following will find all running instances and kill them:
$ ps -ef | grep [w]rapper | awk '{ print $2 }' | xargs kill
IOUlive
What is IOUlive?
IOUlive is a separate application that allows one to bridge an IOU instance to the real world. This is similar to using dynagen’s NIO_linux_eth descriptor. By connecting an IOU instance to IOUlive, your virtual routers can talk to devices on your physical network.
How do I use IOUlive?
I’ve posted an example topology and NETMAP file that might be helpful.
Errors
What does “UNIX ERR:tcgetattr:Invalid argument” mean?
No idea, but it doesn’t seem to hurt anything. it appears that it can be safely ignored.
I’m getting an error about libcrypto.so.4.
These images were compiled against an older version of the libcrypto shared library than what your Linux distribution may have. For me, creating a symbolic link from /lib/libcrypto.so.0.9.8 to /lib/libcrypto.so.4 took care of the error.
I’m getting a “host not found in iourc file” error.
Fix your IOURC file. See above.
How can I add an NM-16ESW module?
You can’t.
There must be some way to add ATM or NM-16ESW modules!
There’s not.
When running “./wrapper-linux -m i86bi_linux-adventerprisek9-ms …” I get “No such file or directory”.
Provide the path to the IOU image. If it’s in the working directory, refer to it as “./i86bi_linux-adventerprisek9-ms”, for example.
I’ve tried everything and I can’t get it to work. What should I do?
Google “gns3″ and follow a tutorial on how to download and install it. Seriously.
If
1/27/2011
added new book to my collection
Just got another book for my collection. I am not big fen of MPLS/VPLS,however, this topic is mandatory in routing and switching lab.
MPLS Configuration on Cisco IOS Software: A complete configuration manual for MPLS, MPLS VPNs, MPLS TE, Any Transport over MPLS (AToM), and VPLS (Networking Technology) [Paperback]
Paperback: 720 pages
Publisher: Cisco Press; 1 edition (10 Jun 2010)
Language English
ISBN-10: 1587142503
ISBN-13: 978-1587142505
MPLS Configuration on Cisco IOS Software: A complete configuration manual for MPLS, MPLS VPNs, MPLS TE, Any Transport over MPLS (AToM), and VPLS (Networking Technology) [Paperback]
Paperback: 720 pages
Publisher: Cisco Press; 1 edition (10 Jun 2010)
Language English
ISBN-10: 1587142503
ISBN-13: 978-1587142505
1/23/2011
Understanding STP convergence
I've been trying to find a good explanations on some of the Internetwork Expert tasks and why they decided to use the solutions they used in some of the tasks. I tagged all posts related to the labs with tag "ccienotes". The one bellow is related to IE lab 11; task 1.3.
1) General overview of STP convergence process
2) How STP converges if a directly connected link fails
3) How STP converges when it detects indirect link failure
4) Topology changes and their effect
See more detailed overview at: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf
STP Convergence in General
As we know, STP protocol follows certain simple procedure to calculate the loop-free subset of the network topology. STP protocol could be compared to RIP in some sense. Both execute a version of Bellman-Ford iterative algorithm, which could be described as “gradient” (meaning it iteratively looks for the optimal solution, selecting the “closest” candidate every time). Every switch accepts and retains only the best current root bridge information. The switch then blocks alternate paths to the root bridge, leaving only the single optimal (in terms of path cost) uplink and continues relaying the optimal information. If a switch learns about a better (“superior”) root bridge than it knows now (e.g. better bridge id, or shorter path to the root), the old information is erased and the new one immediately accepted and relayed. Note that the switch stores the most recent STP BPDUs with every port that receives them. Therefore, for a given switch, there is a BPDUs stored with every root or alternate (blocked port).
There are certain features in STP designed to improve the algorithm stability and ensure the aging out of the old information. Every BPDU contains two fields: Max_Age and Message_Age. The Message_Age field is incremented every time a BPDU traverses a switch (so it might be compared to the hop count). When a switch stores the BPDU with the respective port, it will count the time in seconds, starting from Message_Age and up to the Max_Age. If during this interval, no further BPDUs are received, the current BPDU is wiped out and the port is declared designated. This procedure ensures that the old information is eventually aged out of the topology.
There is one more thing, similar to the “hold-down” feature found in RIP. It is the way in which STP deals with “inferior” BPDUs. The BPDU is considered inferior, if it carries information about the root bridge that is worse than the one currently stored for the port, or the BPDU has longer distance to reach the current root bridge (compare this to RIP’s increase in metric). Inferior BPDUs may appear when a neighboring switch suddenly loses its uplink and claims itself the new root of the topology. By default, every switch should ignore inferior BPDUs, until the currently stored BPDU expires (time=Max_Age – Message_Age). This feature intends to stabilize STP topology in situations where an uplink on some switch flaps, causing the switch to start sending inferior information.
STP convergence in case of directly connected link failure
Consider a switch on Fig 1., with two uplinks – one forwarding (root port, port A) and another blocking (alternate port, port B). Imagine now that the root port fails.
There are two different situations:
1) The switch detects loss of carrier and immediately declares the port dead. Since this was the port with the best information, the switch immediately invalidates it, and selects the next “best candidate” which is the alternate port (Port B) as the new root port. The switch will transition Port B through Listening and Learning states, which takes 2xForward_Time. Therefore, the connectivity is restored in 2xForward_Time.
2) The switch does not detect the loss of carrier (for example, the uplink is fiber connected to a converter or connects through a hub), and thus the port remains up. The root port, however, loses the continuous stream of BPDUs. Thus, the stored BPDU information is no longer updated. Based on the default procedure, it takes time=Max_Age-Message_Age to expire the stored information. After this, the switch considers the BPDU stored with the alternate port, and unblock Port B. It will take another 2xForward_Delay to bring the port to forwarding state. Therefore, the connectivity is resotored in 2xForward_Time + (Max_Age-Message_Age).
If the switch detects loss of carrier on the designated port (Port C) nothing much will happen. Since there are no BPDUs received on this port, the switch will only generate a topology change event (more on that later), but will not block or unblock any other local ports. This event, might, however, affect the downstream switches.
STP Convergence in case of indirect link failure
Consider the topology on Fig 2.
In this case, SW2 has better Bridge ID than SW3, and thus Port D is designated on the segment between SW2 and SW3. SW3 blocks the redundant uplink to via SW3 (Port B) and elects Port A as the root port. Now imagine that SW2 detects loss of carrier on the link connected to SW1 (Port C). The switch will immediately invalidate the best BPDU stored for Port C, and will assume itself the root of the spanning-tree, as there are no other ports receiving BPDUs. SW2 will start advertising BPDUs to SW3, setting the designated and the root bridge to itself in the configuration BPDUs. Those are, by definition, inferior BPDUs, and SW3 will ignore them, as it still hears better information from SW1. SW3 will also keep the previous BPDU associated with Port B for the duration of Max_Age-Message_Age. When this timer expires, SW3 will start considering the inferior BPDUs. Port B will move to Listening state, and SW3 will start relaying SW1’s BPDUs to SW2, as those are superior to SW2’s BPDUs. Now, SW2 would detect the better information on its formerly designated port (Port D) and will cycle the port through Listening and Learning states. Both switches (SW2 and SW3) will eventually move their ports into forwarding states, recovering the connectivity. Therefore, it will take Max_Age-Message_Age + 2xForward_Time to recover from indirect link failure.
The effect of topology changes
Switches forward Ethernet frames based on their MAC address tables (filtering tables) that bind MAC addresses to egress ports. When a change in topology occurs (e.g. a link failure) the MAC address tables may appear to be invalid, as the paths between switches have changed. The switches may eventually re-learn the new information, but it may take considerable time, especially if the traffic is scarce and MAC address aging time is large (5 minutes by default). Based on that, if switch detects a change in the topology (e.g. link going up or down), it should notify all other switches that something has changed. In response to this notification, all switches will reduce their MAC address aging time to Forward_Time (15 secs by default) effectively fastening the aging process.
As we know, topology changes are signaled via special TCN BPDU, which is being sent upstream from the originating switch (the one that detected the change) to the root switch via the root ports. As the root switch hears the TCN BPDU, it will set TCN ACK flag in all its outgoing configuration BPDUs for the duration of Max_Age+Forward_Time. All switches that see this flag, will set their MAC address tables aging time to Forward_Time. Once the switch that originated the TCN BPDU will hear the TCN ACK, it will stop signaling about the topology change.
Now what is the effect of a topology change event? Two major things are impacted:
1) Connectivity. In some cases, it may time additional Forward_Delay seconds to expire the old MAC address information and recover connectivity. This may only happen if the old information persists in some switches, and the frames are black-holed.
2) Network performance. Shortening the MAC address table aging time results in less stable topology. When a switch loses a MAC address, it starts flooding frames for this destination, effectively acting like a hub. If the flow of packets in your network is not intense enough, the switches may start losing MAC address table information, resulting in excessive traffic flooding.
The second issue might become pretty dangerous with high number of topology changes. Excessive flooding might severely impact your network performance. Note, that this issue also pertains to L2 topologies that runs RSTP, as the topology changes are handled in the similar way. In order to reduce the number of topology changes, configure all edge ports in the topology (connected to hosts, IP Phones, servers) as spanning-tree portfast. Portfast ports do not generate TC events when they go up or down.
For more detailed description of topology change notification read the following great article at Cisco’s site:
Understanding Spanning-Tree Topology Changes
Part II of this post will consider UplinkFast and BackboneFast features, and their effect on STP convergence.
PS
We often use the formula Max_Age-Message_Age in this text, to be precise. However, most STP topologies are small enough to ignore Message_Age and assume the value of Max_Age for most calculations, unless Max_Age is artificially set to a very low value.
source:http://blog.ine.com/2009/03/07/understanding-stp-convergence-part-i/
link1: http://www.certificationkits.com/-a-111.html
1) General overview of STP convergence process
2) How STP converges if a directly connected link fails
3) How STP converges when it detects indirect link failure
4) Topology changes and their effect
See more detailed overview at: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf
STP Convergence in General
As we know, STP protocol follows certain simple procedure to calculate the loop-free subset of the network topology. STP protocol could be compared to RIP in some sense. Both execute a version of Bellman-Ford iterative algorithm, which could be described as “gradient” (meaning it iteratively looks for the optimal solution, selecting the “closest” candidate every time). Every switch accepts and retains only the best current root bridge information. The switch then blocks alternate paths to the root bridge, leaving only the single optimal (in terms of path cost) uplink and continues relaying the optimal information. If a switch learns about a better (“superior”) root bridge than it knows now (e.g. better bridge id, or shorter path to the root), the old information is erased and the new one immediately accepted and relayed. Note that the switch stores the most recent STP BPDUs with every port that receives them. Therefore, for a given switch, there is a BPDUs stored with every root or alternate (blocked port).
There are certain features in STP designed to improve the algorithm stability and ensure the aging out of the old information. Every BPDU contains two fields: Max_Age and Message_Age. The Message_Age field is incremented every time a BPDU traverses a switch (so it might be compared to the hop count). When a switch stores the BPDU with the respective port, it will count the time in seconds, starting from Message_Age and up to the Max_Age. If during this interval, no further BPDUs are received, the current BPDU is wiped out and the port is declared designated. This procedure ensures that the old information is eventually aged out of the topology.
There is one more thing, similar to the “hold-down” feature found in RIP. It is the way in which STP deals with “inferior” BPDUs. The BPDU is considered inferior, if it carries information about the root bridge that is worse than the one currently stored for the port, or the BPDU has longer distance to reach the current root bridge (compare this to RIP’s increase in metric). Inferior BPDUs may appear when a neighboring switch suddenly loses its uplink and claims itself the new root of the topology. By default, every switch should ignore inferior BPDUs, until the currently stored BPDU expires (time=Max_Age – Message_Age). This feature intends to stabilize STP topology in situations where an uplink on some switch flaps, causing the switch to start sending inferior information.
STP convergence in case of directly connected link failure
Consider a switch on Fig 1., with two uplinks – one forwarding (root port, port A) and another blocking (alternate port, port B). Imagine now that the root port fails.
There are two different situations:
1) The switch detects loss of carrier and immediately declares the port dead. Since this was the port with the best information, the switch immediately invalidates it, and selects the next “best candidate” which is the alternate port (Port B) as the new root port. The switch will transition Port B through Listening and Learning states, which takes 2xForward_Time. Therefore, the connectivity is restored in 2xForward_Time.
2) The switch does not detect the loss of carrier (for example, the uplink is fiber connected to a converter or connects through a hub), and thus the port remains up. The root port, however, loses the continuous stream of BPDUs. Thus, the stored BPDU information is no longer updated. Based on the default procedure, it takes time=Max_Age-Message_Age to expire the stored information. After this, the switch considers the BPDU stored with the alternate port, and unblock Port B. It will take another 2xForward_Delay to bring the port to forwarding state. Therefore, the connectivity is resotored in 2xForward_Time + (Max_Age-Message_Age).
If the switch detects loss of carrier on the designated port (Port C) nothing much will happen. Since there are no BPDUs received on this port, the switch will only generate a topology change event (more on that later), but will not block or unblock any other local ports. This event, might, however, affect the downstream switches.
STP Convergence in case of indirect link failure
Consider the topology on Fig 2.
In this case, SW2 has better Bridge ID than SW3, and thus Port D is designated on the segment between SW2 and SW3. SW3 blocks the redundant uplink to via SW3 (Port B) and elects Port A as the root port. Now imagine that SW2 detects loss of carrier on the link connected to SW1 (Port C). The switch will immediately invalidate the best BPDU stored for Port C, and will assume itself the root of the spanning-tree, as there are no other ports receiving BPDUs. SW2 will start advertising BPDUs to SW3, setting the designated and the root bridge to itself in the configuration BPDUs. Those are, by definition, inferior BPDUs, and SW3 will ignore them, as it still hears better information from SW1. SW3 will also keep the previous BPDU associated with Port B for the duration of Max_Age-Message_Age. When this timer expires, SW3 will start considering the inferior BPDUs. Port B will move to Listening state, and SW3 will start relaying SW1’s BPDUs to SW2, as those are superior to SW2’s BPDUs. Now, SW2 would detect the better information on its formerly designated port (Port D) and will cycle the port through Listening and Learning states. Both switches (SW2 and SW3) will eventually move their ports into forwarding states, recovering the connectivity. Therefore, it will take Max_Age-Message_Age + 2xForward_Time to recover from indirect link failure.
The effect of topology changes
Switches forward Ethernet frames based on their MAC address tables (filtering tables) that bind MAC addresses to egress ports. When a change in topology occurs (e.g. a link failure) the MAC address tables may appear to be invalid, as the paths between switches have changed. The switches may eventually re-learn the new information, but it may take considerable time, especially if the traffic is scarce and MAC address aging time is large (5 minutes by default). Based on that, if switch detects a change in the topology (e.g. link going up or down), it should notify all other switches that something has changed. In response to this notification, all switches will reduce their MAC address aging time to Forward_Time (15 secs by default) effectively fastening the aging process.
As we know, topology changes are signaled via special TCN BPDU, which is being sent upstream from the originating switch (the one that detected the change) to the root switch via the root ports. As the root switch hears the TCN BPDU, it will set TCN ACK flag in all its outgoing configuration BPDUs for the duration of Max_Age+Forward_Time. All switches that see this flag, will set their MAC address tables aging time to Forward_Time. Once the switch that originated the TCN BPDU will hear the TCN ACK, it will stop signaling about the topology change.
Now what is the effect of a topology change event? Two major things are impacted:
1) Connectivity. In some cases, it may time additional Forward_Delay seconds to expire the old MAC address information and recover connectivity. This may only happen if the old information persists in some switches, and the frames are black-holed.
2) Network performance. Shortening the MAC address table aging time results in less stable topology. When a switch loses a MAC address, it starts flooding frames for this destination, effectively acting like a hub. If the flow of packets in your network is not intense enough, the switches may start losing MAC address table information, resulting in excessive traffic flooding.
The second issue might become pretty dangerous with high number of topology changes. Excessive flooding might severely impact your network performance. Note, that this issue also pertains to L2 topologies that runs RSTP, as the topology changes are handled in the similar way. In order to reduce the number of topology changes, configure all edge ports in the topology (connected to hosts, IP Phones, servers) as spanning-tree portfast. Portfast ports do not generate TC events when they go up or down.
For more detailed description of topology change notification read the following great article at Cisco’s site:
Understanding Spanning-Tree Topology Changes
Part II of this post will consider UplinkFast and BackboneFast features, and their effect on STP convergence.
PS
We often use the formula Max_Age-Message_Age in this text, to be precise. However, most STP topologies are small enough to ignore Message_Age and assume the value of Max_Age for most calculations, unless Max_Age is artificially set to a very low value.
source:http://blog.ine.com/2009/03/07/understanding-stp-convergence-part-i/
link1: http://www.certificationkits.com/-a-111.html
1/14/2011
INE vol2 lab 10 - task 1
--- cut ---
By default, EIGRP will choose the path with the lowest metric. For this topology, the Point to point link between R1-R3 is 1.536 Mbps, frame-relay link between R2-R3 is 1.28 Mbps and the frame-relay link between R1-R2 is 256Kbps. In this scenario, R1 will choose Path 1 to reach VLAN 26. At this point if we configure the variance of 5, then the traffic will be load balanced between the two paths at a ratio of 80:23 as shown in the output below.
RSRack1R1#sh ip route 164.1.26.6
Routing entry for 164.1.26.0/24
Known via “eigrp 100″, distance 90, metric 3026432, type internal
Redistributing via eigrp 100
Last update from 164.1.12.2 on Serial0/0, 00:00:56 ago
Routing Descriptor Blocks:
* 164.1.13.3, from 164.1.13.3, 00:00:56 ago, via Serial0/1
Route metric is 3026432, traffic share count is 80
Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
164.1.12.2, from 164.1.12.2, 00:00:56 ago, via Serial0/0
Route metric is 10514432, traffic share count is 23
Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
To achieve a 5:1 ratio, we can modify the metric through R2 to be 5 times the metric through R3. But before we can do that, let’s figure out how the metric is being calculated in the first place.
Metric = [K1*BW+(K2*BW)/256-Load)+K3*Delay]*[K5/(Reliability+K4)]
As we know, by default K1 and K3 equals 1 while all the other values are ZERO. So we can modify the above equation as follows:
Metric_R3 = (10^7/BW+Delay/10)*256
Metric_R3 = (10^7/1280+40100/10)*256
Metric_R3 = 3026432
In order to get the 5:1 ratio, we must increase the metric through R2 to be 5 times that of the metric through R3. This is how we can get the value of the DELAY through
R2.
Metric_R2 = Metric_R3 * 5
(10^7/BW+Delay/10)*256 = (10^7/BW+Delay/10)*256*5
(10^7/256+Delay/10) = (10^7/1280+40100/10)*5
(39062.5+Delay/10 = (7812.5 + 4010) * 5
Delay/10 = 59112.5 – 39062.5
Delay = 20050 * 10
Delay = 200500
Looking through the routing table, we can see that we already have a delay of 100 microseconds to reach VLAN26.
http://www.ccietalk.com/2008/09/21/eigrp-unequal-cost-load-balancing
and
http://blog.ipexpert.com/2010/05/03/eigrp-unequal-cost-load-balancing/
however, to get what should be the delay it's pretty easy
r2_delay = (10 ^ 7/min-bw-via-R3 + (delay-(r1-r3) + delay(r3+r2) ) /10 )*5
By default, EIGRP will choose the path with the lowest metric. For this topology, the Point to point link between R1-R3 is 1.536 Mbps, frame-relay link between R2-R3 is 1.28 Mbps and the frame-relay link between R1-R2 is 256Kbps. In this scenario, R1 will choose Path 1 to reach VLAN 26. At this point if we configure the variance of 5, then the traffic will be load balanced between the two paths at a ratio of 80:23 as shown in the output below.
RSRack1R1#sh ip route 164.1.26.6
Routing entry for 164.1.26.0/24
Known via “eigrp 100″, distance 90, metric 3026432, type internal
Redistributing via eigrp 100
Last update from 164.1.12.2 on Serial0/0, 00:00:56 ago
Routing Descriptor Blocks:
* 164.1.13.3, from 164.1.13.3, 00:00:56 ago, via Serial0/1
Route metric is 3026432, traffic share count is 80
Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
164.1.12.2, from 164.1.12.2, 00:00:56 ago, via Serial0/0
Route metric is 10514432, traffic share count is 23
Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
To achieve a 5:1 ratio, we can modify the metric through R2 to be 5 times the metric through R3. But before we can do that, let’s figure out how the metric is being calculated in the first place.
Metric = [K1*BW+(K2*BW)/256-Load)+K3*Delay]*[K5/(Reliability+K4)]
As we know, by default K1 and K3 equals 1 while all the other values are ZERO. So we can modify the above equation as follows:
Metric_R3 = (10^7/BW+Delay/10)*256
Metric_R3 = (10^7/1280+40100/10)*256
Metric_R3 = 3026432
In order to get the 5:1 ratio, we must increase the metric through R2 to be 5 times that of the metric through R3. This is how we can get the value of the DELAY through
R2.
Metric_R2 = Metric_R3 * 5
(10^7/BW+Delay/10)*256 = (10^7/BW+Delay/10)*256*5
(10^7/256+Delay/10) = (10^7/1280+40100/10)*5
(39062.5+Delay/10 = (7812.5 + 4010) * 5
Delay/10 = 59112.5 – 39062.5
Delay = 20050 * 10
Delay = 200500
Looking through the routing table, we can see that we already have a delay of 100 microseconds to reach VLAN26.
http://www.ccietalk.com/2008/09/21/eigrp-unequal-cost-load-balancing
and
http://blog.ipexpert.com/2010/05/03/eigrp-unequal-cost-load-balancing/
however, to get what should be the delay it's pretty easy
r2_delay = (10 ^ 7/min-bw-via-R3 + (delay-(r1-r3) + delay(r3+r2) ) /10 )*5
Subscribe to:
Posts (Atom)