NMC DOiT Vol.2 Scenario 18 - BGP Synchronization + BGP network route-map + tunnel mode ipsec ipv4 + 3550 flowcontrol + Fair-queueing In Class-Default
More notes continued from the previous post.
- We’re probably all familiar with the fundamental rule of BGP synchronization. BGP will not advertise a route to a neighbor, unless that route already lives in the RIB via some other IGP. In other words, if you have synchronization enabled, learning a route via BGP isn’t enough - the route must also be known by an IGP. But there’s another rule of synchronization that I didn’t know. If the IGP is OSPF, the router ID (RID) of the autonomous system boundary router (ASBR) must equal the RID of the IBGP speaker advertising that route. If the RIDs are mismatched, then BGP assumes synchronization is broken, and the route will not be advertised to a BGP neighbor. So go ahead and wrap your brain around that one. Heh…it had me scratching my head for a while.
- The BGP network statement accepts a “route-map” option that allows you to (among other things) attach BGP attributes to a route as it’s originated into the BGP AS.
- You can create a tunnel interface that functions in tunnel mode “ipsec ipv4″, meaning that you don’t have to nest IPSEC in a GRE interface anymore. Check out this code for a simple DES tunnel between R2 and R5.
R2:
crypto isakmp policy 10
hash md5
authentication pre-share
crypto isakmp key doit address 151.10.100.5
!
crypto ipsec transform-set VPN25 esp-des esp-md5-hmac
!
crypto ipsec profile VPN25
set transform-set VPN25
!
interface Tunnel25
ip address 151.10.50.2 255.255.255.0
ip rip advertise 10
tunnel source 151.10.100.2
tunnel destination 151.10.100.5
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN25R5:
crypto isakmp policy 10
hash md5
authentication pre-share
crypto isakmp key doit address 151.10.100.2
!
crypto ipsec transform-set VPN25 esp-des esp-md5-hmac
!
crypto ipsec profile VPN25
set transform-set VPN25
!
interface Tunnel25
ip address 151.10.50.5 255.255.255.0
ip rip advertise 10
tunnel source 151.10.100.5
tunnel destination 151.10.100.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN25 - In the context of a Cat3550 switch, if the task asks you to do something with “pause link operation” frames, you need to be working with interface “flowcontrol“.
- If a QoS task asks you to configure “preferential treatment of interactive traffic” in traffic that will be in class-default of CBWFQ, they want you to turn on “fair-queue” for class-default. Class-default is the only class in which you can turn on fair-queue…all other classes are FIFO within the class, although the classes as a whole are queued via fair-queuing.
More in the next post, later tonight…

One Response to “NMC DOiT Vol.2 Scenario 18 - BGP Synchronization + BGP network route-map + tunnel mode ipsec ipv4 + 3550 flowcontrol + Fair-queueing In Class-Default”
December 1st, 2007 at 5:53 pm
It is interesting that if ‘service policy’ with ‘bandwidth percent’ statement applied to ‘map-class frame-relay’, percentages of minCIR are reserved.
minCIR by default is CIR/2.
I use following approach to resolve QoS task in this lab:
policy-map OUTER_MAP
class class-default
shape average 125000
shape adaptive 32000
service-policy MARKING #bandwidth reservation and marking statement
map-class frame-relay R1_QOS
service-policy output OUTER_MAP
int s0/0.124
frame-relay interface-dlci 102
class R1_QOS
frame-relay interface-dlci 104
class R1_QOS
This MQC implementation work without enabling frame-relay traffic-shaping on interface.
But unfortunally this configuration is not fully correspond to task, because ‘shape adaptive’ value reacts to BECN received, but task says: speed down if interface congestion occurred(this can be done only with FRTS commands).
Leave a Reply