Thursday, May 13, 2010

INE Workbook Vol 1 QoS

The hardware output queue is also known as the TX ring, and is configurable under the interface level 'tx-ring-limit' command. This is a FIFO queue only and is used prior to the software queue being used (hold-queue command).

HDLC header is 4 bytes.

In custom queueing, routing update packets need to be manually mapped to custom queue 0 unless the interface is running frame-relay as f/r uses the special broadcast queue for multicast routing updates. To calculate the custom queue sizes, simply divide the desired share count by the packet size, normalize by dividing each queue by the smallest packet value and round up. Now that you have your share amount, simply multiply the packet sizes by the share amount to create the queue size.

RTP Voice requires 30% of the traffic with a queue size of 60 bytes. Account for HDLC overhead for a total of 64. Divide 30/64 = .46875. To normalize we divide by the smallest amount (not shown here) of .096 giving us a result of 4.88 for RTP. Round up and you get a share count of 5. Now to enter the queue size, multiply 5 by the packet size of 64 for a result of 320.Overall, not too difficult. Just need to memorize the formula...

'show queue [interface] [slot/port] [queueID]' will show you the queue contents.

'queue-list 1 lowest-custom 2' will set the round robin scheduler to begin at queue 2 meaning both queue 0 (default priority) and queue 1 will be treated as priority queues.

IP routing updates are sent with a precedence of 6. So to prevent routing packets from being dropped using WRED, set the hold-queue size to something like 10, and set random-detect for prec 6 to something larger than your hold-queue size.

Selective Packet Discard?!? WTH is SPD?!? Well, it's the queue management technique for interface input queuing. The SPD commands are hidden, but you can view them in the running config. Here are some of the commands:


spd extended-headroom 150
spd headroom 120
ip spd mode aggressive
ip spd queue threshold minimum 75 maximum 150


This enables SPD in aggressive mode, increases the memory headroom to 150 (for IGP), increases the headroom for BGP to 120 and sets the thresholds to min 75 max 150. You also need to set the input queue on the interface to match. Aggressive mode simply means the router will drop malformed packets, instead of placing them in the hold queue. 


You can create a hierarchical rate-limit structure on an interface using a 'continue' statement following the rate-limit commands.


Ah - rate limit ACLs, such a thorn in my side. Each rate-limit ACL can contain just one line. The purpose of these ACLs is to create high-performance rate-limiting configurations. The biggest point here is to remember to use rate-limit ACLs and not standard ACLs - but would standard ACLs be accepted in the lab since they would accomplish the same goal? IP Prec based rate-limit ACLs are fun because they can be based on a mask value.To start off, you have 8 possible precedence values, 0 - 7.


[p7] [p6] [p5] [p4] [p3] [p2] [p1] [p0]


So if we want to check for prec values 1,2 and 4 we would re-draw it like this.


0 0 0 1 0 1 1 0


Now you turn that binary to hex to receive a hex value of 16, and that is your mask. I always want to take the prec values, turn those into binary and then convert to hex. Another thing to remember...


I made a mistake doing frame-relay traffic shaping. I accidentally set the Be value to the rate, so for a burst of 384k with a Tc of 10, I set Be value to 3840. Wrong answer! This is EXCESS of the CIR. With a CIR of 256k, the correct answer would have been 1280. It totally makes sense, but little things like that can really screw you up in the exam.


You can change the per-VC FIFO queue depth under the map-class using the frame-relay holdq command. In addition, you can set the physical interface queue depth using the standard hold-queue command.


Legacy QoS configuration packet sizes include the full layer 2 packet length. So if you need to filter packets based on a 60 byte packet, you actually need to configure 64 bytes to account for the 4-byte cisco frame-relay header.


PVC Interface Priority Queueing can prioritize certain DLCI's over other DLCIs. First, assign a map-class to a priority queue, and then attach the map-class to the DLCI. You also need to enable PIPQ by entering 'frame-relay interface-queue priority' interface command. 


You can use DLCI-based Frame Relay Priority feature to forward traffic out different DLCIs based on priority level.The command is frame-relay priorty-dlci-group [x] [high] [med] [norm] [low] where x is the list # and high, med, norm, low are queue levels that the circuits are mapped to. In short, you map priority-queues to DLCIs.



interface Serial0/1
 bandwidth 128
 ip address 155.1.45.4 255.255.255.0
 encapsulation frame-relay
 no keepalive
 priority-group 1
 clock rate 128000
 frame-relay priority-dlci-group 1 100 200 200 200
 frame-relay map ip 155.1.45.5 100 broadcast
 frame-relay interface-dlci 100
 frame-relay interface-dlci 200
 max-reserved-bandwidth 100
priority-list 1 protocol ip high udp rip
priority-list 1 protocol ip low list 101
priority-list 1 protocol ip medium list 102
priority-list 1 protocol http normal
priority-list 1 protocol ip high lt 64
priority-list 1 queue-limit 5 40 60 80



In the above example, RIP and packets <= 64 bytes are sent out DLCI 100, all other traffic is sent out DLCI 200.


On to frame-relay switching and policing. Frame relay switching was pretty easy for me to handle. You can either use the 'connect' global command or the interface 'frame-relay route' command. Also, you can apply classes to switched PVC's - just add the keyword 'switched' to the interface-dlci command.


Know how to use both in the event you are prevented form using one of them. The policing aspect was new. This functions much like the traffic shaping. Enable policing with 'frame-relay policing'. From there you can apply map-classes to the DLCIs. The one important point is to use the 'in' keyword when performing frame-relay policing. Below are the pertinent configs.



interface Serial1/2
 ip address 155.1.13.3 255.255.255.0
 ip rip advertise 10
 encapsulation frame-relay
 serial restart-delay 0
 clock rate 128000
 frame-relay map ip 155.1.13.1 133 broadcast
 frame-relay interface-dlci 132 switched
  class R1
  load-interval 30
 frame-relay interface-dlci 133
 no frame-relay inverse-arp
 frame-relay intf-type dce
 frame-relay route 132 interface Serial1/3 231
 frame-relay policing
 frame-relay congestion-management
  threshold ecn 3
  threshold de 5
!

map-class frame-relay R1
 frame-relay cir in 64000
 frame-relay bc in 8000
 frame-relay be in 8000

Well, I think that is enough for this section. Next section will include MQC related commands.....

Monday, May 10, 2010

INE Workbook Vol 1 IPv6

Unique Local Addressing replaces Site Local addresses. ULA is RFC 4193 and similar to the use of RFC1918 address space. The format is as follows:

FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) + Interface ID (64 bits)

FC00 is a given. The unique ID is totally random and avoids address collisions. Think of the Link ID as the subnet and the Interface as the actual IP address in IPv4 terms.

Globally Routable addresses start with the binary prefix 001 and thus encompass the range 2000 - 3FFF. Currently, only the 2001::/16 is used for allocation.

Remember that the EUI-64 address is constructed by inverting the 7th u/l bit and inserting FFEE in the middle. Mine below is a little funky because of dynamips but the concept is the same. Since we have trailing 0's, we simply end up with FFFE19:0


R1#sh int Fast0/0 | i Hardware      
  Hardware is Gt96k FE, address is c200.0619.0000 (bia c200.0619.0000)
R1#sh ipv int br | s FastEthernet0/0
FastEthernet0/0            [up/up]
    FE80::C000:6FF:FE19:0
    2001:1:0:146:C000:6FF:FE19:0
R1#


You can configure specific prefixes for IPv6 neighbor discovery advertisements. By default, all prefixes are advertised. Doing so, you can configure one to disable autoconfig. Very important to remember to enable ipv6 unicast-routing and un-suppress router advertisements on ethernet interfaces.

interface FastEthernet0/0
 ip address 155.1.58.5 255.255.255.0
 ip rip advertise 10
 speed 100
 full-duplex
 ipv6 address FC00:1:0:58::5/64
 ipv6 address FC00:1:0:85::5/64
 ipv6 nd prefix FC00:1:0:58::/64 14400 14400 no-autoconfig
 ipv6 nd prefix FC00:1:0:85::/64 14400 14400
 ipv6 nd ra interval 40
 ipv6 nd ra lifetime 60
 no ipv6 nd suppress-ra


After spending way too much time, I discovered that 'clear ipv6 route *' doesn't work for RIP like IPv4. Instead, do this.


R5(config)#do clear ipv6 rip RIPNG


...and ta-da my filtered route disappeared. Stupid things like this could really trip you up in the lab.


Interesting note that EIGRPv6 has the option 'no ipv6 next-hop-self eigrp'.This is used on the hub router  and explicitly sets the next hop field in the relayed EIGRPv6 updates to the spoke's router IP address.


OEQ Alert: EIGRPv6 cannot do unequal cost load balancing based on the limitations of CEF6. You can load balance across links of different metrics, but only equally (1 to 1). You configure this just like IPv4 - using the variance command.


There are two ways to originate a default route in EIGRPv6 - using a summary address (with an automatically computed metric and an AD of 90) and using redistribute (with an AD of 170 but you can explicitly set the metric). Currently, there is no leak-map option.


With IPv6 NAT-PT, both source and destination addresses of every packet must be rewritten.A block of IPv6 addresses will represent the IPv4 address space. This block is usually /96 in length to cover all 2^32 IPv4 addresses but could otherwise be arbitrary. IPv6 NAT-PT requires 3 items:
1. Rules to translate IPv4 to IPv6
2. Rules to translate IPv6 to IPv4
3. THe /96 prefix to map the IPv4 address space to. (using ipv6 nat prefix)


So in short, enable 'ipv6 nat' under the respective interfaces, create the NAT rules, enter the nat prefix and route as appropriate.



R6(config-subif)#int f0/0.67
R6(config-subif)#ipv6 nat
R6(config-subif)#int f0/0.146
R6(config-subif)#ipv6 nat

R6(config)#ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7
R6(config)#ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404
R6(config)#ipv6 nat prefix 2000::/96

R6(config)#ipv6 router rip RIPNG
R6(config-rtr)#redistribute connected 
...
SW1(config)#ipv6 route 2000::/96 fc00:1:0:67::6


Nothing really all that new here. It is just important to map the source addresses and enter the NAT prefix.


It is very important to remember IPv6 is represented in hex and not binary. So when converting 11 to binary, remember it's 11 in HEX to binary which is 17 in decimal notation.


IPv6 multicast addresses are the range FF00::/8. The first 8 bits are the multicast address, then four bits each for flags and scopes, leaving 112 bits for group ID. The first 3 flag bits are unused and set to 0. The fourth bit is the transient bit and indicates permanent or temporary. If permanent, this bit is set to 0. Examples of permanent are ff02::2 (all routers) and ff02::6(OSPF DR routers). The remaining four bits are the scope ID bits. There are 16 combinations and not all are in use.


There is no dense mode in IPv6 multicast. As soon as you type 'ipv6 multicast-routing', PIMv6 is enabled across all IPv6 capable interfaces, and must be explicitly disabled. MLD has replaced IGMP. IPv6 multicast uses tunnel to connect the router to the RP. This tunnel is only used for the registration process and then the receivers switch to the optimal path. Use 'show ipv6 pim tunnel' to view these tunnels.


'show ipv6 pim range-list' will show the mappings of RPs to the multicast group ranges.

IPv6 embedded RP gave me nothing but trouble. I just couldn't get it to work after verifying all my unicast routes, my RPF interfaces, and double-checking my configs. I guess I'll need to lab this up some more. From the multicast address ff76:0640:2001:cc1e::8, you can derive the pertinent RP address. 2001:cc1e:: will be the prefix. 0640 includes a 0, 6 is the RP interface-ID, and LL is an 8-bit prefix length, giving you an RP of 2001:cc1e::6/128. The router to be the RP must have a loopback interface with this address, and be reachable via IGP routing protocols.

FF3x::/96 is the IPv6 SSM range.

IPv6 tunnels use protocol 41 for transport. Be careful with access-lists as there is no keyword available is IOS extended access-lists.

The format of 6to4 IPv6 addresses are as follows:
2002 (16 bits):IPv4 address (32 bits):Subnet ID(16 bits):Interface ID (64 bits)

So, 150.1.3.3 becomes 2002:9601(150 = 96 hex, 01 = 1 hex):0303(3 = 3 hex, 3 = 3 hex):: From there, assign 2002:9601:303::3 to your tunnel interfaces, and use 2002:9601:303:1::3 for your loopback. Now route 2002::/16 out your tunnel interfaces and everything should fire away!

ISATAP is another automatic 6to4 tunneling mechanism. ISATAP constructs the interface ID of the IPv6 address based on the IPv4 address of a host using EUI-64 address rules. If you use prefix 2001:1:0:345::/64, then R3 will have the following IP:

2001:1:0:345:0:5efe:9601:0303/64

Since ISATAP cannot automatically extract the destination (tunnels are more for transport), you must use static routes.

Neither tunnel mechanisms are hard to complete, it's just remembering how to construct the IPv6 address. Hopefully this is something easy enough that you can look it up in the DocCD and get an easy 2 -3 points.

Well, that is it for IPv6. Overall, not too bad. There are just a few gotcha's like remembering to enable IPv6 router advertisements, and enabling eigrp under the process, creating your static routes for tunnels, etc. That is about all for my lab for today. Now I am off to prep  my lab for the next section of the workbook - QoS and prepare for the IPexpert vSeminar this afternoon.

Monday, May 3, 2010

EIGRP Unequal Cost Load Balancing...

Sat for one of IPexpert's awesome vLecture series this morning. The topic was EIGRP and I brought up this exact scenario. Thanks to Tyson for working this up into a blog post. Very helpful.

http://blog.ipexpert.com/2010/05/03/eigrp-unequal-cost-load-balancing/

In short, the lesson is to know and memorize the formula...

(accumulated delay/10 + 10^7/bandwidth in kb) x 256 = metric

...I think I might get a blackboard and some chalk and write this formula 1,000 times.....

EIGRP Metric & K-Values

http://blog.ipexpert.com/2010/03/03/eigrp-metric-k-values/

Friday, April 30, 2010

INE Workbook Vol 1 IPv4 Multicast

Well, on to IPv4 multicast which I'm learning pretty well. This is about my fourth foray into IPv4 multicast. My troubles come with IPv6 multicast, which comes later. Here are some of my notes/scenarios regarding multicast...

You can easily troubleshoot multicast RPF failures using 'debug ip mpacket' in conjunction with 'no ip mroute-cache' on all multicast interfaces in the path. In short, multicast RPF failures happen when multicast traffic follows a different path than the unicast traffic. Fixing it is as easy as adding a host mroute for the source, and pointing it to the correct interface/next hop.

Here on R5, the Incoming interface is null for R6.

(155.1.146.6, 224.10.10.10), 00:00:54/00:02:05, flags: 
  Incoming interface: Null, RPF nbr 155.1.45.4
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:00:54/00:00:00
    Serial0/0, Forward/Dense, 00:00:54/00:00:00

Obviously this is not correct. The unicast is pointing to the PtP link between R4 and R5, which is not PIM enabled.

R5(config-if)#do sh ip route 155.1.146.6
Routing entry for 155.1.146.0/24
  Known via "eigrp 100", distance 90, metric 2172416, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets
  Last update from 155.1.45.4 on Serial0/1, 00:08:14 ago
  Routing Descriptor Blocks:
  * 155.1.45.4, from 155.1.45.4, 00:08:14 ago, via Serial0/1
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Let's fix that. Since the PtP is not multicast enabled, we will add a route that forces multicast traffic for 155.1.146.6 to transverse the FR which is multicast enabled.

R5(config)#ip mroute 155.1.146.6 255.255.255.255 155.1.0.4

And test/verify.

R6#ping 224.10.10.10


Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds:


Reply to request 0 from 155.1.108.10, 76 ms


R5(config)#do sh ip mroute
......


(155.1.146.6, 224.10.10.10), 00:00:18/00:02:46, flags: T
  Incoming interface: Serial0/0, RPF nbr 155.1.0.4, Mroute
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:00:18/00:00:00

Well that looks better!! Moving on...

I got a little tripped up by some sparse-mode RPF failures. I added a static mroute which fixed the issue, but the issue can also be caused by differences in unicast IGP routes. For instance, when setting the the RP on R5 Loopback0, the issue is caused because OSPF announces the routes as /32 (to R6) but R4 (the router that sends the RP register message) sees the route as /24 in EIGRP. Simply adding 'ip ospf network point-to-point' on R5 Lo0 fixes the problem. Now both EIGRP and OSPF routers see 150.1.5.0/24.

The PIM Assert procedure dictates who will flood the multicast traffic on a shared segments. The Assert procedures takes into account the AD and the metric, and if all else fails, the highest IP address. So if two ethernet-connected routers have different IGPs, the one with the lowest IGP AD will be the assert winner. I misinterpreted the task and adjusted the DR, which deals with is responsible for multicast source registration and not multicast flooding. Ugh....You should be able to 'show ip mroute x.x.x.x' and see the A flag. You can also 'debug ip pim' to see the Assert messages. Unfortunately, none of these were working for me. First, I thought it was because we switched to SPT trees. Easy enough, set the spt threshold to infinity. That still didn't work. Clear IP mroute. nope. Reboot routers, nope. I could not get anything to work. R4 didn't prune the traffic, none of my routers on the shared segmet showed the A flag, and debug ip pim never showed assert messages. I need to do some more research on this one...perhaps it's dynamips, or maybe my IOS version....moving on....

To limit (*,G) towards an RP address, specify the following:

ip pim accept-rp 150.1.5.5 5
access-list 5 permit 224.10.10.10
access-list 5 permit 224.110.110.110

This will limit groups 224.10.10.10 and 224.110.110.110 for rp 150.1.5.5. This does not affect SPT joins. This is different than the accept register, which limits the sources that can register with the RP and thus this is configured on the RP.

When doing AUTO-RP, you can load-balance and provide redundancy. This is possible using longest match. For instance, we can select SW2 as the RP candidate for groups 224.0.0.0/5 and SW4 as the RP candidate for groups 232.0.0.0/5. Here are the pertinent access-lists on SW2 and SW4.

SW2(config-std-nacl)#do sh ip access-list RPs
Standard IP access list RPs
    30 deny   224.110.110.110
    10 permit 224.0.0.0, wildcard bits 7.255.255.255
    20 permit 224.0.0.0, wildcard bits 15.255.255.255
SW2(config-std-nacl)#


SW4(config-std-nacl)#do sh ip access-list RPs
Standard IP access list RPs
    30 deny   224.110.110.110
    10 permit 232.0.0.0, wildcard bits 7.255.255.255
    20 permit 224.0.0.0, wildcard bits 15.255.255.255

By way of the second entry, both candidates can be the RP for all groups (except 224.110.110.110) in the event the other fails.

In working with BSR, you can load-balance based on the hash value. Now, to figure this out requires some mathematics, but by default the group IP address is ignored, making this rather easy. If you select a hash of 31 (255.255.255.254), we will load balance between even and odd. Evens will go to one RP, odds will go to another. Now, they could make this very tricky but computing the hash based on a specific group address. 'show ip pim rp-hash x.x.x.x' will show you the hash values for a particular group as such...

R4#sh ip pim rp-hash 239.1.1.2
  RP 150.1.8.8 (?), v2
    Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:04:14, expires: 00:02:25
  PIMv2 Hash Value (mask 255.255.255.254)
    RP 150.1.10.10, via bootstrap, priority 0, hash value 1093093598
    RP 150.1.8.8, via bootstrap, priority 0, hash value 1364246456

Even groups are sent to 150.1.8.8 based on the hash value....

R6#sh ip pim rp-hash 239.1.1.1
  RP 150.1.10.10 (?), v2
    Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:03:28, expires: 00:02:09
  PIMv2 Hash Value (mask 255.255.255.254)
    RP 150.1.10.10, via bootstrap, priority 0, hash value 989207280
    RP 150.1.8.8, via bootstrap, priority 0, hash value 718054422

Odd groups are sent to 150.1.10.10 based on the hash value.

The next section required that R6 not learn any RP information. I though of multicast boundary. Good news! With BSR - it's even easier.

'ip pim bsr-border' on both R1 and R4. Now R6 will not hear any RP announcements!

To setup multicast stub routing requires the use of the ip igmp helper-address command. Additionally, set a neighbor filter on the pertinent interfaces so that  downstream devices never become PIM neighbors and enable dense mode on all downstream interfaces.

Bi-dir PIM can be enabled pretty easy. It's a simple concept. Bi-dir multicast means many devices will be senders and receivers. You will need a bidir capable RP (through static, BSR or autorp) and enable bidir pim on all your multicast routers. Keep in mind that there are no register messages in bidir pim because devices can send or receive at anytime (think videoconferencing).

DVMRP! I had no idea this was even on the blueprint, but it's covered in Volume 1.DVMRP functions much like RIP and uses a hop count metric. This information is only used for RPF checks and not actual routing which remains with PIM/IGP routing protocols.

First, enable DVMRP interoperability within the router, and then enable the interfaces for DVMRP.


R4(config)#ip dvmrp interoperability 

By default, the router will only advertised directly connected subnets. To advertise more information, use the metric command with an access-list and specify the IGP protocol. A metric of 0 will filter out those updates.

R4(config)#access-list 40 permit 155.1.0.0 0.0.255.255
R4(config)#interface f0/1
R4(config-if)#ip dvmrp metric 1 list 40 eigrp 100

You can create a tunnel to the DVMRP cloud. You cannot tunnel between two IOS routers.

R4(config-if)#int tun0
R4(config-if)#ip unn l
R4(config-if)#ip unn lo0
R4(config-if)#ip pim dense-m
R4(config-if)#tunn so lo0
R4(config-if)#tunn dest 204.12.1.100
R4(config-if)#tunn mod dvmr

Now you won't be able to test this in the actual lab or your lab but you can debug  with 'debug ip dvmrp detail' to verify DVMRP updates are being generated.

Ahh....multiprotocol multicast using BGP. This simply involves enabling the ipv4 address-family under BGP. The multicast AF will have separate policies than the unicast AF like AS prepend, metric, etc.

I found a very important troubleshooting command. 'show ip rpf x.x.x.x' will show RPF failures for a particular source address. 'debug ip pim' can helps identify possibly RPF failures. As you also know, mtrace can usually pinpoint exactly where an RPF failure occurs. Also, show ip mroute 224.x.x.x count can show if packets are being received/dropped. I highly suggest reading IP Multicast Troubleshooting. Great read.


To wrap things up is MVR. MVR is a special type of multicast delivery suited for metro Ethernet networks. MVR uses a single dedicated VLAN across the whole ring to deliver multicast feed to all receivers. The actual receivers are in different VLANs but the switches intercept the multicast traffic (IGMP Joins) and pull the multicast feed from the MVR Vlan to the receiver VLAN. This is pretty easy to setup. Here are the pertinent configs.


SW1(config)#mvr
SW1(config)#mvr vlan 146
SW1(config)#mvr group 239.1.1.100
SW1(config)#mvr mode dynamic
SW1(config)#int fa0/1
SW1(config)#mvr type source
SW1(config)#int fa0/5
SW1(config)#mvr type receiver


An important note, you can have no more than 256 groups configured for MVR and they should never alias. Meaning that two multicast IP addresses map to the same multicast address. So you can't enable MVR for 228.1.1.1 and 230.1.1.1. So based on the config, you can see that we enable MVR for Vlan 146 using dynamic mode. Traffic received on Fa0/1 will be delivered to R5 on Fa0/5.


Verify with 'show mvr', 'show mvr interface', 'show mvr members' and 'show ip igmp groups'. Disable mroute cache and debug ip mpacket. You should see traffic arriving from the source interface.


Finally, igmp profiles. This works much like a route map or a vlan map. Should be self explanatory.IGMP profiles apply to transit messages - IGMP messages not destined for the switch directly.


ip igmp profile 1
permit
range 232.0.0.0 232.255.255.255
range 239.0.0.0 239.255.255.255
!
interface fa0/4
ip igmp filter 1


Well, it took me incredibly too long to go through the multicast volume but it's been difficult to find study time with all the traveling and work that I do. In addition, multicast is one of my weaker topics and I plan to re-visit this volume if I have enough time. There are only 10 weeks remaining until my lab attempt...time to get cracking...

Tuesday, April 6, 2010

INE Workbook Vol 1 BGP part Duex

'bgp always-compare-med' should be consistent across the AS. This whole always compare MED is still something that gets me. I created a loopback in both AS100 and AS300 with an identical IP address. In the INE workbook, we need to influence AS 200. Within AS 200, we obviously set 'bgp always-compare-med' to make it consistent across the AS. Then from the neighboring AS's we match the route (the loopback address) and set the metric appropriately. We want to prefer AS 300 over AS 100 so obviously you set the metric/MED higher on AS 100 and clear your bgp outbound policies. Here is the pertinent configs from AS 100 and AS 300. This needs to be present on all routers in AS100 and AS300.

ip prefix-list Lo1 seq 5 permit 1.2.3.4/32

route-map To_R3 permit 10
 match ip address prefix-list Lo1
 set metric 1000
route-map To_R3 permit 20

router bgp 100
 neighbor 155.1.13.3 remote-as 200
 neighbor 155.1.13.3 route-map To_R3 out

And now AS300

ip prefix-list Lo1 seq 5 permit 1.2.3.4/32




route-map To_R3 permit 10
 match ip address prefix-list Lo1
 set metric 100
route-map To_R3 permit 20

router bgp 300
 neighbor 155.1.37.3 remote-as 200
 neighbor 155.1.37.3 route-map To_R3 out

Poof! Everything worked! Yay! I just need to wrap my head around this. It's not difficult, it just necessary to be consistent and configure all pertinent routers. Phew. Moving on....

DMZ Link bandwidth is another of those topics that is not difficult to understand or implement. It's just a matter of putting all the pieces together. First, you need to enable dmz-link bw under both the BGP process and for the ebgp neighbors.

R6(config-router)#router bgp 100
R6(config-router)#nei 54.1.1.254 remote-as 54
R6(config-router)#nei 54.1.1.254 dmzlink-bw
R6(config-router)#bgp dmzlink-bw

That was easy enough - but you need to understand how this works. BGP inserts the bandwidth into an extended community to send to it's neighbors. So that means we need to enable send-community to our iBGP neighbors within the relevant AS.

R6(config-router)#router bgp 100
R6(config-router)#nei 155.1.146.1 send-comm ext

Ok, now we should be collecting bandwidth and sending the data to our peers. BGP does not by default load balance across unequal paths. So now we need to enable that within our AS.

R1(config-router)#router bgp 100
R1(config-router)#maximum-paths ibgp 2

Now we will load-balance across unequal paths within AS 100 based on bandwidth to links in AS54. So now if we view our routes in AS100, we will see multiple paths.


R1(config-router)#do sh ip route | i 204.12.1.254|54.1.1.254
B    119.0.0.0/8 [200/0] via 204.12.1.254, 00:06:06
                 [200/0] via 54.1.1.254, 00:06:06
B    118.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B    117.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B    116.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B    115.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B    114.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B    113.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B    112.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
                 [200/0] via 54.1.1.254, 00:06:07
B       28.119.17.0 [200/0] via 204.12.1.254, 00:06:07
                    [200/0] via 54.1.1.254, 00:06:07
B       28.119.16.0 [200/0] via 204.12.1.254, 00:06:07
                    [200/0] via 54.1.1.254, 00:06:07


Take notice that this affects the routing table and not the BGP table as BGP will always select a best route over all available paths, but you will see multipath in the route details.



R1(config-router)#do sh ip bgp 28.119.16.0
BGP routing table entry for 28.119.16.0/24, version 47
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: eBGP iBGP
  Advertised to update-groups:
        1    2
  54, (Received from a RR-client)
    54.1.1.254 (metric 2560002816) from 155.1.146.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath
      DMZ-Link Bw 250 kbytes
  54, (Received from a RR-client)
    204.12.1.254 (metric 2560002816) from 155.1.146.4 (150.1.4.4)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
      DMZ-Link Bw 12500 kbytes


If you see something in a scenario saying you should only accept routes from directly connected ASes, but you can't use AS-Path filtering, it is a simple command. This is where having exposure to every detail of a protocol will help you.

router bgp 100
bgp maxas-limit 1



You can selectively delete communities received from a neighbor, while still adding your own. First you create an expanded community list, using regex to match the communities you want to delete. Here, we are matching any community that starts with 200:


SW1(config)#ip community-list expanded TST permit 200:[0-9]+_

Now create a route-map, add any communities you would like to add in this AS, and then delete the selected communities and apply the route-map.


SW1(config)#route-map SetComm permit 10
SW1(config)# set comm-list TST delete
SW1(config)# set community 300:200 additive
SW1(config)#router bgp 300
SW1(config-router)#nei 155.1.37.3 send-comm both
SW1(config-router)#nei 155.1.37.3 route-map SetComm in

Here is the end result.


SW1(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 80
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x880
  Advertised to update-groups:
     1          2         
  200 254
    155.1.37.3 from 155.1.37.3 (150.1.3.3)
      Origin incomplete, localpref 100, valid, external, best
      Community: 254:100 300:200




For comparison, here is the same route from R2 in AS200 (which send routes to SW1) and from R6 in AS100 (which SW1 send routes to).



R2(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 99
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        2
  254
    192.10.1.254 from 192.10.1.254 (222.22.2.1)
      Origin incomplete, metric 0, localpref 100, valid, external, best
      Community: 200:123 200:254 254:100



R6(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 48
Paths: (2 available, best #1, table Default-IP-Routing-Table, Advertisements suppressed by an aggregate.)
Flag: 0x880
  Not advertised to any peer
  (65014) 200 254
    155.1.13.3 (metric 27260160) from 155.1.146.1 (150.1.1.1)
      Origin incomplete, metric 0, localpref 100, valid, confed-external, best
      Community: 200:123 200:254 254:100
  300 200 254
    155.1.67.7 from 155.1.67.7 (150.1.77.77)
      Origin incomplete, localpref 100, valid, external
      Community: 254:100 300:200





Another fun scenario was using extended access-lists to match a range of subnets, something that would be much simpler with prefix-lists, but alas, can also be accomplished with extended access-lists. In short, the source in your access-list would be what to match in the network, with the destination matching the subnet mask.

R4(config)#access-list 104 deny 0.0.1.0 255.255.254.0 255.255.252.0 0.0.3.255
R4(config)#access-list 104 permit ip any any

This would deny any route with an odd third octet, with a /22 mask or larger up to a /24. I already know how to match networks based on access-lists, but matching the masks with an access-list is something new. Looking at it, it makes total sense, but something I need to see a few more times to really get a handle on.

Moving on, I stumbled across bgp dampening. Something I always though was pretty easy, but INE presents it differently. "Once a prefix flaps two times in a row, the advertisement should resume in 5 minutes". Most scenarios will specify the actual dampening parameters. Here is the actual formula:

P (t) = P (0) /2^(t/Half_life)

We know that the time we want is 5 minutes.

P(5) = P(0)/2^(5/Half_life)

Now substitute P(5) = 750 (the reuse limit) and P(0) = 2000 (suppress limit). The equation becomes:

200/750=2^(5/Half_life)

From this equation, take the logarithm of the both sides.

Half_life=5*Ln(2)/Ln(200/75) = 3.5 (approx.)

We may now round up to 4. Max suppress time is by default 4 x half_life, giving us the following:

router bgp 200
bgp dampening 4 750 2000 16


Wow. Am I the only one lost? It's been a number of years since I've taken an advanced math class, so I'm guessing that is why I am lost. I'll review this again later, but I would hope Cisco doesn't expect all candidates to be up on advanced math.


The default bgp scanner time is 60 seconds. Keepalive is defaulted to 60 seconds with the holdtime being 180. The BGP scanner is responsible checking validity and reachability of BGP NEXT_HOP attributes, performs conditional advertisement and route injection, imports new routes into BGP table from RIB and performs route dampening. If you receive a scenario to configure BGP to do route injection every 20 seconds, you will need to alter the BGP scan time. Also, setting the advertisement-interval to 0 will remove batch updates and advertise immediately. 


You can adjust the bgp next-hop trigger timers. Remember the BGP scan time is responsible for validity and reachability of the NEXT_HOP attributes. If we use the next-hop trigger timers, we can tune this to be more in line with IGP timers.

That finally wraps up BGP. This took me a while, but I wanted to take my time going through BGP, knowing that it is one of my weaknesses. More to come later from Vol 1.....