CCIE Pursuit Blog

April 23, 2009

Can’t We All Just Get Along

Filed under: Cisco,Cisco Certification,IOS — cciepursuit @ 8:00 am
Tags: , , , , ,

Rack1R1(config)#router bgp 1100
Rack1R1(config-router)#neighbor 10.1.1.1 remote-as 1100
Rack1R1(config-router)#neighbor 10.1.1.1 prefix-list PREFIX in
Rack1R1(config-router)#neighbor 10.1.1.1 distr
Rack1R1(config-router)#neighbor 10.1.1.1 distribute-list DISTRIBUTE in
Prefix/distribute list can not co-exist

It sounds like Mr. Prefix-list and Mr. Distribute-list need to sit down and iron out their differences.  Or this could be the problem:

The attributes prefix-list and distribute-list are mutually exclusive, and only one command (neighbor prefix-list or neighbor distribute-list) can be applied to each inbound or outbound direction for a particular neighbor.

Advertisements

December 31, 2008

Would You Like That Abbreviated Or Spelled Out?

Filed under: Cisco,Cisco Certification,IOS,OT: Humor — cciepursuit @ 8:00 am
Tags: , , , , ,

My 3560 is so nice.  It gives me the option of debugging EIGRP based on the AS number OR the Autonomous System number.  🙂

SW2#debug ip eigrp ?
<1-65535>      AS number
<1-65535>      Autonomous System
neighbor       IP-EIGRP neighbor debugging
notifications  IP-EIGRP event notifications
summary        IP-EIGRP summary route processing
vrf            Select a VPN Routing/Forwarding instance
<cr>

SW2#sh ver | i IOS|image
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)
System image file is “flash:c3560-ipservicesk9-mz.122-25.SEE2/c3560-ipservicesk9-mz.122-25.SEE2.bin”

December 11, 2008

Lab Tip: Check For Redistribution On A Device

Filed under: Cisco,Cisco Certification,IOS,Lab Tips — cciepursuit @ 1:05 pm
Tags: , , , , ,

This can be done by many methods, but prefer to use “show run | i router|redist” to see if there is any redistribution currently on the device.  Since all routing processes include the term “router” and all redistributions include…well “redistribution”, this command will show you which – if any – redistributions are currently configured on a device:

Rack1R6(config)#do sh run | i router|redist
router eigrp 10
router ospf 100
router-id 150.1.6.6
redistribute connected subnets route-map CONN->OSPF

In this case we can see that we are redistributing connected routes into OSPF using a route-map.  Good to know before beginning mutual redistribution.

Rack1R5#sh run | i router|redist
router eigrp 100
router ospf 100
router-id 150.1.5.5

In this case we can see that there is no redistribution currently occurring on this device.

I run through this check any time I am about to configure redistribution.  I also note any redistributions on my lab topography, but it’s always good to “measure twice, cut once” 🙂

November 17, 2008

Cool Command 3: show ip ospf database database-summary

‘show ip ospf database’ is one of those commands that every CCIE candidate needs to know how to use as it can show you a ton of very good OSPF information.  There are a ton of options for this command:

r2#show ip ospf database ?
  adv-router        Advertising Router link states
  asbr-summary      ASBR summary link states
  database-summary  Summary of database
  external          External link states
  network           Network link states
  nssa-external     NSSA External link states
  opaque-area       Opaque Area link states
  opaque-as         Opaque AS link states
  opaque-link       Opaque Link-Local link states
  router            Router link states
  self-originate    Self-originated link states
  summary           Network summary link states
  |                 Output modifiers
  <cr>

I can’t believe that I’ve gotten this far and never used the “database-summary” option for this command. 

database-summary
 (Optional) Displays how many of each type of LSA for each area there are in the database, and the total.

Here’s the output of the command for an OSPF process with area 0 and three non-zero areas (note the difference in the LSA types in Area 0 versus the non-zero areas):

r1#show ip ospf database database-summary

            OSPF Router with ID (1.1.1.1) (Process ID 100)

Area 0 database summary
  LSA Type      Count    Delete   Maxage
  Router        2        0        0      
  Network       1        0        0      
  Summary Net   6        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Area 100 database summary
  LSA Type      Count    Delete   Maxage
  Router        1        0        0      
  Network       0        0        0      
  Summary Net   8        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Area 101 database summary
  LSA Type      Count    Delete   Maxage
  Router        1        0        0      
  Network       0        0        0      
  Summary Net   8        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Area 102 database summary
  LSA Type      Count    Delete   Maxage
  Router        1        0        0      
  Network       0        0        0      
  Summary Net   8        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0      

Process 100 database summary
  LSA Type      Count    Delete   Maxage
  Router        5        0        0      
  Network       1        0        0      
  Summary Net   30       0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Type-5 Ext    0        0        0      
      Prefixes redistributed in Type-5  0
  Opaque AS     0        0        0      
  Total         36       0        0

As you can see this command shows a count of each type of LSA for each OSPF area (per process if you’re running multiple processes).  You can limit the output to a specific area (or process) with a grep command:

Show just the database-summary for area 0:

r2#show ip ospf database database-summary | sec Area 0
Area 0 database summary
  LSA Type      Count    Delete   Maxage
  Router        2        0        0      
  Network       1        0        0      
  Summary Net   6        0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
    Prefixes redistributed in Type-7  0
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Subtotal      9        0        0 

Show just the database-summary for Process 100:

r2#show ip ospf database database-summary | sec Process 100
Process 100 database summary
  LSA Type      Count    Delete   Maxage
  Router        5        0        0      
  Network       1        0        0      
  Summary Net   30       0        0      
  Summary ASBR  0        0        0      
  Type-7 Ext    0        0        0      
  Opaque Link   0        0        0      
  Opaque Area   0        0        0      
  Type-5 Ext    0        0        0      
      Prefixes redistributed in Type-5  0
  Opaque AS     0        0        0      
  Total         36       0        0

October 13, 2008

Do 6500s Dream Of Electric Sheep?

This weekend we had a 6509 that was moaning about module 2 so we ran diagnostics on that module:

Oct 11 18:05:01 CDT: SP: ******************************************************************
Oct 11 18:05:01 CDT: SP: * WARNING: Please RESET module 2 prior to normal use. Also, packet
Oct 11 18:05:01 CDT: SP: * switching tests will no longer work (i.e. test failure) because
Oct 11 18:05:01 CDT: SP: * its memories are filled with test patterns.
Oct 11 18:05:01 CDT: SP: ******************************************************************

I would feel sorry for the poor switch but my memories are filled with images of that photo shoot that CCIE Journey did for goatse.cx which are far more horrible than test patterns.  🙂

September 21, 2008

IOS error(?) with OSPF point-to-multipoint network in PPPoFR Hub-and-Spoke Topology

How nerdy is that for a blog post title?   🙂

I’ve run up against this issue twice now.  The issue seems to be an order-of-operations issue in IOS with PPPoFR in a hub-and-spoke network running OSPF network type point-to-multipoint.  This is most likely something that you’ll (hopefully) never see in a real network.  If you do, then kick the router (and the architect) really hard and run away quickly.

In this case we’ve configured PPPoFR with R5 as the hub and R1 and R2 as the spokes.  On R5 we have two PPP circuits assigned – one assigned to each hub DLCI – to a single virtual-template.  Something like this:

r5:
int s0/0.1 multipoint <- just to make it more “interesting”   🙂
 frame-relay interface-dlci 501 ppp virtual-template 1
 frame-relay interface-dlci 502 ppp virtual-template 1

Everything was cool until I configured OSPF and noticed that I wasn’t seeing routes from r2:

RSRack12R5#sh ip route os
     128.8.0.0/16 is variably subnetted, 9 subnets, 2 masks
O IA    128.8.136.0/24 [110/2] via 128.8.125.1, 00:39:59, Virtual-Access2
O IA    128.8.63.0/24 [110/11113] via 128.8.125.1, 00:22:43, Virtual-Access2

Looking at the individual routes it looks like the router is sending traffic to r2 which should be going to r1:

RSRack12R5#sh ip route 128.8.136.0
Routing entry for 128.8.136.0/24
  Known via “ospf 100”, distance 110, metric 2, type inter area
  Last update from 128.8.125.1 on Virtual-Access2, 00:40:10 ago
  Routing Descriptor Blocks:
  * 128.8.125.1, from 150.8.1.1, 00:40:10 ago, via Virtual-Access2
      Route metric is 2, traffic share count is 1

RSRack12R5#sh ip route 128.8.125.1
Routing entry for 128.8.125.1/32
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Virtual-Access1
      Route metric is 0, traffic share count is 1

RSRack12R5#sh int virtual-access 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 128.8.125.5/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0x44
  Bound to Serial0/0.1 DLCI 502, Cloned from Virtual-Template1, loopback not set <-502 is r2
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:12, output never, output hang never
  Last clearing of “show interface” counters 02:09:09
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7938 packets input, 609028 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     7949 packets output, 604952 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

RSRack12R5#p 128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 28 msec 32 msec  <-should go to r1
  2  *

An IP packet debug on r5 shows that the IOS does see any problems with shipping the wrong packets to r2:

Sep  4 07:38:04.065: IP: tableid=0, s=128.8.125.5 (local), d=128.8.136.3 (Virtual-Access2), routed via FIB
Sep  4 07:38:04.069: IP: s=128.8.125.5 (local), d=128.8.136.3 (Virtual-Access2), len 100, sending
Sep  4 07:38:04.069:     ICMP type=8, code=0

It looks like the virtual-access interfaces are associated with the wrong DLCIs.  I tried a reload – no change.

I ripped out PPPoFr and readded it:

RSRack12R5#sh ip int br | i Virtu
Virtual-Access1            128.8.125.5     YES TFTP   up                    up

Virtual-Template1          128.8.125.5     YES NVRAM  down                  down

Virtual-Access2            128.8.125.5     YES TFTP   up                    up

Virtual-Access3            unassigned      YES unset  down                  down

RSRack12R5#sh int virtual-acc 1 | i Bound
  Bound to Serial0/0.1 DLCI 501, Cloned from Virtual-Template1, loopback not set
RSRack12R5#sh int virtual-acc 2 | i Bound
  Bound to Serial0/0.1 DLCI 502, Cloned from Virtual-Template1, loopback not set
RSRack12R5#sh int virtual-acc 3 | i Bound
RSRack12R5#

RSRack12R5#sh ip route 128.8.136.3
Routing entry for 128.8.136.0/24
  Known via “ospf 100”, distance 110, metric 2, type inter area
  Last update from 128.8.125.1 on Virtual-Access2, 00:02:18 ago
  Routing Descriptor Blocks:
  * 128.8.125.1, from 150.8.1.1, 00:02:18 ago, via Virtual-Access2  <- should use virtual-access1
      Route metric is 2, traffic share count is 1

Same issue:

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 28 msec 32 msec  <-should go to r1
  2  *  *

The IOS is up to date:

RSRack12R5#sh ver | i IOS|emo
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10), RELEASE SOFTWARE (fc1)
Cisco 2611XM (MPC860P) processor (revision 3.1) with 127308K/3764K bytes of memory.

I gave up.  I did go back and check my config line by line and everything was in agreement with the IE solution guide.  I looked in my notes and I did not encounter this issue on my last attempt at this lab.  If this were the actual lab I guess that I would rip out the PPPoFR configuration and just use a conventional hub-and-spoke FR network and eat the PPPoFR points.

It appears that I’m not the only person to run up against this issue:

It looks like the fixes are:

1) Reorder the frame-relay maps:

I did that, but IOS puts them back in order:

interface Serial0/0.1 multipoint
 frame-relay interface-dlci 501 ppp Virtual-Template1
 frame-relay interface-dlci 502 ppp Virtual-Template1

But for some reason it fixed the issue:

RSRack12R5#p 128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.1 28 msec 32 msec 29 msec
  2 128.8.136.3 32 msec *  40 msec

This fix does my fucking head in.  I actually stripped out the PPPoFR configuration before and then readded it.  The actual ORDER of configuration is important?  Even though IOS reorders the configuration lines automatically?

Unfortunately this “fix” does not survive a reload:

After reload:
RSRack12R5#p  128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:

Success rate is 0 percent (0/3)

RSRack12R5#trace  128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 32 msec 28 msec
  2
RSRack12R5#

2) Create a separate virtual-template for each DLCI (I think that this is what I did the first time that I ran through this lab).

interface Serial0/0.1 multipoint
frame-relay interface-dlci 501ppp Virtual-Template1
frame-relay interface-dlci 502ppp Virtual-Template2

interface Virtual-Template1
ip address 128.1.125.5 255.255.255.0
ip ospf network point-to-multipoint
!
interface Virtual-Template2
ip address 128.1.125.5 255.255.255.0
ip ospf network point-to-multipoint

RSRack12R5#sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.8.2.2         0   FULL/  –        00:01:59    128.8.125.2     Virtual-Access2
150.8.1.1
         0   FULL/  –        00:01:59    128.8.125.1     Virtual-Access1

Did not work:

RSRack12R5#p  128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

RSRack12R5#trace  128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.228 msec 32 msec 33 msec
  2
RSRack12R5#

But if I switch the virtual-template assignment (as suggested in the forum)……still more failure:

interface Serial0/0.1 multipoint
 frame-relay interface-dlci 501ppp Virtual-Template2
 frame-relay interface-dlci 502ppp Virtual-Template1

RSRack12R5#p 128.8.136.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.8.136.3, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)

RSRack12R5#trace 128.8.136.3

Type escape sequence to abort.
Tracing the route to 128.8.136.3

  1 128.8.125.229 msec 28 msec 32 msec
  2

Brian Dennis stated that the proctors do not reload your routers before grading, so I guess that I have to count on that being the case if I run across this issue in the lab.

I ran across the same issue on an IPexpert lab (mock lab 3).  I was only getting routes from one spoke in a PPPoFR PPP multilink point-to-multipoint OSPF network…with a fucking virtual link thrown in just to increase the nerdtastic design.  I had to flip the multilink assignment of (many!) frame-relay interfaces and that got is cooking once again:

interface Serial0/1/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 205 ppp Virtual-Template2
 frame-relay interface-dlci 206 ppp Virtual-Template1
 frame-relay interface-dlci 215 ppp Virtual-Template2
 frame-relay interface-dlci 216 ppp Virtual-Template1
 frame-relay interface-dlci 225 ppp Virtual-Template2
 frame-relay interface-dlci 226 ppp Virtual-Template1

no frame-relay interface-dlci 205 ppp Virtual-Template2
no frame-relay interface-dlci 206 ppp Virtual-Template1
no frame-relay interface-dlci 215 ppp Virtual-Template2
no frame-relay interface-dlci 216 ppp Virtual-Template1
no frame-relay interface-dlci 225 ppp Virtual-Template2
no frame-relay interface-dlci 226 ppp Virtual-Template1

frame-relay traffic-shaping
frame-relay interface-dlci 205 ppp Virtual-Template1
frame-relay interface-dlci 206 ppp Virtual-Template2
frame-relay interface-dlci 215 ppp Virtual-Template1
frame-relay interface-dlci 216 ppp Virtual-Template2
frame-relay interface-dlci 225 ppp Virtual-Template1
frame-relay interface-dlci 226 ppp Virtual-Template2

September 18, 2008

I’m NOT Gonna Be Your RP Sucker!

Filed under: Cisco,Cisco Certification,IOS — cciepursuit @ 11:16 am
Tags: , , , ,

The IOS has finally grown sick of me and rebelled (albeit in a very polite way):

Sep 17 15:48:36.829: %PIM-1-INVALID_RP_REG: Received Register from router 176.21.35.5 for group 239.3.1.1, 150.21.3.3 not willing to be RP.

I tried bribing it, bullying it, and complimenting it…but it was still not willing to be my RP.  😦

September 17, 2008

EIGRP Offset-Lists and Show IP Protocols

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 8:12 am
Tags: , , , , ,

It’s funny how you may have done a task many times and not noticed an IOS feature.  I applied an offset-list to some EIGRP routes and stumbled across some output I had never noticed before (to be fair I usually use offset-lists with RIP and not EIGRP):

No EIGRP offset-list(s) applied:

Rack17SW1#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.27.2           90      00:24:46
    156.17.67.6           90      00:24:46
  Distance: internal 90 external 170

With the offset-lists applied (different paths based on whether the 3rd octet is even or odd):

router eigrp 10
 timers active-time 5
 offset-list ODD in 666666666 Vlan18
 offset-list EVEN in 666666666 Vlan58

 network 0.0.0.0
 no auto-summary
!
ip access-list standard EVEN
 permit 0.0.0.0 255.255.254.255
ip access-list standard ODD
 permit 0.0.1.0 255.255.254.255

Notice the difference?  🙂

Rack17SW2#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Incoming routes in Vlan18 will have 666666666 added to metric if on list ODD
  Incoming routes in Vlan58 will have 666666666 added to metric if on list EVEN

  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.18.1           90      00:17:55
    156.17.58.5           90      00:17:55
  Distance: internal 90 external 170

September 15, 2008

Disabling EIGRP Unequal-Cost Load-Balancing

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 6:53 am
Tags: , , , , ,

This may be old news to you guys but I had never seen the “traffic-share min across-interfaces” command before.  I was messing about with EIGRP unequal cost load-sharing the other day and came across it.

r1(config-router)#traffic-share ?
  balanced  Share inversely proportional to metric
  min       All traffic shared among min metric paths <-what’s this?

r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config-router)#traffic-share min across-interfaces

Weird.  It turns off unequal-cost load balancing by not allowing traffic over the Feasable Successor route(s) regardless of the variance command:

r1(config-router)#var 4
*Mar  2 00:05:02.000: %FIB-4-UNEQUAL: Range of unequal path weightings too large for prefix 150.1.6.0/24. Some available paths may not be used.

r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
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:03 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:03 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      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:03 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

r1(config-router)#var 40
r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
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:02 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:02 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      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:02 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Here’s the explanation:

Similarly, when you use the traffic-share command with the keyword min, the traffic is sent only across the minimum-cost path, even when there are multiple paths in the routing table.

router eigrp 1
 network x.x.x.x
 variance 3
 traffic-share min across-interfaces

In this situation, EIGRP sends packets only through E-C-A, which is the best path to the destination network. This is identical to the forwarding behavior without use of the variance command. However, if you use the traffic-share min command and the variance command, even though traffic is sent over the minimum-cost path only, all feasible routes get installed into the routing table, which decreases convergence times. 

It turns out that this command is available for all routing protocols.

r1(config)#router os 100
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config)#router rip
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths

September 8, 2008

Hey R6! Quit Your Complaining!!!

Filed under: Cisco,Cisco Certification,IOS — cciepursuit @ 8:46 pm
Tags: , , , ,

To turn logging of MOSPF LSAs (type-6) you need to tell the router to ignore these LSAs.  I get a kick out of the verbiage of the help message:

Rack10R6(config)#router os 100
Rack10R6(config-router)#ignore ?
  lsa  Do not complain upon receiving LSA of the specified type

“Thank you kind sir.  Now I shan’t complain upon receiving these dastardly type-6 LSAs.”

Next Page »

Create a free website or blog at WordPress.com.