Here's a trick I would like to pass along, I worked in a environment , where directors mandate that only senior engineers had access to the routers & in the config mode. This was struggle, due too I didn't want to be sitting around a phone dialup and vpn session for every little issues that cropped up.
Typically we had onsite technicians at our numerous remote-branches, that would execute power-down and relocations in the branch IT room on a monthy if not weekly rotation schedule.
To ensure them that devices (branch routers) where backup, and that no configuration was lost due to a power down/electrical_reroute/rollover on generator/etc........ we use a standard backup user account, within our domain & with the cisco autocmd features , and with tacacs and/or a local userdatabase.
The autocmd used tcl ( aka tickle for us linux geeks ) and called the cmd to be execute as if we where on a cli and doing it ourselves.
In this example, I will show you how a local user named backup, did my chores :)
1st make a user named backup, name can be whatever you want ( neteng,eng,backup, doesn't matter but make it something simple )
config t
username backup priv 15 autocommand tclsh flash:backmeupnow.tcl
!
2nd
next create a tcl ( tickle ) script to call out whatever you want it to do. In this case we will backup and copy the file to a tftp:server located at 1.1.1.1
tclsh
set x [ open "flash:backmeupnow.tcl" w+]
set ken { write mem
copy running tftp://1.1.1.1/myroutername.config
}
puts $x $ken
close $x
tclquit
3rd
validate the script via dir flash:backmeupnow.tcl or a more flash:backmeupnow.tcl
To test, just telnet or ssh into the router as the autocmd username of backup in my case. This user could also execute the same on console, if you have restricted access-class on your vtys. You can run the cmd on the router using the cli also
i.e ( ran'd off a 7200 cli at a equinix facility )
BO17200WEST01BATL#tclsh backmeupnow.tcl
Building configuration...
[OK]
Address or name of remote host [1.1.1.1]?
Destination filename [myroutername.config]?
A backup script like this, can save you from having to be engaged in every powerdown event. It can also be used in a emergency event such as; the remote-branch office is without internet due to a fiber, carrier outage and you want to recycle your gear but was not sure if the device was backuped. And you can create a SNAFU/SHTF account script, for those critical issues that might come up & where your not around or have remote access to the device.
Or worst if you have a major onsite issues ( with lack remote access ), and maybe you want to save any changes before you have the local techie pull the power_plug for that just-in-case moment.
I hope you find this trick simple to use, be creative in your scripting thoughts/ideals and you can use this for other simple daily chores.
for_example;
example1
We use to use have an automated telnet generator ( linux host ) that would rotate thru all of our financial sector routers at 23:59 ( sun-thurs ) and clear the interface counters and logs on our gear so we had a fresh start at market open. Since we had 56 routers spread out over 8 data-hotels, I rather be in bed catching ZZZZzzzzzzzs vrs logging into 56 routers and clearing logs/counts on our interfaces :)
example2
In another issue, we had routers that would fail continually, and I didn't want to give a local techie enable access, so we had a tac act that did a show tech-support, and wrote the file to screen and also copy it down to a tftp server local to each branch. In this way they could get the file over to me via external email & I/them can pass the file to cisco-tac via attach@cisco.com or whatever cisco is using now.
The security risk in all of the examples, is minor in these case. Since nothing is being configured. Whatever action you have, it would need the priv-level adjusted, for it to complete the task at hand. So think about that when you select a autocmd+user+script-cmds.
I hope that you found this tip/trick helpful , and maybe you can hack it up and use it in your setup.
Ken Felix
Freelance Network/Security Guy
kfelix at hyperfeed dot com
Wednesday, January 23, 2013
my Cisco RTP CCIE RS status 01/22/2013
A quick status update. My CCIE attempt didn't even get off the ground. I had major problems with the emulator systems in the TS section at the RTP location in the AM.
My proctor was great with trying to get a final resolution, but at about 11:00AM , I was given the choice to now start my day ( as the proctor worded) or cancel and get credit for a follow up. I choose the other. The lack of momemtum, the back and forth with logging in and out of the lab, trying to wait patiently for a fix, was all tiring and frustrating. So I opt-out to get a re-credit and come back again at the lost of my hotel/air/car-rental cost.
I'm going to leave you some photos of this trip to RTP for my 2nd attempt. 1st here the cisco logo when you drive in off Kitt Road. Btw this logo is bright and nice at night. On my next trip, I will take a night photo of it.
Yes that's my RS book rested on the 2nd C :) Every attempt that I make I like to take photo shoot of my book on the logo.
On the campus you can't get lost , it's marked and with nice direction pointers to the fame or fate (aka building #3 )
Yes even Stevie Wonder can find building #3. It clearly marked with arrows and signs all over the campus.
Here's the building #3 shots.
Yes that lobby is where we meet at bright and early around 07:00ish time. The proctor is quick and very detailed on what you can't and can do at RTP. But basically the walk-thru is like the following;
1: he shows up at the door around 07:08
2: does a roll call, and checks for photo ID ( be ready )
3: we follow him down the main corridor and he points out mens/ladies bathroom, breakroom, and where lunch is served ( pay attention )
4: we enter the lab area ( pay very close attention )
5: he goes over the DOs and DONOTs ( mainly the DONOTs ...once again pay very very very close attention )
6: part of the DONOTs
NOTE : lunch is served at 11:20ish it's not a alot but it's something. They had lasagna on that day. My 1st attempt was some chicken cover in tomatoe paste :(
7: Bottom line the lab is straight forward. And look at it as; "a valuable less and experience in the category of certification that your going thru". Some of the candidates will be 1st timers or vets. Don't be frustrated, upset or nervous. If you prepared correctly, this is just like doing your job, but in a timed crunch fashion. With the time being your worst enemy.
I hope you find this post interesting. I will follow up with ciso and try to reschedule in Feb/Mar depending on my availability and time. The march on for my CCIE in RS will continue, I will surrender in defeat :)
I'm leaving you some pictures of cisco bikes on the RTP campus. I guess you can check these bikes out, and ride around the campus
Ken Felix
Freelance Network/Security Engineer
kfelix hyperfeed dot com
My proctor was great with trying to get a final resolution, but at about 11:00AM , I was given the choice to now start my day ( as the proctor worded) or cancel and get credit for a follow up. I choose the other. The lack of momemtum, the back and forth with logging in and out of the lab, trying to wait patiently for a fix, was all tiring and frustrating. So I opt-out to get a re-credit and come back again at the lost of my hotel/air/car-rental cost.
I'm going to leave you some photos of this trip to RTP for my 2nd attempt. 1st here the cisco logo when you drive in off Kitt Road. Btw this logo is bright and nice at night. On my next trip, I will take a night photo of it.
Yes that's my RS book rested on the 2nd C :) Every attempt that I make I like to take photo shoot of my book on the logo.
On the campus you can't get lost , it's marked and with nice direction pointers to the fame or fate (aka building #3 )
Yes even Stevie Wonder can find building #3. It clearly marked with arrows and signs all over the campus.
Here's the building #3 shots.
Yes that lobby is where we meet at bright and early around 07:00ish time. The proctor is quick and very detailed on what you can't and can do at RTP. But basically the walk-thru is like the following;
1: he shows up at the door around 07:08
2: does a roll call, and checks for photo ID ( be ready )
3: we follow him down the main corridor and he points out mens/ladies bathroom, breakroom, and where lunch is served ( pay attention )
4: we enter the lab area ( pay very close attention )
5: he goes over the DOs and DONOTs ( mainly the DONOTs ...once again pay very very very close attention )
6: part of the DONOTs
- no electrical devices ( yes guys this should obvious, but don't bring your computer,laptop, radio, mini-disc player and even watches and key-flops & electronic badges, have to be remove )
- do not bring your cell phone ( your not allowed to use it and can't bring inside the lab and on this trip; a guy was band, because went outside and brought his phone back in during the lunch break......... Why would you think you need a phone in a lab env is beyond me ) Do yourself a favor and just leave all of these items back at the car or hotel
- Only one person can go to restroom/breakroom at a time during the lab
- You have a small walllocker that you can use for storage, if you happen not to read the above "don't bring to the lab items" :)
NOTE : lunch is served at 11:20ish it's not a alot but it's something. They had lasagna on that day. My 1st attempt was some chicken cover in tomatoe paste :(
7: Bottom line the lab is straight forward. And look at it as; "a valuable less and experience in the category of certification that your going thru". Some of the candidates will be 1st timers or vets. Don't be frustrated, upset or nervous. If you prepared correctly, this is just like doing your job, but in a timed crunch fashion. With the time being your worst enemy.
I hope you find this post interesting. I will follow up with ciso and try to reschedule in Feb/Mar depending on my availability and time. The march on for my CCIE in RS will continue, I will surrender in defeat :)
I'm leaving you some pictures of cisco bikes on the RTP campus. I guess you can check these bikes out, and ride around the campus
Ken Felix
Freelance Network/Security Engineer
kfelix hyperfeed dot com
Monday, January 21, 2013
A quick post on QoS 2960/3560s auto-qos
This post is about a simple diagram that shows the standard queues and cos values associated to various traffic. Please see the diagram here;
VoIP and the voice bearer portion is always set as expedite forward ( AKA EF or decimal value 46 ), in most case it's also associated with CoS value #5. Your cos-2-dscp and dscp-2-qos maps should also reflect this;
cisco 2960:
ccie2960_01>sh mls qos map cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 46 48 56
and
ccie2960_01>sh mls qos map dscp-cos
Dscp-cos map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 01 01
1 : 01 01 01 01 01 01 02 02 02 02
2 : 02 02 02 02 03 03 03 03 03 03
3 : 03 03 04 04 04 04 04 04 04 04
4 : 05 05 05 05 05 05 05 05 06 06
5 : 06 06 06 06 06 06 07 07 07 07
6 : 07 07 07 07
The typical cisco auto-qos does a good job with setting up your mls qos options. You may have to re-view and re-adust them based on the desired QoS goals and classification that you might need in your local LAN.
Typical most congestion are the output of the WAN and trunk-ports. So plan and review you mls qos settings and mainly any drops.
e.g
show mls qos int fas 0/3 statistics | b dropped
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 0 0 0
queue 2: 0 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
To enable auto-qos the commands are simple;
1: what's expected on the port that we are to enable auto-qos on ( phone, etc..)
2: do we want to trust any qos settings layer2 ( cos ) or layer3 (dscp)
3: here's how to set QoS on a layer2 access-port that connected to a phone;
(config-if)#auto qos voip ?
cisco-phone Trust the QoS marking of Cisco IP Phone
cisco-softphone Trust the QoS marking of Cisco IP SoftPhone
trust Trust the DSCP/CoS marking
and
(config-if)#auto qos voip cisco-phone
and the following show cmd provides me with the following output;
sh mls qos int fas 0/4
FastEthernet0/4
Attached policy-map for Ingress: AutoQoS-Police-CiscoPhone
trust state: not trusted
trust mode: trust cos
trust enabled flag: dis
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based
and we will find that the switch now has mls qos enabled globally and the port has some mls qos cfgs
!
interface FastEthernet0/4
switchport access vlan 199
switchport mode access
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
end
In the above, we are using mls qos and legacy policy-map with the map name AutoQoS-Police-CiscoPhone. Let's look at that service policy map;
show policy-map AutoQoS-Police-CiscoPhone
Policy Map AutoQoS-Police-CiscoPhone
Class AutoQoS-VoIP-RTP-Trust
set dscp ef
police 1000000 8000 exceed-action policed-dscp-transmit
Class
AutoQoS-VoIP-Control-Trust set dscp cs3
police 1000000 8000 exceed-action policed-dscp-transmit
Very simple it's a 2 class map using AutoQoS-VoIP-RTP-Trust and AutoQoS-VoIP-Control-Trust.
These class-maps are defined in the cfg as the following;
class-map match-all AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-all AutoQoS-VoIP-Control-Trust
match ip dscp cs3 af31
!
Notice the match-all and in the control-trust we are matching on AF31 and cs3? ( i.e AF31 is cs3 ). It's also kinda of redundant in the policy-map to set dscp ef when the class is already expect to match it to begin with.
The rest of the mls qos setting sets a priority queue-out and adjust the bandwidth per the srr lines;
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
We can validate the queues output by execution of the following show cmd;
show mls qos int fas 0/4 queueing
FastEthernet0/4
Egress Priority Queue : enabled
Shaped queue weights (absolute) : 25 0 0 0
Shared queue weights : 10 10 60 20
The port bandwidth limit : 100 (Operational Bandwidth:100.0)
The port is mapped to qset : 1
So the lines show the queueing status with a priority queued enable, shaped at a hard 25 % of the bandwidth and the shared queues for queue 2-4 are 10/60/20 respectively. So queues #1 value #10 can be ignored since the shaped override it.
Queues #2 #3 #4 can use any unused portion of the other queues if they are not being used and are available.
So that's it for quick 123 on auto-qos on the 2960s. A 3560 and 3750 should be similar since they both use SRR for scheduling queueing operations.
Ken Felix
Freelance Network/Security Engineer
kfelix @ hyperfeed com
VoIP and the voice bearer portion is always set as expedite forward ( AKA EF or decimal value 46 ), in most case it's also associated with CoS value #5. Your cos-2-dscp and dscp-2-qos maps should also reflect this;
cisco 2960:
ccie2960_01>sh mls qos map cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 46 48 56
and
ccie2960_01>sh mls qos map dscp-cos
Dscp-cos map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 01 01
1 : 01 01 01 01 01 01 02 02 02 02
2 : 02 02 02 02 03 03 03 03 03 03
3 : 03 03 04 04 04 04 04 04 04 04
4 : 05 05 05 05 05 05 05 05 06 06
5 : 06 06 06 06 06 06 07 07 07 07
6 : 07 07 07 07
The typical cisco auto-qos does a good job with setting up your mls qos options. You may have to re-view and re-adust them based on the desired QoS goals and classification that you might need in your local LAN.
Typical most congestion are the output of the WAN and trunk-ports. So plan and review you mls qos settings and mainly any drops.
e.g
show mls qos int fas 0/3 statistics | b dropped
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 0 0 0
queue 2: 0 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
To enable auto-qos the commands are simple;
1: what's expected on the port that we are to enable auto-qos on ( phone, etc..)
2: do we want to trust any qos settings layer2 ( cos ) or layer3 (dscp)
3: here's how to set QoS on a layer2 access-port that connected to a phone;
(config-if)#auto qos voip ?
cisco-phone Trust the QoS marking of Cisco IP Phone
cisco-softphone Trust the QoS marking of Cisco IP SoftPhone
trust Trust the DSCP/CoS marking
and
(config-if)#auto qos voip cisco-phone
and the following show cmd provides me with the following output;
sh mls qos int fas 0/4
FastEthernet0/4
Attached policy-map for Ingress: AutoQoS-Police-CiscoPhone
trust state: not trusted
trust mode: trust cos
trust enabled flag: dis
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based
and we will find that the switch now has mls qos enabled globally and the port has some mls qos cfgs
!
interface FastEthernet0/4
switchport access vlan 199
switchport mode access
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone
end
In the above, we are using mls qos and legacy policy-map with the map name AutoQoS-Police-CiscoPhone. Let's look at that service policy map;
show policy-map AutoQoS-Police-CiscoPhone
Policy Map AutoQoS-Police-CiscoPhone
Class AutoQoS-VoIP-RTP-Trust
set dscp ef
police 1000000 8000 exceed-action policed-dscp-transmit
Class
AutoQoS-VoIP-Control-Trust set dscp cs3
police 1000000 8000 exceed-action policed-dscp-transmit
Very simple it's a 2 class map using AutoQoS-VoIP-RTP-Trust and AutoQoS-VoIP-Control-Trust.
These class-maps are defined in the cfg as the following;
class-map match-all AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-all AutoQoS-VoIP-Control-Trust
match ip dscp cs3 af31
!
Notice the match-all and in the control-trust we are matching on AF31 and cs3? ( i.e AF31 is cs3 ). It's also kinda of redundant in the policy-map to set dscp ef when the class is already expect to match it to begin with.
The rest of the mls qos setting sets a priority queue-out and adjust the bandwidth per the srr lines;
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
We can validate the queues output by execution of the following show cmd;
show mls qos int fas 0/4 queueing
FastEthernet0/4
Egress Priority Queue : enabled
Shaped queue weights (absolute) : 25 0 0 0
Shared queue weights : 10 10 60 20
The port bandwidth limit : 100 (Operational Bandwidth:100.0)
The port is mapped to qset : 1
So the lines show the queueing status with a priority queued enable, shaped at a hard 25 % of the bandwidth and the shared queues for queue 2-4 are 10/60/20 respectively. So queues #1 value #10 can be ignored since the shaped override it.
Queues #2 #3 #4 can use any unused portion of the other queues if they are not being used and are available.
So that's it for quick 123 on auto-qos on the 2960s. A 3560 and 3750 should be similar since they both use SRR for scheduling queueing operations.
Ken Felix
Freelance Network/Security Engineer
kfelix @ hyperfeed com
Sunday, January 20, 2013
MPLS/LDP session protection using md5 ( cisco )
-->
This post will speak about LDP session protections. We are
should know by now, that cisco
supports encryption within various
dynamic routing protocols; (RIPv2/OSPF/EIGRP/BGP). But in MPLS and between our LSRs, we can protect the ldp
sessions with a simple md5 password.
Let’s recap our knowledge on LDP
- it uses tcp for the session
- it uses the mcast-all-routers to find our neighbors initially
- builds session between our LSR via the loopback
- we typically use a IGP routing protocol within our LSR space
- cisco supports LDP or TDP within a SP arena
- it uses keepalives to determine when a neighbor is no longer reachable
- the LDP uses port 646/tcp
Okay so let’s see the layout and cfg;
R1:
We 1st define a loopback and enable ldp on the
interfaces that needs to participate in MPLS label swapping
!
interface Loopback0
ip address
1.0.0.1 255.255.255.255
!
!
interface FastEthernet0/0
ip address
10.10.10.1 255.255.255.0
duplex auto
speed auto
mpls label
protocol ldp
mpls ip
Next we enable our favorite IGP, I’m using OSPF in this
example, but it could have been EIGRP
r1.mpls#sh run | sec router ospf
router ospf 1
router-id
1.0.0.1
log-adjacency-changes
network 0.0.0.0
255.255.255.255 area 0
r2:
This router is configure in the same method;
!
interface FastEthernet0/0
ip address
10.10.10.2 255.255.255.0
duplex auto
speed auto
mpls label
protocol ldp
mpls ip
!
interface Loopback0
description
mpls ospf r2 in my virtualize MPLS cloud
ip address
1.0.0.2 255.255.255.255
!
router ospf 1
log-adjacency-changes
network 0.0.0.0
255.255.255.255 area 0
Now let’s configured the password for the session. Remember
the sessions originate and terminates on
the loopbacks. So these will be you neighbors.
R1:
mpls ldp neighbor 1.0.0.2 password cisco1
R2:
mpls ldp neighbor 1.0.0.1 password cisco1
Okay so let’s see how it works;
r1.mpls#show mpls ldp discovery det
Local LDP
Identifier:
1.0.0.1:0
Discovery Sources:
Interfaces:
FastEthernet0/0
(ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms;
Transport IP addr: 1.0.0.1
LDP Id: 1.0.0.2:0
Src IP addr:
10.10.10.2; Transport IP addr: 1.0.0.2
Hold time: 15
sec; Proposed local/peer: 15/15 sec
Reachable via
1.0.0.2/32
Targeted Hellos:
1.0.0.1
-> 1.0.0.2 (ldp): active/passive, xmit/recv
Hello interval: 10000 ms;
Transport IP addr: 1.0.0.1
LDP Id: 1.0.0.2:0
Src IP addr:
1.0.0.2; Transport IP addr: 1.0.0.2
Hold time: 90
sec; Proposed local/peer: 90/90 sec
Reachable via
1.0.0.2/32
r1.mpls#sh tcp br
TCB Local Address
Foreign Address
(state)
650780AC
1.0.0.1.646
1.0.0.2.38458 ESTAB
r1.mpls#
r1.mpls#show mpls interfaces fas 0/0 det
Interface FastEthernet0/0:
IP
labeling enabled (ldp):
Interface config
LSP
Tunnel labeling not enabled
BGP
tagging not enabled
Tagging
operational
Fast
Switching Vectors:
IP to MPLS Fast Switching Vector
MPLS Turbo Vector
MTU
= 1500
If one side is
enable with the wrong or no md5 password, we will se the following ;
*Mar 1
00:11:16.823: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(19067)
*Mar 1
00:11:20.295: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
*Mar 1
00:11:22.287: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
*Mar 1
00:11:22.299: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
*Mar 1
00:11:26.287: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
*Mar 1
00:11:26.299: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
*Mar 1
00:11:34.291: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
*Mar 1
00:11:34.299: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(646) to 1.0.0.2(17163)
Once the md5 password is enable and matched, we should see
the ldp neighbor UP status.
*Mar 1
00:11:45.595: %LDP-5-NBRCHG: LDP Neighbor 1.0.0.1:0 (1) is UP
Okay so what should we have gathered;
- LDP sessions helps to protect our core from un-authorized LDP peers
- it uses a simple md5 passsword
- no keychains
- no means to expire and roll-over new md5 password without taking a hit or lost of ldp neighborship with basic ISR routers ( btw the Nexus supports lossless ldp and uses keychains )
Ken Felix
Freelance Network & Security Engineer
kfelix at
hyperfeed . com
Saturday, January 19, 2013
A PPPoE and RIPv2 problem
I'm going over various aspects of my 1st CCIE lab and one area that's part of the blue-print deals with PPPoE. In this posting I'm showing you a problem that I discovered while building out my lab. I'm confused over it , beacuse I can't figure it out and with fixing the issues.
1st here's my layout done in GNS3 with 2x3700s
We have R1 and R2
R1 = PPPoE server
R2= PPPoE client
R1 cfg
Building configuration...
Current configuration : 1130 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname r1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username ken password 0 ccie
!
!
!
!
bba-group pppoe global
virtual-template 1
!
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
!
interface Loopback18
ip address 10.18.0.1 255.255.255.0
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
duplex auto
speed auto
pppoe enable group global
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback0
ip rip send version 2
ip rip receive version 2
peer default ip address pool pppoe1
ppp authentication pap chap
!
router rip
version 2
network 10.0.0.0
no auto-summary
!
ip local pool pppoe1 10.10.10.10 10.10.10.20
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
!
control-plane
!
R2 config
Current configuration : 1144 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname r2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username r1 password 0 r1cisco
!
!
!
!
!
interface Loopback17
ip address 10.17.0.1 255.255.255.0
!
interface FastEthernet0/0
no ip address
ip tcp adjust-mss 1452
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Dialer1
ip address negotiated
ip rip send version 2
ip rip receive version 2
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap chap callin
ppp chap hostname ken
ppp chap password 0 ccie
ppp pap sent-username ken password 0 ccie
!
router rip
version 2
network 10.0.0.0
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer1
!
!
ip http server
no ip http secure-server
!
!
!
control-plane
!
!
!
!
mgcp behavior g729-variants static-pt
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end
Okay here's the problem, R1 is sending via RIPv2 to R2 and the likewise for R2 to R1, but rip announcements are not showing up in r2 table
debug rip events shows the following;
r1
*Mar 1 00:44:49.391: RIP: sending v2 update to 224.0.0.9 via Loopback18 (10.18.0.1)
*Mar 1 00:44:49.391: RIP: Update contains 3 routes
*Mar 1 00:44:49.391: RIP: Update queued
*Mar 1 00:44:49.391: RIP: Update sent via Loopback18
*Mar 1 00:44:49.391: RIP: ignored v2 packet from 10.18.0.1 (sourced from one of our addresses)
*Mar 1 00:44:52.379: RIP: sending v2 update to 224.0.0.9 via Loopback0 (10.10.10.1)
*Mar 1 00:44:52.379: RIP: Update contains 3 routes
*Mar 1 00:44:52.379: RIP: Update queued
*Mar 1 00:44:52.379: RIP: Update sent via Loopback0
*Mar 1 00:44:52.379: RIP: ignored v2 packet from 10.10.10.1 (sourced from one of our addresses)
*Mar 1 00:44:58.715: RIP: received v2 update from 10.10.10.11 on Virtual-Access1.1
*Mar 1 00:44:58.715: RIP: Update contains 1 routes
*Mar 1 00:45:02.203: RIP: sending v2 update to 224.0.0.9 via Virtual-Access1.1 (10.10.10.1)
*Mar 1 00:45:02.203: RIP: Update contains 2 routes
*Mar 1 00:45:02.203: RIP: Update queued
*Mar 1 00:45:02.203: RIP: Update sent via Virtual-Access1.1
*Mar 1 00:45:15.059: RIP: sending v2 update to 224.0.0.9 via Loopback18 (10.18.0.1)
*Mar 1 00:45:15.059: RIP: Update contains 3 routes
*Mar 1 00:45:15.059: RIP: Update queued
*Mar 1 00:45:15.059: RIP: Update sent via Loopback18
*Mar 1 00:45:15.059: RIP: ignored v2 packet from 10.18.0.1 (sourced from one of our addresses)
*Mar 1 00:45:18.767: RIP: sending v2 update to 224.0.0.9 via Loopback0 (10.10.10.1)
*Mar 1 00:45:18.767: RIP: Update contains 3 routes
*Mar 1 00:45:18.767: RIP: Update queued
*Mar 1 00:45:18.767: RIP: Update sent via Loopback0
*Mar 1 00:45:18.767: RIP: ignored v2 packet from 10.10.10.1 (sourced from one of our addresses)
*Mar 1 00:45:27.851: RIP: received v2 update from 10.10.10.11 on Virtual-Access1.1
*Mar 1 00:45:27.851: RIP: Update contains 1 routes
*Mar 1 00:45:28.279: RIP: sending v2 update to 224.0.0.9 via Virtual-Access1.1 (10.10.10.1)
*Mar 1 00:45:28.279: RIP: Update contains 2 routes
*Mar 1 00:45:28.279: RIP: Update queued
*Mar 1 00:45:28.279: RIP: Update sent via Virtual-Access1.1
*Mar 1 00:45:44.667: RIP: sending v2 update to 224.0.0.9 via Loopback18 (10.18.0.1)
*Mar 1 00:45:44.667: RIP: Update contains 3 routes
*Mar 1 00:45:44.667: RIP: Update queued
*Mar 1 00:45:44.667: RIP: Update sent via Loopback18
*Mar 1 00:45:44.667: RIP: ignored v2 packet from 10.18.0.1 (sourced from one of our addresses)
*Mar 1 00:45:45.591: RIP: sending v2 update to 224.0.0.9 via Loopback0 (10.10.10.1)
*Mar 1 00:45:45.591: RIP: Update contains 3 routes
*Mar 1 00:45:45.591: RIP: Update queued
*Mar 1 00:45:45.591: RIP: Update sent via Loopback0
*Mar 1 00:45:45.591: RIP: ignored v2 packet from 10.10.10.1 (sourced from one of our addresses)
*Mar 1 00:45:54.251: RIP: sending v2 update to 224.0.0.9 via Virtual-Access1.1 (10.10.10.1)
*Mar 1 00:45:54.251: RIP: Update contains 2 routes
*Mar 1 00:45:54.251: RIP: Update queued
*Mar 1 00:45:54.251: RIP: Update sent via Virtual-Access1.1
r2 debug
r2#
*Mar 1 00:43:08.707: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:43:08.707: RIP: Update contains 2 routes
*Mar 1 00:43:08.707: RIP: Update queued
*Mar 1 00:43:08.707: RIP: Update sent via Loopback17
*Mar 1 00:43:08.707: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:43:09.971: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:43:09.971: RIP: Update contains 1 routes
*Mar 1 00:43:09.971: RIP: Update queued
*Mar 1 00:43:09.971: RIP: Update sent via Dialer1
*Mar 1 00:43:11.915: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:43:34.379: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:43:34.379: RIP: Update contains 2 routes
*Mar 1 00:43:34.379: RIP: Update queued
*Mar 1 00:43:34.379: RIP: Update sent via Loopback17
*Mar 1 00:43:34.379: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:43:36.975: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:43:36.975: RIP: Update contains 1 routes
*Mar 1 00:43:36.975: RIP: Update queued
*Mar 1 00:43:36.975: RIP: Update sent via Dialer1
*Mar 1 00:43:40.831: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:44:02.347: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:44:02.347: RIP: Update contains 2 routes
*Mar 1 00:44:02.347: RIP: Update queued
*Mar 1 00:44:02.347: RIP: Update sent via Loopback17
*Mar 1 00:44:02.347: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:44:03.599: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:44:03.599: RIP: Update contains 1 routes
*Mar 1 00:44:03.599: RIP: Update queued
*Mar 1 00:44:03.599: RIP: Update sent via Dialer1
*Mar 1 00:44:08.979: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:44:28.615: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:44:28.615: RIP: Update contains 2 routes
*Mar 1 00:44:28.615: RIP: Update queued
*Mar 1 00:44:28.615: RIP: Update sent via Loopback17
*Mar 1 00:44:28.615: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:44:31.763: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:44:31.763: RIP: Update contains 1 routes
*Mar 1 00:44:31.763: RIP: Update queued
*Mar 1 00:44:31.767: RIP: Update sent via Dialer1
*Mar 1 00:44:35.435: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:44:58.047: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:44:58.047: RIP: Update contains 2 routes
*Mar 1 00:44:58.047: RIP: Update queued
*Mar 1 00:44:58.047: RIP: Update sent via Loopback17
*Mar 1 00:44:58.047: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:44:58.735: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:44:58.735: RIP: Update contains 1 routes
*Mar 1 00:44:58.735: RIP: Update queued
*Mar 1 00:44:58.735: RIP: Update sent via Dialer1
*Mar 1 00:45:02.227: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:45:25.555: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:45:25.555: RIP: Update contains 2 routes
*Mar 1 00:45:25.555: RIP: Update queued
*Mar 1 00:45:25.555: RIP: Update sent via Loopback17
*Mar 1 00:45:25.555: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:45:27.867: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:45:27.867: RIP: Update contains 1 routes
*Mar 1 00:45:27.867: RIP: Update queued
*Mar 1 00:45:27.867: RIP: Update sent via Dialer1
*Mar 1 00:45:28.303: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:45:52.999: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:45:52.999: RIP: Update contains 2 routes
*Mar 1 00:45:52.999: RIP: Update queued
*Mar 1 00:45:52.999: RIP: Update sent via Loopback17
*Mar 1 00:45:52.999: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:45:54.271: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:45:56.947: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:45:56.947: RIP: Update contains 1 routes
*Mar 1 00:45:56.947: RIP: Update queued
*Mar 1 00:45:56.947: RIP: Update sent via Dialer1
*Mar 1 00:46:20.507: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:46:20.507: RIP: Update contains 2 routes
*Mar 1 00:46:20.507: RIP: Update queued
*Mar 1 00:46:20.507: RIP: Update sent via Loopback17
Route tables;
1st R2s;
r2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
20.0.0.0/32 is subnetted, 1 subnets
C 20.0.0.1 is directly connected, Dialer1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.10/32 is directly connected, Dialer1
C 10.17.0.0/24 is directly connected, Loopback17
S* 0.0.0.0/0 is directly connected, Dialer1
r2#
Now r1
r1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.10.11/32 is directly connected, Virtual-Access1.1
C 10.10.10.1/32 is directly connected, Loopback0
C 10.18.0.0/24 is directly connected, Loopback18
R 10.17.0.0/24 [120/1] via 10.10.10.11, 00:00:18, Virtual-Access1.1
Okay and finally show ip protocols;
r1;
r1#show ip proto
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Virtual-Access1.1 2 2
Virtual-Template1 2 2
Loopback0 2 2
Loopback18 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.10.10.10 120 00:00:16
Distance: (default is 120)
and r2;
r2#show ip proto
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 21 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Dialer1 2 2
Loopback17 1 1 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
I have no immediate fix NOW, but I will follow-up later unless some other finds out the issues and reply to my blog.
Ken Felix
Freelance Network & Security Specialist
kfelix at hyperfeed dot c-o-m
1st here's my layout done in GNS3 with 2x3700s
R1 = PPPoE server
R2= PPPoE client
R1 cfg
Building configuration...
Current configuration : 1130 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname r1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username ken password 0 ccie
!
!
!
!
bba-group pppoe global
virtual-template 1
!
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
!
interface Loopback18
ip address 10.18.0.1 255.255.255.0
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
duplex auto
speed auto
pppoe enable group global
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback0
ip rip send version 2
ip rip receive version 2
peer default ip address pool pppoe1
ppp authentication pap chap
!
router rip
version 2
network 10.0.0.0
no auto-summary
!
ip local pool pppoe1 10.10.10.10 10.10.10.20
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
!
control-plane
!
R2 config
Current configuration : 1144 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname r2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username r1 password 0 r1cisco
!
!
!
!
!
interface Loopback17
ip address 10.17.0.1 255.255.255.0
!
interface FastEthernet0/0
no ip address
ip tcp adjust-mss 1452
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Dialer1
ip address negotiated
ip rip send version 2
ip rip receive version 2
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap chap callin
ppp chap hostname ken
ppp chap password 0 ccie
ppp pap sent-username ken password 0 ccie
!
router rip
version 2
network 10.0.0.0
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer1
!
!
ip http server
no ip http secure-server
!
!
!
control-plane
!
!
!
!
mgcp behavior g729-variants static-pt
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end
Okay here's the problem, R1 is sending via RIPv2 to R2 and the likewise for R2 to R1, but rip announcements are not showing up in r2 table
debug rip events shows the following;
r1
*Mar 1 00:44:49.391: RIP: sending v2 update to 224.0.0.9 via Loopback18 (10.18.0.1)
*Mar 1 00:44:49.391: RIP: Update contains 3 routes
*Mar 1 00:44:49.391: RIP: Update queued
*Mar 1 00:44:49.391: RIP: Update sent via Loopback18
*Mar 1 00:44:49.391: RIP: ignored v2 packet from 10.18.0.1 (sourced from one of our addresses)
*Mar 1 00:44:52.379: RIP: sending v2 update to 224.0.0.9 via Loopback0 (10.10.10.1)
*Mar 1 00:44:52.379: RIP: Update contains 3 routes
*Mar 1 00:44:52.379: RIP: Update queued
*Mar 1 00:44:52.379: RIP: Update sent via Loopback0
*Mar 1 00:44:52.379: RIP: ignored v2 packet from 10.10.10.1 (sourced from one of our addresses)
*Mar 1 00:44:58.715: RIP: received v2 update from 10.10.10.11 on Virtual-Access1.1
*Mar 1 00:44:58.715: RIP: Update contains 1 routes
*Mar 1 00:45:02.203: RIP: sending v2 update to 224.0.0.9 via Virtual-Access1.1 (10.10.10.1)
*Mar 1 00:45:02.203: RIP: Update contains 2 routes
*Mar 1 00:45:02.203: RIP: Update queued
*Mar 1 00:45:02.203: RIP: Update sent via Virtual-Access1.1
*Mar 1 00:45:15.059: RIP: sending v2 update to 224.0.0.9 via Loopback18 (10.18.0.1)
*Mar 1 00:45:15.059: RIP: Update contains 3 routes
*Mar 1 00:45:15.059: RIP: Update queued
*Mar 1 00:45:15.059: RIP: Update sent via Loopback18
*Mar 1 00:45:15.059: RIP: ignored v2 packet from 10.18.0.1 (sourced from one of our addresses)
*Mar 1 00:45:18.767: RIP: sending v2 update to 224.0.0.9 via Loopback0 (10.10.10.1)
*Mar 1 00:45:18.767: RIP: Update contains 3 routes
*Mar 1 00:45:18.767: RIP: Update queued
*Mar 1 00:45:18.767: RIP: Update sent via Loopback0
*Mar 1 00:45:18.767: RIP: ignored v2 packet from 10.10.10.1 (sourced from one of our addresses)
*Mar 1 00:45:27.851: RIP: received v2 update from 10.10.10.11 on Virtual-Access1.1
*Mar 1 00:45:27.851: RIP: Update contains 1 routes
*Mar 1 00:45:28.279: RIP: sending v2 update to 224.0.0.9 via Virtual-Access1.1 (10.10.10.1)
*Mar 1 00:45:28.279: RIP: Update contains 2 routes
*Mar 1 00:45:28.279: RIP: Update queued
*Mar 1 00:45:28.279: RIP: Update sent via Virtual-Access1.1
*Mar 1 00:45:44.667: RIP: sending v2 update to 224.0.0.9 via Loopback18 (10.18.0.1)
*Mar 1 00:45:44.667: RIP: Update contains 3 routes
*Mar 1 00:45:44.667: RIP: Update queued
*Mar 1 00:45:44.667: RIP: Update sent via Loopback18
*Mar 1 00:45:44.667: RIP: ignored v2 packet from 10.18.0.1 (sourced from one of our addresses)
*Mar 1 00:45:45.591: RIP: sending v2 update to 224.0.0.9 via Loopback0 (10.10.10.1)
*Mar 1 00:45:45.591: RIP: Update contains 3 routes
*Mar 1 00:45:45.591: RIP: Update queued
*Mar 1 00:45:45.591: RIP: Update sent via Loopback0
*Mar 1 00:45:45.591: RIP: ignored v2 packet from 10.10.10.1 (sourced from one of our addresses)
*Mar 1 00:45:54.251: RIP: sending v2 update to 224.0.0.9 via Virtual-Access1.1 (10.10.10.1)
*Mar 1 00:45:54.251: RIP: Update contains 2 routes
*Mar 1 00:45:54.251: RIP: Update queued
*Mar 1 00:45:54.251: RIP: Update sent via Virtual-Access1.1
r2 debug
r2#
*Mar 1 00:43:08.707: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:43:08.707: RIP: Update contains 2 routes
*Mar 1 00:43:08.707: RIP: Update queued
*Mar 1 00:43:08.707: RIP: Update sent via Loopback17
*Mar 1 00:43:08.707: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:43:09.971: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:43:09.971: RIP: Update contains 1 routes
*Mar 1 00:43:09.971: RIP: Update queued
*Mar 1 00:43:09.971: RIP: Update sent via Dialer1
*Mar 1 00:43:11.915: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:43:34.379: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:43:34.379: RIP: Update contains 2 routes
*Mar 1 00:43:34.379: RIP: Update queued
*Mar 1 00:43:34.379: RIP: Update sent via Loopback17
*Mar 1 00:43:34.379: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:43:36.975: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:43:36.975: RIP: Update contains 1 routes
*Mar 1 00:43:36.975: RIP: Update queued
*Mar 1 00:43:36.975: RIP: Update sent via Dialer1
*Mar 1 00:43:40.831: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:44:02.347: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:44:02.347: RIP: Update contains 2 routes
*Mar 1 00:44:02.347: RIP: Update queued
*Mar 1 00:44:02.347: RIP: Update sent via Loopback17
*Mar 1 00:44:02.347: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:44:03.599: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:44:03.599: RIP: Update contains 1 routes
*Mar 1 00:44:03.599: RIP: Update queued
*Mar 1 00:44:03.599: RIP: Update sent via Dialer1
*Mar 1 00:44:08.979: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:44:28.615: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:44:28.615: RIP: Update contains 2 routes
*Mar 1 00:44:28.615: RIP: Update queued
*Mar 1 00:44:28.615: RIP: Update sent via Loopback17
*Mar 1 00:44:28.615: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:44:31.763: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:44:31.763: RIP: Update contains 1 routes
*Mar 1 00:44:31.763: RIP: Update queued
*Mar 1 00:44:31.767: RIP: Update sent via Dialer1
*Mar 1 00:44:35.435: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:44:58.047: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:44:58.047: RIP: Update contains 2 routes
*Mar 1 00:44:58.047: RIP: Update queued
*Mar 1 00:44:58.047: RIP: Update sent via Loopback17
*Mar 1 00:44:58.047: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:44:58.735: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:44:58.735: RIP: Update contains 1 routes
*Mar 1 00:44:58.735: RIP: Update queued
*Mar 1 00:44:58.735: RIP: Update sent via Dialer1
*Mar 1 00:45:02.227: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:45:25.555: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:45:25.555: RIP: Update contains 2 routes
*Mar 1 00:45:25.555: RIP: Update queued
*Mar 1 00:45:25.555: RIP: Update sent via Loopback17
*Mar 1 00:45:25.555: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:45:27.867: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:45:27.867: RIP: Update contains 1 routes
*Mar 1 00:45:27.867: RIP: Update queued
*Mar 1 00:45:27.867: RIP: Update sent via Dialer1
*Mar 1 00:45:28.303: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:45:52.999: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:45:52.999: RIP: Update contains 2 routes
*Mar 1 00:45:52.999: RIP: Update queued
*Mar 1 00:45:52.999: RIP: Update sent via Loopback17
*Mar 1 00:45:52.999: RIP: ignored v2 packet from 10.17.0.1 (sourced from one of our addresses)
*Mar 1 00:45:54.271: RIP: ignored v2 update from bad source 10.10.10.1 on Dialer1
*Mar 1 00:45:56.947: RIP: sending v2 update to 224.0.0.9 via Dialer1 (10.10.10.11)
*Mar 1 00:45:56.947: RIP: Update contains 1 routes
*Mar 1 00:45:56.947: RIP: Update queued
*Mar 1 00:45:56.947: RIP: Update sent via Dialer1
*Mar 1 00:46:20.507: RIP: sending v2 update to 224.0.0.9 via Loopback17 (10.17.0.1)
*Mar 1 00:46:20.507: RIP: Update contains 2 routes
*Mar 1 00:46:20.507: RIP: Update queued
*Mar 1 00:46:20.507: RIP: Update sent via Loopback17
Route tables;
1st R2s;
r2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
20.0.0.0/32 is subnetted, 1 subnets
C 20.0.0.1 is directly connected, Dialer1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.10.10/32 is directly connected, Dialer1
C 10.17.0.0/24 is directly connected, Loopback17
S* 0.0.0.0/0 is directly connected, Dialer1
r2#
Now r1
r1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.10.11/32 is directly connected, Virtual-Access1.1
C 10.10.10.1/32 is directly connected, Loopback0
C 10.18.0.0/24 is directly connected, Loopback18
R 10.17.0.0/24 [120/1] via 10.10.10.11, 00:00:18, Virtual-Access1.1
Okay and finally show ip protocols;
r1;
r1#show ip proto
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Virtual-Access1.1 2 2
Virtual-Template1 2 2
Loopback0 2 2
Loopback18 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.10.10.10 120 00:00:16
Distance: (default is 120)
and r2;
r2#show ip proto
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 21 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Dialer1 2 2
Loopback17 1 1 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
I have no immediate fix NOW, but I will follow-up later unless some other finds out the issues and reply to my blog.
Ken Felix
Freelance Network & Security Specialist
kfelix at hyperfeed dot c-o-m
Friday, January 18, 2013
Cerrtifications my thoughts on the matter
The IT community has been hot with the need for certifications.
This is great ideal, but I would like to speak my mind on the whole certifications strategy, and how it plays with jobs and candidates selections.
1st off, I've been active within the IT certifications field, going back at least 12+ years. My 1st certification under takings, was that of a Sun Solaris Administration (1998 ) and Cisco Networking CCNP ( 1999 )
But certifications is not the final win-win defacto selector. We all should look at the continual expanding of our knowledge, skills, and formal education. Certifications within a specialize sector is great for the following reasons;
* it shows possible recruiters your level of IT knowledge
* it gives an ideal of your advancements
* shows recognition of your achievements
Ideally a recruiter and/or potential employer , would use the information within the resume, and any formal education and certifications to help determine if this candidate is suited for the role. The face-2-face interview, just completes & finalize the deal.
Basically over the last decade or so, I've been noticing that candidates are showing up with certifications and having zero knowledge, or any hands-on in that sector of specializations. This hurts the IT communitiy (IMHO ), since we now have recruiters only focusing on candidates with "certs", but not of the critical essentials ; practical experiences, hands-on demonstration, or practical knowledge. A lot of these recruiter will pass up the more suited candidate that has experience, if they see no certifications listed on his/her resume. Now we flood the market with the certs only guys/gals and the best candidate is shown the door.
I myself could careless if a person had CCNA/CCNP for example, and studies their rear-end off, but I rather prefer a individual that could demonstrated or show past experience within that area of specializations.
The proper format for any potential employers, is to look for candidates with both cert/education and experience, & the certifications should just enhance or back the recruiter candidate as a possible selectee.
The main advantage that a certs should have is to ; "increase yours chance of being notice by a hiring manager or recruitment firm", but in reality you have candidates with no knowledge or practical skills in that area of their certifications. These candidates are typically from the same crowd that buys a book or two, study and brute-force the exam(s), use a fast-train, or have an Associate or Bachelor degree in IT, but they couldn't explain "how something as simple as ARP or DNS & how it works".
In one case, I ran across a individual that was a microsoft certified engineer, and he had never installed Microsoft OS on a box :(
So keep that in mind when your obtaining a certification, and for anybody interviewing a candidate and bypassing those without certifications in their title or resumes.
I myself like to look at experience 1st. Persons that has a practical knowledge, hands-on, and past working experiences that can be validate, .........are easy selected over individuals with just a cert or formal education imho.
Now here comes the chicken-and-egg issue; "How do we get person with experience , if we ignore those with no certs?"
What I mean by this; " at one of my places of past employment, we picked up a person with a basic CCNA, 1 year of work internship experience, just to get the individual in the door & for him to gain experience". I called it a gut feeling or investing into that person.
So stay focus, get some training, get certifications, stay in touch with new technologies, but never over look experience against certifications.
Ken Felix
Freelance Security & Network Engineer
kfelix at hyperfeed d-o-t com
This is great ideal, but I would like to speak my mind on the whole certifications strategy, and how it plays with jobs and candidates selections.
1st off, I've been active within the IT certifications field, going back at least 12+ years. My 1st certification under takings, was that of a Sun Solaris Administration (1998 ) and Cisco Networking CCNP ( 1999 )
But certifications is not the final win-win defacto selector. We all should look at the continual expanding of our knowledge, skills, and formal education. Certifications within a specialize sector is great for the following reasons;
* it shows possible recruiters your level of IT knowledge
* it gives an ideal of your advancements
* shows recognition of your achievements
Ideally a recruiter and/or potential employer , would use the information within the resume, and any formal education and certifications to help determine if this candidate is suited for the role. The face-2-face interview, just completes & finalize the deal.
Basically over the last decade or so, I've been noticing that candidates are showing up with certifications and having zero knowledge, or any hands-on in that sector of specializations. This hurts the IT communitiy (IMHO ), since we now have recruiters only focusing on candidates with "certs", but not of the critical essentials ; practical experiences, hands-on demonstration, or practical knowledge. A lot of these recruiter will pass up the more suited candidate that has experience, if they see no certifications listed on his/her resume. Now we flood the market with the certs only guys/gals and the best candidate is shown the door.
I myself could careless if a person had CCNA/CCNP for example, and studies their rear-end off, but I rather prefer a individual that could demonstrated or show past experience within that area of specializations.
The proper format for any potential employers, is to look for candidates with both cert/education and experience, & the certifications should just enhance or back the recruiter candidate as a possible selectee.
The main advantage that a certs should have is to ; "increase yours chance of being notice by a hiring manager or recruitment firm", but in reality you have candidates with no knowledge or practical skills in that area of their certifications. These candidates are typically from the same crowd that buys a book or two, study and brute-force the exam(s), use a fast-train, or have an Associate or Bachelor degree in IT, but they couldn't explain "how something as simple as ARP or DNS & how it works".
In one case, I ran across a individual that was a microsoft certified engineer, and he had never installed Microsoft OS on a box :(
So keep that in mind when your obtaining a certification, and for anybody interviewing a candidate and bypassing those without certifications in their title or resumes.
I myself like to look at experience 1st. Persons that has a practical knowledge, hands-on, and past working experiences that can be validate, .........are easy selected over individuals with just a cert or formal education imho.
Now here comes the chicken-and-egg issue; "How do we get person with experience , if we ignore those with no certs?"
What I mean by this; " at one of my places of past employment, we picked up a person with a basic CCNA, 1 year of work internship experience, just to get the individual in the door & for him to gain experience". I called it a gut feeling or investing into that person.
So stay focus, get some training, get certifications, stay in touch with new technologies, but never over look experience against certifications.
Ken Felix
Freelance Security & Network Engineer
kfelix at hyperfeed d-o-t com
Using Cisco DHCP snooping and binding features
DHCP snooping is a very common enterprise security feature. Let me explain the benefits;
The movers unpacked her items ,and decided to help out even farther, by plugging things up for the exec. In one box, she had one of these;
Okay I know everybody has seem a linksys or similar soho wireless device, right ?
About 99% of the rogue dhcp-servers are something like the above, & mistakenly installed into a network by an unknowing staff or end-user.
Will this device was configured with a typical 192.168.1.0/24 address mask , and was setup as a dhcp-server. It was mistakenly connected to the corporate wide network. In doing so; "it become the dhcp-server for the internal LAN, & causing all sorts of havoc, until the device was located and removed"
Depending on the client machine and how fast the dhcp-server responds, you might get the real corp-dhcp-servers, or you might received the rogue-dhcp-server offer from a linksys. Since the internal lan was not configured to use the 192.168.1.0/24 address space, clients who received a lease within that dhcp-scope where blackholed or deny of services, due to the lack of an valid routeable address.
So cisco starting many years ago, realize that we need to protect the LAN from it's self and it's users. Since rogue dhcp servers was popping up more and more, the dhcp snooping feature soon became the standard protection within the enterprise arena for DHCP-servers outages.
For cisco it's an straight forward configuration.
1st we must identify our trusted ports that contains our DHCP-server(s). Yes you establish trusted ports for these servers, because by default ; all ports are untrusted when you enable dhcp-snooping.
here's my trusted port ( gi 0/2 )
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/2 yes yes unlimited
Custom circuit-ids:
!
interface GigabitEthernet0/2
ip dhcp snooping trust
end
Next we enable dhcp snooping globally, and also specify the vlan(s) that will be enabled for dhcp-snooping;
config t
ip dhcp snooping vlan 1
ip dhcp snooping
no ip dhcp snooping information option
I also disable the information-option feature, since we don't need this in this case and nor does this dhcp-server support that feature
Next, we configured dhcp rate-limits ( otional) . Cisco recommends no more than 100pps for a regular access switchport, and trunks that carries multiple vlans, needs a much higher rate set.
config t
int range gi 0/3-48
description "my local lan access ports for desktops"
ip dhcp snooping limit rate 100
I'm going to use dhcp-binding and with an off switch hosted file on a tftp-server. Ideally we would want to used something more secured like scp, but tftp-server was my easiest solution to deploy.
ip dhcp snooping database tftp://172.16.1.3/file
ip dhcp snooping database write-delay 20
I 've also configured a write-delay value, which is useful in heavy dhcp environments that has a host of hosts using dhcp.
Now let's see what happens;
A client make a request, if the port is untrusted the information is looked at and logged to our dhcp snooping binding file. If a port is enabled as a untrusted port and the dhcp message was that of a server, it would be dropped, hence protecting the network from unrecognized dhcp-servers.
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/3 no no 100
Custom circuit-ids:
Any ports that exceed the rate-limit , would also have it's messages dropped. It would go into an err-disable state.
The following show cmds helps provide information on the dhcp-stats and other useful information;
show ip dhcp snoop statistics
show ip dhcp snoop statistics
Packets Forwarded = 78
Packets Dropped = 0
Packets Dropped From untrusted ports = 0
custA#
show ip dhcp snoop binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
AA:AA:AA:BB:BB:CC 172.16.1.6 84531 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:FF:FF 172.16.1.11 84935 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:FF 172.16.1.8 84717 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:BB 172.16.1.5 84408 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:CC:DD 172.16.1.9 84778 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:EE 172.16.1.7 84622 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:CC:FF 172.16.1.10 84873 dhcp-snooping 1 GigabitEthernet0/4
00:0C:29:52:0F:4F 172.16.1.4 84697 dhcp-snooping 1 GigabitEthernet0/3
Total number of bindings: 8
show ip dhcp snoop database
Agent URL : tftp://172.16.1.3/file
Write delay Timer : 20 seconds
Abort Timer : 300 seconds
Agent Running : No
Delay Timer Expiry : Not Running
Abort Timer Expiry : Not Running
Last Succeded Time : 02:02:25 UTC Sat Jan 19 2013
Last Failed Time : 01:55:05 UTC Sat Jan 19 2013
Last Failed Reason : Expected more data on read.
Total Attempts : 11 Startup Failures : 3
Successful Transfers : 7 Failed Transfers : 4
Successful Reads : 0 Failed Reads : 1
Successful Writes : 7 Failed Writes : 0
Media Failures : 0
A few thing that you must taken into consideration; if you want to deploy dhcp-snooping and using the binding database;
This is due to the dhcp-lease information has time/date values enclosed in the offer. Without a correct clock, the binding details could be exploit and flawed.
so enable some sort of NTP to a clock source;
custA#sh run | i ntp
ntp clock-period 36028843
ntp server 172.16.1.1
And ensure your system-clock is 100% correct;
show clock
02:30:25.459 UTC Sat Jan 18 2013
The binding file at the URL location is basic and simple and holds the entries learned during the dhcp snooping process
e.g
TYPE DHCP-SNOOPING
VERSION 1
BEGIN
172.16.1.6 1 aaaa.aabb.bbcc 50FB4E88 Gi0/4 336c813d
172.16.1.11 1 aaaa.aabb.ffff 50FB501C Gi0/4 b01dbbad
172.16.1.8 1 aaaa.aabb.bbff 50FB4F42 Gi0/4 08a88f63
172.16.1.5 1 aaaa.aabb.bbbb 50FB4E0D Gi0/4 fdc5a686
172.16.1.9 1 aaaa.aabb.ccdd 50FB4F7F Gi0/4 037b959f
172.16.1.7 1 aaaa.aabb.bbee 50FB4EE3 Gi0/4 d93819a7
172.16.1.10 1 aaaa.aabb.ccff 50FB4FDF Gi0/4 d8de358e
172.16.1.4 1 000c.2952.0f4f 50FB4F2E Gi0/3 0d5de493
It reccommended to store this file off the switch and on some sort of external device.
Here's a typical DHCP request or correct term discover from a client;
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Option 119, LDAP, Option 252, Netbios-Name-Server
Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether aa:bb:cc:cc:dd:dd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 12: "C02H61ZJDV7M"
END Option 255, length 0
PAD Option 0, length 0, occurs 12
here's a a typical DHCP offer from a dhcp-server;
172.16.1.1.67 > 172.16.1.13.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x8cf45faa, Flags [none] (0x0000)
Your-IP 172.16.1.13
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name Option 15, length 3: "hackersaregoood.com"
Domain-Name-Server Option 6, length 4: 8.8.8.8
END Option 255, length 0
PAD Option 0, length 0, occurs 9
here's a client acking the request;
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:cc:dd:dd, length 300, xid 0x8cf45faa, secs 1, Flags [none] (0x0000)
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Option 119, LDAP, Option 252, Netbios-Name-Server
Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether aa:bb:cc:cc:dd:dd
Requested-IP Option 50, length 4: 172.16.1.13
Server-ID Option 54, length 4: 172.16.1.1
Hostname Option 12, length 12: "C02H61ZJDV7M"
END Option 255, length 0
PAD Option 0, length 0, occurs 6
here's a the final response message known as the lease or DHCP lease from a dhcp-server;
172.16.1.1.67 > 172.16.1.13.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x8cf45faa, Flags [none] (0x0000)
Your-IP 172.16.1.13
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name Option 15, length 3: "hackersaregoood.com"
Domain-Name-Server Option 6, length 4: 8.8.8.8
END Option 255, length 0
PAD Option 0, length 0, occurs 9
Things to take away from this all;
I hope you found this post helpful. Keep your network healthy ,by filtering and protecting unwanted dhcp messages.
Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com
- protects from rouge servers
- protects from misused clients that floods dhcp-requests
- ensure critical systems are not effected by lack of dhcp-offers
- provides higher availlability% and uptime against DHCP DoS attacks
The movers unpacked her items ,and decided to help out even farther, by plugging things up for the exec. In one box, she had one of these;
Okay I know everybody has seem a linksys or similar soho wireless device, right ?
About 99% of the rogue dhcp-servers are something like the above, & mistakenly installed into a network by an unknowing staff or end-user.
Will this device was configured with a typical 192.168.1.0/24 address mask , and was setup as a dhcp-server. It was mistakenly connected to the corporate wide network. In doing so; "it become the dhcp-server for the internal LAN, & causing all sorts of havoc, until the device was located and removed"
Depending on the client machine and how fast the dhcp-server responds, you might get the real corp-dhcp-servers, or you might received the rogue-dhcp-server offer from a linksys. Since the internal lan was not configured to use the 192.168.1.0/24 address space, clients who received a lease within that dhcp-scope where blackholed or deny of services, due to the lack of an valid routeable address.
So cisco starting many years ago, realize that we need to protect the LAN from it's self and it's users. Since rogue dhcp servers was popping up more and more, the dhcp snooping feature soon became the standard protection within the enterprise arena for DHCP-servers outages.
For cisco it's an straight forward configuration.
1st we must identify our trusted ports that contains our DHCP-server(s). Yes you establish trusted ports for these servers, because by default ; all ports are untrusted when you enable dhcp-snooping.
here's my trusted port ( gi 0/2 )
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/2 yes yes unlimited
Custom circuit-ids:
!
interface GigabitEthernet0/2
ip dhcp snooping trust
end
Next we enable dhcp snooping globally, and also specify the vlan(s) that will be enabled for dhcp-snooping;
config t
ip dhcp snooping vlan 1
ip dhcp snooping
no ip dhcp snooping information option
I also disable the information-option feature, since we don't need this in this case and nor does this dhcp-server support that feature
Next, we configured dhcp rate-limits ( otional) . Cisco recommends no more than 100pps for a regular access switchport, and trunks that carries multiple vlans, needs a much higher rate set.
config t
int range gi 0/3-48
description "my local lan access ports for desktops"
ip dhcp snooping limit rate 100
I'm going to use dhcp-binding and with an off switch hosted file on a tftp-server. Ideally we would want to used something more secured like scp, but tftp-server was my easiest solution to deploy.
ip dhcp snooping database tftp://172.16.1.3/file
ip dhcp snooping database write-delay 20
I 've also configured a write-delay value, which is useful in heavy dhcp environments that has a host of hosts using dhcp.
Now let's see what happens;
A client make a request, if the port is untrusted the information is looked at and logged to our dhcp snooping binding file. If a port is enabled as a untrusted port and the dhcp message was that of a server, it would be dropped, hence protecting the network from unrecognized dhcp-servers.
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/3 no no 100
Custom circuit-ids:
Any ports that exceed the rate-limit , would also have it's messages dropped. It would go into an err-disable state.
The following show cmds helps provide information on the dhcp-stats and other useful information;
show ip dhcp snoop statistics
show ip dhcp snoop statistics
Packets Forwarded = 78
Packets Dropped = 0
Packets Dropped From untrusted ports = 0
custA#
show ip dhcp snoop binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
AA:AA:AA:BB:BB:CC 172.16.1.6 84531 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:FF:FF 172.16.1.11 84935 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:FF 172.16.1.8 84717 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:BB 172.16.1.5 84408 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:CC:DD 172.16.1.9 84778 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:EE 172.16.1.7 84622 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:CC:FF 172.16.1.10 84873 dhcp-snooping 1 GigabitEthernet0/4
00:0C:29:52:0F:4F 172.16.1.4 84697 dhcp-snooping 1 GigabitEthernet0/3
Total number of bindings: 8
show ip dhcp snoop database
Agent URL : tftp://172.16.1.3/file
Write delay Timer : 20 seconds
Abort Timer : 300 seconds
Agent Running : No
Delay Timer Expiry : Not Running
Abort Timer Expiry : Not Running
Last Succeded Time : 02:02:25 UTC Sat Jan 19 2013
Last Failed Time : 01:55:05 UTC Sat Jan 19 2013
Last Failed Reason : Expected more data on read.
Total Attempts : 11 Startup Failures : 3
Successful Transfers : 7 Failed Transfers : 4
Successful Reads : 0 Failed Reads : 1
Successful Writes : 7 Failed Writes : 0
Media Failures : 0
A few thing that you must taken into consideration; if you want to deploy dhcp-snooping and using the binding database;
- cisco requires ntp
- and syncronize clock, with the correct time
This is due to the dhcp-lease information has time/date values enclosed in the offer. Without a correct clock, the binding details could be exploit and flawed.
so enable some sort of NTP to a clock source;
custA#sh run | i ntp
ntp clock-period 36028843
ntp server 172.16.1.1
And ensure your system-clock is 100% correct;
show clock
02:30:25.459 UTC Sat Jan 18 2013
The binding file at the URL location is basic and simple and holds the entries learned during the dhcp snooping process
e.g
TYPE DHCP-SNOOPING
VERSION 1
BEGIN
172.16.1.6 1 aaaa.aabb.bbcc 50FB4E88 Gi0/4 336c813d
172.16.1.11 1 aaaa.aabb.ffff 50FB501C Gi0/4 b01dbbad
172.16.1.8 1 aaaa.aabb.bbff 50FB4F42 Gi0/4 08a88f63
172.16.1.5 1 aaaa.aabb.bbbb 50FB4E0D Gi0/4 fdc5a686
172.16.1.9 1 aaaa.aabb.ccdd 50FB4F7F Gi0/4 037b959f
172.16.1.7 1 aaaa.aabb.bbee 50FB4EE3 Gi0/4 d93819a7
172.16.1.10 1 aaaa.aabb.ccff 50FB4FDF Gi0/4 d8de358e
172.16.1.4 1 000c.2952.0f4f 50FB4F2E Gi0/3 0d5de493
It reccommended to store this file off the switch and on some sort of external device.
Here's a typical DHCP request or correct term discover from a client;
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Option 119, LDAP, Option 252, Netbios-Name-Server
Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether aa:bb:cc:cc:dd:dd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 12: "C02H61ZJDV7M"
END Option 255, length 0
PAD Option 0, length 0, occurs 12
here's a a typical DHCP offer from a dhcp-server;
172.16.1.1.67 > 172.16.1.13.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x8cf45faa, Flags [none] (0x0000)
Your-IP 172.16.1.13
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name Option 15, length 3: "hackersaregoood.com"
Domain-Name-Server Option 6, length 4: 8.8.8.8
END Option 255, length 0
PAD Option 0, length 0, occurs 9
here's a client acking the request;
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:cc:dd:dd, length 300, xid 0x8cf45faa, secs 1, Flags [none] (0x0000)
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Option 119, LDAP, Option 252, Netbios-Name-Server
Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether aa:bb:cc:cc:dd:dd
Requested-IP Option 50, length 4: 172.16.1.13
Server-ID Option 54, length 4: 172.16.1.1
Hostname Option 12, length 12: "C02H61ZJDV7M"
END Option 255, length 0
PAD Option 0, length 0, occurs 6
here's a the final response message known as the lease or DHCP lease from a dhcp-server;
172.16.1.1.67 > 172.16.1.13.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x8cf45faa, Flags [none] (0x0000)
Your-IP 172.16.1.13
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name Option 15, length 3: "hackersaregoood.com"
Domain-Name-Server Option 6, length 4: 8.8.8.8
END Option 255, length 0
PAD Option 0, length 0, occurs 9
Things to take away from this all;
- DHCP snooping is helpfull
- most newer model switches support this feature
- It's support on most L2/L3 switches
- Proctects your network
- Does not protect from hijack ip_address
- Does not protect static assigned hosts
I hope you found this post helpful. Keep your network healthy ,by filtering and protecting unwanted dhcp messages.
Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com
Subscribe to:
Posts (Atom)