Frame Relay Bridging

VLAN 16 and 22 are broadcast capable segments only. The requirement here is that these two networks are bridged together.

R1
int fa0/0
bridge-group 1

int s2/0
bridge-group 1

int BVI1
ip address 192.10.1.1 255.255.255.0

bridge irb
bridge 1 protocol ieee
bridge 1 route ip

int s2/0
frame-relay map bridge 102 br


R2
int fa0/0
bridge-group 1

int s2/0
bridge-group 1

int BVI1
ip address 192.10.1.2 255.255.255.0

bridge irb
bridge 1 protocol ieee
bridge 1 route ip

int s2/0
frame-relay map bridge 201 br

R1#s frame map
Serial2/0 (up): bridge dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active

R1#p 192.10.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#p 192.10.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/44/68 ms


In the above config i also connect the bridge group to the router via the BVI router interface. Since the bridged segment is logically one segment i put the routable protocol information on the BVI, and its ip address applies to all interfaces in the bridge group. The IOS treats the BVI as any other interface and so enables routing between the bridge group and the routed interfaces in the router.


cisco doc
http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_transprnt_brdg_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1004971

Spanning Tree - portfast, bpduguard, bpdufilter

I use the above diagram to illustrate the interaction between the spanning tree features: portfast, bpdufilter and bpduguard.

For a long time whilst i understood the purpose of these features i did not understand how in particular bpdufilter and bpduguard interacted with each other.
I have at last resolved this confusion by running a wire capture to see for myself exactly what is going on.

First the basics
portfast - moves a port immediately to the forwarding state
bpdufilter - stops a port sending bpdus
bpduguard - error disables a port if bpdus are received

1)
config-if#spanning-tree portfast

Enabling portfast the port moves to forwarding state and from the capture i can see BPDUs still being sent.

2)
config-if#spanning-tree portfast
config-if#spanning-tree bpdufilter

I enable bpdufilter and BPDUS are no longer sent.

3)
config-if#spanning-tree portfast
config-if#spanning-tree bpduguard

I enable bpduguard and can see bpdus being sent. I was somewhat surprised by this as i had always treated bpduguard as a more severe version of bpdufilter. i.e. no bpdus sent with the guard feature set - Wrong!!

The enlightening moment for me was the realisation that to enforce no bpdus are sent and bpduguard is on perhaps requires bpdufilter to be enabled alongside bpduguard.

4)
config-if#spanning-tree portfast
config-if#spanning-tree bpduguard
config-if#spanning-tree bpdufilter

With the above commands i observed no bpdus being sent. I had previously assumed these features were mutually exclusive. They are not, they perform different functions and can be used alongside each other.

To observe bpdu guard in action i connected the port to another switchport that was sending bpdus.

I then observed the following...

01:03:26: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet0/24 with BPDU Guard enabled. Disabling port.
01:03:26: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/24, putting Fa0/24in err-disable state
01:03:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down
01:03:28: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down

Examining the port status

show int status err-disabled
Port Name Status Reason
Fa0/24 err-disabled bpduguard

To ensure auto recovery i entered the following commands

config#errdisable recovery cause bpduguard
config#errdisable recovery interval 30

I then applied bpdufilter to the neighboring switch port sending bpdus and the local port was automatically restored to normal service.

DHCP Snooping

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It differentiates between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.

To enable on a switch.

config#ip dhcp snooping
config#ip dhcp snooping vlan {n}
All DHCP servers must be connected to the switch through trusted interfaces. Hence the above config goes hand and hand with

config-if#ip dhcp snooping trust

Once dhcp snooping is enabled on a vlan enabled all ports are treated as untrusted by default.
During the process where a user port acquires an ip address via DHCP the switch builds a database of mac addresses and associated IP. Henceforth when a switch receives a packet on an untrusted interface the switch compares the source MAC address and the address in the DHCP binding database. Normally the addresses match and the switch forwards the packet. Conversely if they dont the switch drops the packet.

N.B. By default a switch inserts and removes DHCP relay information (option-82 field) in forwarded DHCP request messages to the DHCP server. Consequently it is necessary to enter the following command on the router

config-if#ip dhcp relay information trusted

default gateway timing

I came across a default gateway lab scenario that initially had me stumped. The requirement could be achieved via standard HSRP or VRRP configuration.

So the basic solution making R2 the active default gateway is as follows:

R1:
interface FastEthernet0/0
vrrp 1 ip 130.1.26.1
vrrp 1 preempt

R2:
interface GigabitEthernet0/1
vrrp 1 ip 130.1.26.1
vrrp 1 preempt
vrrp 1 priority 105


The sting in the requirement (and in my experience with CCIE there usually is one) is to ensure that if R2 has relinquished the active default gateway role, is to not allow resumption of the role, until gi0/1 has been up for a minimum of 5 minutes.

My first thought was to adjust the VRRP timers. INCORRECT since the max timer is 255 seconds - not eneough.

R2(config-if)#vrrp 1 timers advertise ?
<1-255> Advertisement interval in seconds

My second thought was introduce a delay on the interface tracking. INCORRECT since the max timer is 180 seconds - not enough

R2(config)#track 1 interface Fastethernet0/0 line-prot
R2(config-track)#delay up ?
<0-180> Seconds to delay

I thought about combining the two features together but this felt a little too convoluted.

After some further investigation i discovered there is a delay parameter on the preempt. This features has a parameter allowing up to 3600 seconds or 1 hour delay.

R2(config-if)#vrrp 1 preempt delay min ?
<0-3600> Seconds to delay

Hence i added the following line to my lab solution

R2(config-if)#vrrp 1 preempt delay min 300

As ever, it was easy, once i knew how:-)

telnet prohibited

How can you prevent a telnetted user telnetting out to another a router??

Simply:

R1
conf t
line vty 0 4
transport output none

I telnet to router 1 and attempt to open a further telnet session

R1>telnet 160.1.1.2
% telnet connections not permitted from this terminal
Job done!

RMON - Remote Monitoring

Before i detail the lab scenario a brief overview of RMON:

RMON is an IETF standard developed to enable network management stats to be gathered from remote sites without the overhead of SNMP constantly polling. When RMON is configured it gathers info and passes it back to management nodes. RMON is designed to work in conjunction with SNMP. Typically SNMP is enabled alongside RMON for an effective solution.

Lab scenario:
i) configure R1 to generate an SNMP trap whenever the output queue length (ifEntry.21.2) of its Serial0/0 interface exceeds 250 packets.
ii) This MIB value should be sampled every 30 seconds.
iii) When there are more than 250 packets in the output queue R1 should generate the message “WARNING: S1/0 Congested”.
iv) When the value falls back to 50 R1 should generate the message “INFO: S1/0returned to normal utilization”.
v) R1 should send SNMP traps to is 10.1.1.100 with the community string to be RICHTRAP

With RMON first configure the events and then configure the associated alarms

rmon alarm 1 ifEntry.21.2 60 absolute rising-threshold 250 1 falling-threshold 50 2
rmon event 1 trap IETRAP description "WARNING: S1/0 Congested"
rmon event 2 trap IETRAP description "INFO S1/0 returned to normal utilization"

Then configure the SNMP traps.

snmp-server host 10.1.1.100 IETRAP
snmp-server enable traps

As taken from the cisco doc:
For a host to receive notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.

CBAC - Context Based Access Control

CBAC performs a similar function to refelexive acls. With CBAC however there’s much more granular control on the type of sessions monitored, along with the allowed session thresholds and timers (see ip inspect ? For types of control allowed).


R1 (trusted) --------- FA0/0 R2 S1/0 ---------- R3 (untrusted)

In this example no inbound tcp sessions are allowed into the protected network however R1 is allowed tcp access out to the untrusted network (R3). A standard blocking acl is applied to the outside interface on R2

access-list 100 deny tcp any any
access-list 100 deny udp any any
access-list 100 permit icmp any any echo-reply
access-list 100 permit eigrp any any
access-list 100 deny ip any any

interface S1/0
ip access-group 100 in

With this config R1 can ping R3 but cannot telnet to it.

I create an inpsection rule to examine all tcp traffic. I apply the inspection rule to interface Ethernet0/0 to inspect traffic from users on the protected network. When CBAC detects tcp traffic from the protected network, CBAC will create a dynamic entry in access list 100 to allow return traffic.

Router_2(config)#ip inspect name RICH tcp
Router_2(config)#int fa0/0
Router_2(config-if)#ip inspect RICH in

Unlike reflexive acls there is no explicit reference required in the acl on the untrusted interface - initially a source of some confusion for me!!! CBAC will add dynamic entries and open up access without it.

With the above config R1 can now initiate a telnet connection to R3

Verification commands on R2

#show ip inspect all
#show access-list 100

Alternatively the inpsect rule can be applied on the untrusted interface in the out direction achieving the same net result.

Router_2(config)#int s1/0
Router_2(config-if)#ip inspect RICH out

Restricting telnet access

A lab requirement stated 'Allow telnet access to R6 on port 3005 and ensure standard telnet access on port 23 is not allowed'??

To fulfill this requirement requires use of the 'rotary' command on the vty ports.

line vty 0 4
rotary 5

The above enables telnet access on port 3005.

To fulfill the second requirement to restrict access on port 23 can be done via an ACL and access-class command...

ip access-list ext 101
deny tcp any any eq telnet
permit ip any any

line vty 0 4
access-list 101 in

To add an extra twist, a further requirement is added to ensure users entering via vty are prompted for local username and password. No login credentials are required for console access. This can be achieved with the following....

aaa new-model
aaa authentication login default none
aaa authentication login VTY local

line vty 0 4
login authentication VTY

Frame Relay - Load Interval

Whenever the show interface command is used by default the 5 minute input and output rate is displayed along with the load over this interval

Show interface s2/0
…. output omitted ….
reliability 255/255, txload 2/255, rxload 2/255
…. output omitted ….
5 minute input rate 16000 bits/sec, 18 packets/sec
5 minute output rate 16000 bits/sec, 18 packets/sec
…..output omitted …..

This default behaviour can be changed using the interface command load-interval.

int se2/0
load-interval 30

N.B. The minimum is 30 seconds and can be any multiple of 30 up to 10 mins.

Frame Relay - Broadcast Queue

The Cisco IOS creates a broadcast queue for interfaces running frame-relay. This queue performs 2 functions: it ensures routing traffic is dealt with as a priority but it also limits the bandwidth that can be consumed by such traffic.

When an interface has many DLCIs the overhead of replicating routing traffic can be significant.

The interface has the following default settings

size: 64 packets
byte-rate: 256000 bytes per second
packet-rate: 36 packets per second

To change the settings the following interface command can be used

frame-relay broadcast-queue {x} {y} {z}

The following example specifies a broadcast queue to hold 80 packets, to have a maximum byte transmission rate of 240000 bytes per second, and to have a maximum packet transmission rate of 160 packets per second:

frame-relay broadcast-queue 80 240000 160

The actual limit in any second is the first rate limit that is reached I.e. byte or packet.

To examine how the broadcast queue is performing simply use the show interface command:-

Rack1R1#show int s2/0
Serial2/0 is up, line protocol is up
{… output omitted …..}
Broadcast queue 0/64, broadcasts sent/dropped 83/0, interface broadcasts 86

BGP - ORF (Outbound Route Filtering)

The standard method for BGP to filter routes entering the BGP table is to apply prefix-list filtering on incoming updates. For example

R1
ip prefix-list rich permit 10.1.1.0/24
neighbor 1.2.3.4 prefix-list rich in

In the above example R1 will only allow the 10.1.1.0/24 route into its BGP table.

The flaw with the above is that R1 must receive ALL routes from the 1.2.3.4 neighbor. Upon receipt R1 then allows only the required routes to enter the local BGP table. The problem here is that R1 must first receive the whole BGP table advertised by its neighbor.

It is exactly this BGP characteristic that ORF was designed to improve. With ORF enabled on neighboring routers, only the required routes are sent in the first place. Hence link bandwidth and the local routers memory are then spared unnecessary overhead.

An important note i made to myself is that the above config still applies i.e. route filtering is set up exactly as when ORF is not enabled. The required ORF functionality is then simply configured on top of this configuration.

N.B. Running Version 12.3(23) i noticed the config would only take hold if i applied under the address-family ipv4 sub command prompt.

R1
router bgp 200
address-family ipv4
neighbor 1.2.3.4 capability orf prefix-list send

R2
router bgp 100
address-family ipv4
neighbor 4.3.2.1 capability orf prefix-list receive

Once applied i ran debug ip bgp updates and was able to see the router only received the required routes. Before applying the ORF capability i was able to see all routes arriving and then the router denying those not allowed in the prefix-list.