OSPF Network types
Following are the various network types in OSPF.
Interface type DR/BDR Dynamic neighbor Default hello interval
discovery
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 No No 30
nonbroadcast
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.
Read more: http://networklessons.com/ospf/ospf-next-hop-ip-address-with-different-network-types/#ixzz3FIDFbmNy
#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.
Comments