RIPV2 Update Filtering - Offset List,Passive Interface,Administrative Distance,Distribute-List

You can filter RIP updates using various methods and I am going to demonstrate four of them. We will use the topology displayed in figure 1 below. I have auto-summary disabled and running version2. All filtering will take place on R4.

Figure 1

Routing Table Before Any Filtering:

R4#show ip routeed static route

Gateway of last resort is not set

R    200.200.200.0/24 [120/1] via 192.168.100.2, 00:00:07, FastEthernet0/0
     100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       100.100.100.0/24 [120/1] via 192.168.100.2, 00:00:07, FastEthernet0/0
R       100.0.0.0/8 is possibly down,
          routing via 192.168.100.2, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/0
 
Offset List: Lets mark 100.100.100.0/24 invalid by setting an offset of 15. We could of configured 16 as well. I went with 15 since we are already adding 1 hop count by default so it gives us 16.

1. Create an ACL to identify which routes should be filtered.
1.  access-list 1 permit 100.100.100.0 0.0.0.255
2.  Configure the offset-list under the rip process
1. router rip
2.  offset-list 1 in 15

From the debug below we can see that we are successful in preventing the route from making it into the routing table. Rip will only advertise routes that are in the routing table.

R4#debug ip rip
RIP protocol debugging is on
R4#
*Mar  1 00:37:36.811: RIP: received v2 update from 192.168.100.2 on FastEthernet0/0
*Mar  1 00:37:36.815:      100.100.100.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
*Mar  1 00:37:36.815:      200.200.200.0/24 via 0.0.0.0 in 1 hops
*Mar  1 00:37:37.659: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.100.1)
*Mar  1 00:37:37.659: RIP: build update entries - suppressing null update

Passive Interface: Lets enable passive interface default on R4 F0/0.

1. Configure passive-interface default under the rip process
1. router rip
2. passive-interface default

From the debug below we can see that we are successful in preventing R4 from advertising routes to R5.(Compare the Debug From the previous Example). However, R5 can advertise routes to R4.

*Mar  1 00:47:45.955: RIP: received v2 update from 192.168.100.2 on FastEthernet0/0
*Mar  1 00:47:45.955:      100.100.100.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
*Mar  1 00:47:45.959:      200.200.200.0/24 via 0.0.0.0 in 1 hops

Administrative Distance:  Lets increase the Administrative distance for subnet 100.100.100.0/24

1. Create an ACL to identify which routes should be filtered.
1.  access-list 1 permit 100.100.100.0 0.0.0.255
2.  Configure the distance value under the rip process
1. router rip
2.  distance 200 192.168.100.2 0.0.0.0 1 (The way to read this is apply admin distance 200 for any  routes in access-list 1 coming from 192.168.100.2).

We can see the update was succesfull from the following show ip route output. If you wanted to you can set the admin distance to 255(inaccessible) and the route will never get into the routing table (RIB).

R    200.200.200.0/24 [120/1] via 192.168.100.2, 00:00:17, FastEthernet0/0
     100.0.0.0/24 is subnetted, 1 subnets
R       100.100.100.0 [200/1] via 192.168.100.2, 00:00:17, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/0
R4#

distribute-list: Lets filter 100.100.100.0/24 from the routing table.

1. Create a prefix-list to identify which routes we want to only allow in.
1.  ip prefix-list filter_rip permit 200.200.200.0/24
2.  Configure the distribute-list under the rip process
1. router rip
2.  distribute-list prefix filter_rip in

 We can see the update was succesfull from the following show ip route output. We can also confirm
 that we are filtering routes inbound via show ip protocols.

Gateway of last resort is not set

R    200.200.200.0/24 [120/1] via 192.168.100.2, 00:00:06, FastEthernet0/0
C    192.168.100.0/24 is directly connected, FastEthernet0/0

R4#show ip protocols
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is (prefix-list) filter_rip
  Sending updates every 30 seconds, next due in 13 seconds

CCNP TO CCIE

Its been sometime since I last updated the Blog and Now I am going to try and update the blog on a weekly basis. I have passed all three CCNP Routing & Switching Exams. I am officially CCNP Certified. I am now working on my CCIE. I need to update the title of the blog :-).

Cisco FIB VS RIB

Routing Information Base (RIB)

The Routing Information Base RIB is the location in which all IP Routing information is stored. The RIB is not specific to any routing protocol, rather, it is the repository where all the routing protocols place all of their routes. Routes are inserted into the RIB whenever a routing protocol running on the router learns a new route. When a destination becomes unreachable, the route is first marked unusable and later removed from the RIB as per the specifications of the routing protocol they were learned from. It is important to note that the RIB is NOT used for forwarding IP datagrams, nor is it advertised to the rest of the networks to which the router is attached. A Cisco router's RIB will contain filtered routes; however, these will never make it to the "Forwarding Information Base", which contains yet a different set of routes.

 CEF Disabled:

*Mar  1 01:11:40.003: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via RIB
*Mar  1 01:11:40.003: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending
*Mar  1 01:11:40.059: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via RIB
*Mar  1 01:11:40.063: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending
*Mar  1 01:11:40.087: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via RIB
 

Forwarding Information Base (FIB)

Cisco routers build a Forwarding Information Base (FIB) which contains all the routes that could potentially be advertised to all neighboring routers within the next set of announcements. This is also the same set of routes used to forward IP datagrams. On Cisco routers with a distributed forwarding architecture and which have Distributed Cisco Express Forwarding (DCEF) enabled, a copy of the FIB will be 'compiled' and downloaded to the applicable line-cards or modules. This offloads a large portion of the routing load from the main CPU and increases the overall traffic load that can be sustained by the router.

 CEF Enabled:

*Mar  1 01:11:28.735: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via FIB
*Mar  1 01:11:28.735: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending
*Mar  1 01:11:28.755: IP: tableid=0, s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), routed via FIB
*Mar  1 01:11:28.755: IP: s=10.10.10.1 (local), d=192.168.100.1 (FastEthernet0/0), len 100, sending

MPLS Neighbor Security

I am going to show you how to implement LDP security between neighbors.  These are computed as MD5 Signatures.

Lets verify how our neighborship currently looks on R2 AKA the (P) router. We see have two diffrent neighbors.  Lets set a password for each.

R2#show mpls ldp neighbor
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 1.1.1.1.646 - 2.2.2.2.48828
        State: Oper; Msgs sent/rcvd: 8/8; Downstream
        Up time: 00:00:07
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 192.168.100.1
        Addresses bound to peer LDP Ident:
          192.168.100.1   1.1.1.1
    Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 4.4.4.4.23134 - 2.2.2.2.646
        State: Oper; Msgs sent/rcvd: 8/8; Downstream
        Up time: 00:00:06
        LDP discovery sources:
          GigabitEthernet2/0, Src IP addr: 192.168.104.1
        Addresses bound to peer LDP Ident:
          192.168.104.1   4.4.4.4

R2(config)#mpls ldp neighbor 1.1.1.1 password joel
R2(config)#mpls ldp neighbor 4.4.4.4 password joel

Now we will need to do the same on R1 and R4 but lets not do it yet. I am going to clear the LDP neighborship to see what errors are generated since we have not made any changes on R1 and R4.

R2#clear mpls ldp neighbor *
R2#
*Mar 18 22:27:26.395: %LDP-5-CLEAR_NBRS: Clear LDP neighbors (*) by console
*Mar 18 22:27:26.455: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (3) is DOWN (User cleared session manually)
*Mar 18 22:27:26.471: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (1) is DOWN (User cleared session manually)
R2#

We can see from the alert below that we are not getting an MD5 from either neighbor 4.4.4.4 or 1.1.1.1. If they had a password set but it was incorrect it would say something alongs the line as it was invalid.

R2#
*Mar 18 22:27:43.707: %TCP-6-BADAUTH: No MD5 digest from 4.4.4.4(35699) to 2.2.2.2(646) tableid - 0
*Mar 18 22:27:44.055: %TCP-6-BADAUTH: No MD5 digest from 1.1.1.1(646) to 2.2.2.2(45946) tableid - 0

Now lets configure R1 and R4.

R1(config)#mpls ldp neighbor 2.2.2.2 password joel
R1(config)#end
R1#
*Mar 18 22:30:03.471: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar 18 22:30:13.451: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP

R4(config)#mpls ldp neighbor 2.2.2.2 password joel
R4(config)#end
R4#
*Mar 18 22:31:05.403: %SYS-5-CONFIG_I: Configured from console by console
R4#
*Mar 18 22:31:17.335: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP
R4#

We are all done now.

Building an MPLS VPN Extranet/Intranet

I spent the past two days researching and building the MPLS VPN network below. It sure was fun and a great refresher.  Below you will find details of what is required and some verification output.
You also should check out the following PDF link from NIL,the packet life link and the Cisco Video on building MPLS vpn's. I watched the video and its all relevant information.

Introduction to MPLS VPN [Webcast]

MPLS VPN Cheat Sheet

Creating an MPLS VPN - PacketLife

My goal with this post was not to provide you with all the commands but rather a guide. I find that when configurations are provided, you don't retain as well as if you had to research it. If you want the configs, put a comment in with your email address and I will send them over.

 

Building the MPLS Core:

1. Create loopback interfaces on R1,R2 and R4.
2. On R1,R2 and R4 you need to enable OSPF as your transport mechanisms for your loopback interfaces and the interconnects (Point to Point Interfaces) between the switches. Put them all in Area 0.
3. Enable mpls ip globally and on the interconnects between R1,R2 and R4. Also you want to hard set the LDP router id for LDP with the following command, mpls ldp router-id Loopback0.  Hard set it on R1 and R4 as well.
4. keep in mind that you will use the loopback interface for BGP peering between the PE devices.

Verifications:

R2#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               2.2.2.2/32         1     LOOP  0/0
Gi2/0        1     0               192.168.104.2/24   1     P2P   1/1
Gi0/0        1     0               192.168.100.2/24   1     P2P   1/1

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -        00:00:38    192.168.104.1   GigabitEthernet2/0
1.1.1.1           0   FULL/  -        00:00:31    192.168.100.1   GigabitEthernet0/0
R2#

R2#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet0/0     Yes (ldp)     No       No  No     Yes
GigabitEthernet2/0     Yes (ldp)     No       No  No     Yes

R2#show mpls ldp neighbor
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 1.1.1.1.646 - 2.2.2.2.44858
        State: Oper; Msgs sent/rcvd: 135/136; Downstream
        Up time: 01:51:40
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 192.168.100.1
        Addresses bound to peer LDP Ident:
          192.168.100.1   1.1.1.1

Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 2.2.2.2:0
        TCP connection: 4.4.4.4.56543 - 2.2.2.2.646
        State: Oper; Msgs sent/rcvd: 136/136; Downstream
        Up time: 01:51:24
        LDP discovery sources:
          GigabitEthernet2/0, Src IP addr: 192.168.104.1
        Addresses bound to peer LDP Ident:
          192.168.104.1   4.4.4.4
R2#

Keep in mind that the P router is not going to be aware of any customer routes. It will label switch the traffic. Most of the configurations will be on the PE devices and CE.

Building the PE Configurations for R1:

1. Configure VRF's, Route Distinguisher, and Route-Targets.
2. Configure MPLS globally and on Interfaces facing the P router.
3. Configure CE facing interfaces to be part of a VRF.
4. Configure IBGP peering between PE Devices to Exchange vpnv4 routes.
5. Configure CE to PE routing protocol(RIP,EIGRP,OSPF or BGP).

Verifications:
R1#show ip vrf detail
VRF corp (VRF Id = 1); default RD 100:1; default VPNID <not set>
  Interfaces:
    Fa3/0
VRF Table ID = 1
  Export VPN route-target communities
    RT:100:1
  Import VPN route-target communities
    RT:100:1
  No import route-map
  No global export route-map
  No export route-map
  VRF label distribution protocol: not configured
  VRF label allocation mode: per-prefix

VRF das (VRF Id = 2); default RD 102:1; default VPNID <not set>
  Interfaces:
    Gi1/0
VRF Table ID = 2
  Export VPN route-target communities
    RT:102:1
  Import VPN route-target communities
    RT:102:1
  No import route-map
  No global export route-map
  No export route-map
  VRF label distribution protocol: not configured
  VRF label allocation mode: per-prefix


R1#show ip vrf
  Name                             Default RD          Interfaces
  corp                             100:1               Fa3/0
  das                              102:1               Gi1/0

R1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet0/0     Yes (ldp)     No       No  No     Yes
R1#

R1#show mpls ldp neighbor
    Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0
        TCP connection: 2.2.2.2.44858 - 1.1.1.1.646
        State: Oper; Msgs sent/rcvd: 150/148; Downstream
        Up time: 02:03:41
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 192.168.100.2
        Addresses bound to peer LDP Ident:
          192.168.100.2   2.2.2.2         192.168.104.2

R1#show ip bgp vpnv4 all summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 19, main routing table version 19
9 network entries using 1404 bytes of memory
14 path entries using 1120 bytes of memory
10/6 BGP path/bestpath attribute entries using 1440 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
3 BGP extended community entries using 104 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 4116 total bytes of memory
BGP activity 9/0 prefixes, 14/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4         4                100     150     151               19        0    0         02:04:16        6
192.168.103.1   4          200     142     142               19        0    0         02:05:06        2
R1#

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:32    192.168.100.2   GigabitEthernet0/0
7.7.7.7           1   FULL/BDR        00:00:30    192.168.250.1   GigabitEthernet1/0
R1#

Building CE configurations for R3:

Enable EBGP peering between the CE and PE
Update BGP Network statements to reflect any routes you want sent via the MPLS

Verifications:
R3#show ip bgp
BGP table version is 7, local router ID is 200.200.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  5.5.5.5/32       192.168.103.2                          0 100 300 i
 *>  100.100.100.0/24 0.0.0.0                  0         32768 i
 r>  192.168.103.0/30 192.168.103.2            0             0 100 ?
 *>  200.200.200.0    0.0.0.0                  0         32768 i

R3#show ip bgp summary
BGP router identifier 200.200.200.1, local AS number 200
BGP table version is 7, main routing table version 7
4 network entries using 576 bytes of memory
4 path entries using 320 bytes of memory
3/3 BGP path/bestpath attribute entries using 408 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1352 total bytes of memory
BGP activity 5/1 prefixes, 5/1 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.103.2   4          100     147     147        7    0    0 02:09:38        2
R3#

R5#show ip int brief
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        unassigned      YES NVRAM  administratively down down
GigabitEthernet1/0     192.168.120.1   YES NVRAM  up                    up
FastEthernet2/0        unassigned      YES unset  administratively down down
FastEthernet2/1        unassigned      YES unset  administratively down down
Loopback5              5.5.5.5         YES NVRAM  up                    up
Loopback200            unassigned      YES unset  up                    up
R5#

R3#show ip int brief
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        unassigned      YES NVRAM  administratively down down
GigabitEthernet1/0     unassigned      YES NVRAM  up                    up
FastEthernet2/0        192.168.103.1   YES NVRAM  up                    up
FastEthernet2/1        unassigned      YES NVRAM  administratively down down
Loopback100            100.100.100.1   YES NVRAM  up                    up
Loopback200            200.200.200.1   YES NVRAM  up                    up

R3#ping 5.5.5.5 source loopback 200
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 200.200.200.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/119/164 ms
R3#

Upgrade Cisco NX-OS For Cisco Nexus 3000 Series Switch

Step 1:
Copy the files onto the device: You can use TFTP, FTP or SCP. I like SCP because its way faster then then TFTP. Download a free copy of Solar Winds SCP.

copy scp://admin@192.168.100.1/n3000-uk9.5.0.3.U3.2.bin bootflash:
copy scp://admin@192.168.100.1/n3000-uk9-kickstart.5.0.3.U3.2.bin bootflash:

Step 2:
Confirm the files are are in the directory you specified: You also don't need to run an MD5 check because that is part of the install all option.

switch# dir
        638    Jun 18 19:37:32 2012  license_FOC1536R01A_4.lic
      49152    Feb 26 18:24:48 2013  lost+found/
       3166    Feb 26 18:02:57 2013  mts.log
   25439232    Jun 18 19:31:49 2012  n3000-uk9-kickstart.5.0.3.U2.2b.bin
   25439744    Feb 26 19:00:08 2013  n3000-uk9-kickstart.5.0.3.U3.2.bin
   93751392    Jun 18 19:32:32 2012  n3000-uk9.5.0.3.U2.2b.bin
  126502986    Feb 26 18:59:16 2013  n3000-uk9.5.0.3.U3.2.bin
       4096    Jan 29 19:35:08 2010  vdc_2/
       4096    Jan 29 19:35:08 2010  vdc_3/
       4096    Jan 29 19:35:08 2010  vdc_4/

Step 3:
Select which images to install and from what directory:

install all kickstart bootflash:///n3000-uk9-kickstart.5.0.3.U3.2.bin system bootflash:///n3000-uk9.5.0.3.U3.2.bin


switch# install all kickstart bootflash:///n3000-uk9-kickstart.5.0.3.U3.2.bin system bootflash:///n3000-uk9.5.0.3.U3.2.bin
Installer is forced disruptive

Verifying image bootflash:/n3000-uk9-kickstart.5.0.3.U3.2.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS

Verifying image bootflash:/n3000-uk9.5.0.3.U3.2.bin for boot variable "system".
[####################] 100% -- SUCCESS

Verifying image type.
[####################] 100% -- SUCCESS

Extracting "system" version from image bootflash:/n3000-uk9.5.0.3.U3.2.bin.
[####################] 100% -- SUCCESS

Extracting "kickstart" version from image bootflash:/n3000-uk9-kickstart.5.0.3.U3.2.bin.
[####################] 100% -- SUCCESS

Extracting "bios" version from image bootflash:/n3000-uk9.5.0.3.U3.2.bin.
[####################] 100% -- SUCCESS

Performing module support checks.
[####################] 100% -- SUCCESS

Notifying services about system upgrade.
[####################] 100% -- SUCCESS



Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes      disruptive         reset  ISSU not supported



Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            5.0(3)U2(2b)             5.0(3)U3(2)           yes
     1   kickstart            5.0(3)U2(2b)             5.0(3)U3(2)           yes
     1        bios      v1.2.0(08/29/2011)      v1.2.0(08/29/2011)            no
     1   power-seq                    v5.1                    v5.1            no



Step 4: You will be prompted to reboot. Select Yes.

ISSU is not supported on this platform!!
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  [n] y

ISSU is not supported on this platform!!
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  [n] y

Install is in progress, please wait.

Performing runtime checks.
[####################] 100% -- SUCCESS

Setting boot variables.
[####################] 100% -- SUCCESS

Performing configuration copy.
[####################] 100% -- SUCCESS

Finishing the upgrade, switch will reboot in 10 seconds.
switch#

Step 5:  Issue a show version to confirm the NX-OS version once it comes back from the reboot.

Troubleshooting High CPU due to Multicast

Great Video on Troubleshooting High CPU due to Multicast. This video is geared toward IOS and not NX-OS.

https://supportforums.cisco.com/community/netpro/network-infrastructure/switching/blog/2012/12/12/troubleshooting-high-cpu-due-to-multicast

Cisco Multicast Security - IOS Base

A Must read on Multicast Security. One thing that I really like about this article is the illustrations provided. Most documents talk about these feature sets, but never illustrate how they work and for me personally it helps grasp these topics.

 
http://www.cisco.com/web/about/security/intelligence/multicast_toolkit.html

Reverse Engineering - DHCP & NetFlow

Most often than not, you will be required to reverse engineer different environments that are undocumented. I have been tasked with swapping out another 6509 for a 6509E and adding a secondary 6509E for redundancy.

One of the items I discovered that was unique to this environment was the DHCP configurations someone put in but never documented them and some NetFlow that was running but never being exported. It also was against policy for this environment.

 You will learn a lot while reverse engineering. Take for example this DHCP configuration; I have always implemented what was shown to me in Cisco books and never to the extent of what I found.  Another important lesson is to know what dependencies one configuration has to another, this is how things break if you don't over analyze. I obviously masqueraded some of the items due to security concerns and these two configurations have no dependency on each other.

DHCP CONFIG:

ip dhcp pool AP
   host 10.200.10.58 255.255.255.0
   client-identifier 0100.c0b7.2d38.07
   bootfile config.ini
   default-router 10.200.10.254
   domain-name joel.com
   option 150 ip 10.200.10.102
   lease 7

ip dhcp pool AP
   host 10.200.10.59 255.255.255.0
   client-identifier 0100.c0b7.2d37.c3
   bootfile config.ini
   default-router 10.200.10.254
   domain-name joel.com
   option 150 ip 10.200.10.102
   lease 7

Document I used to figure out what was going with this configuration:
http://www.cisco.com/en/US/docs/ios/12_1/iproute/command/reference/1rddhcp.html#wp1018363

Verfication:

6509E#show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address
10.200.10.58 0100.c0b7.2d38.07 Infinite Manual
10.200.10.59 0100.c0b7.2d37.c3 Infinite Manual

NetFlow Config:

6509E#show running-config | include netflow
mls netflow interface
6509E#show run int vlan 30
Building configuration...
Current configuration : 174 bytes
!
interface Vlan30
 description AP
 ip address 10.200.10.254 255.255.255.0
 ip flow ingress
end

Document I used to figure out what was going with this configuration:
http://www.cisco.com/en/US/docs/ios/netflow/command/reference/nf_02.html#wp1012875

Verification:

6509E#show ip cache flow
-------------------------------------------------------------------------------
Displaying software-switched flow entries on the MSFC in Module 6:
IP packet size distribution (98171M total packets):
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .174 .019 .012 .007 .013 .054 .007 .002 .003 .004 .001 .016 .000 .000
    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .080 .073 .523 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
  534 active, 3562 inactive, 2284418974 added
  2945144932 ager polls, 0 flow alloc failures
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 33992 bytes
  0 active, 1024 inactive, 0 added, 0 added to flow
  0 alloc failures, 0 force free
  1 chunk, 1 chunk added
  last clearing of statistics never
Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-Telnet     1685390      0.3         1    47      0.7       0.8      14.3
TCP-FTP        1258810      0.2         1    51      0.5       0.5      12.0
TCP-FTPD        282755      0.0         1    48      0.0       0.0      14.4

Vlan Access-Map and mac address access-list

How do you prevent intravlan communication? If you wanted to prevent InterVlan communications, you would create a RACL and apply it to the L3 interface. But when you want to prevent IntraVlan communications, you will need to a VACL. I will demonstrate how to create a VACL and apply it. Additionally, how you can also filter down to the mac address of a host rather than the ip address.

We will use figure 1 to visualize the configuration and once done we will have completed the following actions.

1.     Prevent PC1 from talking to PC2

2.     Prevent PC1 from talking to PC3

3.     Allow all other communication between hosts

4.     Apply VACL to Vlan 100

Figure 1

Configuration:

access-list 100 permit ip host 192.168.100.1 host 192.168.100.2
!
mac access-list extended macfilter
permit host 4055.39a8.101f host 4055.39a8.103f
!
vlan access-map Vlan_100_Filter 10
action drop
match ip address 100
!
vlan access-map Vlan_100_Filter 20
action drop
match mac address macfilter
!
vlan access-map Vlan_100_Filter 30
action forward
!
vlan filter Vlan_100_Filter vlan-list 100

Verification:

Cisco_4948E_01#show vlan filter
VLAN Map Vlan_100_Filter is filtering VLANs:
  100
Cisco_4948E_01#show vlan access-map Vlan_100_Filter
Vlan access-map "Vlan_100_Filter"  10
  Match clauses:
    ip  address: 100
  Action:
    drop
Vlan access-map "Vlan_100_Filter"  20
  Match clauses:
    mac address: macfilter
  Action:
    drop
Vlan access-map "Vlan_100_Filter"  30
  Match clauses:
  Action:
    forward

Cisco_4948E_01#show ip access-lists 100
Extended IP access list 100
    10 permit ip host 192.168.100.1 host 192.168.100.2
Cisco_4948E_01#show access-list macfilter
Extended MAC access list macfilter
    permit host 4055.39a8.101f host 4055.39a8.103f

I could of just filtered based on the ip addresses of the host rather than creating a mac acl but I wanted to demonstrate the feature. I have not seen it widely deployed.

Cisco 6509E Redundant Mode VS Combined Mode

Today while setting up a spare chassis to be used for burning in cards only, I noticed something that I never ran into.  Two out of the 8 modules that I had loaded into the chassis were showing a status of PwrDeny (See Example 1.1). We can correct this by installing higher wattage power supplies or changing the power mode from redundant to combined mode. I personally would prefer to install the higher wattage power supplies, but due to circumstances out of my control, I ended up changing the power mode to combined. Pros and Cons are below as well.

Redundant Mode:
When running in Redundant Mode, each power supply provides approximately 50% of its capacity to the chassis. In the event of a failure, the unaffected power supply will then provide 100% of its capacity and an alert will be generated. As there was enough to power the chassis ahead of time, there is no interruption to service in this configuration. This is also the default and recommended way to configure power supplies

Combined Mode:
In combined mode, each power supply provides approximately 83% of its capacity to the chassis. This allows for greater utilization of the power supplies and potentially increased PoE densities

Source: http://en.wikipedia.org/wiki/Catalyst_6500

Example 1.1

6509E_BURN_IN#show mod
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     XXXXXXXXXXXX
  2    8  CEF720 8 port 10GE with DFC            WS-X6708-10GE      XXXXXXXXXXXX
  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     XXXXXXXXXXXX
  4   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX    XXXXXXXXXXXX
  5    5  Supervisor Engine 720 10GE (Active)    VS-S720-10G      XXXXXXXXXXXX
  6    5  Supervisor Engine 720 10GE (Hot)       VS-S720-10G        XXXXXXXXXXXX
  7   16  CEF720 16 port 10GE                    WS-X6716-10GE      XXXXXXXXXXXX
  8   16  CEF720 16 port 10GE                    WS-X6716-10GE      XXXXXXXXXXXX

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  1  0023.5e7f.4ac0 to 0023.5e7f.4aef   3.0   12.2(18r)S1  12.2(33)SXI6 Ok
  2  001e.f7f8.21e8 to 001e.f7f8.21ef   1.4   12.2(18r)S1  12.2(33)SXI6 Ok
  3  0012.4376.c1d0 to 0012.4376.c1ff   2.1   Unknown      Unknown      PwrDeny
  4  0021.55df.1ed0 to 0021.55df.1eff   2.8   12.2(18r)S1  12.2(33)SXI6 Ok
  5  0025.84bf.7b08 to 0025.84bf.7b0f   3.1   8.5(3)       12.2(33)SXI6 Ok
  6  001e.4a7e.e468 to 001e.4a7e.e46f   3.1   8.5(3)       12.2(33)SXI6 Ok
  7  e05f.b974.a680 to e05f.b974.a68f   1.0   12.2(18r)S1  12.2(33)SXI6 Ok
  8  e05f.b974.a860 to e05f.b974.a86f   1.0   Unknown      Unknown      PwrDeny

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  1  Distributed Forwarding Card WS-F6700-DFC3B     SAL12437YGQ  4.7    Ok
  2  Distributed Forwarding Card WS-F6700-DFC3C     SAL1223SNM7  1.0    Ok
  3  Centralized Forwarding Card WS-F6700-CFC       SAD0843019H  2.0    PwrDeny
  4  Distributed Forwarding Card WS-F6700-DFC3B     SAL1219Q4TH  4.6    Ok
  5  Policy Feature Card 3       VS-F6K-PFC3C       SAL1407B9EV  1.1    Ok
  5  MSFC3 Daughterboard         VS-F6K-MSFC3       SAL1407BJ77  2.1    Ok
  6  Policy Feature Card 3       VS-F6K-PFC3C       SAL1408BN6M  1.1    Ok
  6  MSFC3 Daughterboard         VS-F6K-MSFC3       SAL1407BFWL  2.1    Ok
  7  Distributed Forwarding Card WS-F6700-DFC3C     SAL15139YZ9  1.4    Ok
  8  Distributed Forwarding Card WS-F6700-DFC3C     SAL1513A3BP  1.4    PwrDeny

Mod  Online Diag Status
---- -------------------
  1  Pass
  2  Pass
  3  Not Applicable
  4  Pass
  5  Pass
  6  Pass
  7  Pass
  8  Not Applicable

Confirming The Current Mode:
6509E_BURN_IN#show power redundancy-mode
system power redundancy mode = redundant

Changing The Power Mode:
6509E_BURN_IN(config)#power redundancy-mode combined
6509E_BURN_IN(config)#
6509E_BURN_IN(config)#end
!
6509E_BURN_IN#show power redundancy-mode
system power redundancy mode = combined



 

 

Capturing 802.11 Frames in Wireshark

Figured I would pass this along. I started reading chapter 15 in the CCNP Switch certification Guide; Integrating Wireless LANs. While reading the first few pages, I quickly wanted to get a sniffer out and check out all of these 802.11 frame specifications that it references.

Some examples are DIFS(duration timer) and the random back off timer.  I decided to fire up Wireshark, but the frames kept appearing as 802.3(Ethernet) frames. This is known as "fake" Ethernet headers. Unfortunately, with the current WIFI card installed in my laptop, I won’t be able to sniff  802.11 traffic.  

Per Wire Shark:
Without any interaction, capturing on WLAN's may capture only user datapackets with "fake" Ethernet headers. In this case, you won't see any 802.11 management or control packets at all, and the 802.11 packet headers are "translated" by the network driver to "fake" Ethernet packet headers.

http://wiki.wireshark.org/CaptureSetup/WLAN

You can also download a 802.11 capture and learn how to read it by following this document.

http://www.cse.ust.hk/~muppala/csit5610/labs/Wireshark_labs/Wireshark_802_11.pdf