Day 3
OSPF
Process ID is LOCALLY Significant
Must have atleast one UP/UP inerface trunning IPV4 for router OSPF to pick it as Router-ID
Network Statement : Misconception: Network Statement relates to Subnet Mask of the network that you are trying to oroiginate
network Statement only is used to pick interface that matches the network statement
For e.g : network 0.0.0.0 255.255.255.255 area 0 ==> ALl interfaces , does not mean that we are originating the Default nwk
In older IOS, the order of entering the network statements were significant, NOt anymore, the newer IOS reorders the network statement to order more specific match first
Forming Adjacencies
########Must Match ####
-area
-hello/dead timers
- MTU
-(OR) ip ospf mtu-ignore
-compatible network types
-stub flags
-authentication
#########Must be unique #########
-Intf IP Address
- OSPF Router-ID
When doing OSPF Adj, chk sh system mtu, it must match one witht he router or use "ip mtu" cmd to change the MTU on rtr on certain interfaces
RECOMMEND: Manually define router-ID, assuming addressing is globally unique, but if u use Anycast IP, then u can have IP duplicates
RECOMMEND: Avoid using Rtr-ID 1.1.1.1 or 2.2.2.2 or like, cos BBRs (backbone routers )cud be using the same, and this can casue inconsistencies in the OSPF Databases.
###############Types###############################
-Broadcast
-Non-Broadcast
-Point-to-Point
-Point-to-Multipoint
-Point-to-Multipoint Non-Boradcast
-Loopback
-Broadcast
-Send Hellos as multicast
-224.0.0.5 (all ospf rtrs in seg ) /224.0.0.6 (all DR/BDR rtrs in the seg)
-uses DR/BDR, to minimise LSA Replication 9Like BGP Router Reflector)
in FR Hub and spoke env
- interface level cmd: "ip ospf network broadcast" on all neighbor's interfaces required.
- ip ospf prio 0 req for spoke sites, so as to avoid them becoming DR/BDR
- no neighbor cmds required on hub
- frame-realy map stmts need broadcast keyword
- If you notice: Next HOp Modification doesn't happen.
- if you notice: DR/BDR are elected.
DR/BDR Election
-Priority, 0 ==> wont participate in election, 255 is max and its best
-No premption in DR/BDR election
==> once DR/BDR are elected, later on a higher prio rtr cannot preempt the DR
-Router-ID
if all teh devices in the segment have the same priority, thena the router0-d wil be chosen
Higer rtr-id is better
Rtr-ID doesnt need to be a valid IP or valid routeable Number, its can be any number in dotted decimal format, for e.g 255.255.255.255 will be the most preferred rtr id
-- Caveat: DR/BDR also depends on whiuch Router is configured first and whose OSPF process converges faster.
#########Debug OSPF####
access-list 100 permit 89 any any
debug ip packet 100
How to find who is the DR in Broadcast/NBMA segments using sho ip ospf Database cmd ??????????
Ans:--The "Net Link States" table shows Who is the DR (BDR cant be found) in teh Adv Router Column for the given Segment as represented by the Link ID
Network Type : NBMA (Updates sent as Replicated Unicast) Has DR/BDR Election, but needs neighbor stmts to be added for Updates to be sent to it as unicast
Hello = 30s , Dead = 120s
FR Main Int
FR multipoint sub-int
ATM interfaces
in FR Hub and spoke env
- Default Network Type for FR (NBMA)
- neighbor cmds under ospf process required on hub, since updates sent as Unicast
- frame-realy map stmts DON'T need broadcast keyword
- ip ospf prio 0 req for spoke sites, so as to avoid them becoming DR/BDR
- If you notice: Next HOp Modification doesn't happen.
- if you notice: DR/BDR are elected.
#################OSPF Network Point to Multipoint #####################
-Not a default Option , need to ue intf cmd "ip ospf network point-to-multipoint"
-Sends hellos as Multicast on 224.0.0.5
-Modifies the next hop
-No DR/BDR elecetion
-Adds in routing table Host /32 route for end points of the links, then uses recursive looksups to find the interface.
-Ensure that you have a broadcast keyword in frame-relay map cmd to allow multicast traffic
-U need to have ONLY 1 Mapping from Spoke to HUB. Rest of L2 mapping is taken care at L3 via OSPF mulitpoint technology
The functional difference between OSPF network type point-to-multipoint versus
broadcast and non-broadcast network types is how point-to-multipoint deals with nexthop
resolution on a non-broadcast media. OSPF network type point-to-multipoint treats
the network as a collection of point-to-point links instead of one flat broadcast network.
With the network types non-broadcast and broadcast, OSPF does not understand that
the underlying layer 2 topology may not mirror a flat layer 3 network. With OSPF network
types broadcast and non-broadcast, next hop values are not modified when updates are
transmitted across an NBMA media. This implies that devices on the NBMA cloud
require layer 3 to layer 2 resolution for any endpoint injecting routes into the network.
With OSPF network type point-to-multipoint, next hop values are modified to the address
of the directly connected neighbor when they are advertised across the NBMA cloud.
This implies that routers on the NBMA network only need layer 3 to layer 2 resolution for
directly connected neighbors when running OSPF network point-to-mulitpoint.
in FR Hub and spoke env
- NOT a Default Network Type for FR
- NO neighbor cmds under ospf process required on hub, since updates sent as multicast
- frame-realy map stmts need broadcast keyword, but only "ONE" map stmt to the HUB, rest are resolved by
- ip ospf prio 0 NOT req for spoke sites, NO DR/BDR in this TYpe
- If you notice: Next HOp Modification DOES happen. There are /32 Routes added for the Link address and the Remtoe networks are pointed to this Link /32 Address.
- if you notice: DR/BDR are NOT elected ( Not supported).
#################OSPF Network Point to Multipoint NonBroadcast #######
-Not a Default Option, use intf cmd "ip ospf network point-to-multipoint non-broadcast"
- Sends hellos as unicast
-neighbor stmts required
-no DR/BDR electioin
- Modifies next-hop
-Can be used when we have PVCs with different costs
-in ethernet : diff BW values for diff neighbors in the link
in FR Hub and spoke env
- NOT a Default Network Type for FR
- Neighbor cmds under ospf process required on hub, since updates sent as unicast
- frame-realy map stmts DON'T need broadcast keyword, AND only "ONE" map stmt to the HUB, rest are resolved by L3 (OSPF)
- ip ospf prio 0 NOT req for spoke sites, NO DR/BDR in this TYpe
- If you notice: Next HOp Modification DOES happen. There are /32 Routes added for the Link address and the Remtoe networks are pointed to this Link /32 Address.
- if you notice: DR/BDR are NOT elected ( Not supported).
- if you notice: ONLY this Network Type, allows COST to be modifed under OSPF process when defining neighbors. => neighbor 10.0.0.4 cost 50 , etc
##########How to change the Cost of a Link ? #########################
Typically to be used in scenarios where u have links > 100mbps , for e.g gig, 10g, OC3, etc
- Interface"Bandwidth"
- Interface "ip ospg cost"
- Process "auto-cost"
-Process "neighbor w.x.y.z cost" ==> used in Multipoint
TIP: How to calculate the Cost of an OPSF Link without using the formual ourselves ?
Ans: Configure on of the physcial lkinsk and change their BW in kbps and then type "sh ip ospf interface" to get its cost
############Point to Point #########
-no DR/BDR
-Update sent as Multicast
"ip ospf 1 area 0 " ==> Eabled at Interface level means that we include the interface for a given area, and ALSO, the secondary addresses if any configured on the itnerface are also enabled for OSPF
This means the secondary addresses will also send out "hello" and form adj
in FR Hub and spoke env
- NOT a Default Network Type for FR
- NO Neighbor cmds under ospf process required on hub, since updates sent as multicast
- frame-realy map stmts need broadcast keyword, since only 1 neighbor, only 1 MAP stmt
- ip ospf prio 0 NOT req for spoke sites, NO DR/BDR in this TYpe
- If you notice: Next HOp Modification DOES NOT happen.
- if you notice: DR/BDR are NOT elected ( Not supported).
Summaray: OSPF network Types
Broadcast can be adj to Non-Broadcast as they both have DR/BDR concept, however we need to ensure tha the Hello/Dead timers are matched
Point-to-point can be adj with Point-to-Multipoint OR adj with point-to-multipoint non-broadcast, as they dont have DR/BDR concept, however we need to ensure tha the Hello/Dead timers are matched
V.V IMP: What gets affected with non-compatible nwks but it appears that u are formining adj , but actually its a neighbor relnaship but not truly adj
-unicast/multicast
-DR/BDR Election
-Next-hop processing
######### OSPF fast Hellos ##############
ip ospf dead-interval minimal hello-multiplier 5
- interface level cmd
- dead int = 1s , hello= 200msx5=1000ms =1s
-so hello sent out every 200ms
1 comment:
Hi DHARMBHAI URF DHARMESSSS
it seems as if u have been referring the same internetwork expert class on demand videos that i have referring to u r a good copy cat
Post a Comment