Wednesday, September 11, 2013

IPv6 link-local duplicate bring the ipv6 traffic on POS interface

Issue : ipv6 route not installed , interface up  , ipv6 protocol down.
Image : IOS XR 4.2.4 - GSR12810
show ipv6 interface brief
 
#show ipv6 interface brief
POS0/2/0/1             [Up/Down]
    fe80::387c:dfff:fee6:b908                     
    2001:x:x:x::1e       
But interface is up /up
show int POS0/2/0/1  
POS0/2/0/1 is up, line protocol is up  (APS not Configured )
if you check the ipv6 interface its reveals hence the interface deteced duplicate link local its brings down the ipv6 protocol.
#show ipv6 interface pos 0/2/0/1

 [KPOS0/2/0/1 is Up, ipv6 protocol is Down, Vrfid is default (0x60000000)
  IPv6 is down (link local duplicate), link-local address is fe80::387c:dfff:fee6:b908 [DUPLICATE]
  Global unicast address(es):
    2001:x:x:xx::1e, subnet is 2001:x:x:x::1c/126 [TENTATIVE]
  Joined group address(es): ff02::1:ffe6:b908 ff02::2 ff02::1
Quite strange issue , can related to multiple bug ids : CSCtq57619, CSCeh47611 and CSCtq55280 i've resolved issue after manually binding the link local address but i think following will do :
clear ipv6 duplicate addresses

Thursday, June 27, 2013

CRS-3 RommonA upgrade issues

First of all if you try to upgrade rommonA there is no option for rommonA in the FPD filed.

 
upgrade hw-module fpd rommonA location 0/3/CPU0

Eventually you will get following Message and no rommonA upgrade will occur .

 
No lc rommonA on location 0/3/CPU0 need upgrade at this time.

you have to force the rommanA upgrade to occur . Following is the command to upgrade the one line card.

 
upgrade hw-module fpd rommonA force location 0/3/CPU0


Starting the upgrade/download of following FPD:
=========== ==== ======= ======= =========== =========
                                   Current    Upg/Dng
Location    Type Subtype Upg/Dng   Version    Version
=========== ==== ======= ======= =========== =========
0/3/CPU0    lc   rommonA upg         2.06        2.07  
------------------------------------------------------
Successfully upgraded   rommonA for                MSC_B on location    0/3/CPU0 from  2.06 to  2.07


 
reload location 0/3/cpu0


after reloading the device will detect the right rommonA

show hw-module fpd location all

0/3/CPU0     CRS1-SIP-800               0.88  lc   fpga1   0       6.00     No
                                              lc   rommonA 0       2.07     No
                                              lc   rommon  0       2.07     No

Thursday, May 2, 2013

Decoding BGP Notification Error

Following Log messages are normal in the IX scenario but decode the error message is quite interesting:
We will see why this error message popped up :


: %BGP-3-NOTIFICATION: sent to neighbor 10.10.194.236 2/7 (unsupported/disjoint capability) 0 bytes  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 xx0D 00B4 C06A 1102 1C02 0601 0400 0200 0102 0280 0002 0202 0002 0246 0002 0641 0400 00C4 0D

its a raw hex out  of the BGP open message and starts from the marker  16byte FF so the actual output starts from 0039 
2 byte length value : 00 39 - 57
1 byte Type : 01 open message
1 byte Version : 04
2 byte ASN : xx0D  [ modified to remove the relevant information ]
2 byte holdtime : 00 B4 - 180 Seconds
4 byte BGP identifier : C06A 1102 [ modified ]
1 byte Optional parameter length : 1C   - 28 bytes
Refer RFC: http://tools.ietf.org/html/rfc5492

http://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-02
http://www.iana.org/assignments/capability-codes/capability-codes.xml
02 0601 0400 0200 01   - 02 parameter type , capability 06 -length   01 : Multiprotocol Extensions for BGP-4
 02 0280 00  - 128 : route refresh
02 0202 00  - 02 : route refresh
02 0246 00  -   70 : enhanced route refresh
 02 0641 0400 00C4 0D :65 Support for 4-octet AS number capability

So the IOS i'm working with doesn't support enhanced route-refresh therefore its dropping the connection . 





Friday, April 12, 2013

Copying crashinfo file from 7600/6500 module

How to retrieve the data from modules 1st one is easy but its a long way , i prefer 2nd way.
1)
attach

more disk0:

 2)
 copy dfc#modnumber-disk0: ftp://username:pass@

Reference: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008072c406.shtml#crashinfo

Tuesday, April 9, 2013

Cisco 12000 XR Turboboot TFTP IP Address


Turboboot is the process we need to proceed to install XR from the scratch . i've observed following behaviour while loading the image (c12k-mini.vm-3.6.2) file from TFTP. Even I've configured the ip address as 192.168.189.1 the bootloader requesting the image from 192.168.100.1 / 1.1.1.1 ( source ip address ) -
rommon 6 > set 
PS1=rommon ! > 
RET_2_RUTC=1151664252
NT_K=0:0:0:0
RANDOM_NUM=2127452086
SRPCFG=00002000002000000000000000000000
BOOTLDR=
CONFGEN=248
CHASSIS_SN=TBM11472326
RET_2_RTS=10:29:35 QST Sun Mar 10 2013
RET_2_RCALTS=1362900734
IOX_ADMIN_CONFIG_FILE=
ReloadReason=67
BSI=0
BOOT_DEV_SEQ_CONF=
BOOT_DEV_SEQ_OPER=
TURBOBOOT=on,disk0,format
IP_SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY=192.168.189.2
IP_ADDRESS=192.168.189.1

Sunday, March 10, 2013

Cisco BGP route-map continue statement confusion


I was confused by the wording of Cisco regarding the route-map continue statement Route maps have a linear behavior, not a nested behavior. Once a route is matched in a route map permit entry with a continue command clause, it will not be processed by the implicit deny at the end of the route-map. Therefore I've designed the following lab to check the actual behaviour
 R1 configuration:
R1#show run
Building configuration...

!
hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip address 20.20.20.1 255.255.255.0
!
interface FastEthernet1/0
 ip address 10.10.10.1 255.255.255.252
 duplex auto
 speed auto
!
router bgp 65001
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 20.20.20.0 mask 255.255.255.0
 neighbor 10.10.10.2 remote-as 65002
 neighbor 10.10.10.2 send-community both
 neighbor 10.10.10.2 route-map TEST out
 no auto-summary
!
ip bgp-community new-format
!
route-map TEST permit 10
 set community 65001:65002
!
route-map TEST1 permit 10
!
end
Scenario 1: In this one we will match prefix list and community list on continue statement and advertise to R3 :
hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
 ip address 10.10.10.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/1
 ip address 10.10.10.5 255.255.255.252
 duplex auto
 speed auto
!
router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.10.1 remote-as 65001
 neighbor 10.10.10.6 remote-as 65003
 neighbor 10.10.10.6 send-community both
 neighbor 10.10.10.6 route-map BLOCK-IT out
 no auto-summary
!

ip bgp-community new-format
ip community-list 100 permit 65001:65002

!
ip prefix-list SEND-ME seq 5 permit 20.20.20.0/24
!
route-map BLOCK-IT permit 10
 match ip address prefix-list SEND-ME
 continue 100
!
route-map BLOCK-IT permit 100
 match community 100
 set community 65002:65003 additive
!
!
as we expected we see the output on R3:
R3#show ip bgp 20.20.20.20
BGP routing table entry for 20.20.20.0/24, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65002 65001
    10.10.10.5 from 10.10.10.5 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
      Community: 65001:65002 65002:65003
But if we change the community list 100 as follows, still we are observing the prefixes are advertised but no community values are added
R2#sho ip community-list 100
Community (expanded) access list 100
    permit 65001:10000
If you are expecting the prefixes that not matched the community list should be dropped that is not the case !!!
R3#show ip bgp 20.20.20.20
BGP routing table entry for 20.20.20.0/24, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65002 65001
    10.10.10.5 from 10.10.10.5 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
      Community: 65001:65002
So cisco says you need to define your explicit deny statement as follows if you want to drop that doesn't match. Therefore if you define the final drop statement it will drop that doesn't match.
route-map BLOCK-IT permit 10
 match ip address prefix-list SEND-ME
 continue 100
!
route-map BLOCK-IT permit 100
 match community 100
 set community 65002:65003 additive
!
route-map BLOCK-IT deny 110

R3#show ip bgp 20.20.20.20
% Network not in table

as defined in cisco if there is a match in the flow of route-map and then if it is transferred to continue statement you can't expect that it will be denied from the implicit deny statement. Tested in Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T