We have completed a full, second practice exam for the Version 4 written. This means the CCIE R&S Written Bootcamp class comes with well over 200 practice exam questions now to assist you with this first certification step, or your recertification. Enjoy the new exam, and as always, enjoy your studies!
Summer was in full swing, and it was over 105 degrees Fahrenheit outside. Bob was told it was a “dry heat”, but he thought “so is my oven”. Needless to say, Bob was glad to be in the data center, where the temperature and humidity controls kept it very cold. He had been asked to setup up a basic route-map with BGP, and here is the diagram he worked from.
The goal, was to modify BGP, so that all traffic going towards the 1.1.1.0 network (which is sourced from AS1), traveling either from or through AS23, would only use the 13.0.0.0/24 segment (between R3 and R1), and not use the 10.0.0.0/24 segment (between R2 and R1) as a transit path.
Bob reviewed some of the BGP topics he had recently learned. Here is the list he made of possibilities:
R1 could pre-pend to the AS path for advertisements of the 1.1.1.0/24 prefix when it is sent to R2 from R1. This way, AS23 would see a better path through R3 rather than R2. He tried this using the following on R1:
ip prefix-list JUST-1.1.1.0 seq 5 permit 1.1.1.0/24 route-map PRE-PEND permit 10 match ip address prefix-list JUST-1.1.1.0 set as-path prepend 1 route-map PRE-PEND permit 20 router bgp 1 neighbor 10.0.0.2 route-map PRE-PEND out
Bob cleared the BGP session, just to be sure. Unfortunately, some traffic destined to 1.1.1.0 was still flowing over the 10.0.0.0 network between R2 and R1.
Bob decided to try another approach, and instead of R1 trying to make AS23 think the path on 10.0.0.0 was worse, perhaps he would tell R3 to make the path on 13.0.0.0 look better. He considered weight, but then realized that would only work for R3, and not every other device in AS23. So Bob decided to use local-preference. On R3, he tried using local-preference, to specify that when a BGP update came in from R1 for 1.1.1.0, R3 would set the local-preference to 250 for that prefix, in hopes that this would allow traffic destined for 1.1.1.0 go exclusively through the 13.0.0.0 segment between R3 and R1. Unfortunately, even with this change, Bob noticed that traffic destined to 1.1.1.0 from our through AS23 still crossed on the link between R2 and R1.
Below are the configurations for R1, R2 and R3 along with the relevant show commands.
Can you assist Bob? What can he do? What did he do wrong, if anything?
Post your ideas and comments below!
R1:
version 12.4 hostname R1 interface Loopback0 ip address 1.1.1.1 255.255.255.0 ip ospf network point-to-point interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ip ospf 1 area 1 interface FastEthernet1/0 ip address 13.0.0.1 255.255.255.0 ip ospf 1 area 1 router bgp 1 no synchronization bgp log-neighbor-changes network 1.1.1.0 mask 255.255.255.0 neighbor 10.0.0.2 remote-as 23 neighbor 10.0.0.2 route-map PRE-PEND out neighbor 13.0.0.3 remote-as 23 no auto-summary ip prefix-list JUST-1.1.1.0 seq 5 permit 1.1.1.0/24 route-map PRE-PEND permit 10 match ip address prefix-list JUST-1.1.1.0 set as-path prepend 1 route-map PRE-PEND permit 20
R2:
version 12.4 hostname R2 interface FastEthernet0/0 ip address 10.0.0.2 255.255.255.0 ip ospf 1 area 1 interface FastEthernet0/1 ip address 23.0.0.2 255.255.255.0 ip ospf 1 area 1 router bgp 23 no synchronization bgp log-neighbor-changes neighbor 10.0.0.1 remote-as 1 neighbor 23.0.0.3 remote-as 23 no auto-summary !
R3:
version 12.4 hostname R3 interface FastEthernet0/0 ip address 13.0.0.3 255.255.255.0 ip ospf 1 area 1 interface FastEthernet0/1 ip address 23.0.0.3 255.255.255.0 ip ospf 1 area 1 router bgp 23 no synchronization bgp log-neighbor-changes neighbor 13.0.0.1 remote-as 1 neighbor 13.0.0.1 route-map SET-LOCAL-PREF in neighbor 23.0.0.2 remote-as 23 no auto-summary ip prefix-list LOCAL-PREF-250 seq 5 permit 1.1.1.0/24 route-map SET-LOCAL-PREF permit 10 match ip address prefix-list LOCAL-PREF-250 set local-preference 250 route-map SET-LOCAL-PREF permit 20
Show commands R1:
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 2, main routing table version 2
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 452 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 23 77 73 2 0 0 00:29:01 0
13.0.0.3 4 23 74 74 2 0 0 00:29:01 0
R1#show ip bgp
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
R1#show ip route | begin resort
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
O 23.0.0.0 [110/2] via 13.0.0.3, 00:48:43, FastEthernet1/0
[110/2] via 10.0.0.2, 00:48:09, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, FastEthernet1/0
Show commands R2:
R2#show ip bgp summary
BGP router identifier 2.2.2.2, local AS number 23
BGP table version is 14, main routing table version 14
1 network entries using 120 bytes of memory
2 path entries using 104 bytes of memory
3/1 BGP path/bestpath attribute entries using 372 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 676 total bytes of memory
BGP activity 1/0 prefixes, 4/2 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 1 73 77 14 0 0 00:29:07 1
23.0.0.3 4 23 71 73 14 0 0 01:04:54 1
R2#show ip bgp
BGP table version is 14, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i1.1.1.0/24 13.0.0.1 0 250 0 1 i
* 10.0.0.1 0 0 1 1 i
R2#show ip route | begin resort
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [200/0] via 13.0.0.1, 00:28:37
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.0.0.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
O 13.0.0.0 [110/2] via 23.0.0.3, 00:48:16, FastEthernet0/1
[110/2] via 10.0.0.1, 00:49:19, FastEthernet0/0
Show commands R3:
R3#show ip bgp summary
BGP router identifier 3.3.3.3, local AS number 23
BGP table version is 6, main routing table version 6
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
3/1 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 600 total bytes of memory
BGP activity 1/0 prefixes, 5/4 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
13.0.0.1 4 1 74 74 6 0 0 00:29:09 1
23.0.0.2 4 23 73 71 6 0 0 01:04:56 0
R3#show ip bgp
BGP table version is 6, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 13.0.0.1 0 250 0 1 i
R3#show ip route | begin resort
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 13.0.0.1, 00:28:39
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.0.0.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O 10.0.0.0 [110/2] via 23.0.0.2, 00:48:18, FastEthernet0/1
[110/2] via 13.0.0.1, 00:48:48, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, FastEthernet0/0
Best wishes,
Keith
And the answer is:
Thanks to you, and your 50+ posts, bob got his answer. By reading your responses, Bob learned the following:
For R2, the BGP next hop for the best route, is still 13.0.0.1, even though it is learned from R3. R3 doesn’t bother to change the next-hop attribute when learning routes via a eBGP neighbor (R1). With R2 having 2 equal cost paths (OSPF) for the next hop of 13.0.0.1, R2 would load balance the traffic over the 10.0.0.0 and 23.0.0.0 networks for traffic going to 1.1.1.0/24
One solution would be to have R3 use next-hop-self for updates sent to R2. Then R2 would see the next hop as 23.0.0.3, and all the traffic would be forwarded to R3 as desired.
The update on R3 would look like this:
router bgp 23 neighbor 23.0.0.2 next-hop-self
This would cause R2, to have the BGP table of this:
R2#show ip bgp BGP table version is 4, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i1.1.1.0/24 23.0.0.3 0 250 0 1 i * 10.0.0.1 0 0 1 1 i
Another option would be increasing the OSPF cost on R2’s 10.0.0.0/24 interface, so that it wouldn’t be considered an equal cost to get to 13.0.0.1 (the previous next hop before the change we just made).
Thanks everyone for all your assistance! You rock.
Cisco has been doing a much better job introducing new topics into the CCIE R&S Written exam.
Be sure to run through Practice Exam 2 again soon as we have updated this exam with some new questions centered around optimizing the network.
Here is a sample for all blog readers to enjoy:
Here ye, here ye, VTP experts. (We are not referring to the Vandenberg Test Program, although they are very likely experts in their field as well. 
)
Can you predict the results of a 3 switch VTP client/server scenario?
SW1-3, are connected, as shown in the diagram.
Here is the initial output of show VTP status, and show VLAN brief on each. Note that SW1 and SW3 are servers, while SW2 is a client. We will be adding a failure to the network in just a moment.
SW1#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW1#
SW2#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Client
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gig0/1, Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW2#
SW3#show vtp status
VTP Version : 2
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x2C 0x04 0x21 0x2B 0x10 0xFE 0x03 0x50
Configuration last modified by 0.0.0.0 at 3-1-93 00:05:40
Local updater ID is 0.0.0.0 (no valid interface found)
SW3#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Fa0/24, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW3#
So here is the scenario for the question. The Fa0/24 connection is suddenly broken between SW1 and SW2, and while that is down, a new VLAN (we will use 999) is created on SW3 like this:
SW3(config)#vlan 999
And then, a few minutes later, SW3 is completely powered off, shipped to another city, and removed completely from this network forever.
If we then restore the Fa0/24 connection between SW1 (the server) and SW2 (the client) what will happen to the VTP/VLAN information on the two switches? Will there be an update on either switch, will SW1 wait for a Server advertisement or will something else happen all together?
Take a moment, and let us know what you think.
Best wishes,
Keith
PS We’ll post the results as a after you have had some time to consider the results.
A few hours have passed, and we have had over 50 comments , ideas and theories.
I appreciate you taking the time to work through this. May your hard work pay off with a successful lab.
SW1, will see that its configuration revision number is lower than SW2, and even though SW2 is a “client” SW1 will use the updated information in the VTP advertisement from SW2 to update to its VLAN database, and get in “sync” with the rest of the VTP domain, including knowing about VLAN 999. The configuration revision number would also move to 4.
Here is SW1, after the connection to SW2 is restored:
SW1#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Server
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x45 0x1D 0x6E 0xF0 0xB7 0xC2 0x84 0xFA
Configuration last modified by 0.0.0.0 at 3-1-93 00:11:43
Local updater ID is 0.0.0.0 (no valid interface found)
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
999 VLAN0999 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW1#
Here is SW2:
SW2#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs : 9
VTP Operating Mode : Client
VTP Domain Name : INE
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x45 0x1D 0x6E 0xF0 0xB7 0xC2 0x84 0xFA
Configuration last modified by 0.0.0.0 at 3-1-93 00:11:43
SW2#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Gig0/1
Gig0/2
2 VLAN0002 active
3 VLAN0003 active
4 VLAN0004 active
999 VLAN0999 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SW2#
Thanks again everyone, and happy studies!
Keith
Fans of the wildly popular CCIE Written Bootcamp by Anthony Sequeira need to check out Practice Exam 2 which has been updated with some more thought-provoking Quality of Service (QoS) questions that will help with the CCIE R&S Written as well as the Lab exam.
For some fun for all, try this question on for size:
Match the QoS marking with the correct definition:
QoS Marking
1. DSCP EF
2. DSCP 20
3. IP PREC 5
4. DE
5. CLP
6. EXP BITS
Definition
a. ATM
b.Diff Serv VoIP
c. Frame Relay
d. MPLS
e.Legacy VoIP Marking
f. Assured Forwarding 22
The answer is posted in the comments. Enjoy.
Sometimes its the simple things that are struggled with. RIP is one of those. Most CCIE candidates understand that we can change the interface or global parameters for updates, unicast, multicast, etc. What does take some time, is figuring out the global timers, especially if a person is not sure how they interact.
In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.
Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)
Here is our topology. Keep your attention on R2, and that will be the focal point for this lesson.
Let’s set up some unique values, so we can see the results.
Defaults are:
Update: 30
Invalid: 180
Hold Down: 180
Flush: 240
We will use 30, 40, 10 and 90 respectively.
R2(config)#router rip R2(config-router)#timers basic 30 40 10 90
We can see the results of our changes with show ip protocols.
R2#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 40 seconds, hold down 10, flushed after 90
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 2 2
FastEthernet0/1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.23.0.3 120 00:00:03
Distance: (default is 120)
We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2 received the last update 7 seconds ago, based on the output.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0 [120/1] via 10.23.0.3, 00:00:07, FastEthernet0/0
R 10.77.0.0 [120/8] via 10.23.0.3, 00:00:07, FastEthernet0/0
Let’s enable debugging so we can see the play by play.
R2#debug ip routing IP routing debugging is on R2#debug ip rip RIP protocol debugging is on
Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned 10.77.0.0 network with a hop count of 8.
R2# 01:24:23: RIP: received v2 update from 10.23.0.3 on FastEthernet0/0 01:24:23: 10.34.0.0/24 via 0.0.0.0 in 1 hops 01:24:23: 10.77.0.0/24 via 0.0.0.0 in 8 hops R2# 01:24:24: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:24:24: RIP: build update entries 01:24:24: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:24:24: 10.34.0.0/24 via 0.0.0.0, metric 2, tag 0 01:24:24: 10.77.0.0/24 via 0.0.0.0, metric 9, tag 0 R2# 01:24:27: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:24:27: RIP: build update entries 01:24:27: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process. While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing updates being sent from R2, at 30 second intervals.
R2# 01:24:53: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:24:53: RIP: build update entries 01:24:53: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:24:53: 10.34.0.0/24 via 0.0.0.0, metric 2, tag 0 01:24:53: 10.77.0.0/24 via 0.0.0.0, metric 9, tag 0 R2# 01:24:56: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:24:56: RIP: build update entries 01:24:56: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2 for the 10.77.0.0, R2 would use it. (In our example, 10.77.0.0 had a metric of 8. If R2 learned about the 10.77.0.0 with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)
R2# 01:25:03: RT: delete route to 10.34.0.0 via 10.23.0.3, rip metric [120/1] 01:25:03: RT: no routes to 10.34.0.0, entering holddown 01:25:03: RT: NET-RED 10.34.0.0/24 01:25:03: RT: delete route to 10.77.0.0 via 10.23.0.3, rip metric [120/8] 01:25:03: RT: no routes to 10.77.0.0, entering holddown 01:25:03: RT: NET-RED 10.77.0.0/24
R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.
R2# 01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:05: RIP: build flash update entries 01:25:05: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:05: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:05: RIP: build flash update entries 01:25:05: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:06: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.
R2# 01:25:08: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:08: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:08: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) R2# 01:25:10: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:10: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:10: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Another normal update, being sent by R2, including the poisoned routes.
R2# 01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:22: RIP: build update entries 01:25:22: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:22: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:22: RIP: build update entries 01:25:22: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:22: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:22: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.
R2# 01:25:36: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1 01:25:36: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:36: RT: 10.34.0.0 came out of holddown 01:25:36: 10.77.0.0/24 via 0.0.0.0 in 16 hops (inaccessible) 01:25:36: RT: 10.77.0.0 came out of holddown
Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 4 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
routing via 10.23.0.3, FastEthernet0/0
Another update clicks off, and then we approach the 90 second flush timer
R2# 01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2) 01:25:49: RIP: build update entries 01:25:49: 10.23.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:49: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2) 01:25:49: RIP: build update entries 01:25:49: 10.12.0.0/24 via 0.0.0.0, metric 1, tag 0 01:25:49: 10.34.0.0/24 via 0.0.0.0, metric 16, tag 0 01:25:49: 10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.
R2# 01:25:53: RT: delete subnet route to 10.34.0.0/24 01:25:53: RT: NET-RED 10.34.0.0/24 01:25:53: RT: delete subnet route to 10.77.0.0/24 01:25:53: RT: NET-RED 10.77.0.0/24
Now the routes don’t show up in the routing table either.
R2# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
C 10.12.0.0 is directly connected, FastEthernet0/1
C 10.23.0.0 is directly connected, FastEthernet0/0
If we use context sensitive help, we find one more parameter for the timers:
R2(config-router)#timers basic 30 40 10 90 ? <1-4294967295> Sleep time, in milliseconds
And we’ll save that one for another blog.
Best wishes,
Keith
One of our students in the INE RS bootcamp today, asked about an OSPF sham-link. I thought it would make a beneficial addition to our blog, and here it is. Thanks for the request Christian!
Reader’s Digest version: MPLS networks aren’t free. If a customers is using OSPF to peer between the CE and PE routers, and also has an OSPF CE to CE neighborship, the CE’s will prefer the Intra-Area CE to CE routes (sometimes called the “backdoor” route in this situation), instead of using the Inter-Area CE to PE learned routes that use the MPLS network as a transit path. OSPF sham-links correct this behavior.
This blog post walks through the problem and the solution, including the configuration steps to create and verify a sham-link.
To begin, MPLS is set up in the network as shown with R2 and R4 acting as Provider Edge (PE) routers, and MPLS is enabled throughout R2-R3-R4.
R1 and R5 are Customer Edge (CE) routers, and the Serial0/1.15 interfaces of R1 and R5 are temporarily shut down, (this means the backdoor route isn’t in place yet, and at the moment, there is no problem).
Currently, R1 and R5 see the routes to each others local networks through the VPNv4 MPLS network, and the routes show up as Inter-Area OSPF routes with the PE routers as the next hop.
Let’s do some testing and verification of what is currently in place. Notice that R1 and R5 can see each others Fa0/0 and Fa0/1 connected networks. These routes show up as Inter-Area (IA) routes.
R1#show ip route ospf 10.0.0.0/24 is subnetted, 2 subnets O IA 10.45.0.0 [110/2] via 10.12.0.2, 00:00:58, FastEthernet0/0 O IA 192.168.1.0/24 [110/3] via 10.12.0.2, 00:00:43, FastEthernet0/0 R5#show ip route ospf 172.16.0.0/24 is subnetted, 1 subnets O IA 172.16.0.0 [110/3] via 10.45.0.4, 00:01:49, FastEthernet0/1 10.0.0.0/24 is subnetted, 2 subnets O IA 10.12.0.0 [110/2] via 10.45.0.4, 00:01:49, FastEthernet0/1
Next, we will enable the Serial0/1.15 interfaces of R1 and R5. When we enable these interfaces, R1 and R5 will become neighbors, and see each others routes to the Fa0/0 and Fa0/1 networks as Intra-Area routes. Even though the OSPF cost will be worse via the serial interfaces, take a close look at what happens and which routes end up in the routing table.
R1(config)#int ser 0/1.15 R1(config-subif)#no shut R5(config)#int ser 0/1.15 R5(config-subif)#no shut
We’ll wait a few moments, to give the network time to converge, then take a look at the OSPF routes on the CE routers R1 and R5, just as we did earlier, and see if the routes are different.
R1#show ip route ospf 10.0.0.0/24 is subnetted, 3 subnets O 10.45.0.0 [110/65] via 10.15.0.5, 00:02:52, Serial0/1.15 O 192.168.1.0/24 [110/65] via 10.15.0.5, 00:02:52, Serial0/1.15 R5#show ip route ospf 172.16.0.0/24 is subnetted, 1 subnets O 172.16.0.0 [110/65] via 10.15.0.1, 00:03:19, Serial0/1.15 10.0.0.0/24 is subnetted, 3 subnets O 10.12.0.0 [110/65] via 10.15.0.1, 00:03:19, Serial0/1.15
Notice, that the remote customer networks attached to Fa0/0 and Fa0/1 are now reachable via the serial 0/1.15 interface, and they appear as Intra-Area routes. Even though the metric of 65 is worse than before, and using the slower serial link, the routers prefer these routes instead of using the PE learned routes, because Intra-Area routes are preferred over Inter-Area routes. Now the Service Provider’s MPLS network will only be used as a backup in the event the serial connection fails. (I don’t think they will be providing a price break either). 
To train the network to use the MPLS network as the primary transit path, we need to make the remote Ethernet customer networks look like Intra-Area routes via the PE routers, with a better metric than the serial interfaces, so they can be used instead of the slower serial link. We are actually going to pull a fast one, or a “sham”, on OSPF because the MPLS network is really acting as a “superbackbone” for OSPF, and therefore routes between the CEs are indeed Inter-Area by default. To create the illusion of the CEs not being separated by a backbone, we will create an OSPF sham-link. We will create a couple loopback interfaces in the VRFs on both PEs, and make sure those loopbacks are originated and advertised via BGP. We will use those loopbacks as the source/destination of the OSPF sham-link.
Because the sham-link is seen as an Intra-Area link between PE routers (R2 and R4), an OSPF adjacency is created and database exchange takes place across the sham-link. The two PE routers can then flood LSAs between sites from across the MPLS VPN backbone. As a result, the desired Intra-Area routes are created.
Enough chat, lets create this sham-link!
R2(config)#int loop 100 R2(config-if)#ip vrf forwarding Vrf1 R2(config-if)#ip address 11.11.11.2 255.255.255.255 R2(config-if)#router bgp 24 R2(config-router)#address-family ipv4 vrf Vrf1 R2(config-router-af)#network 11.11.11.2 mask 255.255.255.255 R2(config-router-af)#exit R2(config-router)#router ospf 1 vrf Vrf1 R2(config-router)#area 1 sham-link 11.11.11.2 11.11.11.4 cost 5 R4(config)#int loop 100 R4(config-if)#ip vrf forwarding Vrf1 R4(config-if)#ip address 11.11.11.4 255.255.255.255 R4(config-if)#router bgp 24 R4(config-router)#address-family ipv4 vrf Vrf1 R4(config-router-af)#network 11.11.11.4 mask 255.255.255.255 R4(config-router-af)#exit R4(config-router)#router ospf 1 vrf Vrf1 R4(config-router)#area 1 sham-link 11.11.11.4 11.11.11.2 cost 5 %OSPF-5-ADJCHG: Process 1, Nbr 10.12.0.2 on OSPF_SL0 from LOADING to FULL, Loading Done
Looks like the sham-link came up. Let’s take a closer look at the sham link with a show command made just for that purpose.
R4#show ip ospf sham-links Sham Link OSPF_SL0 to address 11.11.11.2 is up Area 1 source address 11.11.11.4 Run as demand circuit DoNotAge LSA allowed. Cost of using 5 State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Hello due in 00:00:06 Adjacency State FULL (Hello suppressed) Index 2/2, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec
Looks like it is in place, but is it creating the desired result, of having the CE routers R1 and R5 see the Ethernet remote networks as reachable through the PE routers R2 and R4? Let’s go to R1 and see!
R1#show ip route ospf 10.0.0.0/24 is subnetted, 3 subnets O 10.45.0.0 [110/7] via 10.12.0.2, 00:06:02, FastEthernet0/0 11.0.0.0/32 is subnetted, 2 subnets O E2 11.11.11.2 [110/1] via 10.12.0.2, 00:06:43, FastEthernet0/0 O E2 11.11.11.4 [110/1] via 10.12.0.2, 00:06:13, FastEthernet0/0 O 192.168.1.0/24 [110/8] via 10.12.0.2, 00:06:02, FastEthernet0/0
That looks perfect! How about R5?
R5#show ip route ospf 172.16.0.0/24 is subnetted, 1 subnets O 172.16.0.0 [110/8] via 10.45.0.4, 00:06:27, FastEthernet0/1 10.0.0.0/24 is subnetted, 3 subnets O 10.12.0.0 [110/7] via 10.45.0.4, 00:06:27, FastEthernet0/1 11.0.0.0/32 is subnetted, 2 subnets O E2 11.11.11.2 [110/1] via 10.45.0.4, 00:07:05, FastEthernet0/1 O E2 11.11.11.4 [110/1] via 10.45.0.4, 00:06:45, FastEthernet0/1
And just to be sure, a ping to verify connectivity. We will ping the remote Fa0/1 interface of CE router R1 from CE router R5.
R5#ping 172.16.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 120/130/148 ms
That’s cool, so we know we have connectivity, and based on the routing table output, we believe it is going through the SP MPLS network. Let’s do one more test to prove that as well. A traceroute.
R5#trace 172.16.0.1 Type escape sequence to abort. Tracing the route to 172.16.0.1 1 10.45.0.4 48 msec 92 msec 12 msec 2 10.34.0.3 [MPLS: Labels 16/24 Exp 0] 136 msec 180 msec 228 msec 3 10.12.0.2 [MPLS: Label 24 Exp 0] 124 msec 80 msec 88 msec 4 10.12.0.1 112 msec * 176 msec
Tags and all! I still love it when a plan comes together. Now our transit traffic is moving through the MPLS network, and the serial 0/1.15 interfaces are available as a backup.
More fun times regarding MPLS, OSPF and MPBGP can be found in our workbooks for RS and SP.
Best wishes, and enjoy the journey!
Keith
Having a blast in Chicago with the RS bootcamp students. Thanks for all the hard work you are doing this week!
A student from a past Reno class, named Michal, asked if I would create a blog post regarding BGP proportional load balancing based on the bandwidth of the links to EBGP peers. It has been on my list of things to do, and here it is. Thanks for the request Michal.
The secret to this trick is to pay attention to the links between directly connected external BGP neighbors, (in this case between R6-R5 and R2-R3), and send the link bandwidth extended community attribute to iBGP peer R1. It is enabled by entering the bgp dmzlink-bw command and using extended communities to share the information. To summarize: routes learned from directly connected external neighbor are advertised to IBGP peers including the bandwidth of the external link where the routes were learned, and then the IBGP router (R1) can proportionally load balance between the two paths.
Here is the diagram we will use.
We’ll use loobpacks for our IBGP connections, so let’s verify that we have connectivity between loopbacks in AS 123.
R1#ping 6.6.6.6 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/43/76 ms R1# R1#ping 2.2.2.2 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/40/72 ms
Ok, that looks good, so let’s configure R1 to be an IBGP peer with R6 and R2. The dmzlink-bw feature is implemented as part of the IPv4 address family configuration.
R1(config)#router bgp 126 R1(config-router)#neighbor 6.6.6.6 remote-as 126 R1(config-router)#neighbor 2.2.2.2 remote-as 126 R1(config-router)#neighbor 6.6.6.6 update-source lo0 R1(config-router)#neighbor 2.2.2.2 update-source lo0 R1(config-router)#address-family ipv4 R1(config-router-af)#bgp dmzlink-bw R1(config-router-af)#neighbor 6.6.6.6 activate R1(config-router-af)#neighbor 2.2.2.2 activate R1(config-router-af)#neighbor 6.6.6.6 send-community both R1(config-router-af)#neighbor 2.2.2.2 send-community both R1(config-router-af)#maximum-paths ibgp 2 R1(config-router-af)#end
Next, we will configure R6, and R2 to be IBGP neighbors with R1, and EBGP neighbors with R5 and R3 respectively. We are going to manipulate the external interfaces on R6 and R2 to reflect a bandwidth of 6000k and 5000k respectively using the bandwidth command. BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors. In our example, this will be originated from R6 and R2.
R6(config)#router bgp 126 R6(config-router)#neighbor 1.1.1.1 remote-as 126 R6(config-router)#neighbor 1.1.1.1 update-source lo0 R6(config-router)#neighbor 10.56.0.5 remote-as 345 R6(config-router)#address-family ipv4 R6(config-router-af)#bgp dmzlink-bw R6(config-router-af)#neighbor 1.1.1.1 activate R6(config-router-af)#neighbor 1.1.1.1 next-hop-self R6(config-router-af)#neighbor 1.1.1.1 send-community both R6(config-router-af)#neighbor 10.56.0.5 activate R6(config-router-af)#neighbor 10.56.0.5 dmzlink-bw R6(config-router-af)#int fa 0/0 R6(config-if)#bandwidth 6000
Now, on to R2, with virtually the same configuration.
R2(config)#router bgp 126 R2(config-router)#neighbor 1.1.1.1 remote-as 126 R2(config-router)#neighbor 1.1.1.1 update-source lo0 R2(config-router)#neighbor 10.23.0.3 remote-as 345 R2(config-router)#address-family ipv4 R2(config-router-af)#bgp dmzlink-bw R2(config-router-af)#neighbor 1.1.1.1 activate R2(config-router-af)#neighbor 1.1.1.1 next-hop-self R2(config-router-af)#neighbor 1.1.1.1 send-community both R2(config-router-af)#neighbor 10.23.0.3 activate R2(config-router-af)#neighbor 10.23.0.3 dmzlink-bw R2(config-router-af)#int ser 0/1.23 R2(config-subif)#bandwidth 5000
Now we will configure R5 and R3 as the EBGP neighbors of R6 and R2 respectively. These EBGP peers don’t need any special configuration, other than standard BGP.
R5(config)#router bgp 345 R5(config-router)#neighbor 10.56.0.6 remote-as 126 R5(config-router)#neighbor 4.4.4.4 remote-as 345 R5(config-router)#neighbor 4.4.4.4 update-source lo0 R5(config-router)#neighbor 4.4.4.4 next-hop-self R3(config)#router bgp 345 R3(config-router)#neighbor 10.23.0.2 remote-as 126 R3(config-router)#neighbor 4.4.4.4 remote-as 345 R3(config-router)#neighbor 4.4.4.4 update-source lo0 R3(config-router)#neighbor 4.4.4.4 next-hop-self
Last, but not least we configure R4 as an IBGP peer to R5 and R3. In addition, we will create a loopback and add it into BGP. We will use the loopack as a target destination from R1 to verify the load balancing in a later step, so watch for that coming up.
R4(config)#int loop 44 R4(config-if)#ip add 44.44.44.44 255.255.255.0 R4(config-if)#router bgp 345 R4(config-router)#neighbor 5.5.5.5 remote-as 345 R4(config-router)#neighbor 3.3.3.3 remote-as 345 R4(config-router)#network 44.44.44.0 mask 255.255.255.0
Now let’s verify. Because we are on R4, let’s verify the BGP neighborships it has.
R4#show ip bgp summary
BGP router identifier 44.44.44.44, local AS number 345
BGP table version is 2, main routing table version 2
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 452 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3.3.3.3 4 345 4 5 2 0 0 00:00:41 0
5.5.5.5 4 345 4 5 2 0 0 00:00:35 0
! Note: we can easily verify what routes are being advertised out from R4.
R4#show ip bgp neighbors 5.5.5.5 advertised-routes
BGP table version is 2, local router ID is 44.44.44.44
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 44.44.44.0/24 0.0.0.0 0 32768 i
Total number of prefixes 1
R4#show ip bgp neighbors 3.3.3.3 advertised-routes
BGP table version is 2, local router ID is 44.44.44.44
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 44.44.44.0/24 0.0.0.0 0 32768 i
Total number of prefixes 1
R4#
Looks like AS 345 is fine. Let’s jump to R1, in AS 126, and verify from there.
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 126
BGP table version is 3, main routing table version 3
1 network entries using 120 bytes of memory
2 path entries using 104 bytes of memory
1 multipath network entries and 2 multipath paths
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 496 total bytes of memory
BGP activity 1/0 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 126 10 9 3 0 0 00:06:39 1
6.6.6.6 4 126 11 10 3 0 0 00:07:14 1
R1#show ip bgp
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i44.44.44.0/24 6.6.6.6 0 100 0 345 i
*>i 2.2.2.2 0 100 0 345 i
! Note: Looks like we have the neighbors, and the 44.44.44.0/24 prefix.
! To see more detail on the 44.44.44.0 network, we can use a couple additional commands.
R1#show ip bgp 44.44.44.0
BGP routing table entry for 44.44.44.0/24, version 3
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
Flag: 0x820
Not advertised to any peer
345
6.6.6.6 (metric 1) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
DMZ-Link Bw 750 kbytes
345
2.2.2.2 (metric 1) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
DMZ-Link Bw 625 kbytes
! Note: Let's see what the routing table has to say about this network.
R1#show ip route 44.44.44.0
Routing entry for 44.44.44.0/24
Known via "bgp 126", distance 200, metric 0
Tag 345, type internal
Last update from 2.2.2.2 00:02:56 ago
Routing Descriptor Blocks:
* 6.6.6.6, from 6.6.6.6, 00:02:56 ago
Route metric is 0, traffic share count is 6
AS Hops 1
Route tag 345
2.2.2.2, from 2.2.2.2, 00:02:56 ago
Route metric is 0, traffic share count is 5
AS Hops 1
Route tag 345
! Note: We can also get the information from the CEF table.
R1#show ip cef 44.44.44.0
44.44.44.0/24, version 47, epoch 0, per-destination sharing
0 packets, 0 bytes
via 6.6.6.6, 0 dependencies, recursive
traffic share 6
next hop 10.16.0.6, FastEthernet0/1 via 6.6.6.0/24
valid adjacency
via 2.2.2.2, 0 dependencies, recursive
traffic share 5
next hop 10.12.0.2, FastEthernet0/0 via 2.2.2.0/24
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
So now that the route is there, how do we test the load balancing? One option is to do an extended ping, and record the path. We are expecting a 6 to 5 ratio for outbound traffic favoring the R6 path more than the R2 path. Let’s send 30 ping requests, and show the full response for the benefit of verification.
R1#ping Protocol [ip]: Target IP address: 44.44.44.44 Repeat count [5]: 30 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: loopback0 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: r Number of hops [ 9 ]: 4 Loose, Strict, Record, Timestamp, Verbose[RV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 30, 100-byte ICMP Echos to 44.44.44.44, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 Packet has IP options: Total option bytes= 19, padded length=20 Record route: <*> (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) Reply to request 0 (204 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 1 (156 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list ! Note: the path changes on the next ping request, and begins to use R6 as the next hop. Reply to request 2 (160 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 3 (128 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 4 (156 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 5 (172 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 6 (108 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 7 (136 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 8 (180 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 9 (152 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 10 (80 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 11 (308 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 12 (204 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 13 (108 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 14 (160 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 15 (140 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 16 (140 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 17 (104 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 18 (84 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 19 (192 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 20 (232 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 21 (220 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 22 (168 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 23 (140 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.12.0.1) (10.23.0.2) (10.34.0.3) (44.44.44.44) <*> End of list Reply to request 24 (88 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 25 (224 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 26 (484 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 27 (128 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 28 (108 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Reply to request 29 (136 ms). Received packet has options Total option bytes= 20, padded length=20 Record route: (10.16.0.1) (10.56.0.6) (10.45.0.5) (44.44.44.44) <*> End of list Success rate is 100 percent (30/30), round-trip min/avg/max = 80/166/484 ms R1#
The first 2 requests, numbered 0-1, used the path of R2-R3-R4. The next 6 requests, numbered 2-7, used the path of R6-R5-r4. The next 5, numbered 8-12, use the R2-R3-R4 path again, and then the next 6 use the R6-R5-R4 path.
Happy studies-
Keith
Embedded RP, with IPv6 multicast, is a very cool trick. It simply embeds the RP IPv6 address as part of the multicast group address. This way, when a multicast router sees the group address, it can extract the RP and begin to use it for the shared tree immediately. The only thing that has to be hard coded on a router is to tell the RP that he is the RP, and that’s it. All the other routers in the network dynamically learn the RP address from the group address. So here is the problem: A 128 bit RP address can’t be embedded into a 128 bit group address and still leave space for the group identity, (at least not without compression).
You may want to visit the 2 previous posts on IPv6 multicast using static RPs using this link, or BSR mapped RPs using this link.
Here is the topology we are using, which matches the one from the previous posts:
To facilitate the embedding of an RP address int the multicast group address, there are some rules to follow. These are listed in RFC 3956.
First of all, to indicate that a multicast group contains an embedded RP in it, bits 9, 10, 11 and 12, from the left, need to be 0111. Because the first 8 bits are all 1s, an embedded RP multicast address would always begin with FF70::/12 or 1111 1111 0111
To determine an embedded RP from a multicast group address, we include an example from RFC 3956.
“The network administrator of 2001:DB8::/32 wants to set up an RP for the network and all the customers, by placing it on an existing subnet, e.g., 2001:DB8:BEEF:FEED::/64.
In that case, the group addresses would be something like “FF7x:y40:2001:DB8:BEEF:FEED::/96″, and then their RP address would be “2001:DB8:BEEF:FEED::y”. There are still 32 bits of multicast group-ids to assign to customers and self (”y” could be anything from 1 to F, as 0 must not be used).”
In our lab example, if we wanted R6 to be an RP, using 2002:6666::6 as the RP address, we could reverse engineer a multicast group to be FF7x:y40:2002:6666::1 (x=scope), or FF7e:640:2002:6666::1. The only configuration that would need to be done is to hard code R6 locally, to tell it that it is a RP, and then all the other routers would extract the RP from the multicast group address.
Here is the breakdown to determine the RP address from the group FF7e:0640:2002:6666::1
This example includes the roles of all 128 bits in the IPv6 embedded RP address, which will assist in understanding it.
8 bits = Multicast (0xFF)
1111 1111
4 bits = Flags (0×7)
0111
4 bits = Scope (0xE)
1110
4 bits Reserved (0)
0000
4 bits RIID (RP Interface Identifier) (0×6)
0110
8 bits Prefix Length (0×40) decimal 64
0100 0000
64 bits Network Prefix (0×2002:6666:0:0)
32 bits group ID (0×0:1)
To determine the RP, is simple.
It is the value of the Network Prefix, with the RIID (4bits) tagged on at the end. Thats it.
Since the prefix length says it is 64 (0×40), we take those 64 bits as the high
order bits of the RP, and add the RIID (4bits) to the low order position, and we are done!
Our final RP address would then be 2002:6666:0:0::6, or 2002:6666::6
Let’s configure R6 locally first.
R6(config)#ipv6 pim rp-address 2002:6666::6 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
Next we will have R3 join that group, but before we do, let’s see if R3 knows of a RP for the group. After we join the group, R3 will automagically know who the RP is. (Not really magic, it just extracted the RP from the group address).
R3#show ipv6 pim group-map ff7e:640:2002:6666::1
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF00::/8*
SM
Info source: Default
Uptime: 00:00:17, Groups: 0
R3(config)#int lo 0
R3(config-if)#ipv6 mld join-group ff7e:640:2002:6666::1
R3#show ipv6 pim group-map ff7e:640:2002:6666::1
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF7E:640:2002:6666::/96*
SM, RP: 2002:6666::6
RPF: Fa0/0,FE80::244:44FF:FE44:4444
Info source: Embedded
Uptime: 00:00:02, Groups: 1
Let’s take a look at R6, who is the RP
R6#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:640:2002:6666::1), 00:05:57/00:02:33, RP 2002:6666::6, flags: S
Incoming interface: Tunnel2
RPF nbr: 2002:6666::6
Immediate Outgoing interface list:
FastEthernet0/0, Forward, 00:05:57/00:02:33
Now we will generate some multicast traffic, destined for that group, from R5.
R5# ping ff7e:640:2002:6666::1 Output Interface: fastethernet0/1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FF7E:640:2002:6666::1, timeout is 2 seconds: Packet sent with a source address of 2002:45::5 Reply to request 0 received from 2002:3333::3, 272 ms Reply to request 1 received from 2002:3333::3, 64 ms Reply to request 2 received from 2002:3333::3, 104 ms Reply to request 3 received from 2002:3333::3, 80 ms Reply to request 4 received from 2002:3333::3, 84 ms Success rate is 100 percent (5/5), round-trip min/avg/max = 64/120/272 ms 5 multicast replies and 0 errors. R5#
Looks like it worked. While the ping requests are being sent via multicast to the group, the replies from R3 are unicast. Let’s take a peek at R4 who is in the transit path between R5 (the server) and the listener R3.
R4#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:640:2002:6666::1), 00:05:35/00:02:56, RP 2002:6666::6, flags: S
Incoming interface: FastEthernet0/1
RPF nbr: FE80::255:55FF:FE55:5555
Immediate Outgoing interface list:
FastEthernet0/0, Forward, 00:05:35/00:02:56
(2002:45::5, FF7E:640:2002:6666::1), 00:02:32/00:00:56, flags: ST
Incoming interface: FastEthernet0/1
RPF nbr: FE80::255:55FF:FE55:5555
Immediate Outgoing interface list:
FastEthernet0/0, Forward, 00:02:32/00:02:56
R4#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF7E:640:2002:6666::/96*
SM, RP: 2002:6666::6
RPF: Fa0/1,FE80::255:55FF:FE55:5555
Info source: Embedded
Uptime: 00:17:31, Groups: 1
For more information on embedded RP with IPv6 multicast, check out our workbooks as well as RFC3956.
Happy studies-
Keith.
FF7e:0640:2002:6666::1
8 bits = Multicast (0xFF)
1111 1111
4 bits = Flags (0×7)
0111
4 bits = Scope (0xE)
1110
4 bits Reserved (0)
0000
4 bits RIID (RP Interface Identifier) (0×6)
0110
8 bits Prefix Length (0×40) decimal 64
0100 0000
64 bits Network Prefix
(shown in hex)
2002:6666:0:0
32 bits group ID
To extract the RP, take x number of bits from
the network prefix field, and that will be the
the beginning of our RP address. In this case
our prefix length field of (0×40, or decimal 64)
means that x = 64 bits.
At the tail end of those 64 bits, we append the
value of the 4 bits that make up the RIID, in our
example that is a value of 6.
Our final RP address would then be 2002:6666:0:0::6.
The TechEditor for the Interactive Video Companion Series and valuable INE community member, Nadeem Rafi, provided this unsolicited review of the CCIE Written Bootcamp. Thanks Nadeem.
Just a few days ago, I came across a fantastic product for preparation of the CCIE R&S Written exam. This product is the CCIE Routing and Switching Exam Bootcamp by INE.COM. This product is authored by the famous CCIE instructor, Anthony Sequeira. Anthony has a long history of being a part of some very successful study guides and interactive training products. For example, his KnowledgeNet series is still high in demand from his old days. Anthony’s experience can be seen very clearly in this CCIE Routing and Switching Written Exam Bootcamp.
This product was offered to my by INE as a free add on to enhance my study resources. After this offer was made, the Written Bootcamp was instantly activated in my account by Kady Dennis. Kady is always such a great help; she and her sales team are always offer a pleasant experience at INE.
I made a study plan to finish this bootcamp within a month or so. Then I decided to study every topic as I progress through the INE Volume 1 workbook. But once I started this bootcamp, the whole scenario changed suddenly. I found this product to be so interesting and absorbing, my first session was more than 3 hours in one sitting! I decided to finish it as early as possible, and after a long time, I decided to cut off all my net connections to the outside world to deal with this masterful training resource.
This bootcamp is divided into 11 sections, each representing an individual technology. Furthermore, each technology is subdivided into more focused topics. With this division of topics, the overall experience is amazing. Topics are short and comprehensive. Topics do not bore the viewer at all, and every topic features “recess time”. These “recess times” are highly interactive challenges of the topic being studied in the format of multiple choice questions, drag and drop scenarios, or short answer questions just like the Core Knowledge (OEQ) section of the lab exam. This interactivity keeps you absorbed within the bootcamp, and a hunger for more is always an experience during this bootcamp. Some of the modules are provided with hands on lab experience, which makes it much easier to understand difficult topics like the MQC in very short period of time.
This bootcamp also provides two Practice Tests. The first is equipped with 100 practice questions. All of these are interactive in nature and mimic the actual written exam. The second Practice Test is still in progress and more questions are being added to this. This product is covered under the INE Investment Protection Program.
This COD (Class On Demand) bootcamp is provided in Adobe Captivate format which makes it easier for those who always complain about sound synchronization problems because of slow internet speed. Every topic will be downloaded to your browser and then will be played. These downloadable chunks are highly optimized in size and candidates will not have to wait more than 2-3 minutes for every topic to be played on very moderate bandwidth. A simple trick I used, while I was interacting with a topic, I would load subsequent topics in other tabs. Within 5 minutes or less, all topics for a technology would be ready in my browser to be watched at my own pace.
I strongly feel that this product combined with the CCIE Routing and Switching Exam Certification Guide, 4th Edition will be a killer combination to pass not only the CCIE Written exam on the first try, but also would be very helpful for Core Knowledge (OEQ) preparations. This bootcamp can be very help full to review all of the fundamental topics during CCIE LAB preparations.
Readers, I took two and half days to finish this 20+ hour bootcamp, let me know how much time you will need to finish it.
