Time-Based Redistribution… Ahhh, the horror of it all… ~ CCNP, CCSP and CCIE Security Version 4 Training Institute in India- Delhi

The leading question:

“Is it possible (and if so, how) to redistribute or originate a default route based on time of day?”

The short answer is “Sure, why not?”… But the longer answer has to do with how do we warp the forces of the universe to make that happen???
Well, start with what we know. We know we can do time-ranges in access-lists, right? Can we do them in standard access-lists (what we see used for redistribution all the time)?

Rack1R1(config-if)#exit
Rack1R1(config)#access-list 1 permit 172.16.0.0 0.15.255.255 ?
log  Log matches against this entry
<cr>

Rack1R1(config)#

Nope. There’s a bummer. So we will need to use EXTENDED ACL’s in order to make this work. So now we are reaching the point of “Yes, it can be done, but it will make my head hurt.” as the answer.

First, as a little review, check out a blog we did last year providing some information on that sort of thing in conjunction with a distribute-list in different routing protocols.
http://blog.internetworkexpert.com/2008/01/04/using-extended-access-lists-in-a-distribute-list/

After you’ve had a little time to review that stuff, let’s move on with the testing! I have nabbed my routers in a configured state already. I just recently finished with creating more detailed solutions for Mock Lab 4 (it’s a fun one!), so that’s the topology that I have going right now. Specifics should really matter, I was just hunting for any particular spot of redistribution in order to see what we could accomplish here.
On R3 I happen to have found some redistribution between OSPF and RIP that looks like fun.

R3 Starting:

Rack1R3(config)#do sh run | s router
router ospf 1
log-adjacency-changes
area 0 authentication message-digest
area 123 virtual-link 150.1.1.1 message-digest-key 1 md5 CISCO
redistribute rip metric-type 1 subnets route-map Red-RIP
network 145.1.3.3 0.0.0.0 area 0
network 145.1.13.3 0.0.0.0 area 123
network 145.1.23.3 0.0.0.0 area 123
network 150.1.3.3 0.0.0.0 area 0
router rip
version 2
redistribute ospf 1 metric 7 route-map RIP-R6
passive-interface default
no passive-interface FastEthernet0/0
network 145.1.0.0
distribute-list 11 out FastEthernet0/0
no auto-summary
Rack1R3(config)#

Rack1R3(config)#do sh run | s route-map
redistribute rip metric-type 1 subnets route-map Red-RIP
redistribute ospf 1 metric 7 route-map RIP-R6
route-map RIP-R6 permit 10
match ip address prefix-list R4-R5-Link
set metric 2
route-map RIP-R6 permit 20
set metric 10
route-map Red-RIP deny 10
match ip address prefix-list NAT-Route
route-map Red-RIP permit 20
set metric-type type-1
Rack1R3(config)#

All devices have “debug ip routing” turned on.

Rack1R3(config)#do sh clock
*02:02:28.984 UTC Sun Feb 15 2009
Rack1R3(config)#

No NTP is running, so we can deal with the current clock settings. So let’s look at our route-maps… The one called RIP-R6 is going from OSPF to RIP.

Rack1R3(config)#do sh ip ro os
51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 145.1.23.2, 3w2d, Serial1/3.23
O E1 204.12.1.0/24 [110/865] via 145.1.23.2, 1w6d, Serial1/3.23
[110/865] via 145.1.13.1, 1w6d, Serial1/2.13
145.1.0.0/16 is variably subnetted, 20 subnets, 2 masks
O IA    145.1.17.0/24 [110/782] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.5.0/24 [110/865] via 145.1.23.2, 1w6d, Serial1/3.23
[110/865] via 145.1.13.1, 1w6d, Serial1/2.13
O       145.1.7.0/24 [110/783] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.12.0/24 [110/845] via 145.1.23.2, 3w2d, Serial1/3.23
[110/845] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.48.0/24 [110/847] via 145.1.23.2, 3w2d, Serial1/3.23
[110/847] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.58.0/24 [110/846] via 145.1.23.2, 3w2d, Serial1/3.23
[110/846] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.5/32 [110/867] via 145.1.23.2, 3w2d, Serial1/3.23
[110/867] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.4/32 [110/865] via 145.1.23.2, 3w2d, Serial1/3.23
[110/865] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.0/24 [110/865] via 145.1.23.2, 3w2d, Serial1/3.23
[110/865] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.47.0/24 [110/1782] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.125.5/32 [110/845] via 145.1.23.2, 3w2d, Serial1/3.23
[110/845] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.125.1/32 [110/781] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.125.0/24 [110/867] via 145.1.23.2, 1w6d, Serial1/3.23
[110/867] via 145.1.13.1, 1w6d, Serial1/2.13
O IA    145.1.125.2/32 [110/781] via 145.1.23.2, 3w2d, Serial1/3.23
O IA 192.10.1.0/24 [110/782] via 145.1.23.2, 3w2d, Serial1/3.23
150.1.0.0/16 is variably subnetted, 7 subnets, 3 masks
O       150.1.7.7/32 [110/783] via 145.1.13.1, 3w2d, Serial1/2.13
O       150.1.4.4/32 [110/848] via 145.1.23.2, 3w2d, Serial1/3.23
[110/848] via 145.1.13.1, 3w2d, Serial1/2.13
O       150.1.2.2/32 [110/782] via 145.1.23.2, 3w2d, Serial1/3.23
O       150.1.1.1/32 [110/782] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    150.1.0.0/20 [110/846] via 145.1.23.2, 3w2d, Serial1/3.23
[110/846] via 145.1.13.1, 3w2d, Serial1/2.13
Rack1R3(config)#

We have quite a few OSPF routes, so we can always pick on a few others just to play. But let’s change things around momentarily.

Rack1R3(config)#do sh run | in prefix-list
ip prefix-list NAT-Route seq 5 permit 145.1.133.0/24
ip prefix-list R4-R5-Link seq 5 permit 145.1.45.0/24
match ip address prefix-list R4-R5-Link
match ip address prefix-list NAT-Route
Rack1R3(config)#

Right now, we’re matching a Prefix List… That will need to change. Let’s create a time-range as well.
R3
time-range First12
periodic daily 0:00 to 11:59
exit
access-list 101 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12
route-map RIP-R6 permit 10
no match ip address prefix-list R4-R5-Link
match ip address 101
set metric 2

Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (active) (2 matches)
Rack1R3(config)#

So we’re active now. This is good. We’ll see this route via other paths in this lab, but the metric here is the key. And we’ll notice this change as well. Since we started re-advertising the route:

Rack1R6(config-router)#
*Feb 15 03:17:13.656: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/10] to [120/2]
*Feb 15 03:17:13.656: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Notice the metric change. Now let’s go back to R3 and change the time!

Rack1R3#clock set 15:00:00 feb 15 2009
Rack1R3#
*Feb 15 15:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 02:22:08 UTC Sun Feb 15 2009 to 15:00:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3#

Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (inactive) (2 matches)
Rack1R3(config)#

Notice that now we are inactive on our time. **Time Passes**
Well, 20 minutes later and still no update. Our problem with this is that change IN THE ROUTING TABLE trigger changes to redistribution. We still learn this route via OSPF and therefore nothing has changed. If we were to trigger a change in OSPF that would lead to a status change, we would see the route withdrawn.
How do you trigger a status change? Clear it.

Rack1R3(config)#do clear ip route 145.1.45.0
Rack1R3(config)#
Feb 15 15:12:28.719: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 15:12:28.719: RT: del 145.1.45.0/24 via 145.1.13.1, ospf metric [110/865]
Feb 15 15:12:28.719: RT: delete subnet route to 145.1.45.0/24
Feb 15 15:12:28.719: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: SET_LAST_RDB for 145.1.45.0/24
NEW rdb: via 145.1.13.1

Feb 15 15:12:28.723: RT: add 145.1.45.0/24 via 145.1.13.1, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT:ospf's 145.1.45.0/24 (via 145.1.13.1) metric changed from distance/metric [110/867] to [110/865]
Feb 15 15:12:28.723: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.727: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 15:12:28.727: RT: NET-RED 145.1.45.0/24
Rack1R3(config)#

From R3′s perspective, notice that it comes back just as it was before.

Rack1R6(config-router)#
*Feb 15 03:32:27.576: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/2] to [120/10]
*Feb 15 03:32:27.576: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

On R6 though, it changed because the criteria changed. What if we change the clock and do it again? (By the way, subsequent ‘clear ip route’ commands on R3 make no difference on R6 as long as the time range is still inactive)

Rack1R3(config)#do clock set 3:00:00 feb 15 2009
Rack1R3(config)#
Rack1R3(config)#
Feb 15 03:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 15:14:57 UTC Sun Feb 15 2009 to 03:00:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3(config)#
Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (active) (2 matches)
Rack1R3(config)#

Back to active now. Clearing….

Rack1R6(config-router)#
*Feb 15 03:35:24.672: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/10] to [120/2]
*Feb 15 03:35:24.672: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Back to a metric of 2 on R6. So the redistribution is happening again… So…. Can the router trigger itself? Do we have mechanisms to do so? You betchya! But it’s not perfectly simple! But then again, you would be a CCIE if everything were always simple! Or more importantly, EVERYONE would be a CCIE if it were simple!
We can use EEM (Embedded Event Manager, complicated) or KRON (time scheduler, easier) to trigger things. My vote is kron! In the unix world you’d know this as cron.
R3
kron policy-list ChgRedist
cli clear ip route 145.1.45.0
exit
kron occurrence Midnight at 0:00 recurring
policy-list ChgRedist
kron occurrence Noon at 12:00 recurring
policy-list ChgRedist
exit

Rack1R3(config)#do sh kron schedule
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 20:55:41 at 0 :00 on
Noon inactive, will run again in 0 days 08:55:41 at 12:00 on

Rack1R3(config)#

Rack1R3(config)#do clock set 11:58:00 feb 15 2009
Feb 15 11:58:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 03:05:50 UTC Sun Feb 15 2009 to 11:58:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3(config)#do sh kron schedule
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 12:01:55 at 0 :00 on
Noon inactive, will run again in 0 days 00:01:55 at 12:00 on

Rack1R3(config)#

Rack1R3(config)#do deb kron all
All kron debug flags are on

Rack1R3(config)#

Now we just wait and see! (Pretend you’ve been staring at this for two minutes now!)

Rack1R3(config)#
Feb 15 11:59:59.999: Major 1, Minor 0
Feb 15 11:59:59.999: Timer Event Noon
Feb 15 11:59:59.999: Kron delay for next Noon 60000
Feb 15 11:59:59.999: Call parse_cmd 'clear ip route 145.1.45.0'
Feb 15 11:59:59.999: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 11:59:59.999: RT: del 145.1.45.0/24 via 145.1.13.1, ospf metric [110/865]
Feb 15 11:59:59.999: RT: delete subnet route to 145.1.45.0/24
Feb 15 11:59:59.999: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: Kron CLI return 0
''
Feb 15 12:00:00.003: Major 4, Minor 7
Feb 15 12:00:00.003: Respond to end of CLI Process
Feb 15 12:00:00.003: RT: SET_LAST_RDB for 145.1.45.0/24
NEW rdb: via 145.1.13.1

Rack1R3(config)#
Feb 15 12:00:00.003: RT: add 145.1.45.0/24 via 145.1.13.1, ospf metric [110/867]
Feb 15 12:00:00.003: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 12:00:00.003: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: RT: ospf's 145.1.45.0/24 (via 145.1.13.1) metric changed from distance/metric [110/867] to [110/865]
Feb 15 12:00:00.007: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.007: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Rack1R3(config)#

That looks like the router magically did what we wanted it to on R3! And on R6:

Rack1R6(config-router)#
*Feb 15 03:43:46.695: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/2] to [120/10]
*Feb 15 03:43:46.695: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Bingo! Exactly what you wanted.

Rack1R3(config)#do sh kron sched
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 11:58:24 at 0 :00 on
Noon inactive, will run again in 0 days 23:59:24 at 12:00 on

Rack1R3(config)#

And in 12 hours’ish we’ll see the process reverse itself. So yes, you CAN have redistribution on a timed basis, it’s just not necessarily a pretty thing!

About US

Network Bulls is Best Institute for Cisco CCNA, CCNA Security, CCNA Voice, CCNP, CCNP Security, CCNP Voice, CCIP, CCIE RS, CCIE Security Version 4 and CCIE Voice Certification courses in India. Network Bulls is a complete Cisco Certification Training and Course Coaching Institute in Gurgaon/Delhi NCR region in India. Network Bulls has Biggest Cisco Training labs in India. Network Bulls offers all Cisco courses on Real Cisco Devices. Network Bulls has Biggest Team of CCIE Trainers in North India, with more than 90% of passing rate in First Attempt for CCIE Security Version 4 candidates.

Biggest Cisco Training Labs in India
More than 90% Passing Rate in First Attempt
CCIE Certified Trainers for All courses
24x7 Lab Facility
100% Job Guaranteed Courses
Awarded as Best Network Security Institute in 2011 by Times
Only Institute in India, to provide CCIE Security Version 4.0 Training
CCIE Security Version 4 Training available
Latest equipments available for CCIE Security Version 4

Network Bulls Institute Gurgaon

Network Bulls Institute in Gurgaon is one of the best Cisco Certifications Training Centers in India. Network Bulls has Biggest Networking Training and Networking courses labs in North India. Network Bulls is offering Cisco Training courses on real Cisco Routers and Switches. Labs of Network Bulls Institute are 24x7 Available. There are many coaching Centers in Delhi, Gurgaon, Chandigarh, Jaipur, Surat, Mumbai, Bangalore, Hyderabad and Chennai, who are offering Cisco courses, but very few institutes out of that big list are offering Cisco Networking Training on real Cisco devices, with Live Projects. Network Bulls is not just an institute. Network Bulls is a Networking and Network Security Training and consultancy company, which is offering Cisco certifications Training as well support too. NB is awarded in January 2012, by Times, as Best Network Security and Cisco Training Institute for the year 2011. Network Bulls is also offering Summer Training in Gurgaon and Delhi. Network Bulls has collaboration with IT companies, from which Network Bulls is offering Networking courses in Summer Training and Industrial Training of Btech BE BCA MCA students on real Live projects. Job Oriented Training and Industrial Training on Live projects is also offered by network bulls in Gurgaon and Delhi NCR region. Network Bulls is also providing Cisco Networking Trainings to Corporates of Delhi, Gurgaon, bangalore, Jaipur, Nigeria, Chandigarh, Mohali, Haryana, Punjab, Bhiwani, Ambala, Chennai, Hyderabad.
Cisco Certification Exams are also conducted by Network Bulls in its Gurgaon Branch.
Network Bulls don't provide any Cisco CCNA, CCNP simulations for practice. They Provide High End Trainings on Real topologies for high tech troubleshooting on real Networks. There is a list of Top and best Training Institutes in India, which are providing CCNA and CCNP courses, but NB has a different image from market. Many students has given me their feedbacks and reviews about Network bulls Institute, but there were no complaints about any fraud from this institute. Network Bulls is such a wonderful place to get trained from Industry expert Trainers, under guidance of CCIE Certified Engineers.

CCIE Security Version 4

Cisco Finally updated CCIE Security Lab exam blueprint. WSA Ironport and ISE devices are added in CCIE Security Version 4 Lab Exam Syllabus Blueprint. In Updated CCIE Security Version 4 Syllabus blueprint, new technologies like Mobile Security, VoIP Security and IPV6 Security along with Network Security, are added. As in CCIE Security Version 3 blueprint, Cisco had focused on Network Security only, but now as per market demand, Cisco is looking forward to produce Internet gear Security Engineer, not only Network Security engineers.
In CCIE Security Version 4 Bluerpint, Lab Exam is going to be more interested than before. What is Difference in CCIE Security Version 3 and Version 4? Just go through the CCIE Security Version 4 Lab Equipment and Lab Exam Syllabus Blueprints and find out!

About NB

Network Bulls is Best institute for cisco certifications training in gurgaon. Network Bulls: A Complete CISCO Security Training Institute in Delhi/NCR, Gurgaon. Network Bulls provides Class Room, Online, One to One and Boot camp training on CCNA, CCNP, CCNA Security, CCNA Voice, CCSP, CCIE R&S, CCIE Security. Network Bulls is India's top CCIE (Cisco Certified Internetwork Expert) bootcamps, online classes and expert technical training Provider. Network Bulls provides ccna training in gurgaon. best ccnp training in gurgaon and bootcamp training for ccie written and lab certification in fast track, slow track and normal track for freshers and experienced candidates. NB is best ccie training institute in india. if anyone reallly interested doing quality training of cisco CCIE security Version 4, than i will recommend NB for CCIE Security Version 4 Training in India. CCIE Security Version 4 is highest level Certification offered by Cisco Systems, in Network Security track. All new devices of CCIE Security Version 4, are available in Network Bulls Gurgaon.

About Network Bulls Gurgaon

Best institute for ccna, ccnp, ccsp and ccie security version 4 course training in Delhi and Gurgaon.
Which is best ccsp institute in delhi? cisco certified security professional training in delhi ncr gurgaon. Nb provides world class top training for cisco security firewall in delhi ncr. Cisco CCIE certification exam lab asia's biggest lab training institution in new delhi gurgaon india. There are many institutes in India, who claims to provide Job Guarantee after CCNA even. There are some small institutes, who make fool of students with there cheap tricks and frauds. Some institutes in this field, do not have CCIE Certified trainers and racks available, but they claim to provide best training from other big institutes. Student should not take admission in such fraud and cheap institutes. Students can also give their valuable feedback, complaints and reviews about different institutes in our forums. But students should also be aware of wrong and unauthenticated feedback or complaints against great institutes like Network Bulls, Networkers Home and INE in some fake complaint forums, where no one is authenticating any comment or posts. Those wrong posts are written by some competitor institutes only. Those cheap and fraud institutes can't earn money and get admissions based on their results and infrastructure. They just write rubbish and wrong things on different forums against some good institutes and try to get admissions. A student who want to get refunds or good training or want to give feedback, can also go to consumer court and register a complaint against that fraud institute.
As per my experience Network Bulls and INE are both the best institutes of world.