[c-nsp] Unusual behavior with CSR virtual Router and customer-triggered RTBHs
Ryan McHugh
ryan.mchugh at gnomishthoughts.com
Mon Nov 17 17:48:04 EST 2014
On Mon, Nov 17, 2014 at 11:46 AM, Ryan McHugh <
ryan.mchugh at gnomishthoughts.com> wrote:
> On Mon, Nov 17, 2014 at 11:43 AM, Ryan McHugh <
> ryan.mchugh at gnomishthoughts.com> wrote:
>
>> I am attempting to configure (currently in a test environment with some
>> IPs masked in output) a Customer-Triggered RTBH with a CSR1000v as my test
>> bed. I am running in to an unusual problem.
>>
>>
>>
>> To start, I have a working RTBH configuration that works when I generate
>> a local static route with tag using a redistribute static route-map in my
>> bgp configuration (based on
>> http://packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/
>> ):
>>
>>
>>
>> route-map Redistribute-Static-to-BGP permit 1000
>>
>> description Redistribute static blocks with tag 666 to BGP for RTBH and
>> forward to RTBH capable Peers
>>
>> match tag 666
>>
>> set origin igp
>>
>> set community 64512:666
>>
>> set ip next-hop 192.0.2.1
>>
>> !
>>
>> route-map Redistribute-Static-to-BGP permit 2000
>>
>> description Redistribute static blocks with tag 6666 to BGP for
>> Source-based RTBH, does not get sent to peers
>>
>> match tag 6666
>>
>> set origin igp
>>
>> set community 64512:6666
>>
>> set ip next-hop 192.0.2.1
>>
>> !
>>
>> route-map Redistribute-Static-to-BGP permit 50000
>>
>> description Redistribute Static with tag 2000 to BGP, add
>> Carry-Route-In-non-Full-Table-Routers Comm
>>
>> match tag 2000
>>
>> set origin igp
>>
>> set community 64512:800 64512:30000 64512:31000
>>
>> !
>>
>> route-map Redistribute-Static-to-BGP permit 55000
>>
>> description Redistribute Static with tag 64512 to OSPF AND BGP, add
>> Carry-Route-In-non-Full-Table-Routers Comm
>>
>> match tag 64512
>>
>> set origin igp
>>
>> set community 64512:800 64512:30000 64512:31000
>>
>> !
>>
>>
>>
>> There are some additional tags that are not related to the RTBH but
>> included for completeness. This setup fully works as expected. The odd
>> behavior occurs when I try to allow my ‘customer’ to send a /32 route with
>> a RTBH request community.
>>
>>
>>
>> The router (CSR0) receives the /32 route from the ‘customer’ device
>> properly, I convert the customer RTBH request community (64512:9999) to my
>> internal RTBH community (64512:666) and set next hop to 192.0.2.1 in the
>> following route-map:
>>
>>
>>
>> route-map Customer-In deny 1000
>>
>> description Block BOGONS from coming in
>>
>> match ip address prefix-list BOGON
>>
>> !
>>
>> route-map Customer-In permit 50000
>>
>> description Accept RTBH request from customer and pass along to carriers
>> that accept them
>>
>> match ip address prefix-list RTBH-Customer-In
>>
>> match community GT-Customer-Request-RTBH-Community
>>
>> set community 64512:666
>>
>> set ip next-hop 192.0.2.1
>>
>> !
>>
>> route-map Customer-In permit 55000
>>
>> description default Accept rule for routes from 'customer'
>>
>> set comm-list Remove-GT-Internal-Tags-From-Customer delete
>>
>> set community 64512:30000 64512:31000 64512:31010 additive
>>
>> !
>>
>>
>>
>> The route properly hits the correct match prefix-list (locks
>> announcements down to only accept /32s) and appears to complete its task
>> correctly, however the Routes are not accepted into RIB and do not properly
>> direct the traffic to NULL0.
>>
>>
>>
>> csr0#show ip bgp
>>
>> BGP table version is 5, local router ID is D.E.F.2
>>
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>>
>> r RIB-failure, S Stale, m multipath, b backup-path, f
>> RT-Filter,
>>
>> x best-external, a additional-path, c RIB-compressed,
>>
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> RPKI validation codes: V valid, I invalid, N Not found
>>
>>
>>
>> Network Next Hop Metric LocPrf Weight Path
>>
>> 0.0.0.0 0.0.0.0 0 i
>>
>> *> A.B.C.0/23 <cust peer ip> 0 0 64555 i
>>
>> * A.B.C.125/32 192.0.2.1 0 0 64555 i
>>
>> *> D.E.F.0/23 0.0.0.0 0 32768 i
>>
>>
>>
>> Customer AS 64555 is announcing A.B.C.0/23 which is properly received.
>> As you see, the A.B.C.125/32 route is not marked as ‘best’ (D.E.F.0/23 is a
>> local announced block from CSR0)
>>
>>
>>
>> BGP routing table entry for A.B.C.125/32, version 0
>>
>> Paths: (2 available, no best path)
>>
>> Flag: 0x820
>>
>> Not advertised to any peer
>>
>> Refresh Epoch 1
>>
>> 64555
>>
>> 192.0.2.1 (inaccessible) from <cust peer ip> (<customer routerid>)
>>
>> Origin IGP, metric 0, localpref 100, valid, external
>>
>> Community: 64512:666
>>
>> rx pathid: 0, tx pathid: 0
>>
>> Refresh Epoch 1
>>
>> 64555, (received-only)
>>
>> <cust peer ip> from <cust peer ip> (<customer routerid>)
>>
>> Origin IGP, metric 0, localpref 100, valid, external
>>
>> Community: 64512:9999
>>
>> rx pathid: 0, tx pathid: 0
>>
>>
>>
>>
>>
>> This of course prevents the RTBH function from working correctly.
>> However, if I add a local static route, for either the Customer A.B.C.0/23
>> or the ‘carrier’ block of D.E.F.0/23, initially I get nothing exciting,
>> except the ‘local’ RTBH works:
>>
>>
>>
>> csr0(config)#ip route D.E.F.244 255.255.255.255 null 0 tag 666 name
>> RTBH-Sacrificial-Helper
>>
>> csr0(config)#end
>>
>>
>>
>> csr0#show ip bgp
>>
>> BGP table version is 6, local router ID is D.E.F.2
>>
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>>
>> r RIB-failure, S Stale, m multipath, b backup-path, f
>> RT-Filter,
>>
>> x best-external, a additional-path, c RIB-compressed,
>>
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> RPKI validation codes: V valid, I invalid, N Not found
>>
>>
>>
>> Network Next Hop Metric LocPrf Weight Path
>>
>> 0.0.0.0 0.0.0.0 0 i
>>
>> *> A.B.C.0/23 <cust peer ip> 0 0 64555 i
>>
>> * A.B.C.125/32 192.0.2.1 0 0 64555 i
>>
>> *> D.E.F.0/23 0.0.0.0 0 32768 i
>>
>> *> D.E.F.244/32 192.0.2.1 0 32768 i
>>
>>
>>
>> However, if I reset the bgp peering with the customer (hard clear, soft
>> does not work), the customer RTBH route works:
>>
>>
>>
>> csr0#clear ip bgp <cust peer ip>
>>
>> csr0#show ip bgp
>>
>> BGP table version is 9, local router ID is D.E.F.2
>>
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>>
>> r RIB-failure, S Stale, m multipath, b backup-path, f
>> RT-Filter,
>>
>> x best-external, a additional-path, c RIB-compressed,
>>
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> RPKI validation codes: V valid, I invalid, N Not found
>>
>>
>>
>> Network Next Hop Metric LocPrf Weight Path
>>
>> 0.0.0.0 0.0.0.0 0 i
>>
>> *> A.B.C.0/23 <cust peer ip> 0 0 64555 i
>>
>> *> A.B.C.125/32 192.0.2.1 0 0 64555 i
>>
>> *> D.E.F.0/23 0.0.0.0 0 32768 i
>>
>> *> D.E.F.244/32 192.0.2.1 0 32768 i
>>
>>
>>
>> csr0#show ip bgp A.B.C.125/32
>>
>> BGP routing table entry for A.B.C.125/32, version 8
>>
>> Paths: (2 available, best #1, table default)
>>
>> Advertised to update-groups:
>>
>> 54
>>
>> Refresh Epoch 1
>>
>> 64555
>>
>> 192.0.2.1 from <cust peer ip> (<customer routerid>)
>>
>> Origin IGP, metric 0, localpref 100, valid, external, best
>>
>> Community: 64512:666
>>
>> rx pathid: 0, tx pathid: 0x0
>>
>> Refresh Epoch 1
>>
>> 64555, (received-only)
>>
>> <cust peer ip> from <cust peer ip> (<customer routerid>)
>>
>> Origin IGP, metric 0, localpref 100, valid, external
>>
>> Community: 64512:9999
>>
>> rx pathid: 0, tx pathid: 0
>>
>>
>>
>> At this point the RTBH works as expected, until I remove the Sacrificial
>> route, shortly after words (at next pass through the table checking for
>> next-hop reachable I assume) the customer /32 route is removed from RIB and
>> the RTBH fails again.
>>
>>
>>
>> Additional info:
>>
>>
>>
>> csr0#show ver
>>
>> Cisco IOS XE Software, Version 03.12.00.S - Standard Support Release
>>
>> Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M),
>> Version 15.4(2)S, RELEASE SOFTWARE (fc2)
>>
>> Technical Support: http://www.cisco.com/techsupport
>>
>> Copyright (c) 1986-2014 by Cisco Systems, Inc.
>>
>> Compiled Wed 26-Mar-14 21:09 by mcpre
>>
>>
>>
>>
>>
>> Cisco IOS-XE software, Copyright (c) 2005-2014 by cisco Systems, Inc.
>>
>> All rights reserved. Certain components of Cisco IOS-XE software are
>>
>> licensed under the GNU General Public License ("GPL") Version 2.0. The
>>
>> software code licensed under GPL Version 2.0 is free software that comes
>>
>> with ABSOLUTELY NO WARRANTY. You can redistribute and/or modify such
>>
>> GPL code under the terms of GPL Version 2.0. For more details, see the
>>
>> documentation or "License Notice" file accompanying the IOS-XE software,
>>
>> or the applicable URL provided on the flyer accompanying the IOS-XE
>>
>> software.
>>
>>
>>
>>
>>
>> ROM: IOS-XE ROMMON
>>
>>
>>
>> csr0 uptime is 1 week, 6 days, 21 hours, 49 minutes
>>
>> Uptime for this control processor is 1 week, 6 days, 21 hours, 49 minutes
>>
>> System returned to ROM by reload
>>
>> System image file is "bootflash:packages.conf"
>>
>> Last reload reason: <NULL>
>>
>>
>>
>>
>>
>>
>>
>> This product contains cryptographic features and is subject to United
>>
>> States and local country laws governing import, export, transfer and
>>
>> use. Delivery of Cisco cryptographic products does not imply
>>
>> third-party authority to import, export, distribute or use encryption.
>>
>> Importers, exporters, distributors and users are responsible for
>>
>> compliance with U.S. and local country laws. By using this product you
>>
>> agree to comply with applicable laws and regulations. If you are unable
>>
>> to comply with U.S. and local laws, return this product immediately.
>>
>>
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be
>> found at:
>>
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>>
>>
>> If you require further assistance please contact us by sending email to
>>
>> export at cisco.com.
>>
>>
>>
>> License Level: limited
>>
>> License Type: Default. No valid license found.
>>
>> Next reload license Level: limited
>>
>>
>>
>> cisco CSR1000V (VXE) processor with 2170596K/6147K bytes of memory.
>>
>> Processor board ID 9FIHGN2ARRJ
>>
>> 3 Gigabit Ethernet interfaces
>>
>> 32768K bytes of non-volatile configuration memory.
>>
>> 4194304K bytes of physical memory.
>>
>> 8822783K bytes of virtual hard disk at bootflash:.
>>
>>
>>
>> Configuration register is 0x2102
>>
>>
>> I am now at the point where I am unable to figure out why the router is
>> working in this manner. Any additional pointers would be appreciated. If
>> need be I will try this on our ASRs during a maintenance window but I
>> prefer to understand what is going on. Obviously it could be a bug
>> unique to the CSR virtual appliance but I prefer to be safe. Any
>> assistance would be greatly appreciated.
>>
>> --
>> Ryan McHugh
>>
>>
> Apologizes, for replying to my own post, but I forgot to mention, I DO
> have a static route in for 192.0.2.1:
>
>
> ip route 192.0.2.1 255.255.255.255 Null0 permanent name
> RTBH-Blackhole-Destination
>
>
> I have tried with and without the permanent.
> --
> Ryan McHugh
>
>
Response to off list reply:
AS I said, it works perfectly when using the local tag triggering, as well
as working just fine as long as I have at least one locally triggered route
in place. If it didn't work at all or worked with out needing a local
route I would be significantly less confused.
It does not work with out the 192.0.2.1/32 null routed at all. I can
however use the incoming route-map from the customer and remove the 'set
next-hop 192.0.2.1' and the CSR will properly install the /32 into RIB, as
well as forward the /32 on to my 'upstream' test router, with that pretend
ISPs RTBH community set. If I could rely on management to only negotiate
with carriers that support RTBH and ignoring settlement-free peerings that
would be fine. I obviously could use a manual method to notify the NOC
that a customer has sent a RTBH request and have a manual route added (our
automation is minimal at this time) but I would prefer to have this working
as intended. Lastly I suppose I could just leave a sacrificial RTBH in
place but I would hate to waste the IP.
And now a further development:
Interesting enough, after clearing the bgp session on the 'customer'
router, the route installs but only for an indeterminate period of time. I
enabled some debugging but I am still not able to identify the specific
cause for the route withdraw:
*Nov 17 22:09:31.157: BGP: ses global <cust peer ip> (0x7FE58143B600:1)
Remote close.
*Nov 17 22:09:31.157: BGP: nbr_topo global <cust peer ip> IPv4 Unicast:base
(0x7FE58143B600:1) Not scheduling for GR
processing [Peer did not advertise GR cap]
*Nov 17 14:09:31: %BGP-5-NBR_RESET: Neighbor <cust peer ip> reset (Peer
closed the session)
*Nov 17 22:09:31.157: BGP: ses global <cust peer ip> (0x7FE58143B600:1)
Reset (Peer closed the session).
*Nov 17 22:09:31.158: BGP: <cust peer ip> rcv message type 3, length (excl.
header) 2
*Nov 17 14:09:31: %BGP-3-NOTIFICATION: received from neighbor <cust peer
ip> 6/4 (Administrative Reset) 0 bytes
*Nov 17 22:09:31.158: BGP: ses global <cust peer ip> (0x7FE58143B600:1)
Receive NOTIFICATION 6/4 (Administrative Reset) 0
bytes
*Nov 17 22:09:31.158: BGP: <cust peer ip> went from Established to Closing
*Nov 17 22:09:31.158: BGP: <cust peer ip> reset due to Peer closed the
session
*Nov 17 22:09:31.158: BGP: tbl IPv4 Unicast:base Service reset requests
*Nov 17 22:09:31.158: BGP: tbl IPv4 Multicast:base Service reset requests
*Nov 17 22:09:31.158: BGP: nbr_topo global <cust peer ip> IPv4 Unicast:base
(0x7FE58143B600:1) NSF delete stale NSF not
active
*Nov 17 22:09:31.158: BGP: nbr_topo global <cust peer ip> IPv4 Unicast:base
(0x7FE58143B600:1) NSF no stale paths state is
NSF not active
*Nov 17 22:09:31.158: BGP: nbr_topo global <cust peer ip> IPv4 Unicast:base
(0x7FE58143B600:1) Resetting ALL counters.
*Nov 17 22:09:31.158: BGP: <cust peer ip> closing
*Nov 17 22:09:31.158: BGP: ses global <cust peer ip> (0x7FE58143B600:1)
Session close and reset neighbor <cust peer ip>
topostate
*Nov 17 22:09:31.158: BGP: nbr_topo global <cust peer ip> IPv4 Unicast:base
(0x7FE58143B600:1) Resetting ALL counters.
*Nov 17 22:09:31.158: BGP: <cust peer ip> went from Closing to Idle
*Nov 17 14:09:31: %BGP-5-ADJCHANGE: neighbor <cust peer ip> Down Peer
closed the session
*Nov 17 14:09:31: %BGP_SESSION-5-ADJCHANGE: neighbor <cust peer ip> IPv4
Unicast topology base removed from session Peer
closed the session
csr0#
*Nov 17 22:09:31.158: BGP: ses global <cust peer ip> (0x7FE58143B600:1)
Removed topology IPv4 Unicast:base
*Nov 17 22:09:31.158: BGP: ses global <cust peer ip> (0x7FE58143B600:1)
Removed last topology
*Nov 17 22:09:31.158: BGP: nbr global <cust peer ip> Open active delayed
13312ms (35000ms max, 60% jitter)
*Nov 17 22:09:31.158: BGP: nbr global <cust peer ip> Active open failed -
open timer running
*Nov 17 22:09:31.158: RT: del A.B.C.0 via <cust peer ip>, bgp metric [20/0]
*Nov 17 22:09:31.158: RT: delete subnet route to A.B.C.0/23
*Nov 17 22:09:31.869: BGP: <cust peer ip> passive open to D.E.F.22
*Nov 17 22:09:31.869: BGP: Fetched peer <cust peer ip> from tcb
*Nov 17 22:09:31.869: BGP: <cust peer ip> passive went from Idle to Connect
*Nov 17 22:09:31.869: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
Setting open delay timer to 30 seconds.
*Nov 17 22:09:31.869: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
read request no-op
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcv message type 1,
length (excl. header) 38
*Nov 17 22:09:31.871: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
Receive OPEN
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcv OPEN, version 4,
holdtime 180 seconds
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcv OPEN w/ OPTION
parameter len: 28
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcvd OPEN w/ optional
parameter type 2 (Capability) len 6
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has CAPABILITY code:
1, length 4
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has MP_EXT CAP for
afi/safi: 1/1
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcvd OPEN w/ optional
parameter type 2 (Capability) len 2
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has CAPABILITY code:
128, length 0
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has ROUTE-REFRESH
capability(old) for all address-families
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcvd OPEN w/ optional
parameter type 2 (Capability) len 2
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has CAPABILITY code:
2, length 0
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has ROUTE-REFRESH
capability(new) for all address-families
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcvd OPEN w/ optional
parameter type 2 (Capability) len 2
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has CAPABILITY code:
70, length 0
*Nov 17 22:09:31.871: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
Enhanced Refresh cap received in open message
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcvd OPEN w/ optional
parameter type 2 (Capability) len 6
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has CAPABILITY code:
65, length 4
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive OPEN has 4-byte ASN CAP
for: 64555
*Nov 17 22:09:31.871: BGP: nbr global <cust peer ip> neighbor does not have
IPv4 MDT topology activated
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive rcvd OPEN w/ remote AS
64555, 4-byte remote AS 64555
*Nov 17 22:09:31.871: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
Adding topology IPv4 Unicast:base
*Nov 17 22:09:31.871: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
Send OPEN
*Nov 17 22:09:31.871: BGP: ses global <cust peer ip> (0x7FE58143B600:0) pas
Building Enhanced Refresh capability
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive went from Connect to
OpenSent
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive sending OPEN, version 4,
my as: 64512, holdtime 90 seconds, ID 44403E02
*Nov 17 22:09:31.871: BGP: <cust peer ip> passive went from OpenSent to
OpenConfirm
*Nov 17 22:09:31.874: BGP: <cust peer ip> passive went from OpenConfirm to
Established
*Nov 17 22:09:31.874: BGP: ses global <cust peer ip> (0x7FE58143B600:1) pas
Assigned ID
*Nov 17 22:09:31.874: BGP: nbr global <cust peer ip> Stop Active Open timer
as all topologies are allocated
*Nov 17 22:09:31.874: BGP: ses global <cust peer ip> (0x7FE58143B600:1) Up
*Nov 17 22:09:31.874: BGP: nopeerup-delay post-boot, set to default, 60s
*Nov 17 14:09:31: %BGP-5-ADJCHANGE: neighbor <cust peer ip> Up
csr0#
*Nov 17 22:09:31.876: RT: updating bgp A.B.C.0/23 (0x0) :
via <cust peer ip> 0 1048577
*Nov 17 22:09:31.876: RT: add A.B.C.0/23 via <cust peer ip>, bgp metric
[20/0]
*Nov 17 22:09:31.876: RT: updating bgp A.B.C.125/32 (0x0) :
via 192.0.2.1 0 1048577
*Nov 17 22:09:31.876: RT: add A.B.C.125/32 via 192.0.2.1, bgp metric [20/0]
*Nov 17 22:09:31.876: BGP_Router: unhandled major event code 128, minor 0
csr0#
*Nov 17 22:09:52.423: BGP: Regular scanner timer event
*Nov 17 22:09:52.423: BGP: Performing BGP general scanning
*Nov 17 22:09:52.423: BGP: topo global:IPv4 Unicast:base Scanning routing
tables
*Nov 17 22:09:52.423: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:09:52.423: BGP(0): Future scanner version: 20179, current
scanner version: 20178
*Nov 17 22:09:52.423: BGP: topo global:IPv4 Multicast:base Scanning routing
tables
*Nov 17 22:09:52.423: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:09:52.423: BGP(6): Future scanner version: 20179, current
scanner version: 20178
csr0#
*Nov 17 22:10:01.553: BGP: aggregate timer expired
csr0#
*Nov 17 22:10:32.280: BGP: aggregate timer expired
csr0#
*Nov 17 22:10:52.426: BGP: Regular scanner timer event
*Nov 17 22:10:52.426: BGP: Performing BGP general scanning
*Nov 17 22:10:52.426: BGP: topo global:IPv4 Unicast:base Scanning routing
tables
*Nov 17 22:10:52.426: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:10:52.426: BGP(0): Future scanner version: 20180, current
scanner version: 20179
*Nov 17 22:10:52.426: BGP: topo global:IPv4 Multicast:base Scanning routing
tables
*Nov 17 22:10:52.426: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:10:52.426: BGP(6): Future scanner version: 20180, current
scanner version: 20179
csr0#
*Nov 17 22:11:52.429: BGP: Regular scanner timer event
*Nov 17 22:11:52.429: BGP: Performing BGP general scanning
*Nov 17 22:11:52.429: BGP: topo global:IPv4 Unicast:base Scanning routing
tables
*Nov 17 22:11:52.429: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:11:52.429: BGP(0): Future scanner version: 20181, current
scanner version: 20180
*Nov 17 22:11:52.429: BGP: topo global:IPv4 Multicast:base Scanning routing
tables
*Nov 17 22:11:52.429: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:11:52.429: BGP(6): Future scanner version: 20181, current
scanner version: 20180
--------------SNIP Repeating----------------------
*Nov 17 22:40:52.519: BGP: Regular scanner timer event
*Nov 17 22:40:52.519: BGP: Performing BGP general scanning
*Nov 17 22:40:52.519: BGP: topo global:IPv4 Unicast:base Scanning routing
tables
*Nov 17 22:40:52.519: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:40:52.519: BGP(0): Future scanner version: 20210, current
scanner version: 20209
*Nov 17 22:40:52.520: BGP: topo global:IPv4 Multicast:base Scanning routing
tables
*Nov 17 22:40:52.520: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:40:52.520: BGP(6): Future scanner version: 20210, current
scanner version: 20209
csr0#
*Nov 17 22:40:52.523: RT: del A.B.C.125 via 192.0.2.1, bgp metric [20/0]
*Nov 17 22:40:52.523: RT: delete subnet route to A.B.C.125/32
csr0#
*Nov 17 22:41:22.958: BGP: aggregate timer expired
csr0#
*Nov 17 22:41:52.522: BGP: Regular scanner timer event
*Nov 17 22:41:52.522: BGP: Performing BGP general scanning
*Nov 17 22:41:52.522: BGP: topo global:IPv4 Unicast:base Scanning routing
tables
*Nov 17 22:41:52.522: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:41:52.522: BGP(0): Future scanner version: 20211, current
scanner version: 20210
*Nov 17 22:41:52.523: BGP: topo global:IPv4 Multicast:base Scanning routing
tables
*Nov 17 22:41:52.523: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop
scanning for general scan
*Nov 17 22:41:52.523: BGP(6): Future scanner version: 20211, current
scanner version: 20210
csr0#show ip bg
csr0#show ip bgp
BGP table version is 18, local router ID is 68.64.62.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, m multipath, b backup-path, f
RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
0.0.0.0 0.0.0.0 0 i
*> A.B.C.0/23 <cust peer ip> 0 0 64555 i
* A.B.C.125/32 192.0.2.1 0 0 64555 i
*> D.E.F.0/23 0.0.0.0 0 32768 i
*> D.E.F.244/32 192.0.2.1 0 32768 i
--
Ryan McHugh
More information about the cisco-nsp
mailing list