ヨタ助

携帯用ページ http://www.google.co.jp/gwt/x?u=http%3a%2f%2funipass.blogspot.com&btngo=go&source=wax&ie=utf-8&oe=utf-8

Friday, November 26, 2010

INE WB I: 6.39 OSPF Filtering with Administrative Distance

How the AD in router OSPF configuration mode.

If you want to not install 1 of 2 next hop candidates into routing table, need to use 255. Otherwise, all the source candidates will be installed in routing table, even if the AD which you configured larger AD value to specific source IP address.

Let's take a look an example here.

R5 is using OSPF and destination network is 155.1.67.0/24. Currently, R5 has 2 next hop candidates from 150.1.30.30 and 150.1.6.6. I want to not install 150.1.6.6 as a source IP address using AD filtering function.

If I use AD 120 or 254 to 150.1.6.6 as distance command that are lager than AD 110 which is default value of OSPF AD, both 150.1.30.30 and 150.1.6.6 will remain with the value of AD which I configured.

R5 Configuration
router ospf 1
 router-id 150.1.5.5
 log-adjacency-changes
 no discard-route internal
 area 0 range 150.1.0.0 255.255.252.0
 distribute-list 12 in
 distance 254 150.1.6.6 0.0.0.0 1
!
!
access-list 1 permit 155.1.67.0
!


#####
it's supposed that distance (AD) 254 will be applied to 155.1.67.0/24 network only coming from 150.1.6.6/32 using the commands above.
#####

However, the result will be like this. (both source IP addresses have distance 254)

Rack1R5#sh ip route 155.1.67.0
Routing entry for 155.1.67.0/24
  Known via "ospf 1", distance 254, metric 66, type inter area
  Last update from 155.1.0.1 on Serial0/0, 00:08:57 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.30.30, 00:08:57 ago, via Serial0/0
      Route metric is 66, traffic share count is 1
    155.1.0.1, from 150.1.6.6, 00:08:57 ago, via Serial0/0
      Route metric is 66, traffic share count is 1





So, in this kind of case, I need to use 255 as Administrative Distance.


router ospf 1
 distance 255 150.1.6.6 0.0.0.0 1


Rack1R5#sh ip route 155.1.67.0
Routing entry for 155.1.67.0/24
  Known via "ospf 1", distance 110, metric 66, type inter area
  Last update from 155.1.0.3 on Serial0/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.30.30, 00:00:02 ago, via Serial0/0
      Route metric is 66, traffic share count is 1

source IP of 150.1.6.6 was removed and only 150.1.30.30 with distance 110 will be shown.

INE WB I: 6.38 OSPF Filtering with Distribute-Lists

I don't have any problem with 150.1.1.1 when ping from SW2 and SW4.
However, with 150.1.2.2, packets were sent back and forth between R4 and R5.
It is caused by default route on R5 toward 2 interfaces on R4 (main Frame-relay and point-to-point serial i/f).

At this moment, I have no idea how to fix this. One of these might be a solution.
- break point-to-multipoint desing among R1 through R5 frame-relay backbone
- create direct neighbor relationship between R2 and R4, which means that R4 directly send R2 the packet coming from R5.
- simply just take out the filter on R5 which blocks to install 150.1.2.2/32 network from OSPF database. But it cannot be, because the question of 6.37 requires no change to previously configured distribute-list filter.


Traceroute from SW2
Rack1SW2#traceroute 150.1.1.1 ttl 1 4 ti 1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 155.1.58.5 4 msec 8 msec 4 msec
  2 155.1.0.4 12 msec 8 msec 8 msec
  3 155.1.146.1 8 msec *  28 msec
Rack1SW2#traceroute 150.1.2.2 ttl 1 4 ti 1

Type escape sequence to abort.
Tracing the route to 150.1.2.2

  1 155.1.58.5 4 msec 4 msec 8 msec
  2 155.1.0.4 4 msec 4 msec 4 msec
  3 155.1.0.5 8 msec 4 msec 8 msec
  4 155.1.0.4 8 msec 8 msec 8 mse

Routing Table on SW2
Rack1SW2#sh ip route 150.1.1.1
Routing entry for 150.1.0.0/22
  Known via "ospf 1", distance 110, metric 66, type inter area
  Last update from 155.1.58.5 on Vlan58, 01:09:10 ago
  Routing Descriptor Blocks:
  * 155.1.58.5, from 150.1.5.5, 01:09:10 ago, via Vlan58
      Route metric is 66, traffic share count is 1

Rack1SW2#sh ip route 150.1.2.2
Routing entry for 150.1.0.0/22
  Known via "ospf 1", distance 110, metric 66, type inter area
  Last update from 155.1.58.5 on Vlan58, 01:09:14 ago
  Routing Descriptor Blocks:
  * 155.1.58.5, from 150.1.5.5, 01:09:14 ago, via Vlan58
      Route metric is 66, traffic share count is 1






Routing Table on R5 and R4
 Rack1R5#sh ip route 150.1.1.1
% Subnet not in table
Rack1R5#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 1", distance 110, metric 1, candidate default path
  Tag 1, type extern 2, forward metric 64
  Last update from 155.1.45.4 on Serial0/1, 00:11:17 ago
  Routing Descriptor Blocks:
    155.1.45.4, from 150.1.4.4, 00:11:17 ago, via Serial0/1
      Route metric is 1, traffic share count is 1
      Route tag 1
  * 155.1.0.4, from 150.1.4.4, 00:11:17 ago, via Serial0/0
      Route metric is 1, traffic share count is 1
      Route tag 1


Rack1R4#sh ip route 150.1.2.2
Routing entry for 150.1.2.2/32
  Known via "ospf 1", distance 110, metric 129, type intra area
  Redistributing via rip
  Advertised by rip metric 1
  Last update from 155.1.0.5 on Serial0/0, 20:57:31 ago
  Routing Descriptor Blocks:
  * 155.1.45.5, from 150.1.2.2, 20:57:31 ago, via Serial0/1
      Route metric is 129, traffic share count is 1
    155.1.0.5, from 150.1.2.2, 20:57:31 ago, via Serial0/0
      Route metric is 129, traffic share count is 1

R5's configuration
router ospf 1
 router-id 150.1.5.5
 log-adjacency-changes
 no discard-route internal
 area 0 range 150.1.0.0 255.255.252.0
 distribute-list 12 in
!
access-list 12 deny   150.1.1.1
access-list 12 deny   150.1.2.2
access-list 12 permit any

Monday, November 08, 2010

Backup Interface with GNS3

configuring "backup interface" on frame-relay interface with GNS3, you need to modify the frame-relay command on primary "frame-relay" interface. The reason is that frame-relay sub-interface on router might not recognize end-to-end LMI using shutting down serial interface (neither main FR i/f or sub FR i/f).

In that case, you need to take "interface-dlci" command out from FR sub-interface.

Rack1R4(config)#int se0/0.1
Rack1R4(config-subif)#no frame-relay interface-dlci 405
Rack1R4(config-subif)#end
Rack1R4#
*Mar  1 00:47:30.111: BACKUP(Serial0/0.1): event = primary interface went down
*Mar  1 00:47:30.111: BACKUP(Serial0/0.1): changed state to "waiting to backup"
Rack1R4#
*Mar  1 00:47:30.539: %SYS-5-CONFIG_I: Configured from console by console
Rack1R4#
*Mar  1 00:47:33.111: BACKUP(Serial0/0.1): event = timer expired on primary
*Mar  1 00:47:33.139: BACKUP(Serial0/0.1): secondary interface (Serial0/1) made active
*Mar  1 00:47:33.143: BACKUP(Serial0/0.1): changed state to "backup mode"
Rack1R4#
*Mar  1 00:47:35.115: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Rack1R4#
*Mar  1 00:47:35.131: BACKUP(Serial0/1): event = secondary interface came up
*Mar  1 00:47:36.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

Rack1R4#sh backup          
Primary Interface   Secondary Interface   Status
-----------------   -------------------   ------
Serial0/0.1         Serial0/1             backup mode

 
Rack1R4#





If you want to bring backup i/f back to "normal operation" status, you need to put "interface-dlci" command back to original.

Floating Static route (with AD255)

floatint static routes with AD 255 does not work. Why??

Rack1R4#sh run | i ip route
ip route 150.1.5.0 255.255.255.0 155.1.45.5
ip route 150.1.5.0 255.255.255.0 Serial0/0.1 255
Rack1R4#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            204.12.1.4      YES NVRAM  up                    up     
Serial0/0                  unassigned      YES NVRAM  up                    up     
Serial0/0.1                155.1.0.4       YES NVRAM  up                    up     
FastEthernet0/1            155.1.146.4     YES NVRAM  up                    up     
Serial0/1                  155.1.45.4      YES NVRAM  administratively down down   
Loopback0                  150.1.4.4       YES NVRAM  up                    up     

 Rack1R4#sh ip route 150.1.5.0
% Subnet not in table



Rack1R4(config)#ip route 150.1.5.0 255.255.255.0 155.1.0.5 254

Rack1R4#sh ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "static", distance 254, metric 0
  Routing Descriptor Blocks:
  * 155.1.0.5
      Route metric is 0, traffic share count is 1

Saturday, November 06, 2010

Frame-Relay Point-to-point interface issue

## Topology ##
R5 --- FR --- R1 (s0/0.1 p2p)
           + --- R2 (s0/0.1 p2p)
* R5 uses s0/0 main i/f with frame-relay map
** using GNS3, Cisco 3745 and 12.4(15)T13 Advanced Enterprise

## Configurations ##
R1
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay lmi-type ansi
!
interface Serial0/0.1 point-to-point
 ip address 155.1.0.1 255.255.255.0
 snmp trap link-status

R2
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay lmi-type ansi
!
interface Serial0/0.1 point-to-point
 ip address 155.1.0.2 255.255.255.0
 snmp trap link-status

R5
interface Serial0/0
 ip address 155.1.0.5 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 155.1.0.4 504 broadcast
 frame-relay map ip 155.1.0.3 503 broadcast
 frame-relay map ip 155.1.0.2 502 broadcast
 frame-relay map ip 155.1.0.1 501 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type ansi

## Issue ##
p2p i/f on R1 and R2 have same issue which they are not able to ping to R5. Configurations seem OK, but there are no frame-relay map entry on them.

 Rack1R2#sh frame map
** no entry of frame-relay map

However, R2 recognizes its DLCI (205) as active.

Rack1R2#sh frame-relay pvc 205

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 205, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 1055          output pkts 1046         in bytes 350260   
  out bytes 347272         dropped pkts 0           in pkts dropped 0        
  out pkts dropped 0                out bytes dropped 0        
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0        
  out BECN pkts 0          in DE pkts 0             out DE pkts 0        
  out bcast pkts 1046      out bcast bytes 347272   
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 08:06:24, last time pvc status changed 00:28:50

So, I tried to re-configure "frame-relay interface-dlci" on s0/0.1 i/f of R2. However, R2 said like this below and I was not able to configure dlci value.

Rack1R2(config-subif)#frame-relay interface-dlci 205
%PVC already assigned to interface Serial0/0

## solution ##
I'm still not able to find out the root cause, but I found out the solution for this.

1) delete s0/0.1 interface from router (R1 and R2)
2) configure ip address of se0/0.1 and frame-relay map with dlci to s0/0 main i/f
3) delete ip address and frame-relay map from s0/0 main i/f
4) configure s0/0.1 with ip address and "frame-relay interface-dlci"

interface Serial0/0.1 point-to-point
 ip address 155.1.0.2 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 205  

### Comments  ###
After this solution, all ping are successfully done. After all, configurations are same, but re-configuration of "frame-relay interface-dlci" command makes routers work.
I'm guessing like below,
R1 and R2 are configured (no shutdown s0/0 interface, but s0/0 was not able to recognize dlci properly somehow. Then, interface-dlci was not configured from "show running-config" perspective. "frame-relay interface-dlci xxx" was missing in show run, but dlci value was configured actually.
This might be caused by interface configuration occurred first before FR switch configured. Still not sure...