11:01 AM 3/7/2010 HKT
LAB 3 VOLUME 4 Notes:
Ticket 1 – RIPv2
• Fix the issue preventing R6 from learning RIPv2 prefixes from BB1.
• Do not change the IP addressing on R6 to resolve this problem.
-Know the scope of the problem.
-Check RIP running config first. Check interfaces running RIP.
-Check interface status up/down
-Check Layer 2 parameters, do ping test.
-PPP can be stuck in LCP exchange, check any authetication issue.
-This ticket is not directly related RIP but rather related to L2 PPP issue on the Serial link running RIP.
-Enable logging console and logging buffered
debug ppp negotiation – Look for “Authentication Failure” for hints.
show ip protocols
show ip route rip
show interface x/x
show frame-relay pvc yyy
show interface virtual-access x | i PPP|packets
Ticket 2 – BGP Peering
• The BGP session between R6 and SW2 is not coming up for some
reason.
• Find what might be causing this and fix the problem applying minimal
changes.
-BGP check – Remember BGP is a layer 4
-Underlying issue maybe related to switch trunking or any layer2 issue.
-Make sure the layer 2 is intact.
-Mark all access and trunk links.
-If using DTP (no switchport noneg) make sure VTP names and password are consistent, else trunks using DTP will not come up.
-Checking of logs is very critical, make sure to familiarized log checking.
-This case is not directly related to any BGP process or layer 4 issue, but rather some layer 2 trunking issue.
-Check BGP decent running config.
show spanntree vlan xxx
show interface fx/x switchport | i Mode
show vtp status
show ip bgp summary.
Ticket 3 – Backup Link
• Users on VLAN42 report terrible performance when connecting the
servers on VLAN5.
• You suspect that the problem is that packets are taking suboptimal path across the backup ISDN link between the two sites.
• Restore optimal performance and ensure the primary path over Frame-Relay cloud is being used.
-This setup is a dual link via Serial p2p and Serial frame-relay ckt.
-FR is down. Check for FR configuration, proper DLCI assignment.
-Check EEK.
-Check OSPF neighbor
-EEK is applied via a map-class, make sure it is consisted on both ends.
debug interface xx
debug ip ospf adj
show ip protocols
show interface xx | i LMI
show frame pvc xxx | s UNUSED
show frame-relay pvc | i DELETED
Ticket 4 – Network Optimization
This ticket requires Tickets 1 and 2 resolved prior to starting.
• After a recent merge process, some networks have been joined together.
• In order to provide end-to-end connectivity, mutual redistribution has been configured between RIP and OSPF on R1, R2, R3, R4 and SW1.
• However, the straight-forward configuration approach resulted in network instabilities and sub-optimal routing.
• Fix the network configuration to ensure optimal routing, which means
using high-speed links (Ethernet and Frame-Relay) for primary data paths.
• The routers behind R5 should receive a single default route to reach the rest of the network.
• R4 may still use the Serial link to reach the networks behind R5.
-Redistribution issue.
A. layout 1
RIP-R2–OSPF—-R1—–OSPF—-R3—
| |
|__RIP-SW2-RIP__|
Beware of layout 1 when doing mutual redistribution on all router involved (R1, R2, R3,SW2). The ospf and RIP domain will by default will looped back.
N: At R2 make rip distance lesser than OSPF (e.g. distance 109 – router rip)
B. Redistribution troubleshooting technique.
-Shut down some interfaces to make the topology simple. Check whether you can get expected routes from the neighboring routers.
-Check for filtering in or out direction on the 1. interface, routing process.
-Alternative to bumping up AD of OSPF versus RIP, you can bump down RIP AD targeting only from a specific neighbor.
e.g.
router rip
distance 109 x.x.x.x 0.0.0.0
x.x.x.x is the neighbor.
-this makes routes from neighbor x.x.x.x to have a better distance learned from OSPF.
or it is usually like this:
router ospf 1
distance ospf external 121
! or
distance 110 x.x.x.x 0.0.0.0
! or
router ospf 1
redistribute rip metric 10000 subnets <<<<<<<makes sure the the redistributed routes to OSPF has a worse metric.
General Rule in Redistribution:
1. Native prefixes for one protocol should be reached via this protocol, can have the best metric against others.
2. External prefixes should have AD that is worse than the AD of the native prefixes from different protocol.
3. When injecting external information into a protocol, assign it a high metric value to make is less preferred.
4. You can safely generate default route for stub domains but watch out and do filter of this default if needed.
Redistribution commandments notes:
1. ospf to eigrp -> 110 to 170 -> ok
2. eigrp to ospf-> 90 to 110 -> ok
3. eigrp(external) to ospf -> 170 to 110 <<<– problem here, not ok, watch out!
4. lower AD wins
TECHNIQUES:
1. route tagging
2. route summarization
3. distance
To the following with redistributing:
1. Check first all native routes per router.
2. Check all external routes per protocol type, perrouter.
3. Think of the redistribution commandments.
4. Can make ospf acts like EIGRP on dealing with external prefixes. (distance ospf external 171)
5. Bump up or bump down certain prefixes. (external or internal).
6. The distance of external EIGRP cannot be changed on a per prefix basis.
7. ping the destination using the source IP address interface on different network
8. debug ip packet detail with an ACL (ACL is permit icmp from any to any or host)
9. Adjust default AD of IGP. RIP->109, OSPF= 121, OSPF External = 171, ospf = 89, depends on the situation and requirments.
Watchout on the following with redistributing.
1. route feedback.
2. manually tag the route with higher AD with put into the redistributed towards the lower AD.
3. lockdown pre-redistribution externals to equal to the native AD (e.g. distance 110 0.0.0.0 255.255.255.255 ACL_EXTERNAL_ALREADY
4. The rest of new routes coming is can be bump up (distance ospf external 171)
5. Item 3,4 are OSPF and EIGRP samples.
-debug ip routing
-show ip route xxx
-show ip rip data
-show ip ospf topology
Ticket 5 – Server Farm
• Two new servers have been recently connected to SW1 port 0/18 and SW2 port 0/19 respectively.
• For the lab purpose, the servers are emulated by L3 ports in SW3 and SW4 respectively.
• The following is the configuration policy for the server block:
o The new servers are assigned to the subnet 192.10.X.0/24
o To ensure security, the servers should not be able to communicate directly.
o The servers should be able to reach and communicate via R4.
• However, the configuration appears to be incomplete, as servers cannot reach to each other.
• Ensure the connectivity via R4 and verify it by using IP addresses assigned to the switchports of SW3 and SW4.
-This case is related to private vlan configurations.
show interface f0/x switchport | i private-vlan
show interface trunk
show vlan id
show ip interface f0/xx | i arp
Ticket 6 – BGP
• AS254 and AS54 cannot exchange routes across AS 100, AS 200 and AS 300.
• Applying changes to BGP configurations only, restore the end-to-end connectivity.
• Do not apply any changes to AS 300 routers to accomplish this.
• The ticked will be resolved when AS 54 and AS 254 could see each other’s routes.
-External BGP loop prevention mechanism uses AS-PATH information.
-The use local-as on the source AS will generate the AS path information.
-Use allowas-in on the far receiving end
-Make user no other L2/L3 issue exist. IGP should be stable at this time. No routing loops occured.
-Check for IBGP relationships and watch out for route-refrelector requirments.
show ip bgp regexp _
show ip bgp neig xxx advertise-routes
show ip bgp sum
show ip bgp neig | i state|neighbor|index|update-group|reflec
show ip bgp update-group
Ticket 7 – L2VPN
• You have tasked a junior system administrator to configure an L2VPN tunnel between VLAN64 and VLAN46 interfaces of R6 and R4.
• Some time after this, he reported that the configuration has been done, but there are some issues preventing it from working properly.
• Find and resolve the issues preventing the Layer 2 VPN tunnel from coming up.
-Watch out for inconsistend ckt id name. Ckt id should be the same on both ends.
show vpdn tunnel
show vpdn session
show l2tun session all
show sss circuits
Ticket 8 – L2VPN Issues
• The Frame-Relay connection between R1 and R2 has been recently replaced with L2 VPN. Soon after this, users on VLAN263 started complaining that they cannot download files from the servers on VLAN42.
• They still could use telnet and ssh to access the servers though.
• Suspecting that this may be caused by Path MTU discovery failures, you configured a workaround by clearing DF bit on all TCP packets received by R2 on its VLAN263 interface.
• However, this does not seem to help and the problem persists. Find the solution to this problem that works for all types of network traffic.
-Do ping test with oversized packet to check fragmentation issues.
-Fragments per packet is controlled by VFR – ip virtual-reassembly max-fragments x command.
-Using ip tcp adjust-mss will keep the router to modify and MSS field in TCP packet header. MSS is 40 bytes less than the MTU. Only for TCP.
-IP virtual-reassembly, use to set max amount of fragmented packets
There are basically few ways to filter fragmented packets:
1) Using an access-group applied to an interface.
2) Using a policy-map that routes fragmented traffic to Null0.
3) Using a service-policy that drops fragments.
4) Configuring IP virtual-reassembly on interface.
5) Using IOS IPS to drop fragmented traffic.
6) Using CoPPr or Control-Plane policing to restrict packets going to the router.
show ip virtual-reassembly | i Fragments
show ip int xx | i list
show ip ips all
show ip policy
Ticket 9 – NTP
• You have recently re-loaded the configuration for R3 and R4 using the backup copies and soon after that discovered the logging timestamps went wrong.
• You know that NTP has been used for time synchronization on R3 and R4.
• R5 was supposed to be the NTP master for R3 and R4.
• You may assume that R5 is configured correctly and fix the issues in R3 and R4.
-NTP key should match on Server and client.
-Use key chain to decrypt md5 hash on same router.
-if the master NTP server is using ACLS on the peers and clients make sure the clients and peers are allowed on the ACL. Make sure NTP source is allowed.
-NTP authentications need to do “ntp authenticate” command
-NTP key should be manually trusted.
show ntp status
show ntp ass detail
Ticket 10 – Internet Access
• After the recent security policy changes users on VLAN5 started complaining they cannot reach YouTube videos anymore.
• Asking a few questions you found that uses cannot access any other WWW sites as well.
• After a short investigation you found that the uplink used to reach the YouTube website is via BB1.
• Talking to the users you found that only HTTP is being affected, FTP downloads work well.
• Applying minimal changes to the network configuration resolve this problem and restore WWW connectivity.
-Related to WWW access only. Described that FTP traffic is not affected.
-Not Path MTU issue.
-Watch out for TOS value is matched and on the route-map is set to drop it to null0 interface.
-The DF bit can be cleared using route-map. set ip df 0.
-Check MTU issue
-Check local policy-map
-Check ip ips
-Check route-maps applied to the interface, make sure it is not dropping it.
-enable http server on each router as a test to web traffic.
ip http server
ip http path flash:
copy http://x.x.x.x/test null:
sho ip policy
show ip ips all
show ip int virtual-access x | i access
