Re: Understanding BGP Table Entry

visitor68 · ‎04-15-2009

Im confused about something, maybe someone can help.

I am on a router that is running OSPF and BGP.

It natively advertises a network using the "network" command under its BGP process.

But I am getting a strange output from the "sh ip bgp <prefix>" command. What is strange about it is that it shows a next hop of 10.36.125.249 but that is our firewall and it does not run BGP. Also, it selects OSPF as the route to place in its routing table when this router itself originated the route!

Can you say 'confused'?

EXTRANET#

EXTRANET#sh ip bgp 172.20.4.0

BGP routing table entry for 172.20.4.0/24, version 107296

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Multipath: eBGP

10.36.127.255 (metric 6) from 10.36.127.255 (10.36.127.255)

Origin IGP, metric 37, localpref 100, valid, internal

Local

10.36.125.249 from 0.0.0.0 (10.36.127.254)

Origin IGP, metric 37, localpref 100, weight 32768, valid, sourced, local, best

EXTRANET#

EXTRANET#sh ip ro 172.20.4.0

Routing entry for 172.20.4.0/24

Known via "ospf 2004", distance 110, metric 37, type inter area

Advertised by bgp 64512

Last update from 10.36.125.249 on Vlan499, 06:05:31 ago

Routing Descriptor Blocks:

* 10.36.125.249, from 10.36.31.250, 06:05:31 ago, via Vlan499

Route metric is 37, traffic share count is 1

EXTRANET#

Thanks

Giuseppe Larosa · ‎04-15-2009

Hello Joe,

network command in BGP has a different meaning:

it looks for the prefix in the ip routing table regardless of the prefix to be connected or learned by another routing protocol.

if it finds it it creates the BGP advertisement to be sent to BGP neighbors.

This doesn't mean that the local routing table will use the BGP advertisement: the local node uses the prefix found in the routing table OSPF in your case.

Being the process reverted, BGP advertisement can use as next-hop attribute the OSPF route's next-hop 10.36.125.249

10.36.125.249 from 0.0.0.0 (10.36.127.254)

Origin IGP, metric 37, localpref 100, weight 32768, valid, sourced, local, best

where the next-hop is 10.36.425.249, local and weight 32768 means the BGP advertisement is locally generated with a network command (origin IGP) the metric (MED) attribute = OSPF route metric

If you think of it in this way it should be more clear.

Hope to help

Giuseppe

visitor68 · ‎04-15-2009

Hi, Giuseppe:

I have to say I am still confused.

I do know that BGP will not advertise a network prefix until it has an entry in its RIB. If it is advertising a supernet/summarized route, it should have at least one subnet of that summarized route in the RIB. If it uses the "mask" keyword, the RIB entry has to be identical before BGP advertises it. This is all part of the BGP synchronization (split horizon) rule.

Am I correct about all this?

If so, I still dont understand why the BGP table will give a non-BGP speaker as a "next-hop" from which it supposedly learned about the prefix through BGP.

When I see the output of the "sh ip bgp " command, I am expecting to see the paths that were injected into the BGP table by the receiving BGP-speaker when it received those paths from its BGP peers.

As for using the OSPF route, I guess I can see where my thinking was wrong. BGP will advertise the prefix IF its in the RIB, as I stated above. But that is the only route it has to that prefix. Its not as if it learned the route through another BGP speaker and OSPF too and then had to decide which is the best routing protocol to use (ie lowest AD).

But I am still stuck with the BGP table issue. Sorry.

visitor68 · ‎04-15-2009

Giuseppe:

"When I see the output of the "sh ip bgp " command, I am expecting to see the paths that were injected into the BGP table by the receiving BGP-speaker when it received those paths from its BGP peers."

Wait a minute! I think I got it. :-) And its rather simple, too.

It shows the OSPF firewall as the next hop because it DID learn about it through BGP -- its OWN BGP process! In othr words, the router is saying, "I learned about this prefix through BGP from 2 speakers, one was bla bla bla neighbor, and the second was ME. I advertised it natively to my peers and my BGP process knows about it ONLY because it exists in the RIB as an OSPF route."

Therefore, the OSPF firewall does act as a next hop, and that next hop was learned from itself through the network command (0.0.0.0 and weight 32768).

Correct?

Therefore, the output itself should tell the engineer that the router is acting as a redistribution point. Yes?

Thanks!

Giuseppe Larosa · ‎04-15-2009

Hello Joe,

you got it

sh ip bgp prefix

shows also a bgp prefix injected locally by using the keyword local and weight 32768

Formally it is not a redistribution point if using network command but the idea is correct

Hope to help

Giuseppe

visitor68 · ‎04-15-2009

Thanks, Giuseppe:

Last question from the previous post.

I do know that BGP will not advertise a network prefix until it has an entry in its RIB. If it is advertising a supernet/summarized route, it should have at least one subnet of that summarized route in the RIB. If it uses the "mask" keyword, the RIB entry has to be identical before BGP advertises it. This is all part of the BGP synchronization (split horizon) rule.

Am I correct about all this?

Giuseppe Larosa · ‎04-15-2009

Hello Joe,

there is still two variants of this behaviour depending on the settings of

auto-summary

no auto-summary

with no auto-summary:

a perfect match including mask is needed.

with auto-summary (auto-summary enabled)

a major network command (without mask option) will match if a component route is present.

All practical deployments use the no auto-summary option so an exact match is needed mask included

now no auto-summary is default:

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#wp1041161

to create a summary route when BGP is classless (no auto-summary) the command

aggregate-address

is needed

see

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#wp1011467

Hope to help

Giuseppe