09/04/2008
BGP
Path Vector Protocol, Exterior Gateway Protocol
Doesn't have its own transport uses TCP 179
Relies on IGP for basic IP reachability to route BGP, cannot use BGP alone
TIP:Make sure that when u reach to BGP section in Exam, that u read thru the entire section so that you dont have to redo the entire thing
Doesn't run on per interface basis like IGP, can be directly connected or can be remote
Confederations : Are using peering with diff AS, but not truly eBGP connection
When we say neighbor 1.2.3.4 remote-as 1000
==> we will listen for address 1.2.3.4 starting TCP session at port 179
==> Src of BGP packet, will be the interface IP
==> Server needs to agree on the src-ip to which it will accept the connection
Client uses tcp 179 as dst-port, server uses tcp 179 as the src-port
dont need to use update-source on btoh ends.
Only at the client needs it and this needs to be matched with wht is configured on the server
When we do peering with lo0, its is only for REDUNDANCY of control plane (BGP traffic), its not for load bal of data plane traffic.
Load Bal at data plane is a function of IGP.
By default TTL of BGP is 1
so if we do ebgp with non connected neighbors, we need to increase the TTL using ebgp-multihop, so that the TTL is extended to 255 (the max)
don't modify the 255 unless exam says so....
Loop Prevention: cannot accept prefix with our own AS in the path
Can be override by using neighbor [address] allow-as-in
or
neighbor [addresss] as-override
==> V.V IMP ==>When we USE EBGP, the NEXT-HOP is modified to what we set as the peering address for EBGP
We can change this via route-map if we want to
Loop prevention in IBGP:
ibgp learned routes cannot be adv to another ibgp neigh
==> take the routes directly form the ibgp rtr originating the route
==> We need full mesh ibgp peering
===> This is only for CONTROL Plane traffic, real data flow is still based on ibgp next-hop value
To avoid full mesh, we can use route-reflector
or use confederations
there has to be a full mesh ( or RR) within a confederation
in IBGP there is no next-hop modification,
==> So in IGP we need to have those routes to the next-hop as looked up by IBGP
#########Route reflectors ##############
GOAL: Take updates from ibgp neigh and send out to other iBGP neighbors
Three Roles -
-EBGP neighbor
neigh in diff as
-Client peer
neigh with router-reflector-client
-Non-client Peer
neigh without router-reflector-cleint
Update Propagation
-EBGP
to ALL
-Client
to ALL (EBGP, Client, Non-Cleinet )
-Non-Client
to EBGP and to Client, CANNOT pass to non-client
Placement based on the above rules.
Generally, good design, will have all ibgp neig as clients except the other RR
sh ip bgp cmd analysis
> besides the prefix ==> best route and will be added to routing table and will be advertised further
i besides the PATH col, suggested these were originated by using network statements
? redistribution
r RIB Failure OR we already have a better route in the Routing table with lower AD (hardly the case in real life)
if a route is NOT a best path
1) do we have route to next-hop
2) if they are ibgp route, does bgp synchronisation rule come into play
#########################Confederations ###############################
Loop prevention: AS_PATH
Confederation: Sub Autonomous System use the Private AS range, but technically they don't have to
They do that, just to ensure that other's ISP actual AS numbers are not conflicting with the AS # that we have picked
Inside confederation, we need RR or full-Mesh ibGP
Exam Tip: Ensure that u read thru the entire BGP requirement to prevent picking incorrect BGP AS Number.
sh ip bgp cmd analysis
-next hop not modified
-() confederation number in parentheses]
LAB TIP: It may not be a requirement in LAB to have reachability to BBR prefixes. If its unclear , ask the proctor
Showing posts with label IE CoD. Show all posts
Showing posts with label IE CoD. Show all posts
Sunday, April 27, 2008
Sunday, April 06, 2008
Day3: OSPF
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
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
Day 2: IP Routing, PPP, RIP
CCIE IE CoD IP ROuting
31/03/2008
####Load Balancing occurs at L2 #######
For e.g U might see multiple enteries in routing table for a particular detination
However, we might not have enabled the Load Balancing on L2, i.e CEF disabled
####Can we debug Traffic ? #########
UNless traffic is process switched, we will not see its debug on deb ip packet o/p
Also traffic LOCALLY destined to and from the router is always process switched
Thus to disable CEF, do no ip mroute-cache (for multicast) no ip route-cache at interface level to debug transist traffic
If at any stage in debug messages, if we see, encapsulation failed, ==> no L2 to l3 Mappings are available (true for Ethernet/FR)
########Floating Static ROute ############
Frame Relay: Main Interface Status ( UP/UP, etc) is based on LMI whereas
Sub-Interface Status is based on the PVC status
Hence route Pointed to Main Interface never goes down as long as the LMI from Switch are recd by the Router
==> Floating Static ROute with Higer AD never gets installed as the primary static route is never removed
For Point to Point Subinterface: If PVC goes down, then implicitly Main intf goes down as well
For Multipoint Subinterface: If PVC goes down, Sub iNtf goes down, but for Main intg to go down we need all the DLCI to go down
############GRE ######################
IP Protocol 47
has ability to do end to end keepalives
tunnel dest must not recurse out the tunnel interface, use one of the physical interfaces...
##################RIP ###################
RIP v2 works overs Multicast 224.0.0.9, but provides an option on chaninging it to Broadcast using cmd "ip rip v2 broadcast"
So why shud we know this ? Cos in LAB when we asked to FILTER (ACL) we can use Log stmt so tht we can see if it breaks RIP in the DENY Log
RIPv1 is not UNofficially a topic in LAB, but can exspect to be asked to support Rece or Send of RIP v1
RIPv2 might appear in LAB
no auto-summary is not always need to be applied, so dont make it a habit
wht's done at interface level overrides the stuff done at routing (global) level
default:send v1, rec v1 and v2 , but if we cchange this in routin proc, it changes the interface level stuff to send --v2 and rec -v2
Split Horizon: Enabled for all interfaces except for main int in FR
"ip spilt-horizon"
affects FR Hub and Spoke , so we need to disable under a FR sub-interface
If its main interface, split-horizin is disabled automatically
NOTE: For SVI, split-horizon is enabled
For EIGRP: Look into sh run to chk if its disabled or not
"sh ip interface" will show only for RIP
Under Router Rip, when u give a network cmd
==> it automatically advertises the Network is included under that network
To avoid that use Passive interface to disable sending the updates, but cannot stop receiving the updates and advertsing tht network via other interface
To avoid sending out (advertising) the network via other interfaces, use distribute list
If u dont want to rec updates, use ACL or use Authentication ON, and fail them (but this needs to set receive-ver v2),
OR, use neighbor cmd on the routers and on the switch black-hole the MAC address used by the Multicast Address
OR, use distance and set it to 255, but can only affect inbound routes not for outbound routes
Offset-list
Can be used to increase (cannot decrease) the metric along with an ACL
if access-list "0" is provided mean all routers
Can be used also for RIp by {Poisoning} by setting unusable routers by adding offset to 15 or 16, need to find in REAL LAB. Think about the HOP count already received by you. No HARD Coded Rule
Access-list used for Offset List need to be such that it doesnt look at the subnet mask, it only needs to look at the NETWORK portion of the route only.
for e.g : /24 route , access-list 1 permit 150.1.5.0 0.0.0.0 and not 0.0.0.255
o validate-update-source. ==>Disable the validation of the source IP address of incoming RIP routing updates.
REMEMBER: CCIE Test is not a test for Best Practise and Design, So even though ur traffic takes a sub-optimal routing, U DONT CARE, UNLESS THEY ASK U TO WORRY ABT IT
REMEMBER: Similary for REDUCNDANCY case. If they dont explicity ask, we dont worry abt it
#################### PPP ###################################
Features as compared v/s HDLC
-Authentication
-Multilink
-Reliability (RFC 1663)
-ppp reliable-link
-Error Thresholds
-ppp quality percentage
-Optimised PPP Negotiation
-ROuting
-peer neighbor route (ON by Default)
##peer neighbor route##
-Used to provide reacability whe both ends of the PPP link are not on the same logical subnet e.g ip Unnumbered
-Can be safely disabled when both ends of the link are on the same logical IP subnet
- Only needed if using ip unnumbered
NOTE: Subnet mask is not learned with PPP, So it can cause routing issues, Beware.
IN REAL World: Either FR or PPP or HDLC , in WAN Env, you cannot ping yourself
Cos the Ping Packet is placed on the Wire, if the Link's down and if the Remote End is down, then
u cant ping remote end and u cant ping urself, since the packet it sent across the wire. Even if u ping urself, the Packet is sent across the wire
REMEMBER: For PPP Authentication PAP (or CHAP) password must be saved using useranme ... password 0 (or 7) ......
Dont get trapped into using username .... secret ......
Since secret == mean encrypt using MD5,
==> PAP/CHAP cannot work with this HASH value, they need the clear text value to generate their own HASH
###################Policy ROuting ########################
NOTE: When creating new access-list, alwasy ensure that its not already created for some other task
by issuing sh ip access-list.
31/03/2008
####Load Balancing occurs at L2 #######
For e.g U might see multiple enteries in routing table for a particular detination
However, we might not have enabled the Load Balancing on L2, i.e CEF disabled
####Can we debug Traffic ? #########
UNless traffic is process switched, we will not see its debug on deb ip packet o/p
Also traffic LOCALLY destined to and from the router is always process switched
Thus to disable CEF, do no ip mroute-cache (for multicast) no ip route-cache at interface level to debug transist traffic
If at any stage in debug messages, if we see, encapsulation failed, ==> no L2 to l3 Mappings are available (true for Ethernet/FR)
########Floating Static ROute ############
Frame Relay: Main Interface Status ( UP/UP, etc) is based on LMI whereas
Sub-Interface Status is based on the PVC status
Hence route Pointed to Main Interface never goes down as long as the LMI from Switch are recd by the Router
==> Floating Static ROute with Higer AD never gets installed as the primary static route is never removed
For Point to Point Subinterface: If PVC goes down, then implicitly Main intf goes down as well
For Multipoint Subinterface: If PVC goes down, Sub iNtf goes down, but for Main intg to go down we need all the DLCI to go down
############GRE ######################
IP Protocol 47
has ability to do end to end keepalives
tunnel dest must not recurse out the tunnel interface, use one of the physical interfaces...
##################RIP ###################
RIP v2 works overs Multicast 224.0.0.9, but provides an option on chaninging it to Broadcast using cmd "ip rip v2 broadcast"
So why shud we know this ? Cos in LAB when we asked to FILTER (ACL) we can use Log stmt so tht we can see if it breaks RIP in the DENY Log
RIPv1 is not UNofficially a topic in LAB, but can exspect to be asked to support Rece or Send of RIP v1
RIPv2 might appear in LAB
no auto-summary is not always need to be applied, so dont make it a habit
wht's done at interface level overrides the stuff done at routing (global) level
default:send v1, rec v1 and v2 , but if we cchange this in routin proc, it changes the interface level stuff to send --v2 and rec -v2
Split Horizon: Enabled for all interfaces except for main int in FR
"ip spilt-horizon"
affects FR Hub and Spoke , so we need to disable under a FR sub-interface
If its main interface, split-horizin is disabled automatically
NOTE: For SVI, split-horizon is enabled
For EIGRP: Look into sh run to chk if its disabled or not
"sh ip interface" will show only for RIP
Under Router Rip, when u give a network cmd
==> it automatically advertises the Network is included under that network
To avoid that use Passive interface to disable sending the updates, but cannot stop receiving the updates and advertsing tht network via other interface
To avoid sending out (advertising) the network via other interfaces, use distribute list
If u dont want to rec updates, use ACL or use Authentication ON, and fail them (but this needs to set receive-ver v2),
OR, use neighbor cmd on the routers and on the switch black-hole the MAC address used by the Multicast Address
OR, use distance and set it to 255, but can only affect inbound routes not for outbound routes
Offset-list
Can be used to increase (cannot decrease) the metric along with an ACL
if access-list "0" is provided mean all routers
Can be used also for RIp by {Poisoning} by setting unusable routers by adding offset to 15 or 16, need to find in REAL LAB. Think about the HOP count already received by you. No HARD Coded Rule
Access-list used for Offset List need to be such that it doesnt look at the subnet mask, it only needs to look at the NETWORK portion of the route only.
for e.g : /24 route , access-list 1 permit 150.1.5.0 0.0.0.0 and not 0.0.0.255
o validate-update-source. ==>Disable the validation of the source IP address of incoming RIP routing updates.
REMEMBER: CCIE Test is not a test for Best Practise and Design, So even though ur traffic takes a sub-optimal routing, U DONT CARE, UNLESS THEY ASK U TO WORRY ABT IT
REMEMBER: Similary for REDUCNDANCY case. If they dont explicity ask, we dont worry abt it
#################### PPP ###################################
Features as compared v/s HDLC
-Authentication
-Multilink
-Reliability (RFC 1663)
-ppp reliable-link
-Error Thresholds
-ppp quality percentage
-Optimised PPP Negotiation
-ROuting
-peer neighbor route (ON by Default)
##peer neighbor route##
-Used to provide reacability whe both ends of the PPP link are not on the same logical subnet e.g ip Unnumbered
-Can be safely disabled when both ends of the link are on the same logical IP subnet
- Only needed if using ip unnumbered
NOTE: Subnet mask is not learned with PPP, So it can cause routing issues, Beware.
IN REAL World: Either FR or PPP or HDLC , in WAN Env, you cannot ping yourself
Cos the Ping Packet is placed on the Wire, if the Link's down and if the Remote End is down, then
u cant ping remote end and u cant ping urself, since the packet it sent across the wire. Even if u ping urself, the Packet is sent across the wire
REMEMBER: For PPP Authentication PAP (or CHAP) password must be saved using useranme ... password 0 (or 7) ......
Dont get trapped into using username .... secret ......
Since secret == mean encrypt using MD5,
==> PAP/CHAP cannot work with this HASH value, they need the clear text value to generate their own HASH
###################Policy ROuting ########################
NOTE: When creating new access-list, alwasy ensure that its not already created for some other task
by issuing sh ip access-list.
Tuesday, March 25, 2008
CoD: Frame Relay
1) Multipoint Interfaces
Assign MAP statements automatically assigns Circuit (DLCI) to the interface.
So frame-relay map ... config applied ==> No need to do frame-relay interface-dlci .....
2) Layer 3 to Layer 2 Resoultion is only Locally Significatnt.
==> You can use IARP at one end and frame-relay map at other and viceversa
3) sh frame-relay map cmd o/p on Point-to-point interface
When the configuration is verified with the show frame-relay map command, a unicast
layer 3 address is not associated with the DLCI. Instead, the output point-to-point dlci
indicates that any traffic transiting the subinterface will use the DLCI specified on the
interface. In addition to this, broadcast support is automatically enabled on point-to-point
NBMA circuits. This can be seen by the output of the show frame-relay map command,
as the broadcast keyword is associated with the mapping.
4) Not only is layer 3 to layer 2 resolution only locally significant, the type of interface,
whether a main interface, multipoint subinterface, or point-to-point subinterface, is also
only locally significant.
5) no frame-relay inverse-arp ip 405 ==> to remove Mappings for Unused DLCI
6) V V IMP: Minimise Redundant Broadcast Between Hub-Spoke
--Note that on R4 and R5, multiple mapping statements resolve to the same layer 2
address. This is due to the fact that in order for traffic to pass between R4 and R5, it
must first transit R1. Also, note that the broadcast keyword on the end of their frame relay map statements is only used on one mapping. This prevents the spokes from
duplicating the same broadcast or multicast packet that is sent to the interface out the
same circuit.
--Note that the mapping that the broadcast keyword is associated with is
arbitrary, and could be moved to the mapping for R4 and R5's addresses respectively.
This is due to the fact that the broadcast resolution does not relate to the unicast
address, but instead only relates to the layer 2 circuit address.
Assign MAP statements automatically assigns Circuit (DLCI) to the interface.
So frame-relay map ... config applied ==> No need to do frame-relay interface-dlci .....
2) Layer 3 to Layer 2 Resoultion is only Locally Significatnt.
==> You can use IARP at one end and frame-relay map at other and viceversa
3) sh frame-relay map cmd o/p on Point-to-point interface
When the configuration is verified with the show frame-relay map command, a unicast
layer 3 address is not associated with the DLCI. Instead, the output point-to-point dlci
indicates that any traffic transiting the subinterface will use the DLCI specified on the
interface. In addition to this, broadcast support is automatically enabled on point-to-point
NBMA circuits. This can be seen by the output of the show frame-relay map command,
as the broadcast keyword is associated with the mapping.
4) Not only is layer 3 to layer 2 resolution only locally significant, the type of interface,
whether a main interface, multipoint subinterface, or point-to-point subinterface, is also
only locally significant.
5) no frame-relay inverse-arp ip 405 ==> to remove Mappings for Unused DLCI
6) V V IMP: Minimise Redundant Broadcast Between Hub-Spoke
--Note that on R4 and R5, multiple mapping statements resolve to the same layer 2
address. This is due to the fact that in order for traffic to pass between R4 and R5, it
must first transit R1. Also, note that the broadcast keyword on the end of their frame relay map statements is only used on one mapping. This prevents the spokes from
duplicating the same broadcast or multicast packet that is sent to the interface out the
same circuit.
--Note that the mapping that the broadcast keyword is associated with is
arbitrary, and could be moved to the mapping for R4 and R5's addresses respectively.
This is due to the fact that the broadcast resolution does not relate to the unicast
address, but instead only relates to the layer 2 circuit address.
Subscribe to:
Posts (Atom)