Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > BGP: Applying map to find origin - help

Reply
Thread Tools

BGP: Applying map to find origin - help

 
 
Eli
Guest
Posts: n/a
 
      09-08-2004
RTR-A is a foreign (external) router, feeding BGP routes into my
RTR-B in the DMZ. To further feed those routes into my internal
network, internal RTR-C maintains a BGP neighbourhood with RTR-B
through a firewall. Thus my topology is as follows:

RTR-A (as 65520) --> RTR-B (as 65521) --> FW1 --> RTR-C (as 1)

When a DEBUG IP BGP is activated in RTR-B, the message " BGP: Applying
map to find origin " is sent every minute. Is this a point for
concern?

The Network numbers whose origin is referred to are defined in RTR-B
as follows:

interface Loopback4
ip address 4.4.4.1 255.255.255.255
!
interface Loopback5
ip address 5.5.5.1 255.255.255.255
!
ip route 10.235.0.0 255.255.0.0 Null0

Here are the BGP configurations and a full bgp debug output:

RTC-B:
-----
router bgp 65521
no synchronization
bgp log-neighbor-changes
network 4.4.4.1 mask 255.255.255.255
network 5.5.5.1 mask 255.255.255.255
network 10.235.0.0 mask 255.255.0.0
network 192.168.2.16 mask 255.255.255.240
neighbor RTR-A remote-as 65520
neighbor RTR-C remote-as 1
neighbor RTR-C ebgp-multihop 255

router bgp 1
bgp log-neighbor-changes
neighbor RTR-B remote-as 65521
neighbor RTR-B ebgp-multihop 255
neighbor RTR-B update-source Loopback0
!



Cyber-J#
Sep 8 09:34:10: BGP: RTR-A sending KEEPALIVE (io)
Sep 8 09:34:12: BGP: RTR-A received KEEPALIVE, length (excl. header)
0
Sep 8 09:34:17: BGP: Import timer expired. Walking from 1 to 1
Sep 8 09:34:32: BGP: Performing BGP general scanning
Sep 8 09:34:32: BGP(0): scanning IPv4 Unicast routing tables
Sep 8 09:34:32: BGP: Applying map to find origin for 4.4.4.1/32
Sep 8 09:34:32: BGP: Applying map to find origin for 5.5.5.1/32
Sep 8 09:34:32: BGP: Applying map to find origin for 10.235.0.0/16
Sep 8 09:34:32: BGP: Applying map to find origin for 192.168.2.16/28
Sep 8 09:34:32: BGP(IPv4 Unicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:34:32: BGP(1): scanning IPv6 Unicast routing tables
Sep 8 09:34:32: BGP(IPv6 Unicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:34:32: BGP(2): scanning VPNv4 Unicast routing tables
Sep 8 09:34:32: BGP(VPNv4 Unicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:34:32: BGP(3): scanning IPv4 Multicast routing tables
Sep 8 09:34:32: BGP(IPv4 Multicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:34:43: BGP: RTR-C received KEEPALIVE, length (excl. header)
0
Sep 8 09:34:45: BGP: RTR-C sending KEEPALIVE (io)
Sep 8 09:34:47: BGP: Import timer expired. Walking from 1 to 1
Sep 8 09:35:02: BGP: Import timer expired. Walking from 1 to 1
Sep 8 09:35:10: BGP: RTR-A sending KEEPALIVE (io)
Sep 8 09:35:12: BGP: RTR-A received KEEPALIVE, length (excl. header)
0
Sep 8 09:35:17: BGP: Import timer expired. Walking from 1 to 1
Sep 8 09:35:32: BGP: Performing BGP general scanning
Sep 8 09:35:32: BGP(0): scanning IPv4 Unicast routing tables
Sep 8 09:35:32: BGP: Applying map to find origin for 4.4.4.1/32
Sep 8 09:35:32: BGP: Applying map to find origin for 5.5.5.1/32
Sep 8 09:35:32: BGP: Applying map to find origin for 10.235.0.0/16
Sep 8 09:35:32: BGP: Applying map to find origin for 192.168.2.16/28
Sep 8 09:35:32: BGP(IPv4 Unicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:35:32: BGP(1): scanning IPv6 Unicast routing tables
Sep 8 09:35:32: BGP(IPv6 Unicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:35:32: BGP(2): scanning VPNv4 Unicast routing tables
Sep 8 09:35:32: BGP(VPNv4 Unicast): Performing BGP Nexthop scanning
for general scan
Sep 8 09:35:32: BGP(3): scanning IPv4 Multicast routing tables
Sep 8 09:35:32: BGP(IPv4 Multicast): Performing BGP Nexthop scanning
for general scan
All possible debugging has been turned off
 
Reply With Quote
 
 
 
 
JNCIP#0136
Guest
Posts: n/a
 
      09-08-2004
Hello,
You redistributed 4.4.4.1/32, 5.5.5.1/32, 10.235.0.0/16 and 192.168.2.16/28
into BGP and BGP "daemon" needs to "define"/"construct" an ORIGIN attribute
for these routes before sending (ORIGIN is mandatory attribute so it must be
"attached" to BGP route). The reason You are seeing it every minute is due
to well-known BGP scanner process waking up once a minute.
In a short: these messages are harmless unless the debug is permanently on
which is bad for CPU utilization.
HTH,
Cheers
Alex

"Eli" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> RTR-A is a foreign (external) router, feeding BGP routes into my
> RTR-B in the DMZ. To further feed those routes into my internal
> network, internal RTR-C maintains a BGP neighbourhood with RTR-B
> through a firewall. Thus my topology is as follows:
>
> RTR-A (as 65520) --> RTR-B (as 65521) --> FW1 --> RTR-C (as 1)
>
> When a DEBUG IP BGP is activated in RTR-B, the message " BGP: Applying
> map to find origin " is sent every minute. Is this a point for
> concern?
>
> The Network numbers whose origin is referred to are defined in RTR-B
> as follows:
>
> interface Loopback4
> ip address 4.4.4.1 255.255.255.255
> !
> interface Loopback5
> ip address 5.5.5.1 255.255.255.255
> !
> ip route 10.235.0.0 255.255.0.0 Null0
>
> Here are the BGP configurations and a full bgp debug output:
>
> RTC-B:
> -----
> router bgp 65521
> no synchronization
> bgp log-neighbor-changes
> network 4.4.4.1 mask 255.255.255.255
> network 5.5.5.1 mask 255.255.255.255
> network 10.235.0.0 mask 255.255.0.0
> network 192.168.2.16 mask 255.255.255.240
> neighbor RTR-A remote-as 65520
> neighbor RTR-C remote-as 1
> neighbor RTR-C ebgp-multihop 255
>
> router bgp 1
> bgp log-neighbor-changes
> neighbor RTR-B remote-as 65521
> neighbor RTR-B ebgp-multihop 255
> neighbor RTR-B update-source Loopback0
> !
>
>
>
> Cyber-J#
> Sep 8 09:34:10: BGP: RTR-A sending KEEPALIVE (io)
> Sep 8 09:34:12: BGP: RTR-A received KEEPALIVE, length (excl. header)
> 0
> Sep 8 09:34:17: BGP: Import timer expired. Walking from 1 to 1
> Sep 8 09:34:32: BGP: Performing BGP general scanning
> Sep 8 09:34:32: BGP(0): scanning IPv4 Unicast routing tables
> Sep 8 09:34:32: BGP: Applying map to find origin for 4.4.4.1/32
> Sep 8 09:34:32: BGP: Applying map to find origin for 5.5.5.1/32
> Sep 8 09:34:32: BGP: Applying map to find origin for 10.235.0.0/16
> Sep 8 09:34:32: BGP: Applying map to find origin for 192.168.2.16/28
> Sep 8 09:34:32: BGP(IPv4 Unicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:34:32: BGP(1): scanning IPv6 Unicast routing tables
> Sep 8 09:34:32: BGP(IPv6 Unicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:34:32: BGP(2): scanning VPNv4 Unicast routing tables
> Sep 8 09:34:32: BGP(VPNv4 Unicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:34:32: BGP(3): scanning IPv4 Multicast routing tables
> Sep 8 09:34:32: BGP(IPv4 Multicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:34:43: BGP: RTR-C received KEEPALIVE, length (excl. header)
> 0
> Sep 8 09:34:45: BGP: RTR-C sending KEEPALIVE (io)
> Sep 8 09:34:47: BGP: Import timer expired. Walking from 1 to 1
> Sep 8 09:35:02: BGP: Import timer expired. Walking from 1 to 1
> Sep 8 09:35:10: BGP: RTR-A sending KEEPALIVE (io)
> Sep 8 09:35:12: BGP: RTR-A received KEEPALIVE, length (excl. header)
> 0
> Sep 8 09:35:17: BGP: Import timer expired. Walking from 1 to 1
> Sep 8 09:35:32: BGP: Performing BGP general scanning
> Sep 8 09:35:32: BGP(0): scanning IPv4 Unicast routing tables
> Sep 8 09:35:32: BGP: Applying map to find origin for 4.4.4.1/32
> Sep 8 09:35:32: BGP: Applying map to find origin for 5.5.5.1/32
> Sep 8 09:35:32: BGP: Applying map to find origin for 10.235.0.0/16
> Sep 8 09:35:32: BGP: Applying map to find origin for 192.168.2.16/28
> Sep 8 09:35:32: BGP(IPv4 Unicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:35:32: BGP(1): scanning IPv6 Unicast routing tables
> Sep 8 09:35:32: BGP(IPv6 Unicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:35:32: BGP(2): scanning VPNv4 Unicast routing tables
> Sep 8 09:35:32: BGP(VPNv4 Unicast): Performing BGP Nexthop scanning
> for general scan
> Sep 8 09:35:32: BGP(3): scanning IPv4 Multicast routing tables
> Sep 8 09:35:32: BGP(IPv4 Multicast): Performing BGP Nexthop scanning
> for general scan
> All possible debugging has been turned off



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
std::map::find() throws exception when map is empty? Matthias Hildebrand C++ 5 03-20-2012 06:09 AM
If you can help... (map::find and map::insert) Ricardo C++ 8 07-08-2009 01:16 PM
STL map or hash map using struct as data and find it kl C++ 7 01-01-2008 11:05 AM
applying partial_sum to a map container cesco C++ 1 09-11-2006 05:12 PM
map::insert gets a hint. What about map::find? rudymoore@hotmail.com C++ 3 04-20-2005 01:11 AM



Advertisments