Seeing anything strange below?
Please do not ask here for information where to get it. Just talk to your ****.
Nothing personal...Only technical...
The command scheduler will allow you to run commands, or a sequence of commands once or on a recurring basis. This is very similar to the Windows "at" command.
A common request that people have asked me for is to copy a router's running-config to startup-config or to a TFTP server on a certain day of the week every week. This will ensure that no changes are lost if someone forgets to save the config or the router dies.
Here is an example: To get a router to copy the running-config to startup-config every Sunday at 23:00, do the following:
Step 1) Kron policy list
Create a kron policy list - this is your script which lists what commands the router should run at the scheduled time
Router(config)# kron policy-list SaveConfig
Router(config-kron-policy)# cli write
Router(config-kron-policy)# exit
Note:
cli - Specifies EXEC CLI commands within a Command Scheduler policy list.
policy-list - Specifies the policy list associated with a Command Scheduler occurrence.
IMPORTANT: The reason why "write" was used rather than "copy running-config startup-config" is because kron does not support interactive prompts and "copy running-config startup-config" requires interaction. It is important to remember this when creating commands. Also note that kron does not support configuration commands.
Step 2) Create a kron occurrence
Create a kron occurrence, in which you tell the router when and how often you want to run the policy.
Router(config)# kron occurrence SaveConfigSchedule at 23:00 Sun recurring
Router(config-kron-occurrence)
Note:
SaveConfigSchedule - Name of occurrence. Length of occurrence-name is from 1 to 31 characters. If the occurrence-name is new, an occurrence structure will be created. If the occurrence-name is not new, the existing occurrence will be edited.
at - Identifies that the occurrence is to run at a specified calendar date and time.
recurring - Identifies that the occurrence is to run on a recurring basis.
3) Verify
Verify that you've entered everything correctly by using the show command.
r1#sh kron schedule
Kron Occurrence Schedule
SaveConfigSchedule inactive, will run again in 1 days 12:37:47 at 23:00 on Sun
You can see that the schedule is ready to go and will run at the date above.
Note:
inactive - means that kron is not running the command(s) at present. Active means that kron is running the current command(s)
Verify that kron works via debugs:
Router#debug kron exec-cli
Dec 17 22:59:59.999: Call parse_cmd 'write'
Dec 17 23:00:01.587: Kron CLI return 0
'
**CLI 'write':
Building configuration...[OK]'
Dec 17 23:00:59.999: Call parse_cmd 'write'
Dec 17 23:01:01.559: Kron CLI return 0
'
**CLI 'write':
Building configuration...[OK]'
4) View the output of your configuration:
Router# show running-configuration
kron occurrence SaveConfigSchedule at 23:00 Sun recurring
policy-list SaveConfig
kron policy-list SaveConfig
cli write
“What makes more sense for my business, a UIFN number or an ITFS number and what’s the difference?”
ITFS stands for International Toll Free Service. An ITFS number is the international equivalent of a U.S. Toll Free number in that it allows a customer to call a business and have the business pay for the call. With ITFS, customers in one country can make toll free calls that can then be terminated in another country. The numbers vary country by country.
UIFN is an acronym for Universal Free Phone service whereby businesses can advertise a single number that can be accessed from multiple countries.
Which number makes more sense really depends on each customer’s needs. While the UIFN number is a great idea in principle, in practice it does have some drawbacks.
UIFN numbers consist of a prefix then 800 then 8 digits. An example would be the UK which has a prefix of 00 so a UIFN number as dialed from the UK would be 00 800 XXXX XXXX. Other prefixes include Australia - 0011, Argentina - 00, Finland - 990, and Canada - 011. So here’s the advice we give to our customers...
If you only need toll-free access from one country, use an ITFS number and save yourself the universal registration fee. If you are displaying the numbers on your corporate web site and can provide a drop down box for countries and corresponding toll free numbers, it still might make sense to go with the ITFS. However, if you are paying for advertising and the “real estate” is at a premium, it may make sense to go with one UIFN number, especially if you are advertising to a large number of countries.
There really is no “one size fits all” answer, but with careful consideration companies can select the option that best meets their and enjoy the many advantages of international toll free services – ITFS or UIFN.
Groups of fibers can be designated in several different ways:
Fibers are housed inside of colored plastic tubes, all under the same outer jacket. In this case, colors of the tubes go in the same sequence as colors of the fibers: tube #1 - blue; tube #2 - orange and so on.
Fibers are helix-wrapped in colored threads or plastic ribbons. Same coloring scheme as above applies to the wraps.
Fibers have black stripes, one, two, three or even four. This is by far the most complicated tecnique. The stripes (or stripes pairs, triples etc.) are usually located about a foot (approx. 30 cm) from each other. So, you can't immediately tell what group the individual fiber belongs to. You would have to find the stripes, count them, and then decide what group number it is. If you can't find ANY stripes, it means that this fiber belongs to group one
There are also colors that designate the type of the optical fibers. It is not always followed by all manufacturers, and also, this code only applies to indoor cables: multimode fiber cables have orange jacket, and singlemode fiber cables have yellow.
Cisco IOS has a special feature called local policy routing, which permits to apply a route-map to local (router-generated) traffic. The first way we can use this feature is to re-circulate local traffic (and force it re-enter the router). Here’s an example. By default, locally-generated packets are not inspected by outgoing access-lists. This may cause issues when local traffic is not being reflected under relfexive access-list entries. Say with configuration like that:
!
! Reflect all "session-oriented" traffic
!
ip access-list extended EGRESS
permit tcp any any reflect MIRROR
permit icmp any any reflect MIRROR
permit udp any any reflect MIRROR
!
! Evalute the reflected entries
!
ip access-list extended INGRESS
evaluate MIRROR
permit ospf any any
!
interface Serial 0/0
ip address 54.1.1.6 255.255.255.0
ip access-group INGRESS in
ip access-group EGRESS out
You would not be able to telnet out of a router to destinations behind the Serial interface, even though TCP sessions are reflected in access-list. To fix the issue, we may use local-policy to force the local traffic re-enter the router and be inspected by outgoing access-list:
!
! Redirect local telnet traffic via the Loopback interface
!
ip access-list extended LOCAL_TRAFFIC
permit tcp any any eq 23
!
route-map LOCAL_POLICY 10
match ip address LOCAL_TRAFFIC
set interface Loopback0
!
! Traffic sent to Loopback interface re-enters the router
!
interface Loopback0
ip address 150.1.6.6 255.255.255.50
!
! Apply the local-policy
!
ip local policy route-map LOCAL_POLICY
With this configuration, local telnet session will re-enter the router and hit the outgoing access-list, thereby triggering a reflected entry. This same idea may be utilized to force CBAC inspection of locally-generated traffic, by since 12.3 there has been a special IOS feature to do this natively.
The other useful application of local policy routing is using it for traffic filtering. For example you may want to prohibit outgoing telnet sessions from local router to a certain destination:
ip access-list extended BLOCK_TELNET
permit tcp any host 150.1.1.1 eq 23
!
route-map LOCAL_POLICY 10
match ip address BLOCK_TELNET
set interface Null 0
!
! Apply the local-policy
!
ip local policy route-map LOCAL_POLICY
The syntax is somewhat similar to the vlan access-maps used on Catalyst switches, and similarly the route-map is applied “globally”, i.e. to all router traffic, going out on any interface. Note that you may use the same idea to block incoming session, simply by reversing entries in access-list. (e.g. “permit tcp any eq 23 host 150.1.1.1″). Best of all, with PBR you may apply additional criteria to incoming traffic, e.g. match packet sizes.
The last example is the use of local PBR to apply special treatment to management/control plane traffic - e.g. use different output interfaces for out-of-band management. With local PBR you may also apply special marking for control traffic, e.g. selectively assign IP precedence values.
ip access-list extended MANAGEMENT_TRAFFIC
permit tcp any eq 23 any
permit tcp any eq 22 any
!
route-map LOCAL_POLICY 10
match ip address MANAGEMENT_TRAFFIC
set interface Serial 0/1
set ip precedence 7
!
ip local policy route-map LOCAL_POLICY
This exampls are very userful for real-world problems or mug it up at least for CCIE.
Operations Support Systems (also called Operational Support Systems or OSS) are computer systems used by telecommunications service providers. The term OSS most frequently describes "network systems" dealing with the telecom network itself, supporting processes such as maintaining network inventory, provisioning services, configuring network components, and managing faults. The complementary term Business Support Systems or BSS is a newer term and typically refers to "business systems" dealing with customers, supporting processes such as taking orders, processing bills, and collecting payments. The two systems together are often abbreviated BSS/OSS or simply B/OSS.
The term OSS was historically used to include both network and business systems. It is still sometimes used in this sense, which can cause some confusion. When used in this way, the term OSS may be seen as inclusive of BSS. For more detail about the use of other terms such as "network management", see the section on architecture below.
A lot of the work on OSS has been centred on defining its architecture. Put simply, there are four key elements of OSS:
During the 1990's, new OSS architecture definitions was done by the ITU-T in its TMN model. This established a 4-layer model of TMN applicable within an OSS:
Business Support Systems (BSS) are the components that a telephone operator or telco uses to run its business operations. The term BSS is no longer limited to telephone operators offering mobile to fixed and cable services but also can apply to service providers in all sectors such as utility providers.
Typical types of activities that count as part of BSS are taking a customer’s order, managing customer data, managing order data, billing, rating, and offering B2B and B2C services. Business Support Systems are linked to Operational Support Systems (OSS) in the enhanced Telecom Operations Map (eTOM) that maps processes into the functional areas of Fulfilment, Assurance and Billing where Assurance is typically covered by OSS platform. BSS and OSS platforms are linked in the need to support various end to end services. Each area has its own data and service responsibilities.
The role of Business Support Systems in a service provider is to cover 4 main areas:
Product management supports the sales and management of products, offers and bundles to businesses and mass-market customers. Product Management regularly includes offering cross-product discounts, appropriate pricing and customer loyalty programmes.
Service Providers require a single view of the customer and regularly need to support complex hierarchies across customer-facing applications. Customer Management also covers requirements for partner management and 24x7 Web-based customer self-service. Customer Management can also be thought of a full-fledge Customer Relationship Management systems implemented to help customer care agents handle the customers in a better and informed manner.
Revenue Management is a BSS focus on billing, charging and settlement, that can handle any combination of OSS services, products and offers. BSS Revenue Management supports OSS order provisioning and often partner settlement.
Fulfillment Management as part of assurance is normally associated with Operational Support Systems though Business Support Systems are often the business driver for Fulfillment Management and order provisioning.
Most recently the TM Forum (TMF) has developed a communications domain model that provides the basis for clarifying the distinction between OSS and BSS systems. As shown in the figure the BSS supports the more Customer Facing domains. Whereas the OSS supports the traditional Resource and Resource Facing Service domains.
In NGOSS, applications provide access to system capability, which can generally be categorized as either BSS or OSS. The capability offered by an application through its deployed components can be further categorized as shown in the figure. Business activities such as Fulfillment, Assurance & Billing will necessarily utilize BSS and OSS applications capability from each of the domains to support end-to-end process flows.
For example, problem handling activities (part of Assurance) inside a Service Provider define the interaction between the Customer, Product, Service, Resource and Supplier/Partner entities to resolve the reported incident/problem. As such, problem management applications are required to provide access to Customer, Product, Service, Resource and Supplier/Partner information in support of the problem handling activities that occur throughout the problem management process lifecycle.