How to Log Debug Level Messages IOS XR

[TrivialPants]

How do you log debug level messages on IOS XR routers?

I have the following configuration for my logging:

logging trap debugging
logging events level informational
logging console alerts
logging history size 200
logging history errors
logging monitor critical
logging buffered errors
logging <SYSLOG IP> vrf managementvrf

and here is the output of show logging:

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: level alert, 987818 messages logged
    Monitor logging: level critical, 22 messages logged
    Trap logging: level debugging, 22988449 messages logged
    Logging to <SYSLOG IP>, 12539 message lines logged
    Buffer logging: level error, 120898 messages logged

I have enabled a BGP debug with the following:

debug bgp update

However, I am still only seeing non-debug messages on my syslog server. Any advice?

[pman]

Hi,

Try adding
logging source-interface <gigabitEthernet 0/0/0/0> vrf managementvrf

[balaji.bandi]

Syslog messages can be sent to destinations other than the console, such as the logging buffer, syslog servers.

Once the Logging buffer full, OLD messages will be deleted and new message will be stored.

as per your config: You do have the Syslog server configured: using a source of VRF, can the Syslog server be reached? check with ping ( do you have any firewall between device and syslog then you need to Open UDP/514 port to ship logs to syslog server.

logging <SYSLOG IP> vrf managementvrf

Logging to <SYSLOG IP>, 12539 message lines logged

what logs to ship you can use the below guide :

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-5/system-monitoring/configuration/guide/b-system-monitoring-cg-asr9000-65x/b-system-monitoring-cg-asr9000-65x_chapter_0101.html

[TrivialPants]

Hi All,

The syslog is reachable and is updating with messages. However when i turn on debug bgp updates, I dont' see the verbose bgp messages showing up on the syslog. Just the normal bgp adjacency changes. I am getting logs to my syslog server okay, but I would like to get more detailed debug messages.

Thank you!

[TrivialPants]

I was able to get it to send the debug messages by entering this command:

logging <SYSLOG IP> vrf managementvrf severity debugging

but I still am not sure how to make the debug persist outside of my current terminal session? I can enable bgp debug, but as soon as I exit the debug flags are turned off and the debug messages go away.

is there a way to make them persistent through sessions?

[balaji.bandi]

Running debug all time not advisble.

Coming to your problem, you mean as soon as you logout from console, the debug turn off.

can you SSH to device and chcek show debug  (is the debug still on or no debug  ?)

[TrivialPants]

Hi @balaji.bandi that is right. As soon as I exit the current session, the debug flags are unset. 

Is it possible to keep them enabled so I can attempt to have a debug log of the issue when it arises? 

[Giuseppe Larosa]

Hello @TrivialPants ,

what is the issue you are trying to troubleshoot ?

Because having the debug active for long times means an impact on the route processor of the node.

You can build in SecureCRT or using CLIAnalyzer  a script that sends  a "!" every two seconds to keep the SSH session alive for long times or you can disable the timeout on the line vty.

But before doing this, can you explain what your issue ?

IT is intermittent the BGP session is terminated by the peer from time to time ?

There are ways to detect errors on BGP sessions without using debug.

Hope to help

Giuseppe

[TrivialPants]

Thanks Giuseppe,

We have a BGP peer - the only one of several which is giving some issues. This peer is connected logically to our core router on a Bundle interface on our core BGP router.

It is transported across our internal transport network from the ingress PoP via an mpls l2vpn.

We are not seeing any errors on the mpls path or on any of the interfaces, but the BGP is dropping daily, at least.

Does that provide some more insight? Perhaps this is something you maybe have seen before?


We were hoping to gather more details about why it was dropping BGP with more verbose debug logs.

[Giuseppe Larosa]

Hello @TrivialPants ,

>> it is transported across our internal transport network from the ingress PoP via an mpls l2vpn.

>> We have a BGP peer - the only one of several which is giving some issues. This peer is connected logically to our core router on a Bundle interface on our core BGP router.

if your core BGP router  is a virtual chassis you should configure the MAC address under the bundle interface.

>> We are not seeing any errors on the mpls path or on any of the interfaces, but the BGP is dropping daily, at least.

It is dropped for lack of BGP keepalive from the neighbor what timers are you using ?

It is a strange architecture as usually an eBGP peer is configured on a border PE instead of steering the traffic at L2 in a pseudowire and then present it to the core device.

However, that kind of service is provided by many internet IXPs and it is named wide or WAN area peering.

You should use a dedicated L3 interface on core router that is not the loop0 as source of the eBGP session. But I'm sure you are doing this already.

Hope to help

Giuseppe