To share what I've learned !

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

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 de

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-c

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

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

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