I might not be devoting adequate attention to all postings in the thread, but by "same major network" do you also mean "same classful network?"
"John Neiberger" @groupstudy.com on 12/19/2001 07:26:11 PM Please respond to "John Neiberger" Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Kevin Cullimore) Subject: RE: RE: That Friday Follies Question... [7:29473] Excellent! That perfectly explains the behavior we were experiencing. I was only able to make this work when the tunnel was in the same major network. When I made the tunnel a part of a different major net, things got a little weird. You're correct, in the scenario I've been playing with IGRP is the only protocol involved. The addition of other protocols wouldn't change the behavior of IGRP so I've been testing this with two routers only. Thanks for doing the research, that was great! John >>> "R. Benjamin Kessler" 12/19/01 4:46:27 PM >>> Warning, this is a bit longish...I'd be interested in feedback to see if anyone agrees/disagrees, finds this at all helpful, etc. Part of this exercise is to make sure I've got this straight in my head. Here's a CCO link that may help: http://www.cisco.com/warp/public/103/5.html The scenario you outlined can be examined as a "straight" IGRP problem without confusing the issue by redistributing from/to OSPF. To allow more routes to be advertised in a single update packet, the designers of IGRP decided to only send the three "significant" bytes of the network address. For Interior links the last three bytes are sent - the first byte is assumed to match that of the outgoing interface; for Exterior and System links, only the first three bytes are sent and the last byte is assumed to be zero. Regarding the three different portions of update messages (snipped from the above link): /Begin SNIP/ Note that an IGRP update message has three portions: interior, system (meaning "this autonomous system" but not interior), and exterior. The interior section is for routes to subnets. Not all subnet information is included. Only subnets of one network are included. This is the network associated with the address to which the update is being sent. Normally updates are broadcast on each interface, so this is simply the network on which the broadcast is being sent. (Other cases arise for responses to an IGRP request and point to point IGRP.) Major networks (i.e. non-subnets) are put into the system portion of the update message unless they are specifically flagged as exterior. A network will be flagged as exterior if it was learned from another gateway and the information arrived in the exterior portion of the update message. Cisco's implementation also allows the system administrator to declare specific networks as exterior. Exterior routes are also referred to as "candidate default". They are routes that go to or through gateways that are considered to be appropriate as defaults, to be used when there is no explicit route to a destination. /End SNIP/ Consider the following topology: R1-----R2-----R3-----R4-----R5 Where the following interfaces are configured: R1 - Lo0 - 192.168.10.1/28 E0 - 192.168.10.17/28 R2 - E0 - 192.168.10.18/28 Lo0 - 192.168.10.33/28 S0.1 - 192.168.10.49/28 R3 - S0.1 - 192.168.10.50/28 Lo0 - 192.168.10.65/28 Lo1 - 192.168.10.99/27 E0 - 192.168.10.129/27 R4 - E0 - 192.168.10.130/27 Lo0 - 192.168.10.161/27 S0.1 - 192.168.10.193/27 R5 - S0.1 - 192.168.10.194/27 Lo0 - 192.168.10.225/27 All routers are configured as follows: router IGRP 1 network 192.168.10.0 Here's the routing tables from R1, R3, and R5. Obviously, R3 can see and get to everything but R1 and R5 only see the networks with the matching mask lengths: R1#sh ip ro Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 192.168.10.0/28 is subnetted, 5 subnets I 192.168.10.64 [100/9076] via 192.168.10.18, 00:00:02, Ethernet0 I 192.168.10.32 [100/1600] via 192.168.10.18, 00:00:02, Ethernet0 I 192.168.10.48 [100/8576] via 192.168.10.18, 00:00:02, Ethernet0 C 192.168.10.0 is directly connected, Loopback0 C 192.168.10.16 is directly connected, Ethernet0 R1# R3#sh ip ro Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 192.168.10.0/24 is variably subnetted, 10 subnets, 2 masks C 192.168.10.96/27 is directly connected, Loopback1 C 192.168.10.64/28 is directly connected, Loopback0 I 192.168.10.32/28 [100/8976] via 192.168.10.49, 00:00:52, Serial0.1 C 192.168.10.48/28 is directly connected, Serial0.1 I 192.168.10.0/28 [100/9076] via 192.168.10.49, 00:00:52, Serial0.1 I 192.168.10.16/28 [100/8576] via 192.168.10.49, 00:00:52, Serial0.1 I 192.168.10.224/27 [100/9076] via 192.168.10.130, 00:00:09, Ethernet0 I 192.168.10.192/27 [100/8576] via 192.168.10.130, 00:00:09, Ethernet0 I 192.168.10.160/27 [100/1600] via 192.168.10.130, 00:00:10, Ethernet0 C 192.168.10.128/27 is directly connected, Ethernet0 I 192.168.1.0/24 is possibly down, routing via 192.168.10.130, Ethernet0 R3# R5#sh ip ro Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 192.168.10.0/27 is subnetted, 5 subnets I 192.168.10.96 [100/9076] via 192.168.10.193, 00:01:15, Serial0.1 C 192.168.10.224 is directly connected, Loopback0 C 192.168.10.192 is directly connected, Serial0.1 I 192.168.10.160 [100/8976] via 192.168.10.193, 00:01:15, Serial0.1 I 192.168.10.128 [100/8576] via 192.168.10.193, 00:01:15, Serial0.1 R5# Here's the debugging output from R3 showing the IGRP updates it receives and sends. Notice that all advertisements are Interior, there are no System or Exterior networks advertised. R3#debug ip igrp events IGRP event debugging is on R3#debug ip igrp transactions IGRP protocol debugging is on R3# 01:36:19: IGRP: received update from 192.168.10.49 on Serial0.1 01:36:19: subnet 192.168.10.32, metric 8976 (neighbor 501) 01:36:19: subnet 192.168.10.0, metric 9076 (neighbor 1600) 01:36:19: subnet 192.168.10.16, metric 8576 (neighbor 1100) 01:36:19: IGRP: Update contains 3 interior, 0 system, and 0 exterior routes. 01:36:19: IGRP: Total routes in update: 3 01:36:48: IGRP: sending update to 255.255.255.255 via Ethernet0 (192.168.10.129) 01:36:48: subnet 192.168.10.96, metric=501 01:36:48: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes. 01:36:48: IGRP: Total routes in update: 1 01:36:48: IGRP: sending update to 255.255.255.255 via Loopback0 (192.168.10.65) 01:36:48: subnet 192.168.10.32, metric=8976 01:36:48: subnet 192.168.10.48, metric=8476 01:36:48: subnet 192.168.10.0, metric=9076 01:36:48: subnet 192.168.10.16, metric=8576 01:36:48: IGRP: Update contains 4 interior, 0 system, and 0 exterior routes. 01:36:48: IGRP: Total routes in update: 4 01:36:48: IGRP: sending update to 255.255.255.255 via Loopback1 (192.168.10.99) 01:36:48: subnet 192.168.10.224, metric=9076 01:36:48: subnet 192.168.10.192, metric=8576 01:36:48: subnet 192.168.10.160, metric=1600 01:36:48: subnet 192.168.10.128, metric=1100 01:36:49: IGRP: Update contains 4 interior, 0 system, and 0 exterior routes. 01:36:49: IGRP: Total routes in update: 4 01:36:49: IGRP: sending update to 255.255.255.255 via Serial0.1 (192.168.10.50) 01:36:49: subnet 192.168.10.64, metric=501 01:36:49: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes. 01:36:49: IGRP: Total routes in update: 1 01:37:05: IGRP: received update from 192.168.10.130 on Ethernet0 01:37:05: subnet 192.168.10.224, metric 9076 (neighbor 8976) 01:37:05: subnet 192.168.10.192, metric 8576 (neighbor 8476) 01:37:05: subnet 192.168.10.160, metric 1600 (neighbor 501) 01:37:05: IGRP: Update contains 3 interior, 0 system, and 0 exterior routes. 01:37:05: IGRP: Total routes in update: 3 R3# Notice how only those networks with a matching subnet mask of the outgoing interface are advertised out each interface. Now, I missed the original post and searching the archives, I didn't see a specific topology listed for this problem so perhaps I'm missing something. Given the various lab scenarios available (e.g. CCBootcamp, FatKid, etc.) and the numerous posts on the FLSM/VLSM redistribution problem there are generally these solutions: 1. default-network (IGRP) / default-information-originate (RIP) 2. summarizing (where the VLSM domain has a longer mask than the FLSM domain) 3. secondary addressing (where the FLSM domain has a longer mask than the VLSM domain) I would consider the tunneling option a variation on #3 that doesn't require disabling split-horizon, but see note below. Obviously, policy-routing is an option but I guess I'm more used to seeing policy-routing used to force traffic out a specific interface (i.e. all traffic from network X should go across the BRI - ala Caslow) or to fix a next-hop problem in a NBMA environment (ala CCBootcamp #1). Given the constraints of the scenario, this may be the only viable option though. Perhaps the topology I built isn't representative of the original problem. Were the "requirements" something the original poster thought-up on their own to better understand the available options or is from a sample lab somewhere (e.g. Fatkid, CCBootcamp, etc. - No NDA violations please...). I ask because most FLSM scenarios I've seen have a stub router directly connected to the redistribution router and these are the only two routers in the FLSM domain; in such a config, the above options will work nicely. If we're forced to do this given these requirements and a topology similar to the one I laid-out above, the policy routing would be really ugly as you'd have to setup policy route-maps on two separate routers...again, perhaps my topology breaks the original intent of the problem. OK, I'm almost done... Regarding the tunneling options that several people have discussed; here's my take: Test #1 - If we build a tunnel between R2 and R3 and address it with some other (classful) network (e.g. 192.168.1.64/27) we'd see the following: R2#sh ip ro Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 192.168.10.0/28 is subnetted, 4 subnets I 192.168.10.64 [100/8976] via 192.168.10.50, 00:00:14, Serial0.1 C 192.168.10.32 is directly connected, Loopback0 C 192.168.10.48 is directly connected, Serial0.1 C 192.168.10.16 is directly connected, Ethernet0 192.168.1.0/27 is subnetted, 1 subnets C 192.168.1.64 is directly connected, Tunnel0 R2# 04:09:27: IGRP: sending update to 255.255.255.255 via Ethernet0 (192.168.10.18) 04:09:27: subnet 192.168.10.64, metric=8976 04:09:27: subnet 192.168.10.32, metric=501 04:09:27: subnet 192.168.10.48, metric=8476 04:09:27: network 192.168.1.0, metric=1161111 04:09:27: IGRP: Update contains 3 interior, 1 system, and 0 exterior routes. 04:09:27: IGRP: Total routes in update: 4 04:09:27: IGRP: sending update to 255.255.255.255 via Serial0.1 (192.168.10.49) 04:09:27: subnet 192.168.10.32, metric=501 04:09:27: subnet 192.168.10.16, metric=1100 04:09:27: network 192.168.1.0, metric=1161111 04:09:27: IGRP: Update contains 2 interior, 1 system, and 0 exterior routes. 04:09:27: IGRP: Total routes in update: 3 04:09:27: IGRP: sending update to 255.255.255.255 via Tunnel0 (192.168.1.65) 04:09:27: network 192.168.10.0, metric=501 04:09:28: IGRP: Update contains 0 interior, 1 system, and 0 exterior routes. 04:09:28: IGRP: Total routes in update: 1 04:10:28: IGRP: received update from 192.168.10.50 on Serial0.1 04:10:28: subnet 192.168.10.64, metric 8976 (neighbor 501) 04:10:28: network 192.168.1.0, metric 1163111 (neighbor 1161111) 04:10:28: IGRP: Update contains 1 interior, 1 system, and 0 exterior routes. 04:10:28: IGRP: Total routes in update: 2 04:10:28: IGRP: received update from 192.168.1.66 on Tunnel0 04:10:28: network 192.168.10.0, metric 1161611 (neighbor 501) 04:10:28: IGRP: Update contains 0 interior, 1 system, and 0 exterior routes. 04:10:28: IGRP: Total routes in update: 1 04:10:44: IGRP: sending update to 255.255.255.255 via Ethernet0 (192.168.10.18) 04:10:44: subnet 192.168.10.64, metric=8976 04:10:44: subnet 192.168.10.32, metric=501 04:10:44: subnet 192.168.10.48, metric=8476 04:10:44: network 192.168.1.0, metric=1161111 04:10:45: IGRP: Update contains 3 interior, 1 system, and 0 exterior routes. 04:10:45: IGRP: Total routes in update: 4 04:10:45: IGRP: sending update to 255.255.255.255 via Serial0.1 (192.168.10.49) 04:10:45: subnet 192.168.10.32, metric=501 04:10:45: subnet 192.168.10.16, metric=1100 04:10:45: network 192.168.1.0, metric=1161111 04:10:45: IGRP: Update contains 2 interior, 1 system, and 0 exterior routes. 04:10:45: IGRP: Total routes in update: 3 04:10:45: IGRP: sending update to 255.255.255.255 via Tunnel0 (192.168.1.65) 04:10:45: network 192.168.10.0, metric=501 04:10:45: IGRP: Update contains 0 interior, 1 system, and 0 exterior routes. 04:10:45: IGRP: Total routes in update: 1 R2# R2 and R3 advertise 192.168.1.0 as a "system" route out all interfaces (except Tun0). All other routers will see network 192.168.1.0/24 show up in their routing table - again, this is a system route so the last octet is assumed to be zero thus the classful /24. Also notice that R2 both sends and receives a system route for 192.168.10.0 via its Tun0 interface. In this case, the receiving router suppresses/ignores these advertisements because they have "better" (read more specific) "interior" routes. Remember, this environment is all IGRP, no redistribution (although throwing redistribution into the mix here wouldn't change this behavior). Test #2 - If we build a tunnel between R2 and R3 and address it with the same (classful) network but use the /27 (e.g. 192.168.10.224/27) we'd see the following: Note: I removed R5 from this example because I needed the /27 from its loopback for the tunnel network. R2#sh ip ro Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 192.168.10.0/24 is variably subnetted, 8 subnets, 2 masks I 192.168.10.96/27 [100/1161611] via 192.168.10.226, 00:00:42, Tunnel0 I 192.168.10.64/28 [100/8976] via 192.168.10.50, 00:00:42, Serial0.1 C 192.168.10.32/28 is directly connected, Loopback0 C 192.168.10.48/28 is directly connected, Serial0.1 C 192.168.10.16/28 is directly connected, Ethernet0 C 192.168.10.224/27 is directly connected, Tunnel0 I 192.168.10.160/27 [100/1161711] via 192.168.10.226, 00:00:42, Tunnel0 I 192.168.10.128/27 [100/1161211] via 192.168.10.226, 00:00:42, Tunnel0 R2# 04:28:00: IGRP: received update from 192.168.10.50 on Serial0.1 04:28:00: subnet 192.168.10.64, metric 8976 (neighbor 501) 04:28:00: IGRP: Update contains 1 interior, 0 system, and 0 exterior routes. 04:28:00: IGRP: Total routes in update: 1 04:28:00: IGRP: received update from 192.168.10.226 on Tunnel0 04:28:00: subnet 192.168.10.96, metric 1161611 (neighbor 501) 04:28:00: subnet 192.168.10.160, metric 1161711 (neighbor 1600) 04:28:00: subnet 192.168.10.128, metric 1161211 (neighbor 1100) 04:28:00: IGRP: Update contains 3 interior, 0 system, and 0 exterior routes. 04:28:00: IGRP: Total routes in update: 3 04:28:05: IGRP: sending update to 255.255.255.255 via Ethernet0 (192.168.10.18) 04:28:05: subnet 192.168.10.64, metric=8976 04:28:05: subnet 192.168.10.32, metric=501 04:28:05: subnet 192.168.10.48, metric=8476 04:28:05: IGRP: Update contains 3 interior, 0 system, and 0 exterior routes. 04:28:05: IGRP: Total routes in update: 3 04:28:05: IGRP: sending update to 255.255.255.255 via Serial0.1 (192.168.10.49) 04:28:05: subnet 192.168.10.32, metric=501 04:28:05: subnet 192.168.10.16, metric=1100 04:28:05: IGRP: Update contains 2 interior, 0 system, and 0 exterior routes. 04:28:05: IGRP: Total routes in update: 2 04:28:05: IGRP: sending update to 255.255.255.255 via Tunnel0 (192.168.10.225) 04:28:05: IGRP: Update contains 0 interior, 0 system, and 0 exterior routes. 04:28:05: IGRP: Total routes in update: 0 - suppressing null update R2# OK, notice how the debug info and the routing table are different. R2 now has both the /28 and /27 routes. R2 has no /27 routes of its own to advertise out the tunnel so it doesn't send any advertisements (suppressing null update). Also notice that R2 still only advertises the /28's out the other interfaces regardless of the fact that the routing table shows the 192.168.10.0 network as being 'variably subnetted.' I know this was really long-winded but I hope this helps answer some of the questions as to why IGRP acts the way it does. ...let the flames begin... Ben ================================================================ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ================================================================ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=29783&t=29473 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
