Pete's Packet

Limitless

Archive for June, 2009

IPV6 address’

Posted by Peter Kurdziel on June 26, 2009

http://www.potaroo.net/ispcol/2008-08/ipv6addr.html

::1/128 local host
::FFFF:w.x.y.z IPv4 mapped address – lookup IPv4 address w.x.y.z
FD00::/8 Unique Local Addresses.

    No registry is used for these addresses
FE80::/10 Link Local Addresses

    No registry is used for these addresses
2001:0::/32 Teredo address

    • a Cone NAT flag (C),
    • the Universal (U) flag (set to 0),
    • the Individual/Group (G) flag (set to 0),
    • a reserved flag (R),
    • a 12 bit random value (A) used to deflect intrusion attacks.
      2001:0:cf2e:308c:0:323d:3fa1:c0b0
      Teredo server IPv4 address is cf.2e.30.8c = 207.46.48.140
      External Obscured Port of client is 323d = port 52674
      External Obscured IP address of client is 3f.a1.c0.cb = 192.94.63.70
  • Bits 33 – 64 of the address contain the Teredo server address

    Bits 65 – 80 contain flags: The field format is: CRAA AAUG AAAA AAAA

    Bits 81 – 96 contain the external IPv4 port address, XORed with 1′s

    Bits 97 – 128 contain the external IPv4 address XORed with 1′s

    For example, the Teredo IPv6 address : can be mapped as follows:

2002::/16 6to4 address

    • 2002:cb0a:3cdd:1::1
      cb.0a.3c.dd = 203.10.60.221
  • Bits 17 – 48 contain the IPv4 address of the 6to4 gateway

    For example, the 6to4 address has the IPv4 gateway address of

Posted in IPV6, Routing & Switching Lab | Leave a Comment »

QOS – Sec notes

Posted by Peter Kurdziel on June 23, 2009

  1. dos attack

!
ip tcp intercept list 101
ip tcp intercept connection-timeout 1800
ip tcp intercept watch-timeout 15
ip tcp intercept max-incomplete low 600
ip tcp intercept max-incomplete high 800
ip tcp intercept mode watch
ip tcp intercept drop-mode random
access-list 101

  1. nat virtual interface

ip nat pool NATPOOL 150.50.5.3 150.50.5.255 netmask 255.255.255.0
ip nat source list 10 pool NATPOOL
int f0/0
ip add 150.50.4.8 255.255.255.0
ip nat enable
int s0/0
ip nat enable

R8(config-if)#do ping 150.50.5.3 source 150.50.4.8

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.50.5.3, timeout is 2 seconds:
Packet sent with a source address of 150.50.4.8
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4ms
R8(config-if)#do sho ip nat nvi tran
Pro Source global      Source local       Destin  local Destin  global
icmp 150.50.5.3:5      150.50.4.8:5       150.50.5.3:5 150.50.5.3:5
— 150.50.5.3         150.50.4.8         —                —

  1. Configuring VLAN Maps

Step 1 Create the standard or extended IPv4 ACLs or named MAC extended ACLs that you want to apply to the VLAN. See the “Creating Standard and Extended IPv4 ACLs” section and the “Creating a VLAN Map” section.

Step 2 Enter the vlan access-map global configuration command to create a VLAN ACL map entry.

Step 3 In access-map configuration mode, optionally enter an action—forward (the default) or drop—and enter the match command to specify an IP packet or a non-IP packet (with only a known MAC address) and to match the packet against one or more ACLs (standard or extended).Note If the VLAN map is configured with a match clause for a type of packet (IP or MAC) and the map action is drop, all packets that match the type are dropped. If the VLAN map has no match clause, and the configured action is drop, all IP and Layer 2 packets are dropped.

Step 4 Use the vlan filter global configuration command to apply a VLAN map to one or more

VLANs.

Example 1

This example shows how to create an ACL and a VLAN map to deny a packet. In the first map, any packets that match the ip1 ACL (TCP packets) would be dropped. You first create the ip 1ACL to permit any TCP packet and no other packets. Because there is a match clause for IP packets in the VLAN map, the default action is to drop any IP packet that does not match any of the match clauses.

Switch(config)# ip access-list extended ip1
Switch(config-ext-nacl)# permit tcp any any
Switch(config-ext-nacl)# exit
Switch(config)# vlan access-map map_1 10
Switch(config-access-map)# match ip address ip1
Switch(config-access-map)# action drop

Example 2

In this example, the VLAN map has a default action of drop for IP packets and a default action  of forward for MAC packets. Used with standard ACL 101 and extended named access lists igmp-match and tcp-match, the map will have the following results:

•Forward all UDP packets
•Drop all IGMP packets
•Forward all TCP packets
•Drop all other IP packets
•Forward all non-IP packets
Switch(config)# access-list 101 permit udp any any
Switch(config)# ip access-list extended igmp-match
Switch(config-ext-nacl)# permit igmp any any
Switch(config)# ip access-list extended tcp-match
Switch(config-ext-nacl)# permit tcp any any
Switch(config-ext-nacl)# exit
Switch(config)# vlan access-map drop-ip-default 10
Switch(config-access-map)# match ip address 101
Switch(config-access-map)# action forward
Switch(config-access-map)# exit

Switch(config)# vlan access-map drop-ip-default 20
Switch(config-access-map)# match ip address igmp-match
Switch(config-access-map)# action drop
Switch(config-access-map)# exit
Switch(config)# vlan access-map drop-ip-default 30
Switch(config-access-map)# match ip address tcp-match
Switch(config-access-map)# action forward

Example 3In this example, the VLAN map has a default action of drop for MAC packets and a default action of forward for IP packets. Used with MAC extended access lists good-hosts and good protocols, the map will have the following results:

•Forward MAC packets from hosts 0000.0c00.0111 and 0000.0c00.0211
•Forward MAC packets with decnet-iv or vines-ip protocols
•Drop all other non-IP packets
•Forward all IP packets

Switch(config)# mac access-list extended good-hosts
Switch(config-ext-macl)# permit host 000.0c00.0111 any
Switch(config-ext-macl)# permit host 000.0c00.0211 any
Switch(config-ext-nacl)# exit
Switch(config)# mac access-list extended good-protocols
Switch(config-ext-macl)# permit any any decnet-ip
Switch(config-ext-macl)# permit any any vines-ip
Switch(config-ext-nacl)# exit

Switch(config)# vlan access-map drop-mac-default 10
Switch(config-access-map)# match mac address good-hosts
Switch(config-access-map)# action forward
Switch(config-access-map)# exit

Switch(config)# vlan access-map drop-mac-default 20
Switch(config-access-map)# match mac address good-protocols
Switch(config-access-map)# action forward

Example 4

In this example, the VLAN map has a default action of drop for all packets (IP and non-IP).Used with access lists tcp-match and good-hosts from Examples 2 and 3, the map will have the following results:

•Forward all TCP packets
•Forward MAC packets from hosts 0000.0c00.0111 and 0000.0c00.0211
•Drop all other IP packets
•Drop all other MAC packets

Switch(config)# vlan access-map drop-all-default 10
Switch(config-access-map)# match ip address tcp-match
Switch(config-access-map)# action forward
Switch(config-access-map)# exit

Switch(config)# vlan access-map drop-all-default 20
Switch(config-access-map)# match mac address good-hosts
Switch(config-access-map)# action forward

Applying a VLAN Map to a VLAN
This example shows how to apply VLAN map 1 to VLANs 20 through 22:

Switch(config)# vlan filter map 1 vlan-list 20-22

Creating Named MAC Extended ACLs
Switch(config)# mac access-list extended mac1

Switch(config-ext-macl)# deny any any decnet-iv

Switch(config-ext-macl)# permit any any

Switch(config-ext-macl)# end

Switch # show access-lists

Extended MAC access list mac1

10 deny   any any decnet-iv

20 permit any any

Applying a MAC ACL to a Layer 2 Interface

This example shows how to apply MAC access list mac1 to a port to filter packets entering the port:

Switch(config)# interface gigabitethernet0/2

Router(config-if)# mac access-group mac1 in

Note The mac access-group interface configuration command is only valid when applied to a

physical Layer 2 interface.You cannot use the command on EtherChannel port channels.

  1. The syntax for standard access-lists is as follows:

“I wish to permit all IP traffic from host [host-ip-address]“
“I wish to permit all traffic from [subnet] [wildcard-mask]“
“I wish to deny all IP traffic from host [host-ip-address]“
“I wish to deny all traffic from [subnet] [wildcard-mask]“

The syntax for extended access-lists is slightly different:

“I wish to [permit/deny] [type-of-traffic] going from to [destination-address] [destination-wildcard-mask] [optional port-number]“

5. ddos attack
Extended IP access list 102
10 permit tcp 150.50.46.0 0.0.0.255 host 150.50.17.80
20 permit tcp 150.50.56.0 0.0.0.255 host 150.50.17.80

ip tcp intercept list 102
ip tcp intercept watch-timeout 20
ip tcp intercept mode watch

6. code red
Router(config)#class-map match-any http-hacks
Router(config-cmap)#match protocol http url “*default.ida*”
Router(config-cmap)#match protocol http url “*cmd.exe*”
Router(config-cmap)#match protocol http url “*root.exe*”

Router(config)#policy-map mark-inbound-http-hacks
Router(config-pmap)#class http-hacks
Router(config-pmap-c)#set ip dscp 1

Router(config)#interface serial 0/0
Router(config-if)#service-policy input mark-inbound-http-hacks

Router(config)#access-list 105 deny ip any any dscp 1
Router(config)#access-list 105 permit ip any any

Router(config)#interface ethernet 0/1
Router(config-if)#ip access-group 105 out

7.  login  – prevent dictionary attack – Under aaa > cisco ios enhancements if there are a5 attempts in 5 seconds block for 60sec.  8 max failed logons lock the   database.

login block-for 60 attempts 5 within 5

aaa new-model
aaa local authentication attempts max-fail 8
!
aaa authentication login default local
aaa authentication login MyCon line

8.  ip source-track

IP source tracking allows you to gather information about the traffic that is flowing to a host that is suspected of being under attack. It also allows you to easily trace a denial-of-service (DoS) attack to its entry point into the network.

Router# configure interface
Router(config)# ip source-track 10.10.0.1
Router(config)# ip source-track syslog-interval 2
Router(config)# ip source-track export-interval 60

to read

http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_afrt_shp_ic_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/reg_pkt_flow_shaping.html#wp1046537

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/config_wred_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/config_pq_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/config_wfq_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_d1.html#wp1025051

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/clsfy_trfc_nbar_map_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_cfg_tcp_intercpt_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1000905

http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a00800fc176.shtml

NOTES:

    Posted in Routing & Switching Lab | Leave a Comment »

    ipv6

    Posted by Peter Kurdziel on June 22, 2009

    R7(config-if)#ipv add 2000:1:1:7700::/64
    % 2000:1:1:7700::/64 should not be configured on Loopback0, a subnet router anycast

    solution =   eui-64   Use eui-64 interface identifier = “The host portion of the IPv6 addresses

    should be based partly off of their interfaces’ respective MAC addresses.”

    Loopback0                  [up/up]
    FE80::20D:BCFF:FE0F:D100
    2000:1:1:7700::
    2000:1:1:7700:20D:BCFF:FE0F:D100
    !
    interface Loopback0
    ip address 200.0.0.7 255.255.255.255
    ipv6 address 2000:1:1:7700::/64 **** this was not deleted when I deleted it earlier!!!
    ipv6 address 2000:1:1:7700::/64 eui-64
    !

    RIPng
    Enable globally and on the interface:
    ipv6 unicast-routing
    ipv6 router rip cisco67 <——————

    interface Loopback0
    ip address 200.0.0.6 255.255.255.255
    ipv6 address 2000:1:6600::/64 eui-64
    ipv6 rip cisco67 enable <—————–

    ========================

    ipv6 over ip GRE tunnel
    r2 – cisco12 RIPng is already enabled.

    interface Tunnel26
    no ip address
    ipv6 address 2000:1:1:78::7/64
    ipv6 rip cisco12 enable
    tunnel source 150.50.100.2
    tunnel destination 150.50.100.6
    tunnel mode ipv6ip

    r6 – need to add the RIPng routing process in global(cisco12)

    interface Tunnel26
    no ip address
    ipv6 address 2000:1:1:26::6/64
    ipv6 rip cisco12 enable
    tunnel source 150.50.100.6
    tunnel destination 150.50.100.2
    tunnel mode ipv6ip

    Check to make sure the RIPng is enable globally and on the interace.
    ===================================

    ipv6 router rip cisco67
    redistribute rip cisco12
    !
    ipv6 router rip cisco12

    R6(config-rtr)#ipv6 router rip cisco67
    do sho run | be ipv6 router

    ipv6 router rip cisco67
    redistribute rip cisco12
    !
    ipv6 router rip cisco12
    <————————where is the command I just entered? Odd Can I only add it once under a routing process? When I add the redistribute with a metric then I do see it on both process’.
    solution:
    ipv6 router rip cisco67
    redistribute rip cisco12 metric 4
    !
    ipv6 router rip cisco12
    redistribute rip cisco67 metric 4

    R7(config-if)# do ping 2000:1:1:1100::1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 2000:1:1:1100::1, timeout is 2 seconds:
    ….. <——————————–can ping it?
    Success rate is 0 percent (0/5)
    –> same as with IPV4 we are missing our connected routes during redistribution. Since R7′s source address will be the Ethernet between R6 and R7 (2000:1:1:67/64), R1′s routing table won’t have that information. (R1 does not have a route to 2000:1:1:67/64. But it does have a route to R7′s loopback (R   2000:1:1:7700::/64 [120/6]) This is because when we redistributed cisco12 and cisco67 we only redistributed what was in the routing table for those two process’.

    R1 does not see 2000:1:1:6600::/64  because that’s a connected interface on R6, the redistributing router. R1 does not see R7 f0/0  2000:1:1:67::7 because it’s a connected interface on R6  2000:1:1:67::6 and that is not redistributed. r6 and r7 will not have rip routes to each others directly connected 2000:1:1:67::/64 interfaces.
    When redistributing the connected interfaces will need to be redistributed. Your only redistributing routing information.

    * The solution is to redistribute the connected interfaces under both routing process’ on R6

    ipv6 router rip cisco67
    redistribute connected route-map Myconnect
    redistribute rip cisco12 metric 4
    !
    ipv6 router rip cisco12
    redistribute connected route-map Myconnect
    redistribute rip cisco67 metric 4
    !
    route-map Myconnect permit 10
    match ipv6 address Mine
    !
    !
    ipv6 access-list Mine
    permit ipv6 2000:1:1:6600::/64 any
    sequence 30 remark this is r6 loopback0
    permit ipv6 2000:1:1:67::/64 any
    remark 2000:1:1:67::/64 is the ethernet
    permit ipv6 2000:1:1:26::/64 any
    remark 2000:1:1:26::/64 is tunnel26

    Or on R6 tun26 and e0/0 we could have said ipv6 rip [cisco12 |cisco67]cisco default-information

    originate
    ===================================================

    ? config r7 so that r1 (cisco12),r2 (cisco12/67),and r6(cisco12/67) can ping 2000:1:1:8800::8/64 do not redistribute and RIPng instances.

    solution:
    R7
    interface fa 0/0
    ipv6 rip cisco67 default-information originate

    interface Serial0/0
    ipv6 rip cisco8 default-information originate

    1. config both the ipv6 address and the link-local address (preferably do that link local matches the router, eg fe80::5 link local)
    2. When configuring frame maps config both ipv6 and the link local.
    3. don’t forget the router id in ospfv3
    4. you need ipv router ospf 1 and interf ipv6 osp 1 a 0
    5. don’t forget to set up your frame maps ( should be the same as in ipv4 int cfg)
    6. ipv6 treats misconfiguration ip addresses as secondary ip’s so double check with sh run int  to see if you have any mistakes and extra IP’s.
    7. don’t forget to add fram maps and virtual-links where needed. (draw it out)
    8. sh bgp ipv6 unicast summary = sh ip bgp sum.
    9. IPV4 we are missing our connected routes during redistribution. Since R7′s source address will be the Ethernet between R6 and R7 (2000:1:1:67/64), R1′s routing table won’t have that information. (R1 does not have a route to 2000:1:1:67/64. But it does have a route to R7′s loopback (R   2000:1:1:7700::/64 [120/6]) This is because when we redistributed cisco12 and cisco67 we only redistributed what was in the routing table for those two process’. R1 does not see 2000:1:1:6600::/64  because that’s a connected interface on R6, the redistributing router. R1 does not see R7 f0/0  2000:1:1:67::7 because it’s a connected interface on R6  2000:1:1:67::6 and that is not redistributed. r6 and r7 will not have rip routes to each others directly connected 2000:1:1:67::/64 interfaces.
      When redistributing the connected interfaces will need to be redistributed. Your only redistributing routing information.

      * The solution is to redistribute the connected interfaces under both routing process’ on R6

    Posted in Routing & Switching Lab | Leave a Comment »

    Narbik’s CCIE routing and switching bootcamp!

    Posted by Peter Kurdziel on June 22, 2009

    I took Narbik’s bootcamp last year and it was the best CCIE bootcamp I have ever attended.

    I have been to a few other vendors bootcamps (1 in 2005 and 2 2008) they were ok but somewhat lacking. I walked out feeling that I was left hanging. Not so with Narbik’s bootcamp. I can not say enough good things about Narbik and his bootcamp. I think he has hit the nail on the head with his bootcamp and it’s exactly what I need.

    Narbik is very knowledgeable and a really funny guy. Narbik covers a lot of material and there are tons and tons of labs. The material is presented thoroughly and in a way that is easy to understand. Narbik charges ONLY $2500.00 (it was 2000.00 when I attended)  for his bootcamp. Guys you can not find any training class for that amount of money let alone a CCIE bootcamp!!!!!
    Narbik goes out of his way on the groupstudy, via email and over the phone to help you succeed. Some vendors want to charge you extra for that!

    If everyone was as generous and honest as Narbik is then the world would be a better place. I’m not kidding.

    Job well done Narbik.

    Thank you!

    If you are considering taking a CCIE bootcamp go to Narbik’s I guarantee you will love it and you will not be disappointed.

    http://www.micronicstraining.com/ccie-routing-switching-lab.html

    Instructor

    Narbik Kocharians CCSI, CCIE #12410 (R&S, Security, SP)
    Narbik a Triple CCIE has over 30 years of experience in the industry. He has designed, implemented and supported numerous enterprise networks. Some of the companies that Narbik has worked for are IBM, Carlton United Breweries, Australian Cable and Wireless, BP, AMOCO and in US, 20th Century Ins., Home Saving of America, Verizon, TTI, Trinet Inc, NLI, IPexpert, Anderson Networking and Consulting and many more. Narbik has been a dedicated CCIE instructor for over 10 years.

    What the Students Get

    • Upon registration, the students will receive an E-COPY of “Soup-To-Nuts” Work Book; this Work Book is written as a preparatory work book for the Boot Camp, this work book is written by Narbik Kocharians. This Book is valued at $295.
    • During the Boot Camp, the students will also receive one of the best CCIE R&S Work Books called “Advanced CCIE Routing and Switching Work Book” Which is also written by Narbik Kocharians, this work book is valued at $595.
    • During the Boot Camp, the students will receive a workbook that is written specifically for the Boot Camp.

    Retake Policy

    Students can retake the same course based upon availability of a seat. If requested date/location is not available, we will offer an alternate date/location. The policy to retake a course is as follows:

    • There will be a charge of $75 for the boot camp material
    • If the student wants to do the labs, they must have access to their pod of hardware; this hardware can be rented from a vendor of their choice.

    Click here now:       http://www.micronicstraining.com/ccie-routing-switching-lab.html

    Posted in Routing & Switching Lab | Leave a Comment »

    How do I advertise the true subnet mask of loopbacks

    Posted by Peter Kurdziel on June 19, 2009

    1.) redistribute connected (external) (acl / route-map)
    2.) area x range (internal)
    3.) ip ospf network type point-to-point (internal)

    I am testing in my lab.

    2 +3 worked.
    Once have specified a proper network instead of using ” network 0.0.0.0 0.0.0.0” # 1 worked.

    Posted in OSPF, Routing & Switching Lab | Leave a Comment »

    Cheap rack rental

    Posted by Peter Kurdziel on June 19, 2009

    Joe Astorino posted on groupstudy that he is renting out his personal rack for a great cheap price.

    Contact Joe for pricing and scheduling:  jastorino@ipexpert.com

    Posted in Routing & Switching Lab | Leave a Comment »

    Day 88 – security

    Posted by Peter Kurdziel on June 18, 2009

    ACL’s

    Deny only 100.0.0.2, 100.0.0.4 and 100.0.0.6. Do not drop OSPF adjacencies
    access-list 1 deny 100.0.0.0 0.0.0.6 ( this denies even routes 0,2,4,6)
    access-list 1 per any
    Permit web/ftp/ospf traffic for all users on the 10.1.1.0/24 network (there are web/ftp clients on the 10.1.1.0/24 network (destination))

    ip access-list extended test
    remark permits web/ftp/ospf traffic for all users on the 10.1.1.0/24 network (there are web/ftp clients on the 10.1.1.0/24 network)
    permit tcp 10.1.1.0 0.0.0.255 any eq www
    permit tcp 10.1.1.0 0.0.0.255 any eq ftp
    permit tcp 10.1.1.0 0.0.0.255 any eq ftp-data
    remark these three lines cover user generated traffic
    permit tcp 10.1.1.0 0.0.0.255 eq www any
    remark this line covers replies from the web servers on the inside
    permit tcp 10.1.1.0 0.0.0.255 any established
    remark this line is necessary for the FTP server responses since ports vary
    permit ospf 10.1.1.0 0.0.0.255 any
    remark permits ospf traffic


    Timed ACL’s

    I couldn’t find this one the doc cd under router configuration. I did however find it under the switching section here: http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_50_se/configuration/guide/swacl.html

    *** The time range relies on the switch system clock; therefore, you need a reliable clock source. Use Network Time Protocol (NTP).


    Command
    Purpose
    Step 1 configure terminal Enter global configuration mode.
    Step 2 time-range time-range-name Assign a meaningful name (for example, workhours) to the time range to be created, and enter time-range configuration mode. The name cannot contain a space or quotation mark and must begin with a letter.
    Step 3 absolute [start time date]
    [end time date]
    or
    periodic day-of-the-week hh:mm to [day-of-the-week] hh:mm
    or
    periodic {weekdays | weekend | daily} hh:mm to hh:mm
    Specify when the function it will be applied to is operational.
    You can use only one absolute statement in the time range. If you configure more than one absolute statement, only the one configured last is executed.
    You can enter multiple periodic statements. For example, you could configure different hours for weekdays and weekends.
    See the example configurations.
    Step 4 end Return to privileged EXEC mode.
    Step 5 show time-range Verify the time-range configuration.
    Step 6 copy running-config startup-config (Optional) Save your entries in the configuration file.

    Repeat the steps if you have multiple items that you want in effect at different times.

    To remove a configured time-range limitation, use the no time-range time-range-name global configuration command.

    This example shows how to configure time ranges for workhours and to configure January 1, 2006, as a company holiday and to verify your configuration.

    Switch(config)# time-range workhours
    Switch(config-time-range)# periodic weekdays 8:00 to 12:00
    Switch(config-time-range)# periodic weekdays 13:00 to 17:00
    Switch(config-time-range)# exit
    Switch(config)# time-range new_year_day_2006
    Switch(config-time-range)# absolute start 00:00 1 Jan 2006 end 23:59 1 Jan 2006
    Switch(config-time-range)# end
    Switch# show time-range
    time-range entry: new_year_day_2003 (inactive)
    absolute start 00:00 01 January 2006 end 23:59 01 January 2006
    time-range entry: workhours (inactive)
    periodic weekdays 8:00 to 12:00
    periodic weekdays 13:00 to 17:00
    another example

    time-range AFTERHOURS
    periodic daily 0:00 to 6:59
    !
    time-range HOLIDAY
    absolute start 00:00 4 July 2009 end 23:59  4 July 2009
    !
    time-range WEB
    periodic weekdays 0:00 to 23:59

    ip access-list extended AFTERHOURS
    deny   udp 150.50.7.0 0.0.0.255 150.50.4.0 0.0.0.255 eq domain time-range AFTERHOURS
    deny   tcp 150.50.7.0 0.0.0.255 150.50.4.0 0.0.0.255 eq domain time-range AFTERHOURS
    deny   tcp 150.50.7.0 0.0.0.255 150.50.4.0 0.0.0.255 eq smtp time-range AFTERHOURS
    deny   tcp 150.50.7.0 0.0.0.255 150.50.4.0 0.0.0.255 eq www time-range AFTERHOURS
    permit ip any any

    ip access-list extended FILTEROUT
    deny   tcp host 150.50.4.100 any eq www time-range WEB
    deny   ip 150.50.4.0 0.0.0.255 any time-range HOLIDAY
    permit ip any any

    =============================

    Extended IP access list OSPFPIM1023
    10 permit ospf host 150.50.7.5 any log
    15 deny ospf any any
    20 deny pim host 150.50.7.6 any
    30 deny tcp 150.50.7.32 0.0.0.31 any gt 1023
    40 permit ip any any
    =================
    r1 <> r2 <> r3
    Restrict traffic from R1 to R2 and beyond

    ip access-list extended Trusted
    permit ip any any reflect TrustMe
    remark this is all we need to establish a peer state.
    ip access-list extended Untrusted
    permit ospf any any
    evaluate Trustme
    deny   ip any any log
    remark this allows our monitoring of things that are not denied

    Refective acl in action after pinging /telnetting from R1 to r5 (untrusted) and successful telnet from R5 to R1:

    R2(config-if)#do sho access-list

    Reflexive IP access list TrustMe
    permit udp host 150.50.100.2 eq ntp host 200.0.0.8 eq ntp (13 matches) (time left 267)
    permit icmp host 150.50.24.2 host 150.50.24.4  (7 matches) (time left 243)
    permit udp host 150.50.17.1 eq ntp host 200.0.0.8 eq ntp (3 matches) (time left 121)
    permit ospf host 150.50.100.2  host 150.50.100.5  (12 matches) (time left 277)
    permit ospf host 224.0.0.5  host 150.50.9.5  (34 matches) (time left 297)
    permit ospf host 150.50.100.2  host 150.50.100.6  (13 matches) (time left 295)

    Extended IP access list Trusted
    10 permit ip any any reflect TrustMe (88 matches)

    Reflexive IP access list Trustme
    Extended IP access list Untrusted
    10 permit ospf any any (14 matches)
    20 evaluate Trustme
    30 deny ip any any log (8 matches)

    ——————————
    HTTP / SNMP acl
    snmp-server community ipexpert RO 2
    snmp-server community IpExPeRt RW 3

    access-list 2 permit 150.50.17.0 0.0.0.255
    access-list 2 remark this is for http and snmp ro
    access-list 3 permit 150.50.200.200
    access-list 3 remark this is for SNMP rw

    ip http access-class 2

    ———————
    prevent access from with the least lines of acl config
    97.150.81.0/24
    129.150.17.0/24
    129.150.81.-/24
    161.150.17.0/24
    161.150.81.0/24
    193.150.17.0/24
    193.150.81.0/24

    97 =  01100001
    129 = 10000001
    161 = 10100001
    193 = 11000001
    ^^^differences / some options see below

    17 = 00010001
    81 = 01010001
    ^ differences / so the acl will be X.X.64.255

    2^x where x = the number of 1 bits in the ACL mask tells us the number pf matches that the mask will get.

    97 = separate acl
    129 and 161 have 1 common different bit (32) – one acl here 32.0.64.255
    129 and 193 have 1 common differnet bit (64) – one acl here 64.0.64.255

    so you have three choices.

    Standard IP access list 1
    10 deny   129.150.17.0, wildcard bits 32.0.64.255
    20 deny   193.150.17.0, wildcard bits 0.0.64.255
    30 deny   97.150.81.0, wildcard bits 0.0.0.255
    40 permit any

    or

    Standard IP access list 2
    10 deny   129.150.17.0, wildcard bits 64.0.64.255
    20 deny   161.150.17.0, wildcard bits 0.0.64.255
    30 deny   97.150.81.0, wildcard bits 0.0.0.255
    40 permit any
    or

    Standard IP access list 3
    10 deny   129.150.17.0, wildcard bits 96.0.64.255
    20 deny   97.150.81.0, wildcard bits 0.0.0.255
    30 permit any

    ———-
    **Traffic that is generated by the router is not subject to outbound acl’s.

    access-list 166 permit ip any any precedence critical
    access-list 166 deny   ip any any

    interface Ethernet0/0
    ip access-group 166 out

    testing acl
    R2(config)#do trace 150.50.7.7

    Type escape sequence to abort.
    Tracing the route to 150.50.7.7

    1 150.50.100.6 28 msec
    150.50.100.5 32 msec
    150.50.9.5 24 msec
    2 150.50.100.6 !A
    150.50.7.7 28 msec *

    !A means administratively prohibited.

    ————-

    1. When you apply and ACL to an outbound interface, the ACL acts upon traffic flowing through the router. It does not act upon traffic that originates in the router.
    2. Every ACL must have at least one permission statement. Otherwise you block all traffic.
    3. Use deny log to see how many times the acl was hit.
    4. Don’t forget to account for routing protocols when building ACL’s.
    5. When considering to use out or in use the interface as the point of reference.
    6. A 1 bit in an ACL mask means you don’t care what the value of that bit is .
    7. A 0 but in an ACL mask means the bit value will stay the same.

    Posted in Routing & Switching Lab, Security | Leave a Comment »

    Cisco Mind maps – awesome!!

    Posted by Peter Kurdziel on June 18, 2009

    Krzysztof Zaleski CCIE R&S #24081 Mind maps

    http://inetcon.org/study_en.html

    Posted in Routing & Switching Lab | Leave a Comment »

    Day 89 notes – redistribution

    Posted by Peter Kurdziel on June 17, 2009

    Routing protocol seed metric for redistribution

    router rip

    redistribute static
    redistribute eigrp 1
    redistribute ospf 1
    default-metric 1

    router ospf 1

    redistribute static metric 200 subnets
    redistribute rip metric 200 subnets
    redistribute eigrp 1 metric 100 subnets

    router igrp/eigrp 1

    redistribute static metric 10000 100 255 1 1500
    redistribute ospf 1  metric 10000 100 255 1 1500
    redistribute rip  metric 10000 100 255 1 1500

    * or use default-metric 10000 100 255 1 1500

    Allow/deny even/odd routes

    access-list 1 120.10.0.0 0.0.254.255 ==> 120.10.(0,2,4,6,8).x ===> Even numbers

    access-list 1 120.10.1.0 0.0.254.255 ==> 120.10.(1,3,5,7,9).x ===> Odd numbers

    lab notes

    1. permit only odd routes – routes should be in the rip database
      • access-list 1 per 199.1.1.0 0.0.254.0
      • router rip
      • distance 255 135.5.1.1 255.255.255.255 1
    2. set cost t0 300 do not use ip ospf bandwidth
    3. 300 * 1544000(link bw) = 463.2 round up 464
      • auto-cost reference-bandwidth 464
    4. rip, ospf 1, ospf 256 – you need to redistribute mutually, even though your redistributed between ospf 1 and ospf 256.
    5. watch out for typo’s in the AS when redistributing.
    6. do not see ospf routes: solution:
      • redistribute ospf 256 match internal external 1 external 2
    7. clear ip ospd redistribution -flushes type 5 and type 7 routes.
    8. always set a seed metric when redistributing:
    9. rip – 1 – cisco recomments you use the lowest.
    10. ospf – cost – 10^8/BW – for ethernet 1000 for 1544 serial 64767 (if you forget this then ospf will default to 20 for all protocols except bgp which will dedault to 1).
    11. eigtp – bandwidth delay reliability load mtu 1000 100 255 1 15000
    12. bgp – no metric
    13. area X range only works on ABR
    14. summary-address only works on ASBR
    15. Common ways to solve issues with redistribution, distance, distribute-lists, route-maps and tags.
    16. OSPF and BGP router ID must match
    17. Whenever you see ” minimum number of commands” start thinking of all the ways to do something because something is likely out of the ordinary

    Posted in Routing & Switching Lab | Leave a Comment »

    Day 89 BGP notes

    Posted by Peter Kurdziel on June 16, 2009

    BGP notes

    1. BGP not working? Three things to look at:
      • EBGP-MULTIHOP (both sides)
      • UPDATE-SOURCE (loopback …)
      • NEXT-HOP-SELF (sho ip bgp x.x.x.x look for inaccessible)
    2. NEXT-HOP-SELF is used in unmeshed networks (fr) where BGP neighbors do no have a direct access to all other neighbors on the same subnet.
    3. redistributing ospf into BPG: (by default only EBGP routes are redistributed)
      • redistribute ospf 1 internal external route-map XX
    4. BGP Community attributes
      • internet – advertise to everyone
      • no export – advertise  to no ebgp peer
      • local as – advertise to the local as only = If you are using BGP confederations, local-as prevents the routes from traversing the sub ASes.  No-export allows the routes to go between sub-ASes in the confederation, but not to any other ASes outside of the confederration.
      • no advertise – advertise to no one
      • Community Description
        Local-AS Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS).
        no-export Do not advertise to external BGP (eBGP) peers. Keep this route within an AS.
        no-advertise Do not advertise this route to any peer, internal or external.
        none Apply no community attribute when you want to clear the communities associated with a route.
        internet Advertise this route to the internet community, and any router that belongs to it.
    5. 200.0.0.1/32 = net 200.0.0.1 mask 255.255.255.255
    6. Use aggregate-address w/ summary-only to send a summary
    7. ^2004 = originated on AS200
    8. ^$ empty as path list
    9. Don’t see local info in sho ip bgp = typo
    10. When using loopbacks for peerings don’t forget ebgp-multihop and update-source
    11. troubleshooting: sh ip bpg , sho ip bgp XXX , sho ip bgp sum. Hop by hop.

    Do internal BGP (iBGP) sessions modify the next hop?

    A. iBGP sessions preserve the next hop attribute learned from eBGP peers. This is why it is important to have an internal route to the next hop. The BGP route is otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or issue the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. Refer to the BGP Next Hop Attribute section of BGP Case Studies for a more detailed explanation.

    This command is useful in unmeshed networks (such as Frame Relay or X.25) where BGP neighbors may not have direct access to all other neighbors on the same IP subnet.

    More info on redistributing OSPF into BGP:

    1. router bgp 100
      1. redistribute ospf 1 match internal external 1 external 2
      2. !— This redistributes all OSPF routes into BGP.
    2. router bgp 100
      • redistribute ospf 1
      • !– This redistributes only OSPF intra- and inter-area routes into BGP.If you configure the redistribution of OSPF into BGP without keywords, by only OSPF intra-area and inter-area routes are redistributed into BGP, by default.
    3. redistribute ospf 1 match external 1 external 2
      • !— This redistributes ONLY OSPF External routes,
      • !— but both type-1 and type-2.
    4. redistribute ospf 1 match nssa-external 1 nssa-external 2
      • !— This redistributes only OSPF NSSA-external routes
      • !— Type-1 and Type-2 into BGP.

    Posted in BGP, Routing & Switching Lab | Leave a Comment »

     
    Follow

    Get every new post delivered to your Inbox.