[info]1.1 (Layer 2 Features)[/info]
[success]When told to make a switch the primary STP root bridge for a specific VLAN:[/success]
spanning-tree vlan # root primary (global)
[success]When told to make sure a VLAN never traverses a switch:[/success]
interface (trunk interface)
switchport trunk allowed vlan 1-101,103-4094 <–VLAN 102 is not allowed
[success]When told that users are complaining how long it takes to get an IP Address from a DHCP server or the DHCP requests time out:[/success]
interface <interface>
spanning-tree portfast
[success]When that any ports in a VLAN will be shut down if a device is running spanning-tree protocold is detected:[/success]
spanning-tree bpduguard (global)
[info]2.1 (OSPF)[/info]
[success]When told that Router# should always be elected DR:[/success]
interface <interface>
ip ospf priority 0 (ON ALL SPOKES)
[success]When told that host devices should not intercept the OSPF communication between R# and R#:[/success]
interface <interface>
ip ospf network non-broadcast (Now you need to use the neighbor command)
!
router ospf 1
neighbor <ip address>
[success]When told to advertise a VLAN but you can not use “network” or “ip ospf” commands:[/success]
(Use route maps)
ip prefix-list VLAN_# permit <ip subnet>
!
route-map CONNECTED->OSPF permit 10
match ip address prefix-list VLAN_#
!
router ospf 1
redistribute connected route-map CONNECTED->OSPF subnets
[success]When told that the OSPF traffic should flow over the ethernet segment instead of the FR cloud and do no use the “backup interface” command:[/success]
R4:
interface fa0/0
ip ospf cost 10000 <–A higher bandwidth indicates a lower cost
[success]When told a router should detect a loss within 1 second:[/success]
interface <interface>
ip ospf dead-interval minimal hello-multiplier 3
[error]Area 0 will be broke if the FR line goes down between R5 and R4 and the ethernet backup line kicks in. Pay attention to situations that will break up area 0. If it does, virtual links will be needed just like in this task. Remember that a virtual link is actually an extension of Area 0.:
R4:
router ospf 1
area 45 virtual-link 150.1.5.5
R5:
router ospf 1
area 45 virtual-link 150.1.4.4[/error]
[info]2.2 (IGP Features)[/info]
[success]When told a router should use the most secure authentication:[/success]
key chain <name>
key 1
key-string <password>
interface <interface>
ip rip authentication mode md5
ip rip authentication key-chain <name>
[success]When told you should redistribute between OSPF and EIGRP:[/success]
router eigrp #
redistribute rip metric 10000 100 255 1 1500
router rip
redistribute eigrp 100 metric 1
[success]When told to route through a router when you have two routes and you’re dealing with two different protocols like EIGRP and OSPF, you need to keep a look out for AD distances when doing redistribution. Please go to http://cordero.me/blog/igp-redistribution-311 for more info:[/success]
route ospf 1
distance 89 0.0.0.0 255.255.255.255 1
[error]In this case we are dealing with internal EIGRP which has a AD of 90. We had to make OSPF’s AD 89, just under 90, in order for traffic to take the OSPF route.[/error]
[info]2.3 (BGP)[/info]
[success]When told you have multiple connections to AS54 and in order to maximize throughput your policy dictates that all traffic destined for prefixes originated in AS54 should traverse the FR link between R6 and BB1 AND When told when one of links goes down, you should use another link but do not use weight:[/success]
[error](If you can’t use weight then your other choice is local preference)[/error]
ip as-path access-list 1 permit _54$
!
route-map LOCAL_PREFERENCE permit 10
match as-path 1
set local-preference 200 (the path with the highest local preference will be the preferred path)
!
route-map LOCAL-PREFERENCE permit 1000
!
router bgp 100
neighbor 54.1.1.254 route-map LOCAL_PREFERENCE in
[success]When told to create a new loopback and advertise it:[/success]
int loopback1
ip address 10.1.1.0 255.255.255.0
!
router bgp 200
network 10.1.1.0 mask 255.255.255.0
[success]When told to have traffic for a prefix sitting in one AS# coming from another AS# that has TWO paths to get to that prefix (So we are talking inbound traffic.) and you’re told not to use AS-Path Pre-Pending, you’re only other choices is to use MED or The Community Attribute Coupled with the Local-Preference Attribute. MED is the correct choice:[/success]
R2: (Border router inside the AS where the prifix resides)
ip prefix-list R1_BGP_LOOPBACK seq 10 permit 150.1.11.0/24 <–The prefix we are trying to get to
!
route-map MED permit 10
match ip address prefix-list R1_BGP_LOOPBACK
set metric 200 (A lower MED value is preferred over a higher value)
!
route-map MED permit 1000
!
router bgp 200
neighbor 183.1.123.3 route-map MED out
SW4: (Border router inside the AS where the prifix resides)
ip prefix-list R1_BGP_LOOPBACK seq 10 permit 150.1.11.0/24 <–The prefix we are trying to get to
!
route-map MED permit 10
match ip address prefix-list R1_BGP_LOOPBACK
set metric 100
!
route-map MED permit 1000
!
router bgp 200
neighbor 183.1.105.5 route-map MED out
[error]A lower MED value is preferred over a higher value. So in this case we are taking the path towards SW4 instead of R2.[/error]
Another thing to watch out for is that R5 needs to have itself set to next-hop:
rotuer bgp 100
neighbor 183.1.0.3 next-hop-self
[info]3. (IPV6)[/info]
[success]When told to make sure the host addresses should be derived from the interfaces MAC address:[/success]
interace <interface>
ipv6 address 2001:CC1E:1:505::/64 eui-64 <– this is key
[success]When told to create a tunnel over the existing IPV4 network and to make sure to use the loopback interfaces as the source:[/success]
R4:
interface tunnel45
ipv6 address 2001:CC1E:1:4545::4/64
tunnel source 150.1.4.4 <–loopback interface IP
tunnerl destination 150.1.5.5 <–loopback interface IP
tunnel mode ipv6ip <– this is the right choice when they say to use existing IPV4 network
[success]When told to enable EIGRPv6 on VLAN#’s and the tunnel interface:[/success]
ipv6 router eigrp 45
no shut
!
interface Tunnel#
ipv6 eigrp 45
!
interface <interface that belongs to that VLAN>
ipv6 eigrp 45
[info]3.2 (IPv6 Multicast Basics)[/info]
[success]When told to have R# join the multicast group FF06::6 on its connection to R#:[/success]
interface <interface connected to that R#>
ipv6 enable
ipv6 mld join-group ff06::6
[success]When told to have R4 accept MLD messages only for the group range FF06::/16:[/success]
ipv6 access-list MLD_FILTER
permit ipv6 any FF06::/16
!
interface fa0/0
ipv6 mld access-group MLD_FILTER
[success]When told to use R5 as the PIM RP and ensure multicast packet from R5 can reach R6:[/success]
R5:
ipv6 multicast-routing
!
ipv6 pim bar candidate rp 2001:CC1E:1:505:C004:CFF:FE7A:0
R6:
int fa0/0
ipv6 enable
ipv6 mld join-group ff06::6
[info]4.0 (MPLS)
4.1 (LDP)[/info]
[success]When told to make sure labels are only generated for the respective routers loopback interfaces:[/success]
mpls ip
access-list 1 permit 150.1.0.0 0.0.255.255
!
no mpls ldp advertise-labels
mpls ldp advertise-labels for 1
[info]4.2 (VPN)[/info]
[success]When told to use RD 100:5 and 100:6 and configure two VRFs named VPN_A and VPN_B in R5 and R6 respectively:[/success]
And
[success]When told to use same route-target values to tag respective routes and create 2 loopback interfaces on R5 and R6 with IPs 172.16.5.5/24 and 192.168.6.6/24 and assign them respectively. Also make sure R5 and R6 have reachability between the two subnets:[/success]
R5:
ip vrf VPN_A
rd 100:5
route-target export 100:5
route-target import 100:6
!
int loopback 1
ip vrf forwarding VPN_A
ip address 172.16.5.5 255.255.255.0
!
router bgp 100
address-family vpnv4
neighbor 150.1.6.6 activate
neighbor 150.1.6.6 send-community extended <– Routes across the SP Backbone use IBGP. IBGP uses extended community attributes in a common routing table to differentiate the customers’ routes with overlapping IP addresses.
address-family ipv4 unicast vrf VPN_A
redistribute connected
R6:
ip vrp VPN_B
rd 100:6
route-target export 100:6
route-target import 100:5
!
int loopback 1
ip vrf frowarding VPN_B
ip address 192.168.6.6 255.255.255.0
!
router bgp 100
address-family vpnv4
neigh 150.1.5.5 activate
neigh 150.1.5.5 send-community extended
address-family ipv4 unicast vrf VPN_B
redistribute connected
[info]5 (IP Multicast)
5.1 (RP Assignment)[/info]
[success]When told to configure R3 to announce it most reliable interface as the RP for all multicast groups using Auto-RP protocol:[/success]
int looback0 <–Loopbacks are the most reliable
ip pim sparse-mode
!
ip pim send-rp-announce looback0 scope 16
[success]When told R2 should be responsible for group to RP Mappings:[/success]
int loopback0
ip pim sparse-mode
!
ip pim send-rp-discovery loopback0 scope 16
[info]5.2 (Multicast Testing)[/info]
[success]When asked to configure R5′s ethernet interface thats attached to VLAN 105 to help track down the source to a problem where a server on VLAN 28 can not be accessed from VLAN 105 by joining it to the multicast group 226.26.26.26:[/success]
R5:
interface fa0/0
ip igmp join-group 226.26.26.26 (Having the router join the multicast group causes upstream routers to maintain multicast routing table information for that group and keep the paths for that group active.)
[success]When asked to ensure that R5 responds to ICMP echo-requests sourced from VLAN28 which are sent to 226.26.26.26:[/success]
R5:
ip mroute 0.0.0.0 0.0.0.0 183.1.0.3
[info]5.3 (Multicast Filtering)[/info]
[success]When told there is a new app on VLAN 28 that generated random multicast streams and in order to prevent this traffic from being unnecessarily forwarded throughout the network, configure R3 so that hosts in VLAN33 are not allowed to join any groups in this range:[/success]
R3:
access-list 1 deny 239.0.0.0 0.255.255.255 <–”administratively scoped IPv4 multicastspace”
access-list 1 permit any
!
int fa0/0
ip igmp acceess-group 1
[info]6 (Security)
6.1 (Denial of Service Tracking)[/info]
[success]When told you are getting complaints from users that web server 183.1.28.100 is inaccessible because of a TCP SYN attack. You want to track down the source by configuring R3 and SW4 to generate log messages when HTTP SYN packets are received on VLANs 33 or 102 that are destined for 183.1.28.100. These log messages should include the MAC address of the device which forwarded the packets:[/success]
R3:
ip access-list ext SYN_ATTACK
permit tcp any host 183.1.28.100 eq www syn log-input
permit ip any any
!
int fa0/0
ip access-group SYN_ATTACK in
SW4:
ip access-list ext SYN_ATTACK
permit tcp any host 183.1.28.100 eq www syn log-input
permit ip any any
!
int vlan102
ip access-group SYN_ATTACK in
[info]6.2 (Spoof Prevention)[/info]
[success]When told after the viewing the log files you noticed hosts with spoofed source addresses. To prevent this type of attack you want to configure your network so that traffic will not be accepted from BB1, BB2, or BB3 if it’s sourced from 183.1.0.0/16:[/success]
R3:
ip access-list ext SYN_ATTACK
deny ip 183.1.0.0 0.0.255.255 any
permit ip any any
!
int fa0/0
ip access-group SYN_ATTACK in
SW4:
ip access-list ext SYN_ATTACK
deny ip 183.1.0.0 0.0.255.255 any
permit ip any any
!
int vlan102
ip access-group SYN_ATTACK in
R6:
ip access-list ext SYN_ATTACK
deny ip 183.1.0.0 0.0.255.255 any
permit ip any any
!
int s0/0
ip access-group SYN_ATTACK in
[info]6.3 (Information Leaking)[/info]
[success]When told to configure SW4 NOT to notify hosts behind BB2 on any networks it doesn’t know about and SW4 should not disclose its network mask to any host on the VLAN 102 segment:[/success]
SW4:
int vlan 102
no ip unreachables
no ip mask-rely
[info]6.4 (Control Plane Protection)[/info]
[success]When told to configure R4 to drop and transit IP packet with the TTL lower than 3:[/success]
R4:
ip access-list ext TTL
deny ip any any ttl lt 3 log
permit ip any any
!
int fa0/0
ip access-group TTL out
!
int fa0/1
ip access-group TTL out
[success]When told to log the drop events to the system console and the routers memory buffer:[/success]
R4:
logging on
logging console informational
logging buffered informational
no logging monitor
[info]7 Network Services
7.1 (RMON)[/info]
[success]When told to configure R2 help detect flood attacks by generating SNMP traps when unicast packets (ifEntry.11.1) value rises more than 15000 per minute and when it falls back below 5000 per minute. The sampling interval should be every 60 seconds:[/success]
R2:
rmon alarm 1 ifEntry.11.1 60 delta rising-threshold 15000 1 falling-threshold 5000 2
[success]When told when the 15000 threshold is breached, an event should generated that reads “Above 1500 for ifInUcastPkts”:[/success]
R2:
rmon even 1 trap IETRAP description “Above 1500 for ifInUcastPkts”
[success]If the value falls back to 5000, it should generate something that reads “Below 5000 for ifInUcastPkts”:[/success]
R2:
rmon event 2 trap IETRAP description “Below 5000 for ifInUcastPkts”
[success]When told the server to send these traps to is 183.1.17.100 and that the server is expecting the community string to be IETRAP:[/success]
R2:
snmp-server host 183.1.17.100 IETRAP
[info]7.2 (NTP)[/info]
[success]When told R3 and R6 should get their network time from BB3 and BB1:[/success]
R3:
ntp server 204.12.1.254
R6:
ntp server 54.1.1.254
[success]When told R1, R2, and SW1 should get their time from R3:[/success]
R1, R2, and SW1:
ntp server 150.1.3.3
[success]When told R4, R5, and SW4 should get their time from R6:[/success]
R4, R5, and SW4:
ntp server 150.1.6.6
[success]When told that R3 should failover to R6 if BB3 goes down:[/success]
R3:
ntp server 150.1.6.6
[success]When told that R6 should fail-over to R3 if BB1 goes down:[/success]
R6:
ntp server 150.1.3.3
[info]7.3 (Authentication)[/info]
[success]When told to secure your internal time servers from being spoofed by configuring R3 and R6 to be authenticated by using MD5 password CISCO:[/success]
R3:
ntp authentication-key 1 md5 CISCO
R6:
ntp authentication-key 1 md5 CISCO
R1, R2, and SW1:
ntp authentication-key 1 md5 CISCO
ntp authenticate
ntp trusted-key 1
ntp server 150.1.3.3 key 1
R4, R5, and SW4:
ntp authentication-key 1 md5 CISCO
ntp authenticate
ntp trusted-key 1
ntp server 150.1.6.6 key 1
[info]7.4 (Traffic Accounting)[/info]
[success]When told to configure R2 and R3 to collect usage statistics on packets with an IP precedence value and store them locally:[/success]
R2:
int s0/0
ip accounting precedence input
ip accounting precedence output
R3:
int s1/0
ip accounting precedence input
ip accounting precedence output
[success]When told that R2 and R3 should store up to 50000 of these entries in memory:[/success]
R2 and R3:
ip accounting-threshold 50000
[info]7.5 (Gateway Redundancy)[/info]
[success]When told to configure redundancy between R5 and Sw 4 but you can not use VRRP or GLBP. And as long as R5′s FR connection is up (S0/0) it should respond to ARP requests. If this connection goes down, then host should use SW4 as their DG:[/success]
R5:
int fa0/0
standby 1 ip 183.1.105.254
standby 1 preempt
standby 1 track s0/0
SW4:
int fa1/12
standby 1 ip 183.1.105.254
standby 1 priority 50
standby 1 preempt
[info]7.6 (NAT)[/info]
[success]When told to hide info from BB3 and only have reachability to your hosts if a connection is initiated from inside your network. Make sure all devices in the 183.1.0.0/16 network can successfully ping BB3:[/success]
R3:
access-list 2 permit 183.1.0.0 0.0.255.255
!
ip nat inside source list 2 interface fa0/0 overload
!
int fa0/0
ip nat outside
!
int s1/0
ip nat inside
!
int s1/1
ip nat inside
[info]7.7 (Embedded Event Manager)[/info]
[success]When told to have R6 generate syslog messages once it’s FR utilization exceeds 80% of total interface bandwidth and the messages should containing interface name and current load. You should also generate another message when the interface transmit load falls below 40% of the total bandwidth. Do not use RMON:[/success]
R6:
event manager applet INTERFACE_MONITOR trap
event int name “S0/0″ parameter txload entry-val 204 entry-op gt entry-val-is-increment tru exit-val-is-increment tru exit-time
1 poll-interval 1 maxrun 1
action 1.0 syslog msg “R6′s $_inteface_name output route: $_interface_parameter = $_interface_value”
!
int s1/0
load-interval 30
[info]8 (QOS)
8.1 (Frame Relay Traffic Shaping)[/info]
[success]When told to implement QOS on R5 because you are killing R3 and R4′s connection to the FR cloud with these specs:
R5′s connection to the FR cloud support transmission rate of 1536Kbps
R5 should send at an average rate of 128Kbps on DLCI 513 to R3
R5 should send at an average rate of 512Kbps on DLCI 504 to R4
If the FR cloud notifies R5 of congestion it should reduce its sending rate to no lower than 96Kbps for the DLCI to R3 and 284Kbps for DLC to R4
If R5 has accumulated credit it should be allowed to burst up to the max transmission rate supported to the circuit to R4
Bursting on the circuit to R3 is not allowed
Assume an interval (Tc) of 50ms:[/success]
R5:
map-class frame-relay DLCI_504
frame-relay cir 512000
frame-relay bc 25600
frame-relay be 51200
frame-relay mincir 384000
frame-relay adaptive-shaping becn
!
map-class frame-relay DLCI_513
frame-relay cir 128000
frame-relay bc 6400
frame-relay be 0
frame-relay mincir 96000
frame-relay adaptive-shaping becn
!
int s0/0
frame-relay traffic-shaping
frame-relay interface-dlci 504
class DLCI_504
frame-relay interface-dlci 513
class DLCI_513
[info]8.2 (Rate Limiting)[/info]
[success]When told that your admin noticed a large number of ICMP packets on the ethernet segment of R1 and you want to prevent this. Configure R1 so that it does not send more than 128Kbps of ICMP traffic out of its interface and allow for a bust of 1/4th of this rate. Do not use “match protocol” command. :[/success]
R1:
ip access-list ext ICMP
permit icmp any any
class-map match-all ICMP
match access-group name ICMP
!
policy-map POLICE_ICMP
class ICMP
police cir 128000 bc 4000
!
int fa0/0
service-policy output POLICE_ICMP
[info]8.3 (CBWFQ)[/info]
[success]When asked to seperate Voice and Data on R5 using these specs:
64Kbps of PVC for VOIP marked DSCP EF
Guarentee 30% of remaining bandwidth to Citrix
Do not use “match protocol”
Set queue depth for the Citrix traffic class to 16 packets
All other remaining traffic should receive flow-based fair scheduling:[/success]
R5:
ip access-list ext CITRIX
permit udp any any eq 1604
permit udp any eq 1604 any
permit tcp any any eq 1494
permit tcp any eq 1494 any
!
class-map match-all CITRIX
match access-group name CITRIX
class-map match-all VOICE
match dscp ef
!
policy-map CBWFQ
class VOICE
priority 64
class CITRIX
bandwidth remaining percent 30
queue-limit 16
class class-default
fair-queue
!
map-class frame-relay DLCI_504
service-policy output CBWFQ