NAT Load Balancing

As an added feature of NAT it can be used to load balance a ‘serverfarm’. The router performing the natting can round robin connection requests to the real servers.

A virtual server address is required. The natting router takes tcp requests received on this address, and the specified ports, and passes them on in a rotary fashion to the servers.

This can be achieved with the following configuration on R2…..


interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat outside
!
interface FastEthernet1/0
ip address 11.0.0.2 255.255.255.0
ip nat inside

ip nat pool REALS 11.0.0.3 11.0.0.4 prefix-length 24 type rotary
ip nat inside destination list VIPACCESS pool REALS
!
ip access-list extended VIPACCESS
permit tcp any host 11.0.0.254 eq telnet

Now when telnetting to 11.0.0.254 from R1, R2 redirects the request to one of the 3 real server addresses

Router_1#telnet 11.0.0.254Trying 11.0.0.254 ... Open
Router_4>

On R2 i examine the nat translation table

Router_2#s ip nat trans

Pro Inside global Inside local Outside local Outside globaltcp 11.0.0.254:23 11.0.0.4:23 10.0.0.1:16630 10.0.0.1:16630

!

Multicast Gotchas

I have listed a few gotchas that i have come across when configuring IP multicast.....

Multicast on a hub-and-spoke frame-relay network.

A multipoint interface won't, by default, send multicast received from one spoke out to another spoke. This doesn't apply to a 'hub-and-spoke' where the hub is using separate physical or virtual interfaces, just multipoint interfaces. For sparse traffic this can be fixed by applying 'ip pim nbma-mode' to the multipoint interface. For dense traffic, you can use a PIM-enabled tunnel between the spokes to fix this. To use the tunnel an mroute pointing to the tunnel is required, to ensure the RPF check does not fail.

Consider the above topology where R1, R2 and R3 are all enabled with ip pim dense-mode on the serial interfaces. R1 has joined multicast group 226.1.1.1. R2 is able to successfully ping this address but from R3 this fails.

To circumvent this problem the following tunnel configuration can be applied...

R1
interface Tunnel1
ip address 148.1.1.1 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.3.3

ip mroute 0.0.0.0 0.0.0.0 Tunnel1

R3
interface Tunnel1
ip address 148.1.1.2 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.1.1

RPF Checks

If multicast traffic is required to take a path which unicast wouldn't, then the recieving router will likely drop the traffic because it fails the RPF check. This is typically fixed by applying an mroute.

Using Auto-RP in Sparse Mode
It was my misconception until recently that Auto RP operates in sparse-dense mode only. In fact in can operate in sparse mode as long as routers are configured with ip pim autorp listener command.

IPV6 6to4 tunnels

A IPV6 tunnelling method that can be used in a one to many environment (as opposed to point to point tunnelling). To configure it all that's required is
1) a tunnel interface given a special IPV6 address with an embedded IPV4 interface address.
2002:{first 2 octects ipv4 address}:{second 2 octects of ipv4 address}:...
2) an ipv6 static route '2002::/16 tu0'

The CISCO IOS works its magic to nail up connectivity to the other tunnel end points.

interface Tunnel0
no ip address
no ip redirects
ipv6 address 2002:101:101:134::1/64
tunnel source Loopback0
tunnel mode ipv6ip 6to4

interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
ipv6 route 2002::/16 Tunnel0

interface Loopback1
no ip address
ipv6 address 2002:1::1/64


All thats required to connect IPV6 address spaces over the tunnel is to implement IPV6 routing over the tunnel

e.g.

R1
ipv6 route 2002:3::/64 2002:303:303:134::3

Router_1#PING 2002:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/97/152 ms
Router_1#

Regular Expression Special Characters

As a reminder to my self, the regular expression special characters.

Character Meaning
^ Start of string
$ End of string
[] Range of characters
- Used to specify range ( i.e. [0-9] )
( ) Logical grouping
. Any single character
* Zero or more instances
+ One or more instance
? Zero or one instance
_ start or end of string, or space

Examples (ive only scratched the surface here!)

Example 1
Only allow routes originated by as 54
ip as-path access-list 1 permit _54$
ip as-path access-list 1 deny .*

Example 2
Only allow routes from as 54 and directly connected peer AS,s
ip as-path access-list 1 permit ^54_([0-9]+)?$
ip as-path access-list deny .*

Example 3
To match on any route that has transitioned through as 54.  i.e. one that originated in, passed through, or advertised by use

ip as-path access-list 1 permit _54_

In fact the _ (underscore) character permits a space, command, start of string, end of string or a bracket symbol.




A great way to test regular expression is via the command
show ip bgp regexp {expression}
N.B. to enable a ? to be entered in a command line precede with ctrl-V.

Mark and Police

In this post i bring together a number of QOS features to implement an end to end QOS marking and policing scenario.

On R2 i mark all traffic destined to UDP port 3333 with an IP precednce of 3. On R3 i ensure all traffic with an IP precednce of 3 utilises no more than 100,000 bps of the bandwidth between R3 and R4.

In order to test this scenario i make use of the IP SLA feature. R1 generates the traffic to the loopback 0 on R4 with a UDP dest port of 3333. On R4 i configure an IP SLA responder to ensure these packets are answered.

Here is the config i used....

R1
ip sla monitor 1
type udpEcho dest-ipaddr 99.99.99.99 dest-port 3333
request-data-size 1500
timeout 2000
frequency 15
ip sla monitor schedule 1 life forever start-time now


R2

access-list 100 permit udp any any eq 3333

class-map match-all SLA
match access-group 100

policy-map MARK
class SLA
set precedence 3

interface FastEthernet1/0
service-policy output MARK


R3
access-list rate-limit 1 mask 08

interface FastEthernet1/0
rate-limit output access-group rate-limit 1 100000 18750 37500 conform-action transmit exceed-action drop

R4
ip sla monitor responder type udpEcho ipaddress 99.99.99.99 port 3333


For verification i used the following commands on each of the routers

R1
s ip sla monitor stat
Round trip time (RTT) Index 1
Latest RTT: 160 ms
Latest operation start time: *06:04:24.763 UTC Thu Dec 25 2008
Latest operation return code: OK
Number of successes: 152
Number of failures: 24
Operation time to live: Forever

R2
s policy-map int fa1/0
FastEthernet1/0

Service-policy output: MARK

Class-map: SLA (match-all)
296 packets, 233248 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group 100
QoS Set
precedence 3
Packets marked 296

Class-map: class-default (match-any)
451 packets, 38519 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any


R3
#s int fa1/0 rate-limit
FastEthernet1/0
Output
matches: access-group rate-limit 1
params: 96000 bps, 18750 limit, 37500 extended limit
conformed 100 packets, 78800 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 7788ms ago, current burst: 14 bytes
last cleared 00:12:48 ago, conformed 0 bps, exceeded 0 bps

R4
show ip sla monitor responder
IP SLA Monitor Responder is: Enabled
Number of control message received: 4 Number of errors: 0
Recent sources:
10.0.0.1 [06:10:24.379 UTC Thu Dec 25 2008]
10.0.0.1 [06:10:09.391 UTC Thu Dec 25 2008]
10.0.0.1 [06:09:54.395 UTC Thu Dec 25 2008]
10.0.0.1 [06:09:39.371 UTC Thu Dec 25 2008]
Recent error sources:

udpEcho Responder:
IP Address Port
99.99.99.99 3333


It works! :-)

Policing: MQC vs Rate Limiting

Suppose the lab requirement is to restrict traffic with IP precedence 3,4 and 5 to a max throughput of 500,000 mps. As ever with the CCIE there is more than one method to crack this nut. I guess it depends on your preferred method versus what the actual requirements and restrictions of the task are.

My personal preference would be to use MQC. The above requirement could be achieved as follows.....


ip access-list extended 101
permit ip any any prec 3
permit ip any any prec 4
permit ip any any prec 5

class-map PREC345
match access-group 101

policy-map POLICE
class PREC345
police 500000 93750 187500 conform-action transmit exceed-action drop

int fa0/0
service-policy output POLICE

For verification use the 'show policy-map int fa0/0' command.


Another method of achieving the same result is to use the older rate-limit command.....

rate-limit output access-group 101 496000 93750 187500 conform-action transmit exceed- action drop

There is a 3rd method of achieving the above. This is another variation on the rate-limit command. If the lab requirement specified the solution must be achieved using an ACL with only 1 line this may be one scenario where such a solution would come to the rescue.

There is a special access-list type named 'rate-limit'. This allows traffic to be selected based on MAC address, precedence or MPLS markings.

Router_2(config)#access-list rate-limit ?
<0-99> Precedence ACL index
<100-199> MAC address ACL index
<200-299> mpls exp ACL index

The requirement here is to use IP precedence 3,4 and 5.

access-list rate-limit 0 ?
Router_2(config)#access-list rate-limit 0 ?
<0-7> Precedence
mask Use precedence bitmask

As with an ACL only 1 precedence value can be configured per line. To allow multiple precedence values to be configured with one 'hit' requires the use of the mask option.

To make use of this the coding of the precedence values needs to first be recalled...

IP Precedence 0 = 00000001
IP Precedence 1 = 00000010
IP Precedence 2 = 00000100
IP Precedence 3 = 00001000
IP Precedence 4 = 00010000
IP Precedence 5 = 00100000
IP Precedence 6 = 01000000
IP Precedence 7 = 10000000

A packet with ip precedence of either 3,4 or 5 can be matched with bit pattern 00111000. The mask parameter expects this bit pattern in 2 HEX digits, so this has the equivalent value 38. (Note.. this is the 2 byte HEX equivalent and not the HEX value of the full byte which would be 56!!).

So bringing this all together the 1 line solution to the question would be

rate-limit output access-group rate-limit 0 1000000 93750 187500 conform-action
transmit exceed-action drop

Verification with rate-limiting can be done with 'show int fa0/0 rate-limit'

vlan filter

Consider the following scenario where routers 1,2 and 3 are connected on a common LAN segment. All routers are in a common RIP domain.

The requirement is for Routers 2 and 3 to not accept ANY routes from R1 WITHOUT changing the config on R2 and R3!

A solution here is to use a vlan filter on the intermediate switch.
My first attempt was to apply the following (incorrect) configuration.

access-list 1 permit 224.0.0.9

vlan access-map DROP_RIP permit 10
match ip address 1
action drop
vlan access-map DROP_RIP permit 20

vlan filter DROP_RIP vlan 232

With the above config ALL RIP neighbor adjacencies were lost!!! The problem was the access list i had used. A more targetted ACL is required to only drop RIP traffic from Router 1.

The following ACL achieves the requirement.

access-list 100 permit udp host 192.10.1.254 any eq rip

This question also got me thinking on how it would be possible to block other routing protocols of the switch.

The equivalent access list entries for EIGRP, OSPF and BGP are as follows......

Extended IP access list 100
20 permit eigrp host 50.0.0.254 any
30 permit ospf host 50.0.0.254 any
40 permit tcp host 50.0.0.254 any eq bgp

50 permit tcp host 50.0.0.254 eq bgp any

RIP - Versions 1 and 2

Most RIP scenarios these days are based on version 2. That is RIP updates are multicast to ip address 224.0.0.9. In RIP version 1 updates are broadcast to 255.255.255.255.

By default RIP sends updates in version 1 but is capable of receiving up dates in version 1 and 2.

When the 'version 2' command is entered at the router config prompt RIP only then sends and receives in version 2.

If a requirement arises where another router requires version 1 updates, whilst not changing the version 2 operation of the router, this poses a problem. This can be overcome by manipulating the sent and received RIP version on an interface level. This overrides the config router commands.

Here i enable the router to send rip version 1 and 2 updates out of interface fa1/0.

int fa1/0
ip rip send version 1 2

Use the show ip protocol command for verification.

FRTS versus MQC FRTS - Part II

Following on from part I i know introduce a further requirement to set the frame-relay discard eligibility bit on all non critical frames (non DSCP 5).

For consistency i apply this on R4 using traditional FRTS on R4 and then using MQC FRTS on R5.

R4

1) i create a new class DSCP5 matching the critical traffic
2) I create a policy-map FR_405 that only sets the de bit for the non-critical frames
3) Finally within the pre-existing frame-relay map-class RICH i reference the new policy-map.

class-map match-all DSCP5
match dscp cs5

policy-map FR_405
class DSCP5
class class-default
set fr-de

map-class frame-relay RICH
frame-relay cir 768000
frame-relay bc 7680
service-policy output FR_405
frame-relay fragment 960

For verification is use the 'show frame-relay pvc 405' command

R4#s frame-relay pvc 405

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 169 output pkts 175 in bytes 21260
out bytes 18308 dropped pkts 6 in pkts dropped 6
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 30
out bcast pkts 112 out bcast bytes 13140
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:17:45, last time pvc status changed 00:16:05
service policy FR_405
Serial2/0: DLCI 405 -

Service-policy output: FR_405

Class-map: DSCP5 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group 100
0 packets, 0 bytes
5 minute rate 0 bps
Match: dscp cs5 (40)
0 packets, 0 bytes
5 minute rate 0 bps

Class-map: class-default (match-any)
30 packets, 3169 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
fr-de
Packets marked 30
Output queue size 0/max total 600/drops 0
fragment type end-to-end fragment size 960
cir 768000 bc 7680 be 0 limit 960 interval 10
mincir 384000 byte increment 960 BECN response no IF_CONG no
frags 175 bytes 18308 frags delayed 0 bytes delayed 0

shaping inactive
traffic shaping drops 0


On R5

As on R4 the first 2 steps are identical: i create a new class and policy map. I then reference the new policy map from within the pre-existing service-policy RICH. Nested service policies!!!:-)

class-map match-all DSCP5
match dscp cs5


policy-map FR_405
class DSCP5
class class-default
set fr-de

policy-map RICH
class class-default
shape average 768000 7680
service-policy FR_405


For verification i use the 'show policy-map int s2/0.54' command.

R5#s policy-map int s2/0.54

Serial2/0.54

Service-policy output: RICH

Class-map: class-default (match-any)
1 packets, 84 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/768000 1920 7680 7680 10 960

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 1 84 0 0 no

Service-policy : FR_405

Class-map: DSCP5 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: dscp cs5 (40)

Class-map: class-default (match-any)
1 packets, 84 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
fr-de
Packets marked 3


Both methods achieve the same result!

FRTS versus MQC FRTS - Part I

MQC FRTS (Modular Quallity Of Service Command Line Interface Frame Relay Traffic Shaping!) has become mainstream in IOS 12.4. This enables FRTS to conform to the same MQC standard method of configuration.

In the following example i use FRTS on the spoke routers with the equivalent MQC FRTS configuration on the hub router.

Spoke Router Config

map-class frame-relay RICH
frame-relay cir 768000
frame-relay bc 7680
frame-relay fair-queue
frame-relay fragment 960

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 405
class RICH


Hub Router Config

policy-map SHAPE
class class-default
shape average 768000 7680 0

interface Serial2/0.35 multipoint
service-policy output SHAPE
interface Serial2/0.54 multipoint
service-policy output SHAPE

Points of note
1) For the shaping within MQC this requires the configuration to be done under the class class-default.
2) If required the class-default can reference another policy map, via the service-policy command. In this way CBWFQ or LLQ can also be introduced.
3) the 'shape average 768000 7680' command equates to the 'frame-relay cir 768000' plus the 'frame-relay bc 7680' command.

For verification use 'show traffic-shape' for FRTS and 'show policy-map' for MQC FRTS

e.g.

s traffic-shape

Interface Se2/0.35
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
503 768000 6048 768000 0 63 6048 -


s policy-map int s2/0.54

Serial2/0.54

Service-policy output: SHAPE

Class-map: class-default (match-any)
22 packets, 242 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/768000 960 7680 0 10 960

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 22 242 0 0 no

rip - neighbor filtering options

In the above topology i want R6 to only allow routes from R2. Similarly i want R2 to only allow routes from R6.

To meet this requirement i use different methods on each router to achieve the same net result. Both methods require use of the distribute-list command.

On R6 i use and extended acl to first deny the RIP neighbors i do not require and allow the rest. On R2 i make use of the distribute-list gateway command in conjunction with a prefix-list to only allow the neighbors i require.

R6

router rip
version 2
network 54.0.0.0
network 150.1.0.0
network 204.12.1.0
distribute-list 100 in
no auto-summary
!

access-list 100 deny ip host 54.1.7.254 any
access-list 100 deny ip host 204.12.1.254 any
access-list 100 permit ip any any

R2

router rip
version 2
network 204.12.1.0
distribute-list gateway RICH in
no auto-summary
!
ip prefix-list RICH seq 5 permit 204.12.1.6/32

The IP prefix-list in the distribute-list gateway statement allows prefixes to be filtered as they are received based on the source of the update. This allows updates learned from BB3 to be denied, but still allows updates to be received from R6.

Frame Relay - End to End Keepalives

Frame Relay keepalives allow end to end monitoring of a frame-relay circuit. This enables the local DLCI status to represent the status of the end to end ciruit.

To enable it has to be configured within a frame relay map-class - so its no good looking under the frame-relay sub interface!!

map-class frame-relay DLCI504
frame-relay end-to-end keepalive request

interface s2/0.54
frame-relay class DLCI504

To verify use the command 'show frame-relay end-to-end keepalive'

End-to-end Keepalive Statistics for Interface Serial2/0 (Frame Relay DTE)

DLCI = 504, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 91, Receive Sequence Number: 255
Configured Event Window: 3, Configured Error Threshold: 2
Total Observed Events: 111, Total Observed Errors: 38
Monitored Events: 0, Monitored Errors: 0
Successive Successes: 0, End-to-end VC Status: UP

IP Telephony

In this post an ip phone is attached to fa0/5 on a switch. The requirement is for the switch to mark the voice vlan as 10 and data as 100. The COS value from the phone should be trusted and the switch needs to instruct the phone to assign cos value of 1 to data.

mls qos
vlan 10

int fa0/5
switchport voice vlan 10
switchport access vlan 100
mls qos trust cos
switchport priority extend cos 1N.B. unlike data, when a voice vlan is assigned on an interface the vlan is NOT automatically created on the switch.
N.B.B without any instruction, the cisco phone will mark all data packets with a COS value of 0.

The necessary config for voice on a 3560 can be cribbed from the 'VOICE Vlan' section under the 3560 configuration guide.

Traffic Filtering - Without an ACL

There is a requirement for R2 to filter traffic to and from neighboring routers R1 and R3. The catch however is that an ACL cannot be used. An unlikely scenario in the real world, but there again something that may be thrown up in a CCIE lab.


R1 ---------------(fa1/0) R2 (fa1/1)--------------- R3


To acheive this a service-policy can be used.


class FROM_R1
match input-interface fa1/0

class FROM_R3
match input-interface fa1/1

policy-map TO_R1
class FROM_R3
drop

policy-map TO_R3
class FROM_R1
drop

int fa1/0
service-policy output TO_R1

int fa1/1
service-policy output TO_R3


Another scenario that might lead to use of a service policy to filter traffic is when an acl cannot be used in isolation to achieve the required filtering results.
For example the requirement may be drop icmp echo and echo replies with a packet length between 300 and 350.

This functionality cannot be achieved using an ACL alone: there is no way of matching on packet length in an acl.
However packet length can be matched in a class map.

Hence

ip access-list ext 101
permit icmp any any echo
permit icmp any any echo-reply

class-map match-all ICMP
match access-group 101
match packet length min 300 max 250

policy-map ICMP
class ICMP
drop

int fa0/0
service-policy input ICMP
service-policy output ICMP

Frame Relay Traffic Shaping - Part II

In this post i look at applying WRED within the frame-relay traffic shaping construct.

Assume interface s2/0 already has frame-relay traffic shaping enabled.

interface Serial2/0
bandwidth 1544
ip address 174.1.145.4 255.255.255.0
ip pim sparse-dense-mode
encapsulation frame-relay
delay 2
serial restart-delay 0
no fair-queue
frame-relay class FR
frame-relay traffic-shaping
frame-relay map ip 174.1.145.1 401 broadcast
frame-relay map ip 174.1.145.4 401
frame-relay map ip 174.1.145.5 401 broadcast
end

The frame-relay map class FR is already applied

map-class frame-relay FR
frame-relay cir 128000
frame-relay bc 16000
frame-relay adaptive-shaping becn
frame-relay fecn-adapt

At this point there is a requirement to apply WRED to IP packets with 'critical' ip precedence. As denoted in an earlier post of mine this can be achieved within MQC via application to a service policy that either has 'bandwidth' applied or must be done in the 'class default' with fair-queue applied. As there are no bandwidth requirements here i use the 'class default' option.


policy-map WRED
class class-default
fair-queue
random-detect
random-detect precedence 5 60 90 5

With the above parameters ip packets with a priority of 5 will start to be dropped once the queue size reaches 60. Once the queue size reaches 90, 1 in 5 packets will be dropped.

To apply a policy to a frame-relay map the same method is used as applying to an interface.

Thus

map-class frame-relay FR
service-policy output WRED

Once applied use the 'show frame-relay pvc' command to examine the settings.

Rack1R4#s frame-relay pvc 401

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 329 output pkts 294 in bytes 26959
out bytes 18027 dropped pkts 16 in pkts dropped 16
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 198 out bcast bytes 11496
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
Shaping adapts to BECN
pvc create time 00:26:31, last time pvc status changed 00:24:52
cir 128000 bc 16000 be 0 byte limit 2000 interval 125
mincir 64000 byte increment 2000 Adaptive Shaping BECN
pkts 212 bytes 12481 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
service policy WRED
Serial2/0: DLCI 401 -
Service-policy output: WRED

Class-map: class-default (match-any)
187 packets, 11007 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 16
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9

class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 0/0 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 60 90 1/5
6 72/4237 0/0 0/0 32 40 1/10
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10


Output queue size 0/max total 600/drops 0

BGP Next Hop

With iBGP the next hop for the advertised route is changed to match the address of the advertising router.

With eBGP the next hop is unchanged based on the assumption that the receiving router must have reachability to the eBGP peer address. If this assumption is incorrect there are a number of commands that can be used to manipulate the next hop address associated with the route.

The simplest of these is
neighbor a.b.c.d next-hop-self

This will change the next hop for all advertised routes to the local router address.

If more garnularity is required or you are prohibited from using 'next-hop-self' then route maps can be used to influence the next hop of advertised routes.


route-map TO_R4
set ip next-hop peer-address