RE: RE: That Friday Follies Question... [7:29473]
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
RE: RE: That Friday Follies Question... [7:29473]
belaboring beyond all usefulness maybe, but I am prone to write this one off as because that's how it works and move one. secondary addressing appears to be filled with pitfalls. I believe it has nothing to do with RFC's, but rather, it's just the way the code runs. I think over the past few weeks we have examined the behaviour in detail, and have at best a few things to try, but no real consistency. RIP appeared to be happier with secondary addressing than does IGRP. with regards to the /16 summary, IGRP appears to accept routes only with the classful mask matching that of the interface that receives the route. I suppose a good question is how does it know? In my experiments, I redistributed lots of routes with lots of different masks into IGRP. Only those with a mask matching that of the IGRP domain were accepted. A summary /16 was never created. At this point I am supposing that the redistribution code is what controls that. Otherwise, why not accept ALL routes as matching the IGRP domain mask? e.g. 129.5.10.1/22 as 129.5.10.0/28 for example? I wish CCO got into this kind of thing a bit more. Sure would love to talk to the people who coded this stuff. What I wish is that Cisco would STOP TEACHING classful addressing. With classless addressing, pretty much all the needs for secondary addresses go away. Treat classful legacy networks as a special case like NetBEUI or Banyan. The problem, in part, is that IGRP and RIPv1 were not designed or implemented with secondary addresses in mind. They dealt well with a consistent classful world on primary addresses only. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Neiberger Sent: Tuesday, December 18, 2001 11:12 PM To: [EMAIL PROTECTED] Subject: Re: RE: That Friday Follies Question... [7:29473] I thought I had discovered a way to do this but it didn't work, either. It was a variation of the tunnel technique except the tunnel is in a completely different classful network. For example... A(igrp)-B The link is 172.16.1.0/28. I create a tunnel that is 4.0.0.1/8. On B, I configure both networks in IGRP. I was hoping that B would send a 172.16.0.0/16 summary back to A, which it does, but A ignores it and I could never figure out why. I wonder if that strange behavior earlier with split horizon might come into play here? There just *has* to be a way to get A to accept the summary route from B over the 4/8 tunnel. Any thoughts there? John BTW, if I marked the calendar every time I was wrong there'd be no room left on the calendar! :-) Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Wed, 19 Dec 2001, Chuck Larrieu ([EMAIL PROTECTED]) wrote: that reminds me... mark this date on your calendars, everyone. I was WRONG. I pretty much spent the weekend testing various scenarios, and I have compiled several pages of observations. But the short of it is that given the constraints of the scenario - full reachability into a VLSM domain from an FLSM domain whose prefix is LONGER that most of the routes in the VLSM domain, and without the use of a default network or default route seems doable only by judicious use of policy routing. Local policy in particular, depending upon the topology. I was thinking that one could create a summary route on the classful boundary of the network in question. But IGRP in particular will not accept the summary /16 if all the interfaces in its domain are some other prefix. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of c1sc0k1d Sent: Tuesday, December 18, 2001 1:02 PM To: [EMAIL PROTECTED] Subject: Re: That Friday Follies Question... [7:29473] Hmmm... interesting. I'll give it a go in my lab and let you know what happens. I'm looking forwards to Chucks answer as well. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method,
RE: RE: That Friday Follies Question... [7:29473]
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 I192.168.1.0/24 is possibly down, routing via 192.168.10.130, Ethernet0 R3# R5#sh ip ro Codes: C - connected, S -
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
That Friday Follies Question... [7:29473]
John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29473t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: That Friday Follies Question... [7:29473]
The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29488t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: That Friday Follies Question... [7:29473]
AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29510t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: That Friday Follies Question... [7:29473]
In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29515t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: That Friday Follies Question... [7:29473]
Hmmm... interesting. I'll give it a go in my lab and let you know what happens. I'm looking forwards to Chucks answer as well. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29520t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: That Friday Follies Question... [7:29473]
did you disable split horizon? I can't think of why it should work, but a couple of weeks ago we had a thread on secondary addresses with RIP and the only way to get that one to work was by disabling split horizon on the interfaces where the secondaries appeared. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Neiberger Sent: Tuesday, December 18, 2001 12:06 PM To: [EMAIL PROTECTED] Subject: Re: That Friday Follies Question... [7:29473] In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29591t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: That Friday Follies Question... [7:29473]
that reminds me... mark this date on your calendars, everyone. I was WRONG. I pretty much spent the weekend testing various scenarios, and I have compiled several pages of observations. But the short of it is that given the constraints of the scenario - full reachability into a VLSM domain from an FLSM domain whose prefix is LONGER that most of the routes in the VLSM domain, and without the use of a default network or default route seems doable only by judicious use of policy routing. Local policy in particular, depending upon the topology. I was thinking that one could create a summary route on the classful boundary of the network in question. But IGRP in particular will not accept the summary /16 if all the interfaces in its domain are some other prefix. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of c1sc0k1d Sent: Tuesday, December 18, 2001 1:02 PM To: [EMAIL PROTECTED] Subject: Re: That Friday Follies Question... [7:29473] Hmmm... interesting. I'll give it a go in my lab and let you know what happens. I'm looking forwards to Chucks answer as well. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27 r1/r8 tunnel 172.168.11.0/27 r8network 172.168.10.32/28 I tried all combinations of /27 /28 masks on the tunnel to try and get the /27 routes into the table on r1 but with no joy. Look at this form debug ip igrp trans 04:49:59: IGRP: sending update to 255.255.255.255 via Tunnel0 (172.168.11.1) 04:49:59: subnet 172.168.10.32, metric=6882 So the route appears to be advertised out of tunnel0 towards r1 as you would expect , because the mask is the same. However the route never appears in the routing table on r1 although it has an interface using a /27 ( tunnel ) You do not see r1 receiving the /27 route I would like to hear your thoughts as I cannot think of another way to get around this one. Best regards Richard Botham Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=29599t=29473 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: RE: That Friday Follies Question... [7:29473]
Well, this is getting even weirder. Adding no ip split-horizon seems to work, sort of. If I shut down the interfaces involved and then bring them back up, all routes are advertised. Look at the following: C 172.16.20.0/24 is directly connected, Serial1 I 172.16.20.0/28 [100/10476] via 172.16.20.1, 00:00:05, Serial1 I 172.16.10.0/28 [100/8976] via 172.16.20.1, 00:00:05, Serial1 I 172.16.5.0/28 [100/8976] via 172.16.1.1, 00:00:06, Serial1 C 172.16.1.0/28 is directly connected, Serial1 That was from the IGRP-only router. As you can see, it is learning /24 and /28 routes over the same interface. Now look at the output of show ip protocols: Routing Information Sources: Gateway Distance Last Update 172.16.20.1 100 00:00:13 172.16.1.1 100 00:00:13 As you can see, it is receiving updates from both IP addresses. Here's where it gets weird. I now do a clear ip route * and look what happens: Routing Information Sources: Gateway Distance Last Update 172.16.20.1 100 00:00:20 172.16.1.1 100 00:00:03 It stops receiving routes from the secondary! The /24 routes disappear from the routing table and can only be brought back by doing a shut/no shut on the interfaces involved. If I don't ever clear routes, this router continues to receive updates from both source addresses. Why would it stop receiving routes *after* I clear routes? Very interesting. This is close to what I noticed before. Sometimes it would seem to work but then it would stop. Thanks to this experiment I can now reproduce it. However, I have no explanation. :-) Any takers? Thanks, John Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Tue, 18 Dec 2001, Chuck Larrieu ([EMAIL PROTECTED]) wrote: did you disable split horizon? I can't think of why it should work, but a couple of weeks ago we had a thread on secondary addresses with RIP and the only way to get that one to work was by disabling split horizon on the interfaces where the secondaries appeared. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Neiberger Sent: Tuesday, December 18, 2001 12:06 PM To: [EMAIL PROTECTED] Subject: Re: That Friday Follies Question... [7:29473] In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary-address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8--(
Re: RE: That Friday Follies Question... [7:29473]
I thought I had discovered a way to do this but it didn't work, either. It was a variation of the tunnel technique except the tunnel is in a completely different classful network. For example... A(igrp)-B The link is 172.16.1.0/28. I create a tunnel that is 4.0.0.1/8. On B, I configure both networks in IGRP. I was hoping that B would send a 172.16.0.0/16 summary back to A, which it does, but A ignores it and I could never figure out why. I wonder if that strange behavior earlier with split horizon might come into play here? There just *has* to be a way to get A to accept the summary route from B over the 4/8 tunnel. Any thoughts there? John BTW, if I marked the calendar every time I was wrong there'd be no room left on the calendar! :-) Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Wed, 19 Dec 2001, Chuck Larrieu ([EMAIL PROTECTED]) wrote: that reminds me... mark this date on your calendars, everyone. I was WRONG. I pretty much spent the weekend testing various scenarios, and I have compiled several pages of observations. But the short of it is that given the constraints of the scenario - full reachability into a VLSM domain from an FLSM domain whose prefix is LONGER that most of the routes in the VLSM domain, and without the use of a default network or default route seems doable only by judicious use of policy routing. Local policy in particular, depending upon the topology. I was thinking that one could create a summary route on the classful boundary of the network in question. But IGRP in particular will not accept the summary /16 if all the interfaces in its domain are some other prefix. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of c1sc0k1d Sent: Tuesday, December 18, 2001 1:02 PM To: [EMAIL PROTECTED] Subject: Re: That Friday Follies Question... [7:29473] Hmmm... interesting. I'll give it a go in my lab and let you know what happens. I'm looking forwards to Chucks answer as well. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but you could also use a couple of the other methods posted. First, you could create a loopback interface on R8 and then assign it to a dummy OSPF area. This allows you to use the area range command to summarize the /28 routes into a /27. Another option that someone posted was to use two OSPF processes and redistribute one into the other and use the summary- address command. I thought that Chuck's Follies question was how to get shorter-mask routes from OSPF into IGRP. Using your example, try making the OSPF domain /27 and the IGRP domain /28. That makes things much more difficult! I've found two ways to handle this and I don't like either one, to be honest. I'm anxiously awaiting Chuck's answer because this is really bugging me. There ought to be an easier way. However, in the real world we wouldn't have the restrictions of the lab. John Richard Botham 12/18/01 8:18:00 AM John, Thanks for wrecking my weekend too.. I tried to get this to work using the tunnel method and the secondary addressing method but with no success. My lab looks look like this r4--(igrp/27)--r2--(igrp/27)--r1--(igrp /27)--r8-- (ospf /28) interfaces r4/r2 network 172.168.10.80/27 r2/r1 network 172.168.10.64/27 r1/r8 network 172.168.10.16/27
RE: RE: That Friday Follies Question... [7:29473]
belaboring beyond all usefulness maybe, but I am prone to write this one off as because that's how it works and move one. secondary addressing appears to be filled with pitfalls. I believe it has nothing to do with RFC's, but rather, it's just the way the code runs. I think over the past few weeks we have examined the behaviour in detail, and have at best a few things to try, but no real consistency. RIP appeared to be happier with secondary addressing than does IGRP. with regards to the /16 summary, IGRP appears to accept routes only with the classful mask matching that of the interface that receives the route. I suppose a good question is how does it know? In my experiments, I redistributed lots of routes with lots of different masks into IGRP. Only those with a mask matching that of the IGRP domain were accepted. A summary /16 was never created. At this point I am supposing that the redistribution code is what controls that. Otherwise, why not accept ALL routes as matching the IGRP domain mask? e.g. 129.5.10.1/22 as 129.5.10.0/28 for example? I wish CCO got into this kind of thing a bit more. Sure would love to talk to the people who coded this stuff. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Neiberger Sent: Tuesday, December 18, 2001 11:12 PM To: [EMAIL PROTECTED] Subject: Re: RE: That Friday Follies Question... [7:29473] I thought I had discovered a way to do this but it didn't work, either. It was a variation of the tunnel technique except the tunnel is in a completely different classful network. For example... A(igrp)-B The link is 172.16.1.0/28. I create a tunnel that is 4.0.0.1/8. On B, I configure both networks in IGRP. I was hoping that B would send a 172.16.0.0/16 summary back to A, which it does, but A ignores it and I could never figure out why. I wonder if that strange behavior earlier with split horizon might come into play here? There just *has* to be a way to get A to accept the summary route from B over the 4/8 tunnel. Any thoughts there? John BTW, if I marked the calendar every time I was wrong there'd be no room left on the calendar! :-) Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Wed, 19 Dec 2001, Chuck Larrieu ([EMAIL PROTECTED]) wrote: that reminds me... mark this date on your calendars, everyone. I was WRONG. I pretty much spent the weekend testing various scenarios, and I have compiled several pages of observations. But the short of it is that given the constraints of the scenario - full reachability into a VLSM domain from an FLSM domain whose prefix is LONGER that most of the routes in the VLSM domain, and without the use of a default network or default route seems doable only by judicious use of policy routing. Local policy in particular, depending upon the topology. I was thinking that one could create a summary route on the classful boundary of the network in question. But IGRP in particular will not accept the summary /16 if all the interfaces in its domain are some other prefix. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of c1sc0k1d Sent: Tuesday, December 18, 2001 1:02 PM To: [EMAIL PROTECTED] Subject: Re: That Friday Follies Question... [7:29473] Hmmm... interesting. I'll give it a go in my lab and let you know what happens. I'm looking forwards to Chucks answer as well. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In my testing I was never able to get secondary interfaces to work properly. IGRP would advertise over one or the other, but not both, and I wasn't able to figure out how it picked which one to use. I've configured slightly different scenarios from scratch two or three times and I could never make secondary IP addresses work. John c1sc0k1d 12/18/01 12:25:29 PM AFAIK, there is only one way to summarize with rip and igrp and that is by creating a static and redistributing the static. Since that is not possible and since we cannot use the default network command we must have an ospf interface that shares the /27 igrp network to get routes to pass. That could be performed with secondary addresses or a tunnel interface (or a frame subinterface). I think for igrp to advertise on the secondary address method, it also needs to be configured to advertised on the primary, although I could be mistaken. I know it's that way for eigrp. The k1d John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The R1/R8 Tunnel needs to be a /28 since you're trying to get /28 routes into the IGRP domain. However, since you're going from a longer-match mask to a shorter-mask, you don't need to use this method. It will work but yo
