Director Response Protocol

As far as i can tell this is one of those oddball subjects that just may rear its head on the CCIE Lab.

In this post i just denote
i) what is it
ii) where to find it on the doc cd
iii) provide a basic config.

Director Response Protocol.
This is a CISCO proprietary product. The DRP server agent is used to communicate with the Distributed Director platform. As a requirement in a lab i guess configuration of the server agent is a possibility.

On the doc cd look in 12.2 IP Configuration Guide. Then under Configuring IP Services. There is a reasonable description on configuring the server agent there.

The only configuration that is required to enable DRP is the global configuration
command 'ip drp server'. Over and above that the DRP server agent can then be configured to only allow certain Directors to communicate with it.


access-list 10 permit 185.28.8.1
access-list 10 permit 104.12.8.1

ip drp access-group 10


Additionally some authentication can be included between server agent and directors

key chain RICH
key 1
key-string CISCO
!
ip drp authentication key-chain RICH


I must confess the DRP still reamins a bit of a 'black box' subject to me, but i figure the above will be enough to cover off the basics.

NTP Broadcast Setup

Most of the scenarios i have encountered with NTP involve setting up NTP relationships with the 'ntp server' or 'ntp peer' commands. In this post i am not going to detail this setup.

An interesting scenario i came across was when the lab requirement was to establish NTP in an environment but WITHOUT using the 'ntp peer' or 'ntp server' commands.

To enable this requires use of NTP in a broadcast mode. The config for this is straightforward (as always if you know the answer:-})

R1
config-if#ntp broadcast client

R2
config-if#ntp broadcast

Thats it!

As with standard udp NTP the setup can be verified via 'show ntp associations'.

Frame Relay Traffic Shaping - Part III

A short post just to clarify a couple of frame relay traffic shaping features...

The minimum time slice on a Frame Relay interface is 10ms or 1/100 of a second. Hence to set the time slice on the interface to be the minimum, simply divide the CIR by 100.

As a further note....If there is a requirement to ensure that a single packet cannot take more than one interval to be transmitted, divide the bc by 8 to get the number of bytes and then set the fragment size to this. For example

map-class frame-relay DLCI_304
frame-relay cir 256000
frame-relay bc 2560
frame-relay fragment 320

Multicast Routing - Part III Controlling Access Part 2

In my fist post on controlling multicast access i described the 'ip igmp access-group' command.

As denoted this can be usefull controlling access to specified multicast address spaces. On a further lab i encountered a multicast access scenario that required multicast traffic to be restricted in both directions i.e. not only prevent multicast feeds being accepted from an interface, but also prevent multicast feeds being sent out an interface.

In such a situation where multicast access control is required in both directions then the 'multicast boundary' functionality can be used. This creates more stringent access control.

Access can be controlled in a granular fashion by utilising the access-list parameter.

For example...use this to prevent access to the administratively scoped address space

Router(config-if)# ip multicast boundary 1
Router(config)# access-list 1 deny 239.0.0.0 0.255.255.255
Router(config)# access-list 1 permit 224.0.0.0 15.255.255.255


Whilst researching on multicast boudaries i then realised there was a 3rd option to control multicast access:-)...

The 'ip igmp access-group' command works perfectly for L3 interfaces. However if required to restrict access on a L2 interface this command will NOT cut the mustard.

This is where 'igmp profiles' can be used on an L2 access port.

int f0/01
switchport mode access
switchport access vlan 7
ip igmp filter 1
!
ip igmp profile 1
deny
range 239.0.0.0 239.255.255.255

BGP snippets

BGP Default Router

R1 -------- R2

In this scenario R1 must advertise a BGP default route to R2. NO other BGP routes are allowed.

R1

router bgp 1
neighbor {a.b.c.d} default-originate
neighbor {a.b.c.d} prefix-list DEFAULT out

ip prefix-list DEFAULT permit 0.0.0.0/0





BGP - NON transit area

How do you ensure a BGP area is not used as a tranit area? One answer is to ensure it only advertises routes originated in it own area.

ip as-path access-list 1 permit ^$
router bgp 1
neighbor {a.b.c.d} filter-list 1 out




Redistribution from BGP

router ospf 1
redistribute bgp 1

With the statement above all BGP EXTERNAL routes will be propogatedinto OSPF. If there is a requirement for BGP internal routes to be propogated into OSPF then the following command is required under at BGP router prompt.

router bgp 1
bgp redistribute-internal




Redistribution of a single BGP area

If redistribution from BGP is required but only from a single BGP area this can be achieved via a route-map in conjunction with an as-path access-list.


router ospf 1
redistribute bgp 1 route-map BGP2OSPF
!
ip as-path access-list 1 permit _54_
!
route-map BGP2OSPF permit 10
match as-path 1



thats it:-)

OSPF Routing Problem

Consider the following scenario.

Router 1 is sending a lot of traffic to the 164.1.5.0 subnet on Router 2. The preferred route (by default) is via R3 as this is an Intra-Area Route. The route between R1 and R2 is an Inter Area route so will NOT be considered for the traffic flow - this is regardless of the metric cost value.

The question is how to get R1 to prefer the direct, faster route to R2! As mentioned altering the route cost will have NO bearing, as Intra vs Inter are considered above such comparisons. Intra Area routes always win regardless of costs.

The way around this problem is to build a virtual link between R1 and R2. This way once up, the route to 164.1.5.0 will beomce preferrable.

Router 4
router ospf 100
area 1 virtual-link 5 150.1.5.5

Router 5
router ospf 100
area 1 vitual-link 150.1.4.4

EIGRP metric calculation

If the standard bandwidth and delay parameters are used within EIGRP the formula for calculating the metric is as follows...

(10,000,000/bw(kbit) + delay/10) * 256

As an example examine the following entry from the eigrp topology table.


Router_1#s ip eigrp top 164.1.26.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2684416
Routing Descriptor Blocks:
164.1.13.3 (Serial2/1), from 164.1.13.3, Send flag is 0x0
Composite metric is (3026432/2514432), Route is Internal
Vector metric:
Minimum bandwidth is 1280 Kbit
Total delay is 40100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2

Using the formula....

(10,000,000/1280 + 40100/10) * 256 = (7812.5 + 4010) * 256
= 11822 * 256
= 3026432!!

N.B. Before moving figures outside of brackets truncate (not round) the figure to 0 decimal places.

Understanding this metric calculation may seem a bit like overkill - it did to me! However it could feasibly come into play if a question asked for EIGRP load balancing to be performed according to a certain ratio. In this instance it may be necessary to adjust the EIGRP metric to achieve the desired balancing.