Jon,

Can you explain this?:

"Because the network statement under OSPF is used to tell the router which interfaces to start on rather than which networks to advertise"

What do you mean by "start on"?

Wilson

I was differentiating between the function of the network statement under BGP and the function under OSPF/EIGRP etc.

router bgp 64521

network 192.168.10.0 mask 255.255.255.240

the above tells BGP to advertise this network to any of it's peers

router ospf 1

network 192.168.10.0 0.0.0.15

this does not tell OSPF to advertise this network to it's peers. What it does is tell OSPF to start OSPF on any interface that falls under the above range. So if on the same router there was the following

int fa0/0

ip address 192.168.10.1 255.255.255.0

then the OSPF config "network 192.168.10.0 0.0.0.15" covers this address ie.

192.168.10.0 0.0.0.15 = 192.168.10.1 -> 192.168.10.15

192.168.10.1 falls within the above range so OSPF starts up on int fa0/0 and will form adjacencies/neighborships with any other routers with interfaces on that subnet running OSPF.

Note that when OSPF starts it sends an advertisement for 192.168.10.0 255.255.255.0 which is the actual subnet mask allocated to the interface and not the subnet mask 0.0.0.15 = 255.255.255.240 configured under router ospf.

Hope this makes sense.

Edit - see also this recent thread which also covers the same point -

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&topicID=.ee71a06&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cc1e1a6/6#selected_message

Jon

Richard

If Jon had said "run on" rather than "start on" would it make any more sense to you?

Jon was addressing a fairly common misunderstanding of the use of the network command in OSPF (and other Interior Routing Protocols). The network statement does not tell OSPF what network to advertise but tells OSPF which interfaces to include in the protocol - or what interfaces to run on. When OSPF runs on an interface it looks at the address and subnet mask information and based on that OSPF decides what to advertise.

HTH

Rick

Hi,

Thank you all for the quick replies. here is more information...

This from one of #2-6513 which are core to the network.

Just as a note, the 2nd 6513 has a p2p gig connection to another location- a stub area.

*************************************

2nd 6513:

router ospf 100

area 0.0.0.0 range 1.1.1.4 255.255.255.252

area 0.0.0.0 range 10.20.20.0 255.255.255.252

area 0.0.0.0 range 10.60.0.0 255.255.0.0

area 0.0.0.0 range 6.9.5.0 255.255.255.192

area 0.0.0.0 range 6.9.5.64 255.255.255.192

area 0.0.0.0 range 6.9.5.128 255.255.255.192

area 0.0.0.0 range 6.9.5.192 255.255.255.192

area 0.0.0.0 range 192.168.100.0/24

area 0.0.0.0 range 192.168.109.0/24

area 0.0.0.0 range 192.168.111.0/24

area 0.0.0.0 range 192.168.160.0/24

redistribute connected

redistribute static

network 1.1.1.4 0.0.0.3 area 0.0.0.0

network 10.20.20.0 0.0.0.3 area 0.0.0.0

network 10.60.0.0 0.0.255.255 area 0.0.0.0

network 6.9.5.0 0.0.0.63 area 0.0.0.0

network 6.9.5.64 0.0.0.63 area 0.0.0.0

network 6.9.5.128 0.0.0.63 area 0.0.0.0

network 6.9.5.192 0.0.0.63 area 0.0.0.0

network 192.168.100.0 0.0.0.255 area 0.0.0.0

network 192.168.109.0 0.0.0.255 area 0.0.0.0

network 192.168.111.0 0.0.0.255 area 0.0.0.0

network 192.168.160.0 0.0.0.255 area 0.0.0.0

!

Below are the 'interface' infor ffrom one of the switches. As you can guess, other switch has similar with HSRP configs..

Also, no seperate interfaces existing for 6.9.5.X subnet.

!

!

interface Vlan11

ip address 192.168.100.2 255.255.255.192

!

interface Vlan12

ip address 192.168.100.66 255.255.255.192

!

interface Vlan13

ip address 192.168.100.130 255.255.255.192

!

interface Vlan14

ip address 192.168.100.194 255.255.255.192

!

interface Vlan15

ip address 192.168.111.2 255.255.255.0

!

interface Vlan16

ip address 192.168.160.2 255.255.255.0

!

interface Vlan25

ip address 10.60.25.2 255.255.255.0

!

interface Vlan100

ip address 6.9.5.2 255.255.255.0

!

interface Vlan101

ip address 10.60.101.2 255.255.255.0

!

interface Vlan109

ip address 192.168.109.2 255.255.255.0

!

interface Vlan110

ip address 192.168.110.2 255.255.255.0

!

interface Vlan121

ip address 10.60.121.2 255.255.255.0

!

interface Vlan151

ip address 10.60.151.2 255.255.255.0

!

Also, no seperate interfaces existing for 6.9.5.X subnet.

Thank you

MS

MS

Thank you for providing the additional information. It shows quite a mixture:

- 2 summarizations are effective and do summarize several smaller prefixes

area 0.0.0.0 range 10.60.0.0 255.255.0.0

area 0.0.0.0 range 192.168.100.0/24

- 3 summarizations have exactly the same size as the subnets on the interfaces, so the summarization does no good (but are not broken or invalid)

area 0.0.0.0 range 192.168.109.0/24

area 0.0.0.0 range 192.168.111.0/24

area 0.0.0.0 range 192.168.160.0/24

- 4 summarizations are broken or invalid since they describe smaller pieces of a larger single subnet

area 0.0.0.0 range 6.9.5.0 255.255.255.192

area 0.0.0.0 range 6.9.5.64 255.255.255.192

area 0.0.0.0 range 6.9.5.128 255.255.255.192

area 0.0.0.0 range 6.9.5.192 255.255.255.192

- 2 of the summarizations are suspect since they describe address blocks that do not correspond to any interface on the router. If the addresses are learned from other routers these might possibly be valid

area 0.0.0.0 range 1.1.1.4 255.255.255.252

area 0.0.0.0 range 10.20.20.0 255.255.255.252

Also you comment that:"no seperate interfaces existing for 6.9.5.X subnet". But there is a subnet for 6.9.5

interface Vlan100

ip address 6.9.5.2 255.255.255.0

HTH

Rick

Hi Rick,

Thank you for the great& detailed input. Got to score all you genius's at the end:-).

1.no seperate interfaces existing for 6.9.5.X subnet". But there is a subnet for 6.9.5

-->I should have phrased this in a correct way. I wanted to mention that interface ip created with /24 and in summarization it was broken in to 4, so this definitely does not sound correct.

2. area 0.0.0.0 range 1.1.1.4 255.255.255.252

area 0.0.0.0 range 10.20.20.0 255.255.255.252

1.1.1.4 : 1.1.1.5 / 30 : Ip for gig interface connceting to other location (ospf stub area)

10.20.20.0 : 10.20.20.1/30 : Ip for gig interface connecting to WAN router at this facility which in turn connects to satellite offices vis T1/ DS3s.

Any comments on this entries?

Also, not related to this query but related to config on same switches.. enabling BGP with some 'network' statements and 'NO' Established neighbour (Active or Never state) will do anything good..?

Thank you

MS

MS

1) We agree about this. There is a single subnet of /24 and the area range statements divide it into 4 parts. This is backwards. The area range is intended to aggregate smaller address blocks into larger address blocks and not to subdivide an address block.

2) if the subnets do exist then the area range command is not invalid or broken. But since it is using the mask 255.255.255.252 it is summarizing to a /30 which is the smallest mask and the area range command is not summarizing any address blocks.

We might need a little more information about the BGP to provide really good answers. I believe that you are saying that the BGP configuration does have some network statements and does have some neighbor statements. But that none of the BGP neighbors are established. If there are no established neighbors then the BGP is doing no real good. If a neighbor state is never then the configured neighbor has never established a BGP neighbor relationship. I would sure want to investigate and see why this has never worked. If the neighbor goes to active state then it implies that at some point the neighbor was working ok but that it is not working now. I would want to investgate and determine the reason that the neighbor can no longer become established.

If there are no established neighbors than the BGP is not doing any good at this time.

HTH

Rick

Hi Rick,

Thank you very much for your quick reply. As far as BGP.. there are no 'Establised neighbors'. Not sure why these configs in place. Just to make my slef clear b4 taking them (entire BGP) out..

Core S1:

router bgp 65529

network 10.29.2.0 mask 255.255.255.0

network 10.29.4.0 mask 255.255.255.0

network 10.40.0.0 mask 255.255.0.0

network 192.168.29.0

network 192.168.100.0 mask 255.255.255.192

network 192.168.100.64 mask 255.255.255.192

network 192.168.100.128 mask 255.255.255.192

network 192.168.100.192 mask 255.255.255.192

network 192.168.109.0

neighbor 10.129.25.2 remote-as 65129 --> Used to be a neighbor and not anymore.

neighbor 6.2.17.1 remote-as 2506

neighbor 6.2.17.1 soft-reconfiguration inbound

ip bgp summary:

Neighbor up/down State/PfxRcd

10.129.25.2 16w1d Active

6.2.17.1 never Idle

Core S2:

!

router bgp 65030

network 172.16.30.0 mask 255.255.255.0

!

172.16.30.0/24 : IP space assigned for RA VPN cleints at another location (on VPN concentrator).

ip bgp summary:

Thank you

MS

MS

I would interpret this that sometime since the BGP process started (probably when the router booted) the neighbor at 10.129.25.2 has been established but it no longer is. I am not sure how to interpret your comment that it "Used to be a neighbor and not anymore". Is the not anymore just an acknowledgement that it is not working now or does it indicate that there is a reason why it should no longer be an established neighbor.

If the neighbor should be established and is not then some troubleshooting is called for. If neither neighbor is valid (should be establihsed) then there is no reason not to remove the BGP config.

On S2 if the config of BGP truly has no neighbor statements then I do not see any good that it could do and you should feel free to eliminate this.

HTH

Rick

Hi Rick,

Thanks again for your reply.

10.129.25.2 :"Used to be a neighbor and not anymore". --> The rtr with this IP used to be BGP neighbor for the one of the core sw. That site was deco'ed later. So it looks like BGP can safely be re moved from these switches.

Thank you all for your time & valuable replies/suggestions.

regards

MS

MS

Yes it sounds like the BGP can be safely removed.

I am glad that my responses and suggestions have been helpful. Good luck with getting things updated.

HTH

Rick