Routing & Switching Demystified

OSPF Network types

Following are the various network types in OSPF.

 

Interface type DR/BDR Dynamic neighbor discovery Default hello interval
Broadcast Yes Yes 10
Non-Broadcast Yes No 30
Point to Point No Yes 10
Loopback NA NA NA
Point to multipoint No Yes 30
Point to multipoint nonbroadcast No No 30

Key points to remember

1. OSPF lookback area type is considered as a stub area and advertised as a host.So if the subnet mask of a loopback interface is /24 then only /32 can be seen in the OSPF routing table of neighbors via LSAs. One of the methods to avoid is use network as point to point under loopback interface

2.Dead interval is 4 times that of Hello interval.

3.Point to multipoint non broadcast is Cisco proprietary and is used in Multipoint frame relays or DMVPN related scenarios.

4.The “broadcast” and “non-broadcast” network types will use the next hop IP address of the router advertising the network and you might have to create additional frame-relay maps to solve reachability issues. The “point” network types will use the next hop IP address of the router that we received the information from.

#BGP route selection procedure -Origin type

If you ever worked with BGP, you will see the route information contain; EGP/IGP/INCOMPLETE. What does this mean?

  • IGP = means the prefix was originated from routing information learned from an interior gateway protocol such as OSPF/EIGRP/RIP
  • EGP = means the prefix originated from routing information obtained from a the EGP protocol such as some other eBGP router
  • INCOMPLETE = means the prefix originate mainly from aggregate statement or via redistribution of a static route.

Take a look at this prefix as seen on a route-server at host dot net ( telnet route-server.host.net );
route-server> show ip bgp 27.89.0.0/16

BGP routing table entry for 27.89.0.0/16

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

Not advertised to any peer

13645 19151 2516

64.135.0.1 from 64.135.0.1 (64.135.0.1)

     Origin IGP, localpref 100, valid, external, best

Community: 13645:3111

Last update: Mon Jan 21 13:40:18 2013

 

 

The above shows the originate AS == 2516 and via IGP

Now look at the following;

route-server> show ip bgp 1.229.138.0/24

BGP routing table entry for 1.229.138.0/24

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

Not advertised to any peer

13645 19151 9318 38388

64.135.0.1 from 64.135.0.1 (64.135.0.1)

Origin incomplete, localpref 100, valid, external, best

Community: 13645:3111

Last update: Mon Jan 21 13:40:14 2013

The above originated via AS38388 but the origin information was incomplete. So we can guess it was via aggregation or a redistribution process.

And now the following;

show ip bgp ipv4 unicast 172.16.29.0/24

BGP routing table entry for 172.16.29.0/24, version 124

Paths: (1 available, best #1, table default, not advertised to EBGP peer)

Multipath: eBGP

Advertised to update-groups:

     65001  

Local

   10.0.0.1 (metric 91) from 10.11.0.1 (10.11.0.1)

     Origin EGP, metric 0, localpref 220, valid, internal, best

     Community: 65001:777 no-export

     Originator: 10.11.1.26, Cluster list: 10.23.44.1

Okay the last  route was something that I created in my local LAN. Notice in all samples, how the origin source are all unique?
Okay what does this mean in bgp path selection?   Will part of the tie breaker when we have paths for the same destination, but with different origin type is to prefer lowest origin code.   IGP   Than   EGP   Than   Incomplete   So we select paths that are from a IGP process, over those from a EGP process and like-wise if the origin type is incomplete, is least preferred.   Think of it in this fashion; Who would be more trusted if you want to call some one directly and had their phone #?     1: the person that has his/her number and gives it to you directly?   or   2: the a phone number found in the white pages of the phonebook ?   or   3: some number found laying on the ground and we have no clue as to who/what/where that number originated from?     No this means very little in real-life, because we can enforce or control the origin type via route-map   i.e

Enter configuration commands, one per line. End with CNTL/Z.

rtr1(config)#route-map setorigin permit 10

rtr1(config-route-map)#set origin?

egp remote EGP

igp local IGP

incomplete unknown heritage

So we can change any of the originate information or attribute.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s