A9K BGP

Hi, i´m new in the world of XR and i need to pass the next configuration in XR and i can´t, can you help me please?
router bgp 2222
bgp log-neighbor-changes
scope global
neighbor 94.142.103.17 remote-as 1111
neighbor 94.142.103.17 description CDE
neighbor 94.142.103.17 password 123123
neighbor 94.142.103.17 timers 20 60 60
neighbor 94.142.103.17 activate
neighbor 94.142.103.17 soft-reconfiguration inbound
neighbor 94.142.103.17 prefix-list Filter in
neighbor 94.142.103.17 prefix-list Filter-out out
neighbor 94.142.103.17 route-map LOCAL-PREF-BACKUP in
   network 181.125.192.0 mask 255.255.192.0
   network 181.125.192.0 mask 255.255.224.0
   network 181.125.224.0 mask 255.255.224.0
   network 181.126.0.0 mask 255.255.128.0
   network 181.126.0.0 mask 255.255.192.0
   network 181.126.64.0 mask 255.255.192.0
   network 181.126.128.0 mask 255.255.128.0
   network 181.126.128.0 mask 255.255.192.0
   network 181.126.192.0 mask 255.255.192.0
   network 181.127.0.0 mask 255.255.192.0
   network 181.127.0.0 mask 255.255.224.0
   network 181.127.32.0 mask 255.255.224.0
ip prefix-list Filter seq 20 permit 216.9.251.0/24
ip prefix-list Filter seq 30 permit 66.117.0.0/16 ge 17 le 24
ip prefix-list Filter seq 40 permit 208.109.88.0/22
ip prefix-list Filter seq 50 permit 83.39.0.0/16
ip prefix-list Filter seq 100 permit 201.217.0.0/16 ge 17 le 24
ip prefix-list Filter seq 101 permit 190.23.0.0/17 ge 18 le 24
ip prefix-list Filter seq 102 permit 190.52.128.0/19 ge 20 le 24
ip prefix-list Filter seq 103 permit 190.52.160.0/19 ge 20 le 24
ip prefix-list Filter seq 104 permit 156.42.0.0/16 ge 17 le 24
ip prefix-list Filter seq 105 permit 65.197.244.0/24
ip prefix-list Filter seq 106 permit 65.216.64.0/20
ip prefix-list Filter seq 10000 permit 0.0.0.0/0
ip prefix-list Filter-out seq 101102005 permit 186.16.96.0/20
ip prefix-list Filter-out seq 101102006 permit 186.16.128.0/20
ip prefix-list Filter-out seq 101102007 permit 186.16.144.0/20
ip prefix-list Filter-out seq 101102008 permit 186.16.160.0/20
ip prefix-list Filter-out seq 101102009 permit 186.16.176.0/20
ip prefix-list Filter-out seq 101102020 permit 190.128.192.0/19
ip prefix-list Filter-out seq 1011022225 permit 200.12.146.0/24
ip prefix-list Filter-out seq 1011022230 permit 201.220.25.0/24
route-map LOCAL-PREF-BACKUP permit 10
set local-preference 95

The following 2 refences will give you some guidance on how to do that:
https://supportforums.cisco.com/docs/DOC-22848
and for RPL:
https://supportforums.cisco.com/docs/DOC-22031
You will need to use RPL to define your prefix sets (as opposed to prefix lists you have in IOS)
to filter inbound and outbound route updates.
You also use the RPL to modify BGP attributes.
The neighbor and network statements (need to be under the address family ipv4 unicast) are pretty much the same as in IOS.
regards
xander

Similar Messages

BGP on A9K: Filtering prefixes using Communities on iBGP

Hello,
We are trying to filter some prefixes to a iBGP connection but it doesn't work properly:
The rpl is like this:
community-set MID
15525:8657
end-set
route-policy Deny_Community_MID
if community matches-any MID then
    drop
else
    pass
endif
end-policy
This rpl only removes the community from the prefix, and the prefix always arrive on the iBGP neighbor, which it not what we intend to do ! What we intend to do is to filter out the prefix ...
On our research we find this which is absolutely different from the IOS behaviour ...
BGP community and extended-community filtering cannot be configured for iBGP neighbors. Communities and extended-communities are always sent to iBGP neighbors
on
http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r4.0/routing/configuration/guide/rc40asr9k_chapter1.html#task_1211424
Is this true or are we seeing this the wrong way?
Thank you!

Done! But i have several more examples on the poor and buggy IOSXR documentation .. :
Command Reference A9K 4.0, BGP Chapter:
                The commands “additional-paths” should have a brief explanation stating that they belong the PIC Edge Framework .. but nothing .. No usage guidelines
Command Reference A9K 4.0, IS-IS Chapter:
The command “ipfrr” is deprecated and replaced by “fast-reroute” but still appears on documentation ..
Configuration Guide A9K 4.0, Routing Chapter:
                There is no reference to PIC anywhere .. only a couple of meaningless words

Partitioned-MDT MP2MP with BGP-AD/mLDP in XR 4.3

I've been working on trying to get LSM working between a couple of A9Ks to support a SSM based IPTV application.
After ingesting a bunch of content on the subject, I think what I want is Partitioned MDT, MP2MP with BGP-AD/mLDP (PIM-free core). I'm wondering if anyone has any links to working configuration examples for this type of MVPN or some good troubleshooting guides for this type of MVPN specifically.
The XR 4.3 configuration guide seems to provide either a broken or an incomplete example, so what I've managed to work out from it, doesn't seem to work.
By 'doesn't seem to work', I mean I have a SSM based join-group configured on a CE with a PIM adjacency to XR PE1. XR PE1 sees the (S,G) from the CE, but the adjacent XR PE2 (config below) doesn't see it.
Thanks in advance for any pointers.
interface Loopback0
ipv4 address 72.15.48.4 255.255.255.255
interface Loopback2022
vrf tv
ipv4 address 172.16.0.32 255.255.255.255
interface TenGigE0/0/0/15
description Facing Source
vrf tv
ipv4 address 172.16.1.1 255.255.255.0
interface TenGigE0/0/0/0
description Facing Core
cdp
mtu 9216
ipv4 address 72.15.49.80 255.255.255.254
carrier-delay up 0 down 0
dampening
router bgp 21949
address-family ipv4 unicast
address-family vpnv4 unicast
address-family ipv4 mvpn
neighbor-group P-MVPN
remote-as 21949
update-source Loopback0
address-family vpnv4 unicast
address-family vpnv6 unicast
address-family ipv4 mvpn
neighbor 72.15.48.10
use neighbor-group P-MVPN
vrf tv
rd 21949:2022
address-family ipv4 unicast
redistribute connected route-policy SOURCE--INTERNAL-CONNECTED
redistribute static route-policy SOURCE--INTERNAL-STATIC
address-family ipv4 mvpn
multicast-routing
address-family ipv4
interface TenGigE0/0/0/0
enable
nsf
mdt source Loopback0
rate-per-route
accounting per-prefix
vrf tv
address-family ipv4
mdt source Loopback2022
mdt partitioned mldp ipv4 mp2mp
rate-per-route
interface all enable
bgp auto-discovery mldp
accounting per-prefix
mpls ldp
router-id Loopback0
graceful-restart
session protection
log
neighbor
graceful-restart
session-protection
mldp
logging notifications
interface TenGigE0/0/0/0
router pim
vrf tv
address-family ipv4
rpf topology route-policy MLDP-TV
interface TenGigE0/0/0/15
enable
route-policy MLDP-TV
set core-tree mldp-partitioned-mp2mp
end-policy

Hi Jason,
As we have worked on this already. The resolution of this issue is by putting Loopback0 under multicast-routing.
multicast-routing
address-family ipv4
interface TenGigE0/0/0/0
enable
interface loopback 0
enable
Thanks,
Rivalino

Troubleshooting with IOS BGP and IOS XR BGP - routing table Empty

Hi
actually we tried to make a neigborhood between ASR9000 and Cisco 7600, we have the neigborhood active but on routing tables from ASR only have the networks locals or connected doesn´t learn anything from BGP 7600
the diagram is this:
When try to know the routes on ASR9000 from Cisco 7609 happen the follow
the neighbor is UP from Cisco 7600 and ASR 9000 but the routing table is empty.
the config on cisco 7600 is:
router bgp 2006
neighbor 172.16.14.6 remote-as 64512
address-family ipv4
neighbor 172.16.14.6 activate
the config on cisco ASR9000 is:
router bgp 64512
bgp router-id 172.16.161.1
address-family ipv4 unicast
neighbor 172.16.14.5
remote-as 2006
address-family ipv4 unicast
Help us
Best Regards

Another important one is the fact that in XR you need to have RPL policies (even if they only have a "pass-all" functionality) to accept inbound/outbound routes in eBGP.
Check the article on the asr9000 unequal cost multipath that has some sample BGP outputs and show command verifications that may help also.
If not the case, get us the XR config from the A9K side.
Also what does the bgp table on teh IOS side look like? as Richard suggests, there doesnt seem to be anything injected by the 7600 itself.
regards
xander
Xander Thuijs
Principal Engineer CCIE#6775, ASR9000

BGP NSF

Hello,
1. Is NSF supported for BGP routing protocol? If so how to enable that?
2. Can we configure both NSF and NSR for a same instance of IGP routing protocol? If so, which will have top priority(whether NSF or NSR)?
Thanks
Hari

Hi Hari,
because the a9k provides for a total distributed architecture, whereby the control plane is separated from teh forwarding, there is natively already NSF, so for that you dont have to configure anything.
You can read up more on that topic if you like when you google asr9000 route scale architecture.
NSR, that is bascially to keep a peering alive, while the standby sending the actual TCP packets (to keep the seq numbers in sync) is something that you configure separately via:
rotuer bgp 100
nsr
Assisting in NSF can be the fucntionality of graceful restart (to maintain the session before declaring it down), and NSF is also implemented by nature via the functionality of SSO (stateful switchover).
The concept of NSR is tricky and important, I have a write up for you here:
The NSR implementation in XR relies on the use of the Standby RP. If the
process were to fail/crash on the Active RP, unless control is passed to the
Standby RP, NSR operation will not work - in effect it will then revert back to
either Graceful-restart (if enabled) or a full process restart (peer down/adj
down etc.). The process on the Active RP cannot recover state from the Standby
RP. If you were to have a situation where the Active RP were to crash, then NSR
functionality will kick-in as control will be passed to the Standby RP.
The question is, do you only want NSR to occur in the event of an RP failure
(which should be a rare occurrence)? If the answer is 'yes', then do no enable
the configuration 'nsr process-failures switchover'. If the answer is 'no' and
the customer understand that an RP failover is expected in the circumstances,
then enable 'nsr process-failures switchover'. For some customer, the very idea
of an RP failover is just 'bad' - for others, they are comfortable with this
form of operation.
There are only a few SPs using NSR today, since for many, the key driver has
been BGP NSR which was only delivered in rls 3.8.0. We do have customers who
are in service with NSR for OSPF and LDP and BGP - we have a good number of
customers who are using ISIS with NSF CISCO (which is actually NSR), which was
delivered back in rls 3.3.x. They do use the 'nsr process-failures switchover'
since the RP failover is considered to be too rare an event.
Without 'nsr process-failures switchover' enabled, NSR will only come into
effect should the RP crash or an RP failover be manually triggered.
Enabling this config will result in a failover being initiated if BGP, TCP, LDP
or OSPF were to crash. Since an FO is immediately triggered to preserve NSR, a
core-dump of the crashed process will not be available. If diagnosing such a
crash is more important for the customer, then this knob should not be turned
on.
xander

Multi-Instance BGP

BGP Multi-instance was supposed to be released in XR 4.2, I could not find any mention of it in the Release notes for 4.2, 4.3, & 5.1?
How do I find out if it was implemented and if so how to configure it, if not if it is still on the road map?
Thanks,
John

Hello,
It is in release note XR .4.2:
http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.2/general/release/notes/reln_a9k_42.html
And some writing on Cisco doc:
http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.2/routing/configuration/guide/b_routing_cg42crs_chapter_01.html#concept_E6B1D3D6B8CA4742AED837B3A94E826F
Below is the example what i did in my lab running 4.2.3:
RP/0/RSP1/CPU0:ASR-9006-01#show run router bgp
Fri Jan 31 21:05:02.170 UTC
router bgp 1 instance IPV4
bgp router-id 72.15.48.5
bgp graceful-restart
ibgp policy out enforce-modifications
address-family ipv4 unicast
redistribute connected
allocate-label all
address-family vpnv4 unicast
retain route-target all
neighbor 172.16.8.3
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-policy PASS in
route-policy PASS out
router bgp 1 instance IPV6
bgp router-id 99.2.3.4
address-family ipv6 unicast
redistribute connected
thanks,
rivalino

Do you need a cisco router at remote sites when using VRF BGP?

Hello.....
If you could refer to the attached document and read the following... I need to know if a CISCO router is required for each of the sites. OR does the ISP (Provider) provide the only required Router in the private cloud?
We want to replace the Cisco 891 with a PepLink but I don't know if we can do that. Can anyone jump in and help me understand?
When we hear about VRF, its almost synonymous to MPLS VPN. Virtual Routing and Forwarding is commonly used by Service Providers to provide services within an MPLS cloud with multiple customers. The most interesting feature of this is that, VRF allows creation of multiple routing tables within a single router. This means that overlapping use of IP addresses from different customers is possible. Some enterprises use VRF to seggrate their services like VOIP, wireless, geographical location and other varieties.

Whether you can replace the 891 device with another device boils down to a single question: Do you need to run BGP with the Service Provider in order to use their service. If you need to run a routing protocol with your service provider, your service is likely a L3VPN (IP VPN) solution ( i.e. you inject your site's routes into the providers L3VPN session, they use MP-BGP+VRF for segmentation within their network).
If, however, they just drop you a L2 connection and provide L2 emulated services ( e.g. L2VPN or VPLS ) across their network, then your device can be whatever you want it to be.
From your device's perspective, it is not VRF aware. That is, it does not know about how the service provider segments your service from another customers. In the L3VPN case, your device is routing-protocol aware. In the L2VPN case, your device is not routing protocol aware and does not need to form adjacency with the service provider's equipment.
HTH.
Rate if helpful.

ASR9001 module A9K-MPA-20X1GE issue

Hi all!
Who knows, what does these messages mean?
LC/0/0/CPU0:Oct 22 10:53:32.120 : envmon_lc[160]: %PLATFORM-ENVMON-4-OPERATION_WARN : Unable to get plug sensor data, error code 'Subsystem(2890)' detected the 'fatal' condition 'Code(0)'
RP/0/RSP0/CPU0:Oct 22 10:53:32.860 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/0 A9K-MPA-20X1GE state:ADMIN DOWN
LC/0/0/CPU0:Oct 22 10:53:32.862 : lda_server[65]: %PLATFORM-LDA-3-MPA_BAY_SW_ERROR : Unable to initialize MPA in bay: 0, Module has been shutdown due to identify test failure (0x00000000 - No error) : pkg/bin/lda_server : (PID=40990) : -Traceback= 4ed5159c 4bf1eed0 4bf1efdc 4d02c28c 4d02a1f4 4ba73a44 4ba71554 4d029ddc 4bada400
RP/0/RSP0/CPU0:Oct 22 10:53:33.860 : invmgr[250]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/0, state: UNPOWERED
Is this hardware or software issue? What do you think?
I think we have faced with hardware issue of module A9K-MPA-20X1GE.
More outputs:
RP/0/RSP0/CPU0:asr9001#sh ver
Tue Oct 22 10:53:46.186 UTC
Cisco IOS XR Software, Version 4.3.2[Default]
Copyright (c) 2013 by Cisco Systems, Inc.
ROM: System Bootstrap, Version 2.01(20130627:172232) [ASR9K ROMMON],
asr9001 uptime is 6 minutes
System image file is "bootflash:disk0/asr9k-os-mbi-4.3.2/0x100000/mbiasr9k-rp.vm"
cisco ASR9K Series (P4040) processor with 8388608K bytes of memory.
P4040 processor at 1500MHz, Revision 2.0
ASR-9001 Chassis
2 Management Ethernet
4 TenGigE
4 DWDM controller(s)
4 WANPHY controller(s)
219k bytes of non-volatile configuration memory.
2880M bytes of hard disk.
3932144k bytes of disk0: (Sector size 512 bytes).
Configuration register on node 0/RSP0/CPU0 is 0x102
Boot device on node 0/RSP0/CPU0 is disk0:
Package active on node 0/RSP0/CPU0:
iosxr-infra, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-infra-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-fwding, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-fwding-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-routing, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-routing-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-diags, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-diags-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-ce, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-ce-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-os-mbi, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-os-mbi-4.3.2
    Built on Sun Sep 1 19:23:39 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-base, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-base-4.3.2
    Built on Sun Sep 1 19:21:14 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-fwding, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-fwding-4.3.2
    Built on Sun Sep 1 19:21:14 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-diags-supp, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-diags-supp-4.3.2
    Built on Sun Sep 1 19:21:19 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-scfclient, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-scfclient-4.3.2
    Built on Sun Sep 1 19:21:22 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-cpp, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-cpp-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-ce, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-ce-4.3.2
    Built on Sun Sep 1 19:21:16 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-mini-px, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-mini-px-4.3.2
    Built on Sun Sep 1 19:27:30 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-mgbl, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-mgbl-4.3.2
    Built on Sun Sep 1 19:28:25 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-mgbl-supp, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-mgbl-supp-4.3.2
    Built on Sun Sep 1 19:28:25 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-mgbl-px, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-mgbl-px-4.3.2
    Built on Sun Sep 1 19:28:37 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-fpd, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-fpd-4.3.2
    Built on Sun Sep 1 19:29:15 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-fpd-px, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-fpd-px-4.3.2
    Built on Sun Sep 1 19:29:40 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9K-doc-supp, V 4.3.2[Default], Cisco Systems, at disk0:asr9K-doc-supp-4.3.2
    Built on Sun Sep 1 19:29:07 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-doc-px, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-doc-px-4.3.2
    Built on Sun Sep 1 19:29:14 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
Boot device on node 0/0/CPU0 is mem:
Package active on node 0/0/CPU0:
iosxr-infra, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-infra-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-fwding, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-fwding-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-routing, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-routing-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-diags, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-diags-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
iosxr-ce, V 4.3.2[Default], Cisco Systems, at disk0:iosxr-ce-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-os-mbi, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-os-mbi-4.3.2
    Built on Sun Sep 1 19:23:39 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-base, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-base-4.3.2
    Built on Sun Sep 1 19:21:14 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-fwding, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-fwding-4.3.2
    Built on Sun Sep 1 19:21:14 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-diags-supp, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-diags-supp-4.3.2
    Built on Sun Sep 1 19:21:19 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-scfclient, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-scfclient-4.3.2
    Built on Sun Sep 1 19:21:22 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-cpp, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-cpp-4.3.2
    Built on Sun Sep 1 19:21:10 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-ce, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-ce-4.3.2
    Built on Sun Sep 1 19:21:16 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
asr9k-mini-px, V 4.3.2[Default], Cisco Systems, at disk0:asr9k-mini-px-4.3.2
    Built on Sun Sep 1 19:27:30 UTC 2013
    By iox-bld2 in /auto/srcarchive7/production/4.3.2/all/workspace for pie
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#sh log
Tue Oct 22 10:54:22.823 UTC
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: level warnings, 44 messages logged
    Monitor logging: level debugging, 0 messages logged
    Trap logging: level informational, 0 messages logged
    Buffer logging: level debugging, 148 messages logged
Log Buffer (307200 bytes):
RP/0/RSP0/CPU0:Oct 22 10:47:29.090 : init[65540]: %OS-INIT-7-MBI_STARTED : total time 8.814 seconds
RP/0/RSP0/CPU0:Oct 22 10:47:29.113 : imio[64]: %PLATFORM-IMIO-3-OPERATION_NOTIFY : imio_main: cold start
RP/0/RSP0/CPU0:Oct 22 10:48:42.672 : sysmgr[96]: %OS-SYSMGR-5-NOTICE : Card is COLD started
RP/0/RSP0/CPU0:Oct 22 10:48:50.075 : init[65540]: %OS-INIT-7-INSTALL_READY : total time 89.801 seconds
RP/0/RSP0/CPU0:Oct 22 10:48:51.803 : sysmgr[407]: %OS-SYSMGR-6-INFO : Backup system manager is ready
RP/0/RSP0/CPU0:Oct 22 10:48:52.088 : sc_reddrv[376]: imio_lance2_init_interrupts:
RP/0/RSP0/CPU0:Oct 22 10:48:58.262 : sysmgr[96]: %OS-SYSMGR-7-DEBUG : node set to DSC
RP/0/RSP0/CPU0:Oct 22 10:49:04.763 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-SYSTEM_COLD_START : System cold start detected. Resetting Line Cards.
RP/0/RSP0/CPU0:Oct 22 10:49:06.487 : pwr_mgmt[360]: %PLATFORM-PWR_MGMT-2-MODULE_FAILURE : Power-module 0/PM1/SP failure condition raised : Module input voltage out of range
RP/0/RSP0/CPU0:Oct 22 10:49:07.565 : online_diag_rsp[427]: %DIAG-DIAG-6-RUN_MINIMUM : ASR9001-RP 0/RSP0/CPU0: Running Minimum Diagnostics...
RP/0/RSP0/CPU0:Oct 22 10:49:09.369 : envmon[204]: %PLATFORM-ENVMON-4-FANTRAY_RPM : Fan tray RPM warning on slot 0/FT0/SP
RP/0/RSP0/CPU0:Oct 22 10:49:12.761 : bpe[144]: %PLATFORM-BPE-5-INFO : successfully retrieved i2c eeprom
RP/0/RSP0/CPU0:Oct 22 10:49:12.969 : shelfmgr[381]: %PLATFORM-SHELFMGR_HAL-7-CAN_INFO : Can API: slot 0 online event.
RP/0/RSP0/CPU0:Oct 22 10:49:12.991 : shelfmgr[381]: %PLATFORM-SHELFMGR_HAL-3-POWER_SUPPLY_REDUNDANCY : Power Supply Failures are not protected.
RP/0/RSP0/CPU0:Oct 22 10:49:13.624 : invmgr[250]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/FT0/SP inserted
RP/0/RSP0/CPU0:Oct 22 10:49:13.780 : invmgr[250]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/PM0/SP inserted
RP/0/RSP0/CPU0:Oct 22 10:49:13.788 : invmgr[250]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/PM1/SP, state: FAILED
RP/0/RSP0/CPU0:Oct 22 10:49:13.789 : invmgr[250]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/PM1/SP inserted
RP/0/RSP0/CPU0:Oct 22 10:49:13.800 : invmgr[250]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/RSP0/CPU0, state: IOS XR RUN
RP/0/RSP0/CPU0:Oct 22 10:49:18.393 : envmon[204]: %PLATFORM-ENVMON-3-OPERATION_ERROR : Failed in envmon lwmconnect.message channel connection failed!,-1 error code 'Subsystem(8191)' detected the 'unknown' condition 'Code(63)': Unknown Error(511)
RP/0/RSP0/CPU0:Oct 22 10:49:19.395 : envmon[204]: %PLATFORM-ENVMON-3-OPERATION_FAIL : Failed in envmon_fantray_alarms.7076, error code 'Subsystem(8191)' detected the 'unknown' condition 'Code(63)': Unknown Error(511)
RP/0/RSP0/CPU0:Oct 22 10:49:19.395 : envmon[204]: %PLATFORM-ENVMON-2-ENV_CONDITION : Outstanding environmental condition exists in the chassis
RP/0/RSP0/CPU0:Oct 22 10:49:19.815 : invmgr[250]: lance_client_init: Client already connected
RP/0/RSP0/CPU0:Oct 22 10:49:20.816 : invmgr[250]: lance_client_init: Client already connected
RP/0/RSP0/CPU0:Oct 22 10:49:21.817 : invmgr[250]: lance_client_init: Client already connected
RP/0/RSP0/CPU0:Oct 22 10:49:22.843 : invmgr[250]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/RSP0/CPU0 inserted
RP/0/RSP0/CPU0:Oct 22 10:49:27.313 : sysmgr[96]: %OS-SYSMGR-7-DEBUG : sysmgr_admin_plane_check:SYSMGR_PLANE_ADMIN Notification sent.
RP/0/RSP0/CPU0:Oct 22 10:49:32.838 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_DISCOVERY : Node State Discovery complete
RP/0/RSP0/CPU0:Oct 22 10:49:32.854 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/CPU0 ASR9001-LC state:PRESENT
RP/0/RSP0/CPU0:Oct 22 10:49:32.905 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/FT0/SP FAN TRAY state:PRESENT
RP/0/RSP0/CPU0:Oct 22 10:49:32.957 : invmgr[250]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/0/CPU0 inserted
RP/0/RSP0/CPU0:Oct 22 10:49:35.224 : syslog_dev[94]: hsbi_fpd_agent[240]: FPD ltrace_file_name => fpd-agent/hsbi_fpd_agent
RP/0/RSP0/CPU0:Oct 22 10:49:37.310 : alphadisplay[115]: %PLATFORM-ALPHA_DISPLAY-6-CHANGE : Alpha display on node 0/RSP0/CPU0 changed to IOXR in state default
RP/0/RSP0/CPU0:Oct 22 10:49:48.759 : syslog_dev[94]: netio[327]: > WARNING (BM) [/ws/akgoswam-bgl/hellhound/nto6.4-XR/cisco/lib/3rdparty/netcomm/NetCommSw/Peripherals/BM/bm.h:352 BmBpidGet]: No Ipc - can't validate bpid.^M
RP/0/RSP0/CPU0:Oct 22 10:50:02.721 : ipodwdm[275]: %L2-G709-6-INFO : /harddisk:/ipodwdm_log Already present
RP/0/RSP0/CPU0:Oct 22 10:50:03.698 : shelfmgr[381]: %PLATFORM-SHELFMGR_HAL-6-BOOT_REQ_RECEIVED : Boot Request from 0/0/CPU0, RomMon Version: 2.1
RP/0/RSP0/CPU0:Oct 22 10:50:04.481 : shelfmgr[381]: %PLATFORM-MBIMGR-7-IMAGE_VALIDATED : Remote location 0/0/CPU0: : MBI tftp:/disk0/asr9k-os-mbi-4.3.2/lc/mbiasr9k-lc.vm validated
RP/0/RSP0/CPU0:Oct 22 10:50:04.499 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/CPU0 ASR9001-LC state:MBI-BOOTING
RP/0/RSP0/CPU0:Oct 22 10:50:07.632 : alphadisplay[115]: %PLATFORM-ALPHA_DISPLAY-6-CHANGE : Alpha display on node 0/RSP0/CPU0 changed to ACTV in state default
RP/0/RSP0/CPU0:Oct 22 10:50:14.758 : canb-server[149]: %PLATFORM-CANB_SERVER-3-ALARM_CLEARED : Clear alarm from CBC in slot 0/FT0/SP, alarm code CBC_ALRM_FT_LED_RED_FAILED
RP/0/RSP0/CPU0:Oct 22 10:50:14.764 : canb-server[149]: %PLATFORM-CANB_SERVER-3-ALARM_INDICATION : Raise alarm from CBC in slot 0/FT0/SP, alarm code CBC_ALRM_FT_LED_GREEN_FAILED
RP/0/RSP0/CPU0:Oct 22 10:50:29.223 : placed[346]: LR-PLANE-READY DECLARATION
RP/0/RSP0/CPU0:Oct 22 10:50:31.360 : envmon[204]: %PLATFORM-ENVMON-4-FANTRAY_RPM_CLEAR : Fan tray RPM warning cleared on slot 0/FT0/SP
RP/0/RSP0/CPU0:Oct 22 10:50:33.247 : ifmgr[242]: %PKT_INFRA-LINK-5-CHANGED : Interface MgmtEth0/RSP0/CPU0/1, changed state to Administratively Down
RP/0/RSP0/CPU0:Oct 22 10:50:33.251 : ifmgr[242]: %PKT_INFRA-LINK-3-UPDOWN : Interface MgmtEth0/RSP0/CPU0/0, changed state to Down
RP/0/RSP0/CPU0:Oct 22 10:50:33.251 : ifmgr[242]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface MgmtEth0/RSP0/CPU0/0, changed state to Down
RP/0/RSP0/CPU0:Oct 22 10:50:33.257 : cfgmgr-rp[158]: %MGBL-CONFIG-6-OIR_RESTORE : Configuration for node '0/RSP0/0' has been restored.
RP/0/RSP0/CPU0:Oct 22 10:50:35.006 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/PM1/SP A9K-750W-AC state:PRESENT
RP/0/RSP0/CPU0:Oct 22 10:50:35.012 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/PM0/SP A9K-750W-AC state:PRESENT
RP/0/RSP0/CPU0:Oct 22 10:50:35.588 : ifmgr[242]: %PKT_INFRA-LINK-3-UPDOWN : Interface MgmtEth0/RSP0/CPU0/0, changed state to Up
RP/0/RSP0/CPU0:Oct 22 10:50:35.589 : ifmgr[242]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface MgmtEth0/RSP0/CPU0/0, changed state to Up
RP/0/RSP0/CPU0:Oct 22 10:51:15.756 : canb-server[149]: %PLATFORM-CANB_SERVER-3-ALARM_INDICATION : Raise alarm from CBC in slot 0/FT0/SP, alarm code CBC_ALRM_FT_LED_RED_FAILED
RP/0/RSP0/CPU0:Oct 22 10:51:15.756 : canb-server[149]: %PLATFORM-CANB_SERVER-3-ALARM_CLEARED : Clear alarm from CBC in slot 0/FT0/SP, alarm code CBC_ALRM_FT_LED_GREEN_FAILED
RP/0/RSP0/CPU0:Oct 22 10:51:23.316 : dsc[181]: %PLATFORM-DSC_CTRL-6-RACK_STATE : Rack 1 is now Down
RP/0/RSP0/CPU0:Oct 22 10:51:23.321 : gsp[239]: gsp_rack_down_handler: for node:0x1
RP/0/RSP0/CPU0:Oct 22 10:51:25.396 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/CPU0 ASR9001-LC state:MBI-RUNNING
LC/0/0/CPU0:10: init[65540]: %OS-INIT-7-MBI_STARTED : total time 5.152 seconds
LC/0/0/CPU0:Oct 22 10:51:57.119 : sysmgr[91]: %OS-SYSMGR-5-NOTICE : Card is COLD started
LC/0/0/CPU0:Oct 22 10:51:57.524 : init[65540]: %OS-INIT-7-INSTALL_READY : total time 38.219 seconds
LC/0/0/CPU0:Oct 22 10:51:58.119 : sysmgr[341]: %OS-SYSMGR-6-INFO : Backup system manager is ready
RP/0/RSP0/CPU0:Oct 22 10:52:11.473 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/0 UNKNOWN state:UNPOWERED
RP/0/RSP0/CPU0:Oct 22 10:52:11.896 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/0 A9K-MPA-20X1GE state:POWER UP
LC/0/0/CPU0:Oct 22 10:52:12.716 : lda_server[65]: %L2-SPA-5-STATE_CHANGE : SPA in bay 0 type A9K-MPA-20X1GE Initing
RP/0/RSP0/CPU0:Oct 22 10:52:13.786 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/0 A9K-MPA-20X1GE state:INITIALIZED
LC/0/0/CPU0:Oct 22 10:52:25.265 : prm_server_ty[295]: %PLATFORM-QOSHAL-6-QOS_MODE_CHANGE : Line-card QoS mode set to child-shaping-enabled.
LC/0/0/CPU0:Oct 22 10:52:25.273 : prm_server_ty[295]: %PLATFORM-QOSHAL-6-QOS_MODE_CHANGE : Line-card QoS mode set to lowburst-disabled.
LC/0/0/CPU0:Oct 22 10:52:25.402 : lda_server[65]: %PLATFORM-UPGRADE_FPD-4-DOWN_REV : fpga3 instance 0 is down-rev (V0.07), upgrade to (V0.08). Use the "upgrade hw-module fpd" CLI in admin mode.
LC/0/0/CPU0:Oct 22 10:52:25.632 : sysmgr[91]: %OS-SYSMGR-7-DEBUG : sysmgr_admin_plane_check:SYSMGR_PLANE_ADMIN Notification sent.
LC/0/0/CPU0:Oct 22 10:52:27.651 : syslog_dev[89]: hsbi_fpd_agent[198]: FPD ltrace_file_name => fpd-agent/hsbi_fpd_agent
RP/0/RSP0/CPU0:Oct 22 10:52:37.663 : exec[65727]: %MGBL-exec-3-LOGIN_AUTHEN : Login Authentication failed. Exiting...
RP/0/RSP0/CPU0:Oct 22 10:52:43.079 : exec[65727]: %SECURITY-login-6-AUTHEN_SUCCESS : Successfully authenticated user 'shopik' from 'console' on 'con0_RSP0_CPU0'
RP/0/RSP0/CPU0:Oct 22 10:52:46.558 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/0 A9K-MPA-20X1GE state:OK
RP/0/RSP0/CPU0:Oct 22 10:52:46.578 : invmgr[250]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/0, state: OK
RP/0/RSP0/CPU0:Oct 22 10:52:46.583 : invmgr[250]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/0/0 inserted
LC/0/0/CPU0:Oct 22 10:52:58.858 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface TenGigE0/0/2/3, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:58.863 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface TenGigE0/0/2/2, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:58.863 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface TenGigE0/0/2/1, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:58.863 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface TenGigE0/0/2/0, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.133 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/19, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.133 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/18, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.133 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/17, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.133 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/16, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.133 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/15, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/14, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/13, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/12, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/11, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/10, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/9, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/8, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/7, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.134 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/6, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.135 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/5, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.135 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/4, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.135 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/3, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.135 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/2, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.135 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/1, changed state to Administratively Down
LC/0/0/CPU0:Oct 22 10:52:59.135 : ifmgr[200]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/0, changed state to Administratively Down
RP/0/RSP0/CPU0:Oct 22 10:53:00.041 : upgrade_fpd_cli[65763]: %PLATFORM-UPGRADE_FPD-6-STATUS : FPD upgrade started.
LC/0/0/CPU0:Oct 22 10:53:01.800 : lda_server[65]: %PLATFORM-SCC-2-BAD_ID_HW : Failed Identification Test in 0/130/0 [5/0] The module in 0/130/0 in this router may not be a genuineCisco product. Cisco warranties and support programs onlyapply to genuine Cisco products. If Cisco determines thatyour insertion of non-Cisco SPA cards or other modules into aCisco product is the cause of a support issue, Cisco maydeny support under your warranty or under a Cisco supportprogram such as SmartNet.
RP/0/RSP0/CPU0:Oct 22 10:53:09.746 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/CPU0 ASR9001-LC state:IOS XR RUN
RP/0/RSP0/CPU0:Oct 22 10:53:09.755 : invmgr[250]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/CPU0, state: IOS XR RUN
LC/0/0/CPU0:Oct 22 10:53:31.822 : lda_server[65]: %PLATFORM-LDA-4-MPA_OIR_QUICK_BACK_TO_BACK_ERROR : OIR operation was performed on MPA in bay:0 while the system is initializing. Recommend waiting for two minutes after EP initialized.
LC/0/0/CPU0:Oct 22 10:53:31.988 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/19, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.988 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/19, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/18, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/18, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/17, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/17, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/16, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/16, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/15, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/15, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/14, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/14, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/13, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/13, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/12, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.990 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/11, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.989 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/12, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.990 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/11, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.990 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/10, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.990 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/10, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.990 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/9, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.990 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/9, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/8, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/8, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/7, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/7, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/6, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/5, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/5, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/4, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/4, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/6, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/3, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/3, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/2, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.991 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/2, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.992 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/1, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.992 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/1, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.992 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:31.992 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/0, changed state to Down
LC/0/0/CPU0:Oct 22 10:53:32.120 : envmon_lc[160]: %PLATFORM-ENVMON-4-OPERATION_WARN : Unable to get plug sensor data, error code 'Subsystem(2890)' detected the 'fatal' condition 'Code(0)'
RP/0/RSP0/CPU0:Oct 22 10:53:32.860 : shelfmgr[381]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/0 A9K-MPA-20X1GE state:ADMIN DOWN
LC/0/0/CPU0:Oct 22 10:53:32.862 : lda_server[65]: %PLATFORM-LDA-3-MPA_BAY_SW_ERROR : Unable to initialize MPA in bay: 0, Module has been shutdown due to identify test failure (0x00000000 - No error) : pkg/bin/lda_server : (PID=40990) : -Traceback= 4ed5159c 4bf1eed0 4bf1efdc 4d02c28c 4d02a1f4 4ba73a44 4ba71554 4d029ddc 4bada400
RP/0/RSP0/CPU0:Oct 22 10:53:33.860 : invmgr[250]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/0, state: UNPOWERED
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#
RP/0/RSP0/CPU0:asr9001#show inventory
Tue Oct 22 11:01:32.251 UTC
NAME: "module 0/RSP0/CPU0", DESCR: "ASR 9001, Route Switch Processor with 8GB memory"
PID: ASR9001-RP, VID: V01 , SN: FOC1728XXXX
NAME: "module 0/0/CPU0", DESCR: "ASR 9001, Modular Line Card"
PID: ASR9001-LC, VID: V01 , SN: FOC1728XXXX
NAME: "module 0/0/0", DESCR: "ASR 9000 20-port 1GE Modular Port Adapter"
PID: A9K-MPA-20X1GE, VID: V00, SN: FOC1522XXXX
NAME: "module 0/0/2", DESCR: "ASR 9000 Virtual Module"
PID: A9K-MODULEv, VID: N/A, SN: N/A

Bryan,
We checked the "show hw-module fpd location all" and there is no "yes" in the last column.
http://pastebin.com/W1wuqYks
RP/0/RSP0/CPU0:asr9001#sh hw-module fpd location all
Thu Oct 24 13:40:19.487 UTC
===================================== ==========================================
                                      Existing Field Programmable Devices
                                      ==========================================
                                        HW                       Current SW Upg/
Location     Card Type                Version Type Subtype Inst   Version   Dng?
============ ======================== ======= ==== ======= ==== =========== ====
0/RSP0/CPU0 ASR9001-RP                 1.0   lc   fpga2   0       1.14     No
                                              lc   cbc     0      22.114    No
                                              lc   rommon 0       2.01     No
0/FT0/SP     ASR-9001-FAN               1.0   ft   cbc     7      24.114    No
0/0/CPU0     ASR9001-LC                 1.0   lc   cbc     0      23.114    No
                                              lc   fpga2   0       1.18     No
                                              lc   fpga4   0       2.07     No
                                              lc   rommon 0       2.01     No

Load balance not happening in BGP

Dear Friends,
As per I know local BGP process may implement equal-cost load-balancing to the paths that:
Have the same set of path attributes up to the MED (weight, Local Preference, Origin, MED)
Are of the same type (both learned via iBGP or eBGP)
Have the same IGP cost to reach their NEXT_HOP IP address
If the above conditions are met andmaximum-paths [ibgp]is configured under the BGP process, BGP will install multiple equal-cost routes into the local RIB and use them for load-balancing. We call the above condition as load-balancing conditions for BGP.
As all the above criteria are matched still BGP is not doing load balance. Please find below routing table:
R1:
R1#sh ip bgp
BGP table version is 4, local router ID is 40.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0      20.1.1.2                 0    100      0 i
* i                        30.1.1.1                 0    100      0 i
R1#sh ip route
Gateway of last resort is not set
     20.0.0.0/24 is subnetted, 1 subnets
R       20.1.1.0 [120/1] via 10.1.1.2, 00:00:03, FastEthernet0/0
     40.0.0.0/24 is subnetted, 1 subnets
C       40.1.1.0 is directly connected, FastEthernet0/1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/0
B    192.168.1.0/24 [200/0] via 20.1.1.2, 00:12:01
     30.0.0.0/24 is subnetted, 1 subnets
R       30.1.1.0 [120/1] via 40.1.1.2, 00:00:15, FastEthernet0/1
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.1.1.2 remote-as 100
neighbor 40.1.1.2 remote-as 100
maximum-paths 2
no auto-summary
Please help....!!!!!!!   why BGP is not load balancing here????
R1#traceroute 192.168.1.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
1 10.1.1.2 88 msec 60 msec 28 msec
2 20.1.1.2 104 msec 56 msec 120 msec
Regards,
Sanjib

Dear Jon,
Thank you so much.
When I changed the configuration BGP is now loadbalancing. But in configuartion Max-path showing as 1 instead of 2.
R1#sh ip pro | sec bgp
Routing Protocol is "bgp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    12.1.1.2
    13.1.1.3
Maximum path: 1
Routing Information Sources:
    Gateway         Distance      Last Update
    13.1.1.3             200      00:01:12
    12.1.1.2             200      00:02:15
Distance: external 20 internal 200 local 200
Regards,
Sanjib

BGP Path Selection

With reference to cisco's document on BGP Best Path Selection Algorithm (http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html).
Out of given 9 paths why 6th has been selected even though AS_PATH for 8th route is better.
Can anyone explains here, as this document has not considered the AS-PATH during path selection and used lowest ROUTER ID only.
Thanks in advance and expect technical explanation here.

Hey Buddy
The AS_PATH for both is only 1, don't get confused by (AS_SET) which only counts as 1 no matter how many AS are in the set. Refer to section "How the Best Path Algorithm Works"
4.Prefer the path with the shortest AS_PATH.
Note: Be aware of these items:
◦An AS_SET counts as 1, no matter how many ASs are in the set.
So bearing the above in mind
Example: BGP Best Path Selection
Path6
(64955 65003) 65089 --- this equals 1
    172.16.254.226 (metric 20645) from 10.57.255.11 (10.57.255.11)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
!--- BGP selects this as the Best Path on comparing
!--- with all the other routes and selected based on lower router ID.
Path8
(65003) 65089 --- this equals 1
    172.16.254.226 (metric 20645) from 172.16.254.234 (172.16.254.234)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Extended Community: RT:1100:1001
      mpls labels in/out nolabel/362
Comparing path 6 with path 8:
Both paths have reachable next hops
Both paths have a WEIGHT of 0
Both paths have a LOCAL_PREF of 100
Both paths are learned
Both paths have AS_PATH length 1 --- because the (AS_SET) always equals 1
Both paths are of origin IGP
Both paths have the same neighbor AS, 65089, so comparing MED.
Both paths have a MED of 0
Both paths are confed-external
Both paths have an IGP metric to the NEXT_HOP of 20645
Path 6 is better than path 8 because it has a lower Router-ID.
Hope it helps (:

Can you display routes advertised and/or received in OSPF, similar to BGP command sh ip bgp neighbors x.x.x.x advertised-routes?

TOC-BP-SWa#sh ip bgp neighbors 10.14.0.3 advertised-routes
BGP table version is 1674320, local router ID is 10.14.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.14.0.1/32 0.0.0.0 0 32768 i
*> 147.249.37.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 64681 i
*> 147.249.38.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 64681 i
*> 147.249.46.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 12159 12159 i
*> 147.249.196.0/24 172.20.18.1 120 0 2001 65015 65016 64823 64870 65124 i
*> 147.249.237.0/24 172.20.18.1 120 0 2001 65015 65016 64823 7381 64681 i
TOC-BP-SWa#sh ip bgp neighbors 10.14.0.3 received-r
Total number of prefixes 0
TOC-BP-SWa#sh ip bgp neighbors 10.14.0.2 received-r
BGP table version is 1674320, local router ID is 10.14.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.14.0.2/32 10.14.0.2 0 100 0 i
* i147.249.37.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 64681 i
* i147.249.38.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 64681 i
* i147.249.46.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 12159 12159 i
* i147.249.196.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 64870 65124 i
* i147.249.237.0/24 10.14.0.2 0 120 0 2001 65015 65016 64823 7381 64681 i
Can this output be duplicated with an OSPF command?

Not really because OSPF does not advertise routes it sends LSAs to it's peers.
So you need to look at the OSPF database ie. -
"sh ip ospf database"
which will show you all the LSAs the router is aware of.
In terms of all the LSAs the router has received it will show all of those but it will also show you LSAs that were generated by the router itself although the advertising router IP will point to that being the case.
In terms of all the LSAs the router advertises again it depends on the area and how that has been configured.
So for example an ABR might well have external LSAs (which aren't tied to any area in the OSPF database) but that doesn't necessarily mean it is advertising them to peers within an area as it could have been configured not to.
So it gives you a good idea but you need to also work out a few things for yourself as well.
Jon

Difference between sh ip bgp & sh ip route? BGP tables and main routing table.

Difference between sh ip bgp & sh ip route?
sh ip bgp :::: loc-rib ?
sh ip bgp nei x.x.x.x advertised-routes : adj-rib-in.
sh ip bgp nei x.x.x.x recieved-routes : adj-rib-out.
sh ip bgp nei x.x.x.x routes : loc-rib ?
sh ip route = rib ? if yes does it mean its loc-rib ?
so in a given router with bgp running, will there be 5 tables (sh ip bgp; adj-rib-in; loc-rib;adj-rib-out; sh ip route) ? if yes where are they saved ?

sh ip bgp
shows the BGP table (where are stored info coming from BGP update)
sh ip bgp nei x.x.x.x advertised-routes
shows networks that your router will advertise to a specific neighbor
sh ip bgp nei x.x.x.x recieved-routes
shows advertisement received from a specific neighbor; networks (NLRI) filtered with route-map distribute-list,... are included (Inbound soft reconfiguration must be enabled)
sh ip bgp nei x.x.x.x routes
shows only routes sent by a specific neighbor and not filtered or discarded (i.s accepted)
sh ip route
show routing table; it contains the best route for each network (best is first of all the lowest administrative distance, then the lowest metric)
Bye,
enrico.
PS please rate if useful

Question about network statement in OSPF and BGP

The network statements in OSPF and BGP can be used to advertise networks. But I'm not clear under what circumstances would make more sense to use network statements to advertise a network than by using other methods to have the network learned by other routers.
Here is an example: assume I'm running BGP on router A. I want to advertise network 10.1.1.0/24 to other BGP peers. I have a OSPF route for this network. I can do 2 things: one is to use "network 10.1.1.0 mask 255.255.255.0", the other is to do "redistribute OSPF ... route-map OSPF-INTO-BGP", and create a prefix list to permit 10.1.1.0/24.
Both would work to have this network learned by other BGP peers. But which is better for what purpose?
Thanks a lot
Gary

Hi Gary,
There is one little difference between the use of the two approaches - the route injected into BGP by using a network statement will carry an Origin attribute of IGP, whereas the route injected using redistribution will have an Origin attribute of Incomplete. Now, that is not a huge issue since you can always change that whatever value you desire both with the use of the network statement and redistribution. The important thing, however, is that in the BGP best path selection process, the Origin attribute comparison is fairly high up and will prefer a route with the attribute of IGP.
Apart from that, there is absolutely no difference between using the network statement and using redistribution with a route-map that matches exactly on the same route that you would have specified with the network statement.
I guess one advantage of using the redistribute approach is that it does not clutter up the BGP config. If you wish to add more routes, you simply add them to the prefix list so that you don't really touch the BGP config portion at all..
Hope that helps - pls do remember to rate posts that help.
Paresh

How to prevent BGP code 6 (Cease) subcode 6 (Other Configuration Change)

Can anyone tell How to prevent BGP code 6 (Cease) subcode 6 (Other Configuration Change) ?
We are facing frequent problem with this error. Please suggest how to stop this....
Note :- We are using BGP VPN between this peers.
Logs :
Date/Time : 2015-04-30 00:49:40+05:30
State : Up
Date/Time : 2015-04-30 00:39:05+05:30
State : Down
Error Code : 6(CEASE)
Error Subcode : 6(Other Configuration Change)
Notification : Send Notification
Date/Time : 2015-04-29 18:22:11+05:30
State : Up
Date/Time : 2015-04-29 18:21:39+05:30
State : Down
Error Code : 6(CEASE)
Error Subcode : 6(Other Configuration Change)
Notification : Send Notification

on the same dates you mean the same request are posted in IT2001? ie both full days?
Please clarify
usually the Time collision checks are followed only via posting using report rptarqpost and not while applying through portal in ESS
This is very strange you indicate
SO you need to check the basic tables first
You may need to check the collision.
Collisions Tables V_T554Y and V_554Y_B reaction indicators.
and V_T508A
able T582A set to time constraint of "Z
In backend Pa30 collision works like this
1) the logical collision, checks if there is an overlap in the validity
interval of the IT´s (begda, endda).
2) the physical collision, checks if there is an overlap in the time
interval of the IT's.
In the logical collision it is checked if there is an overlap in the
validity interval if at least one of the records is a full-day
( that is the case when you enter a Daily Work Schedule (DWS) )
So when one of the records has a DWS it is considered to be a full day
record and the logical collision is taken into consideration.
If instead you enter the only the time interval manually the records
are considered to be partial-day and the physical collision is
performed. In that case only the time interval is important.
So if the clock times are not entered the physical collision can not
take place.
The collision functionality is always based on clock times and dates,
never on the total nr of hours.
Edited by: Siddharth Rajora on Sep 21, 2011 4:57 PM

How many BGP peers does the 3548 switch support?

Is it possible to run more than 40 peers on a single switch? What is the limitation if not?

Hi ,
You can have 40 BGP peers , IPV4 unicast routes handled by hardware is only 24000 .Enusre all your BGP peering routing updates is within this limits .
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3548-switch/data_sheet_c78-707001.html
Table 7. Hardware Specifications Common to Both Switches
Mode
Normal Mode
Warp Mode
Hardware tables and scalability
Number of MAC addresses
64,000
8000
Number of IPv4 unicast routes
24,000
4000
Number of IPv4 hosts
64,000
8000
Number of IPv4 multicast routes
8000
8000
Number of VLANS
4096
Number of ACL entries
4096
Number of spanning-tree instances
Rapid Spanning Tree Protocol (RSTP): 512
Multiple Spanning Tree (MST) Protocol: 64
Number of EtherChannels
24
Number of ports per EtherChannel
24
Buffer size
6 MB shared among 16 ports; 18 MB total
Boot flash memory
2 GB
HTH
Sandy

A9K BGP

Similar Messages

Maybe you are looking for