Why can’t I ping btw different IP subnets on same VLAN!

October 21, 2008 at 6:19 pm | Posted in IP Services, Routing | 1 Comment

I came accross an interesting question, where we have a two routers, on the same VLAN, but are configured with IP belonging to different subnets(e.g 101.1.1.1/24 on one router and 102.1.1.1/24 on another router). No matter we configure static routes and proxy-arp, local proxy-arp, the two routers still cannot ping each other!

Here is the reason behind it.

By default, when routing is enabled, routers will not respond to arp requests from stations whose source IP addresses are not on the IP subnet that receives the request, regardless of whether proxy arp or local proxy arp is enabled or not.

When R1 try to ARP for R2 IP address, R2 will see the ARP comes from 101.1.1.1 on the interface that has IP of 102.1.1.1/24, and will ignore it.

R2#

*Mar  1 06:39:11.166: IP ARP req filtered src 101.1.1.1 0000.1111.1111, dst 101.1.1.2 0000.0000.0000 wrong cable, interface FastEthernet0/0
To disable this sanity check, you will have to use any of the following solutions:

1. Static ARP

R2#
arp 101.1.1.1 0000.1111.1111 arpa

2. Local Area Mobility (LAM)

R2#
interface FastEthernet0/0
mac-address 0000.2222.2222
ip address 102.1.1.1 255.255.255.0
ip mobile arp

See the debug message that R2 now does not complain any more about ARP from wrong subnet!
R2#
*Mar  1 06:43:15.334: IP ARP: rcvd req src 101.1.1.1 0000.1111.1111, dst 102.1.1.1 FastEthernet0/0 *Mar  1 06:43:15.334: IP ARP: sent rep src 102.1.1.1 0000.2222.2222,
dst 101.1.1.1 0000.1111.1111 FastEthernet0/0

3. Disable routing on both routers.

4. Configure secondary IP address.

The Local Proxy Arp or Proxy Arp are not required here.

– Local proxy arp is used, so that a router can work as proxy for two hosts on the same subnet, which normally can not communicate directly (e.g. Private VLAN or on protected port).

– Proxy arp (on by default) is used so that router responds on any ARP for subnets outside LAN subnet (e.g. when you have a default static route on R1 pointing to e0/0, instead of R2 LAN IP, you will need to enable R2 proxy arp (on by default).

As said above, both these options does not work in this case, because we have different IP subnets on the two routers, and by default, routers just ignore ARP request from each other.

Advertisements

OSPF capability transit

September 29, 2008 at 1:00 pm | Posted in OSPF, Routing | Leave a comment

OSPF area capability transit is enabled by default, allowing the OSPF Area Border Router to install better-cost routes to the backbone area through the transit area instead of the virtual links.

If you want to retain a traffic pattern through the virtual-link path, you can disable capability transit by entering the no capability transit command. If paths through the transit area are discovered, they are most likely to be more optimal paths, or at least equal to, the virtual-link path. To reenable capability transit, enter the capability transit command.

If you need to verify whether OSPF area capability transit is enabled for a specific routing process, enter the show ip ospf command.

DOC CD Navigation

  • Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4
  • Part 5: OSPF
  • OSPF Area Transit Capability

Also we can look up in the Command Reference.

Weird RIP metric behavior

September 10, 2008 at 2:34 pm | Posted in RIP, Routing | Leave a comment

RIP metric automatically gets increased by one when we do interface summarisation for routes redistributed from other routing protocols.

This is interesting observation. I have never noticed it before.

I now also notice that the metric gets increased by 1 when these two conditions must meet

– manual interface summarization
– this is summary route for routes that you redistribute from other protocols (e.g. OSPF, static)

This means, if you do manual summary for RIP routes, then the metric is equal to the minimum metric amongh more specific routes, and NOT the minimum metric + 1.

Also, when you enable Auto-Summary, the metric of summary-route for prefixes redistributed from other protocols does not get increased by 1 automatically.

This could well a bug!

In a real lab, if the task asks for a specific metric, and you can not make the metric for redistributed routes, and the summary route the same using interface summary command, then remember that you may meet the task requirement by leaving the AutoSummary ON – an option that we normally overlook.

Configuration & Observation

      OSPF         RIP
R1 --------- R3 ----------- R2
        S2/2   S2/3

R3#
interface Loopback0
 ip address 3.3.3.3 255.255.255.0

interface Serial2/2
 ip address 13.0.0.3 255.255.255.0

interface Serial2/3
 ip address 23.0.0.3 255.255.255.0
 ip summary-address rip 1.0.0.0 255.0.0.0
 ip summary-address rip 3.3.0.0 255.255.0.0
!
router ospf 1
 network 13.0.0.3 0.0.0.0 area 0
!
router rip
 version 2
 redistribute static metric 3
 redistribute ospf 1 metric 10
 network 3.0.0.0
 network 23.0.0.0
 no auto-summary
!
ip route 33.33.33.0 255.255.255.0 Null0
!

R3#sh ip rip data
1.0.0.0/8    auto-summary
1.0.0.0/8    int-summary
1.1.1.0/24    redistributed
    [10] via 1.1.1.1, 
3.0.0.0/8    auto-summary
3.3.0.0/16    int-summary
3.3.3.0/24    directly connected, Loopback0
11.0.0.0/8    auto-summary
11.11.11.11/32    redistributed
    [10] via 1.1.1.1, 
13.0.0.0/8    auto-summary
13.0.0.0/24    directly connected, Serial2/2
23.0.0.0/8    auto-summary
23.0.0.0/24    directly connected, Serial2/3
33.0.0.0/8    auto-summary
33.33.33.0/24    redistributed
    [3] via 0.0.0.0, 

R2#sh ip route | b /
R    1.0.0.0/8 [120/11] via 23.0.0.3, 00:00:16, Serial0/1
     33.0.0.0/24 is subnetted, 1 subnets
R       33.33.33.0 [120/3] via 23.0.0.3, 00:00:16, Serial0/1
     3.0.0.0/16 is subnetted, 1 subnets
R       3.3.0.0 [120/1] via 23.0.0.3, 00:00:16, Serial0/1
     23.0.0.0/24 is subnetted, 1 subnets
C       23.0.0.0 is directly connected, Serial0/1
     11.0.0.0/32 is subnetted, 1 subnets
R       11.11.11.11 [120/10] via 23.0.0.3, 00:00:16, Serial0/1
     13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/10] via 23.0.0.3, 00:00:16, Serial0/1

R3#c
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router rip
R3(config-router)#auto-summary
R3(config-router)#
R3#
R3#

R3#sh ip rip data
1.0.0.0/8    auto-summary
1.0.0.0/8    int-summary
1.1.1.0/24    redistributed
    [10] via 1.1.1.1, 
3.0.0.0/8    auto-summary
3.3.0.0/16    int-summary
3.3.3.0/24    directly connected, Loopback0
11.0.0.0/8    auto-summary
11.11.11.11/32    redistributed
    [10] via 1.1.1.1, 
13.0.0.0/8    auto-summary
13.0.0.0/24    redistributed
    [10] via 0.0.0.0, 
23.0.0.0/8    auto-summary
23.0.0.0/24    directly connected, Serial2/3
33.0.0.0/8    auto-summary
33.33.33.0/24    redistributed
    [3] via 0.0.0.0, 

R2#sh ip route | b /
R    1.0.0.0/8 [120/10] via 23.0.0.3, 00:00:04, Serial0/1
R    33.0.0.0/8 [120/3] via 23.0.0.3, 00:00:04, Serial0/1
R    3.0.0.0/8 [120/1] via 23.0.0.3, 00:00:04, Serial0/1
     23.0.0.0/24 is subnetted, 1 subnets
C       23.0.0.0 is directly connected, Serial0/1
R    11.0.0.0/8 [120/10] via 23.0.0.3, 00:00:04, Serial0/1
R    13.0.0.0/8 [120/10] via 23.0.0.3, 00:00:04, Serial0/1

Twicking EIGRP metrics

September 2, 2008 at 5:35 pm | Posted in EIGRP, Routing | Leave a comment

What if I want to prefer one EIGRP path over the other? Changing metrics of course ;-)

R1 —- R3 —- R2

Both R1 and R2 advertized 100.0.0.0/8 toward R3, but R1 advertises a better metrics, hence a prefered path. I want to make R3 to chose path via R2 instead.

We can change bandwidth or delay on R3 interface. Note that EIGRP uses the minimum bandwidth of the path as one of the metrics (BW). So bumping up the BW for interface connecting to R3 might not actually doing me any good. If we check the show ip ei topo for the route, we might still see minimum bandwidth metric the unchanged for the path via Serial1/3. Instead

  • We can decrease bandwidth of Serial1/2 to let say 56K.
  • Alternatively, you can give Serial1/3 a very high delay.
  • Another option is to use offset-list

Here’s metric before the change

R3#sh ip ei topology 100.0.0.0/8
IP-EIGRP (AS 100): Topology entry for 100.0.0.0/8
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2244096
  Routing Descriptor Blocks:
  13.0.0.1 (Serial1/2), from 13.0.0.1, Send flag is 0x0
      Composite metric is (2244096/1732096), Route is External
      Vector metric:
        Minimum bandwidth is 1500 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 13.0.0.1 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)
  23.0.0.2 (Serial1/3), from 23.0.0.2, Send flag is 0x0
      Composite metric is (5537536/5025536), Route is External
      Vector metric:
        Minimum bandwidth is 512 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 23.0.0.2 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

R3#sh ip route ei
D EX 100.0.0.0/8 [170/2244096] via 13.0.0.1, 00:02:55, Serial1/2

Offset-list configuration

access-list 99 permit 100.0.0.0 0.255.255.255
router eigrp 100
 offset-list 99 in 5000000 Serial1/2
R3#sh ip eigrp topology 100.0.0.0/8
IP-EIGRP (AS 100): Topology entry for 100.0.0.0/8
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5537536
  Routing Descriptor Blocks:
  23.0.0.2 (Serial1/3), from 23.0.0.2, Send flag is 0x0
      Composite metric is (5537536/5025536), Route is External
      Vector metric:
        Minimum bandwidth is 512 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 23.0.0.2 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)
  13.0.0.1 (Serial1/2), from 13.0.0.1, Send flag is 0x0
      Composite metric is (7244096/6732096), Route is External
      Vector metric:
        Minimum bandwidth is 1500 Kbit
        Total delay is 216312 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 13.0.0.1 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

R3#sh ip route ei
D EX 100.0.0.0/8 [170/5537536] via 23.0.0.2, 00:01:21, Serial1/3

Reliable policy based routing

August 31, 2008 at 5:16 pm | Posted in Protocol independent, Routing | 1 Comment

Policy based routing with next hop reachability verification via CDP and via enhanced object tracking.

Sample Configuration:

!
!
!
! Track next hop R4 reachibility
ip sla monitor 4
 type echo protocol ipIcmpEcho 155.1.146.4 source-ipaddr 155.1.146.1
 timeout 2000
 frequency 5
ip sla monitor schedule 4 start-time now
!
track 4 rtr 4
!
!
!
interface FastEthernet0/0
 ip address 155.1.146.1 255.255.255.0
!
interface Serial0/0
 ip address 155.1.0.1 255.255.255.0
 encapsulation frame-relay
! enable CDP to check if R5 is availble.
 cdp enable
 frame-relay map ip 155.1.0.5 105 broadcast
 no frame-relay inverse-arp
!
interface Serial0/1
 ip address 155.1.13.1 255.255.255.0
 ip policy route-map POLICY
 clock rate 56000
!
!
ip access-list extended TO_R4
 permit ip any 150.1.4.0 0.0.0.255
ip access-list extended TO_R5
 permit ip any 150.1.5.0 0.0.0.255
!
! By default CDP is sent every 60sec, and neighbor only decleared
! dead after a holdtime of 180sec. Setting CDP timers to quicken convergence
cdp timer 5
cdp holdtime 15
!
!
! This first statement shows tracking via CDP
route-map POLICY permit 10
 match ip address TO_R4
 set ip next-hop 155.1.0.5
 set ip next-hop verify-availability
 set ip default next-hop 155.1.146.4
!
! This second statement shows tracking via enhanced object
route-map POLICY permit 20
 match ip address TO_R5
 set ip next-hop verify-availability 155.1.146.4 1 track 4
 set ip default next-hop 155.1.0.5
!

Verification:
Rack1R3#ping 150.1.4.4 rep 1

Rack1R1#debug track
Rack1R1#debug ip policy
Rack1R1#
*Mar  1 01:19:58.887: IP: s=155.1.13.3 (Serial0/1), d=150.1.4.4, len 100, FIB policy match
*Mar  1 01:19:58.887: IP: s=155.1.13.3 (Serial0/1), d=150.1.4.4, g=155.1.0.5, len 100, FIB policy routed

! Shutdown R5 Serial0 frame interface.

Rack1R1#sh cdp nei | in R5
Rack1R1#

*Mar  1 01:21:47.071: IP: s=155.1.13.3 (Serial0/1), d=150.1.4.4, len 100, FIB policy match
*Mar  1 01:21:47.071: IP: s=155.1.13.3 (Serial0/1), d=150.1.4.4, g=155.1.146.4, len 100, FIB policy routed

! Bringback R5 Serial0 frame interface
Rack1R1#sh cdp nei | in R5
Rack1R5          Ser 0/0            14          R S       1721      Ser 0

Rack1R3#ping 150.1.5.5 rep 1

Rack1R1#
*Mar  1 01:23:06.019: IP: s=155.1.13.3 (Serial0/1), d=150.1.5.5, len 100, FIB policy match
*Mar  1 01:23:06.019: IP: s=155.1.13.3 (Serial0/1), d=150.1.5.5, g=155.1.146.4, len 100, FIB policy routed

! Shutdown R4 ethernet interface.

Rack1R1#
*Mar  1 01:25:41.151: Track: 4 Change #2 rtr 4, state Up->Down

*Mar  1 01:25:55.471: IP: s=155.1.13.3 (Serial0/1), d=150.1.5.5, len 100, FIB policy match
*Mar  1 01:25:55.471: IP: s=155.1.13.3 (Serial0/1), d=150.1.5.5, g=155.1.0.5, len 100, FIB policy routed
Doc CD Navigation

  • Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4
  • Part 6: Protocol-Independent Routing
  • PBR Support for Multiple Tracking Options

Weird behavior: Redistribution with Route-map from OSPF to RIP

August 13, 2008 at 11:17 am | Posted in Blogroll, OSPF, Routing | Leave a comment

It is observed that if we do OSPF to RIP redistribution (or EIGRP as well, even though I have not tested with EIGRP yet) without route-map, then we introduce a route-map, e.g. to filter routes, the route-map will only take place for OSPF routes that have been bounced, removed or newly learnt. We can bounce routes by resetting OSPF process (this change only impact routes learnt from neighbors, but not the connected routes) and/or bouncing the interface

Here’s the detailed observation
Topology:

R1 ——- R3 ——- R2

OSPF Area0  |   RIP

R1#sh ver | in IOS
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(17a), RELEASE SOFTWARE (fc2)

R1#

interface Loopback71
ip address 77.1.1.1 255.255.255.0
!
interface Loopback72
ip address 77.1.2.1 255.255.255.0
!
interface Loopback73
ip address 77.1.3.1 255.255.255.0
!
interface Loopback77
ip address 77.77.77.1 255.255.255.0
ip ospf network point-to-point
!
interface Serial1/1
description Connection to R3
ip address 13.0.0.1 255.255.255.0
!
!
router ospf 1
log-adjacency-changes
area 1 range 77.0.0.0 255.0.0.0
network 13.0.0.1 0.0.0.0 area 0
network 77.1.0.0 0.0.255.255 area 1
network 77.77.77.1 0.0.0.0 area 77

R3#

!
interface Serial1/2
description Connection to R1
ip address 13.0.0.3 255.255.255.0
!
interface Serial1/3
description Connection to R2
ip address 23.0.0.3 255.255.255.0
serial restart-delay 0
!
router ospf 1
network 13.0.0.3 0.0.0.0 area 0
!
router rip
version 2
redistribute ospf 1 metric 1 route-map OSPF->RIP
passive-interface default
network 23.0.0.0
neighbor 23.0.0.2
no auto-summary
!
!
!
ip prefix-list SUMMARY seq 5 permit 77.0.0.0/8
ip prefix-list SUMMARY seq 10 deny 0.0.0.0/0 le 32
!
route-map OSPF->RIP permit 10
match ip address prefix-list SUMMARY
!
route-map OSPF->RIP deny 20

R2#

interface Serial1/1
description Connection to R3
ip address 23.0.0.2 255.255.255.0
!
router rip
version 2
passive-interface default
network 23.0.0.0
neighbor 23.0.0.3
no auto-summary

This configuration result in only summary route being received on R2, as expected.

R2#sh ip route rip
R    77.0.0.0/8 [120/1] via 23.0.0.3, 00:00:18, Serial1/1

R3 has a summary route 77.0.0.0 and a specific 77.77.77.0 (both are learnt from R1)

R3#sh clock
08:59:34.219 UTC Wed Aug 13 2008
R3#sh ip route ospf
77.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA    77.77.77.0/24 [110/65] via 13.0.0.1, 00:00:18, Serial1/2
O IA    77.0.0.0/8 [110/65] via 13.0.0.1, 00:16:07, Serial1/2

If we advertize OSPF to RIP without the route-map, we will see that the specific route is also shown up on R2 (almost immediately)

R3#sh clock
09:05:28.035 UTC Wed Aug 13 2008

R3(config)#router rip
R3(config-router)#no  redistribute ospf 1 metric 1 route-map OSPF->RIP
R3(config-router)#redistribute ospf 1 metric 1

R2#sh clock
09:05:43.919 UTC Wed Aug 13 2008
R2#sh ip route rip
77.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       77.77.77.0/24 [120/1] via 23.0.0.3, 00:00:01, Serial1/1
R       77.0.0.0/8 [120/1] via 23.0.0.3, 00:00:01, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:01, Serial1/1

If we reapply the route-map, the specific route stay on !!!

R3#sh clock
09:07:34.755 UTC Wed Aug 13 2008
R3#c
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router rip
R3(config-router)#redistribute ospf 1 metric 1 route-map OSPF->RIP
R3(config-router)#

R2#sh clock
09:09:29.383 UTC Wed Aug 13 2008
R2#sh ip route rip
77.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       77.77.77.0/24 [120/1] via 23.0.0.3, 00:00:22, Serial1/1
R       77.0.0.0/8 [120/1] via 23.0.0.3, 00:00:22, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:22, Serial1/1
R2#sh clock
09:09:57.151 UTC Wed Aug 13 2008
R2#sh ip route rip
77.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       77.77.77.0/24 [120/1] via 23.0.0.3, 00:00:21, Serial1/1
R       77.0.0.0/8 [120/1] via 23.0.0.3, 00:00:21, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:21, Serial1/1
R2#sh clock
09:11:36.359 UTC Wed Aug 13 2008
R2#sh ip route rip
77.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       77.77.77.0/24 [120/1] via 23.0.0.3, 00:00:11, Serial1/1
R       77.0.0.0/8 [120/1] via 23.0.0.3, 00:00:11, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:11, Serial1/1


The specific route stays on until I bounce the route.

R1(config-if)#int lo77
R1(config-if)#shut
Aug 13 09:12:46.815: %LINK-5-CHANGED: Interface Loopback77, changed state to administratively down
Aug 13 09:12:47.819: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback77, changed state to down
R1(config-if)#no shut
R1(config-if)#
Aug 13 09:12:51.963: %LINK-3-UPDOWN: Interface Loopback77, changed state to up
Aug 13 09:12:52.963: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback77, changed state to up

R2#sh ip route rip
77.0.0.0/8 is subnetted, 1 subnets
R       77.0.0.0 [120/1] via 23.0.0.3, 00:00:09, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:09, Serial1/1

Note that after I bounce the interface on R1, only the affected route (77.77.77.0/24 disapears from routing table on R2, as R3 does not sends it anymore). The 13.0.0.0/24 still stays on, (i.e. this unaffected route is not subject to the new route-map).

R3#sh ip route ospf
77.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA    77.77.77.0/24 [110/65] via 13.0.0.1, 00:05:49, Serial1/2
O IA    77.0.0.0/8 [110/65] via 13.0.0.1, 00:33:45, Serial1/2

R3#debug  ip rip
RIP protocol debugging is on
Aug 13 09:21:39.387: RIP: sending v2 update to 23.0.0.2 via Serial1/3 (23.0.0.3)
Aug 13 09:21:39.391: RIP: build update entries
Aug 13 09:21:39.391:    13.0.0.0/24 via 0.0.0.0, metric 1, tag 0
Aug 13 09:21:39.395:    77.0.0.0/8 via 0.0.0.0, metric 1, tag 0
Aug 13 09:21:39.395: RIP: Update contains 2 routes
Aug 13 09:21:39.399: RIP: Update queued
Aug 13 09:21:39.399: RIP: Update sent via Serial1/3

R2#sh clock
09:16:28.351 UTC Wed Aug 13 2008
R2#sh ip route rip
77.0.0.0/8 is subnetted, 1 subnets
R       77.0.0.0 [120/1] via 23.0.0.3, 00:00:23, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:23, Serial1/1
R2#sh clock
09:16:45.031 UTC Wed Aug 13 2008
R2#sh ip route rip
77.0.0.0/8 is subnetted, 1 subnets
R       77.0.0.0 [120/1] via 23.0.0.3, 00:00:14, Serial1/1
13.0.0.0/24 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 23.0.0.3, 00:00:14, Serial1/1

If I remove the route-map and put it back in, we can see again that R3 continues to advertize all routes to RIP, NOT subject to the route-map

R3(config)#router rip
R3(config-router)#no redistribute ospf 1 metric 1 route-map OSPF->RIP
R3(config-router)#redistribute ospf 1 metric 1
R3(config-router)#redistribute ospf 1 metric 1 route-map OSPF->RIP

Aug 13 09:24:51.883: RIP: sending v2 update to 23.0.0.2 via Serial1/3 (23.0.0.3)
Aug 13 09:24:51.887: RIP: build update entries
Aug 13 09:24:51.887:    13.0.0.0/24 via 0.0.0.0, metric 1, tag 0
Aug 13 09:24:51.891:    77.0.0.0/8 via 0.0.0.0, metric 1, tag 0
Aug 13 09:24:51.891:    77.77.77.0/24 via 0.0.0.0, metric 1, tag 0
Aug 13 09:24:51.895: RIP: Update contains 3 routes
Aug 13 09:24:51.895: RIP: Update queued
Aug 13 09:24:51.899: RIP: Update sent via Serial1/3

If we clear OSPF process, we can see that only OSPF routes affected by the OSPF adjacency reset are subject to the route-map. The connected route (part of OSPF database), will still being advertized to RIP without being subject to the route-map.

R3#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R3#
Aug 13 09:31:25.135: RIP: sending v2 update to 23.0.0.2 via Serial1/3 (23.0.0.3)
Aug 13 09:31:25.139: RIP: build update entries
Aug 13 09:31:25.139:    13.0.0.0/24 via 0.0.0.0, metric 1, tag 0
Aug 13 09:31:25.143:    77.0.0.0/8 via 0.0.0.0, metric 1, tag 0

Now if we bounce the connected interface, we can see that it will be blocked by the route-map, and it will no longer be redistributed to RIP.

R3#c
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int serial1/2
R3(config-if)#shut
Aug 13 09:33:02.771: %OSPF-5-ADJCHG: Process 1, Nbr 13.0.0.1 on Serial1/2 from FULL to DOWN, Neighbor Down: Interface down or detached
Aug 13 09:33:04.735: %LINK-5-CHANGED: Interface Serial1/2, changed state to administratively down

R3(config-if)#no shut
R3#
Aug 13 09:34:11.847: RIP: sending v2 update to 23.0.0.2 via Serial1/3 (23.0.0.3)
Aug 13 09:34:11.851: RIP: build update entries
Aug 13 09:34:11.851:    77.0.0.0/8 via 0.0.0.0, metric 1, tag 0

R2#sh clock
09:34:50.047 UTC Wed Aug 13 2008
R2#sh ip route rip
R    77.0.0.0/8 [120/1] via 23.0.0.3, 00:00:13, Serial1/1

Redistribution note – Lab 11 Task 3.9

August 10, 2008 at 3:15 pm | Posted in Blogroll, EIGRP, OSPF, Routing | Leave a comment

If an interface is redistributed into OSPF, then if we redistribute from OSPF -> EIGRP, then the interface is not automatically redistributed into EIGRP. We have to manually redistribute the connected interface into EIGRP.

RSRack1R5#srsr
router eigrp 10

redistribute ospf 1 metric 1 1 1 1 1 route-map OSPF_TO_EIGRP

router ospf 1
redistribute connected subnets route-map CONNECTED_TO_OSPF
redistribute eigrp 10 subnets route-map EIGRP_TO_OSPF

In this config, the CONNECTED_TO_EIGRP is missing. As the result, R6 will not see R5 Loop0. The R2 also learns an sub-optimal route of R5 loopback via R3 OSPF route, instead of from R5 directly.

RIP (or any other IGP) route filtering using Extended ACL

August 3, 2008 at 3:53 pm | Posted in Routing | Leave a comment

This example is to prevent the route 150.1.7.0/24 learnt via router 155.1.0.1 off interface Serial0.

access-list 199 deny  ip host 155.1.0.1 host 150.1.7.0
access-list 199 permit ip any any

router rip
version 2
network 150.1.0.0
network 155.1.0.0
distribute-list 199 in Serial0
no auto-summary

I usually make mistake with creating extended ACL for this purpose. I do
tend to put learnt route as source address of ACL, before the gateway
(destination address). The right ACL should be created in the
reverse order, as above.

NOTE that:

Extended ACL when called as a distribute-list in IGP have a different meaning than in redistribution or as in BGP.

EIGRP Maximum Delay pitfall

July 24, 2008 at 5:55 pm | Posted in EIGRP, Routing | Leave a comment

Setting interface delay to a maximum number will have undesired effect on the routing. You would normally expect that setting it to the max value, EIGRP will unfavor the path via  that link. It is not always the case. I think this is because when exceeding a certain integer number, the metric will be offset back to a small number, and is actually preferred.

Similar weid behavior is observed in OSPF virtual link path cost too. If you set the the “exiting” interface of the router with virtual link the to max of 65535, virtual link wont come up. However, it is OK to set ANY transit link to this maximum value, and the virtual link is fine. That weid things make IOS so beautifull, and attractive ;)

Here again is example of the weird EIGRP behaviour when setting the link delay to max.

IE WB – VOL1 – ver5, Task 5.14

Default Interface Delay

Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 10 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256
Routing Descriptor Blocks:
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (128256/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1

EIGRP is well behaving when Interface Delay is set to 1sec.

Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#int vlan 67
Rack1SW1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Rack1SW1(config-if)#delay 100000
Rack1SW1(config-if)#end
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
02:09:19: %SYS-5-CONFIG_I: Configured from console by console
Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 1000000 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 668160
Routing Descriptor Blocks:
155.1.37.3 (FastEthernet0/3), from 155.1.37.3, Send flag is 0x0
Composite metric is (668160/642560), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit

Total delay is 26100 microseconds ! via other path

Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (25728000/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 1005000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1
Rack1SW1#sir 150.1.6.6
Routing entry for 150.1.6.0/24
Known via “eigrp 100”, distance 90, metric 668160, type internal
Redistributing via eigrp 100
Last update from 155.1.37.3 on FastEthernet0/3, 00:00:52 ago
Routing Descriptor Blocks:
* 155.1.37.3, from 155.1.37.3, 00:00:52 ago, via FastEthernet0/3
Route metric is 668160, traffic share count is 1
Total delay is 26100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3

EIGRP (or IOS??) is a bad boy when Interface Delay is set to Maximum.


Rack1SW1#
Rack1SW1#
Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#int vlan 67
Rack1SW1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Rack1SW1(config-if)#delay 16777215
Rack1SW1(config-if)#
Rack1SW1#conf t
02:10:40: %SYS-5-CONFIG_I: Configured from console by console
Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 167772150 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 127744
Routing Descriptor Blocks:
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (127744/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 4990 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1
Rack1SW1#sir 150.1.6.6
Routing entry for 150.1.6.0/24
Known via “eigrp 100”, distance 90, metric 127744, type internal
Redistributing via eigrp 100
Last update from 155.1.67.6 on Vlan67, 00:00:19 ago
Routing Descriptor Blocks:
* 155.1.67.6, from 155.1.67.6, 00:00:19 ago, via Vlan67
Route metric is 127744, traffic share count is 1
Total delay is 4990 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1504 bytes
Loading 1/255, Hops 1

Verifying EIGRP Weight Metric

July 24, 2008 at 5:14 pm | Posted in EIGRP, Routing | Leave a comment

By default K1 = K3 = 1. All others weight metric are 0. This means, only bandwidth and delays are used in the EIGRP metric equation.

The online IOS help does not provide much information as to what metric a certain K refers to (e.g. K1 refers to bandwidth whereas K3 refers to delay). The Doc CD command reference is the friend in the lab! Also, we can use the show ip protocol command to verify the weight setting.

Rack1R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R1(config)#router ei 100
Rack1R1(config-router)#metric weight ?
<0-8>  Type Of Service (Only TOS 0 supported)

Rack1R1(config-router)#metric weight 0 ?
<0-255>  K1

Rack1R1(config-router)#metric weight 0

Rack1R1#sh ip protocols
Routing Protocol is “eigrp 100”
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=0, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
150.1.0.0
155.1.0.0
Routing Information Sources:
Gateway         Distance      Last Update
(this router)         90      00:10:59
155.1.146.4           90      00:05:07
155.1.146.6           90      00:05:07
155.1.13.3            90      00:05:07
155.1.0.5             90      00:05:07
Distance: internal 90 external 170

Next Page »

Blog at WordPress.com.
Entries and comments feeds.