RE: OSPF vs EIGRP [7:41613]
I remembered this email and ran into a problem with OSPF MTU on a tunnel interface about an hour ago. The tunnel was to connect a non backbone area through an nssa area to the backbone. Adjusting the mtu of the physical interface that was the source of the tunnel on the router with the larger mtu fixed it, and I found an interesting interface command, ip ospf mtu-ignore which makes the router with the smaller mtu ignore the mismatch and allow an adjacency to form. I set the mtu's back to the defaults and allowed the router to complain about the mismatch and then put in the command above on the tunnel interface, works like a charm. Just thought it was interesting so I figured I would send this. ~-Original Message- ~From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] ~Sent: Thursday, April 18, 2002 10:18 PM ~To: [EMAIL PROTECTED] ~Subject: Re: OSPF vs EIGRP [7:41613] ~ ~ ~He didn't say that BGP negotiates the MTU in any of its PDUs. ~He just says ~that mismatched MTUs can be a problem, which is all I mentioned in my ~message about OSPF also (although OSPF does in fact also ~include the MTU in ~database description packets and refuse to become adjacent ~with a router ~that doesn't agree on the MTU). Did that have enough TLAs for you? ;-) ~ ~Priscilla ~ ~At 09:53 PM 4/18/02, nrf wrote: ~Really? I had never heard of this problem. I'm not aware that BGP ~negotiates MTU in any of its PDU's. Can you provide the RFC ~that discusses ~this problem? ~ ~ ~suaveguru wrote in message ~[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... ~ If I am not wrong this problem also occurs for BGP ~ peers with unmatched MTU sizes which causes BGP to ~ flap when they exchange routing tables , especially if ~ one neighbour is configured with full-routes ~ ~ ~ regards, ~ ~ suaveguru ~ --- Priscilla Oppenheimer wrote: ~ The problem happens when the routers try to exchange ~ database description ~ packets. One side can send packets that are too ~ large for the other side to ~ receive. Then the routers never achieve adjacency. ~ It's an infamous ~ problem. I was glad that Kevin brought it up. I was ~ thinking we should have ~ mentioned it in that other thread about OSPF Hellos ~ (although this problem ~ happens after the initial hellos). ~ ~ More here: ~ ~ http://www.cisco.com/warp/public/104/12.html ~ ~ Priscilla ~ ~ At 11:33 AM 4/17/02, Kane, Christopher A. wrote: ~ The most frequently mismatched parameters ~ relevant for OSPF ~ configuration ~ seem to be dead intervals mtu sizes. ~ ~ OSPF doesn't care about MTU size. ~ ~ ~ Priscilla Oppenheimer ~ http://www.priscilla.com ~ [EMAIL PROTECTED] ~ ~ ~ __ ~ Do You Yahoo!? ~ Yahoo! Tax Center - online filing with TurboTax ~ http://taxes.yahoo.com/ ~ ~ ~Priscilla Oppenheimer ~http://www.priscilla.com ~ ~ ~ ~ ~Report misconduct ~and Nondisclosure violations to [EMAIL PROTECTED] ~ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=42755t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
At 10:57 PM -0400 4/18/02, nrf wrote: Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... He didn't say that BGP negotiates the MTU in any of its PDUs. He just says that mismatched MTUs can be a problem, which is all I mentioned in my message about OSPF also (although OSPF does in fact also include the MTU in database description packets and refuse to become adjacent with a router that doesn't agree on the MTU). That's what I'm talking about - OSPFv2 does in fact include an MTU field in its PDU's (Ok, Ok, it's not really a negotiation per se, but still...), so if somebody starts a discussion about MTU and BGP, then it would stand to reason that BGP includes an MTU field somewhere, which I am not aware of. And besides, the idea of MTU problems in BGP is an interesting one, because of the fact that BGP peering often occurs between non-adjacent routers. What is the relevant MTU size of such a peering arrangement? The routers do not share a common network, so is it really relevant to talk about MTU? Did that have enough TLAs for you? ;-) I've read enough RFC's in my day to be impervious to TLA's. Yes, but now FLAs are quite routine. It's especially elegant that the F is overloaded for four (MPLS) and five (CAIDA), and we are scaling rapidly to higher values of xLA. Who says the Internet can't scale? :-) -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41925t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
There's not a word about MTU in draft 17 of the update to RFC1771 (even being on the working group, I'm not sure if draft 18 is out yet). There is a maximum update length of 4K, but updates are inherently variable length. At 9:53 PM -0400 4/18/02, nrf wrote: Really? I had never heard of this problem. I'm not aware that BGP negotiates MTU in any of its PDU's. Can you provide the RFC that discusses this problem? suaveguru wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes The term flapping in BGP generally means that a route is rapidly withdrawn and advertised many times in sequence. In general, high routing activity in BGP is called churn. This isn't in 1771, but we have documented it in http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-01.txt (hopefully we'll be posting -02 in a week or so, and then going into Last Call for RFC. This document is on BGP convergence). -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41930t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
That's what I thought, which is why what suaveguru said made me so curious. The only problems with MTU that I thought BGP would have are the same problems that any IP packet might have with MTU (fragmentation, etc.) Howard C. Berkowitz wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... There's not a word about MTU in draft 17 of the update to RFC1771 (even being on the working group, I'm not sure if draft 18 is out yet). There is a maximum update length of 4K, but updates are inherently variable length. At 9:53 PM -0400 4/18/02, nrf wrote: Really? I had never heard of this problem. I'm not aware that BGP negotiates MTU in any of its PDU's. Can you provide the RFC that discusses this problem? suaveguru wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes The term flapping in BGP generally means that a route is rapidly withdrawn and advertised many times in sequence. In general, high routing activity in BGP is called churn. This isn't in 1771, but we have documented it in http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-01.txt (hopefully we'll be posting -02 in a week or so, and then going into Last Call for RFC. This document is on BGP convergence). -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41967t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
BGP Keepalives are very short, but Updates can be very long. It looks like they can be 4096 bytes from RFC 1771 (not counting headers). BGP relies on TCP and IP, as you know, of course. Those layers would have to make sure that the IP Don't Fragment bit was set to 0 (which means May Fragment). I checked a few BGP packets from a Cisco router and they do seem to have that bit set to 0. I still think it's worth discussion, though. There may be some implementations that don't set the bit to 0. MTU problems also crop up in weird places due to tagging, although you might not expect to see that with BGP. The poster seems to have run into actual problems, though, maybe. Sorry if my message was a bit punchy. I just thought you sounded so imperious that I had to sound that way too. I'm glad that you are impervious to TLAs though. ;-) Priscilla At 10:57 PM 4/18/02, nrf wrote: Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... He didn't say that BGP negotiates the MTU in any of its PDUs. He just says that mismatched MTUs can be a problem, which is all I mentioned in my message about OSPF also (although OSPF does in fact also include the MTU in database description packets and refuse to become adjacent with a router that doesn't agree on the MTU). That's what I'm talking about - OSPFv2 does in fact include an MTU field in its PDU's (Ok, Ok, it's not really a negotiation per se, but still...), so if somebody starts a discussion about MTU and BGP, then it would stand to reason that BGP includes an MTU field somewhere, which I am not aware of. And besides, the idea of MTU problems in BGP is an interesting one, because of the fact that BGP peering often occurs between non-adjacent routers. What is the relevant MTU size of such a peering arrangement? The routers do not share a common network, so is it really relevant to talk about MTU? Did that have enough TLAs for you? ;-) I've read enough RFC's in my day to be impervious to TLA's. Priscilla At 09:53 PM 4/18/02, nrf wrote: Really? I had never heard of this problem. I'm not aware that BGP negotiates MTU in any of its PDU's. Can you provide the RFC that discusses this problem? suaveguru wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes regards, suaveguru --- Priscilla Oppenheimer wrote: The problem happens when the routers try to exchange database description packets. One side can send packets that are too large for the other side to receive. Then the routers never achieve adjacency. It's an infamous problem. I was glad that Kevin brought it up. I was thinking we should have mentioned it in that other thread about OSPF Hellos (although this problem happens after the initial hellos). More here: http://www.cisco.com/warp/public/104/12.html Priscilla At 11:33 AM 4/17/02, Kane, Christopher A. wrote: The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Priscilla Oppenheimer http://www.priscilla.com [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41984t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs EIGRP [7:41613]
If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes regards, suaveguru --- Priscilla Oppenheimer wrote: The problem happens when the routers try to exchange database description packets. One side can send packets that are too large for the other side to receive. Then the routers never achieve adjacency. It's an infamous problem. I was glad that Kevin brought it up. I was thinking we should have mentioned it in that other thread about OSPF Hellos (although this problem happens after the initial hellos). More here: http://www.cisco.com/warp/public/104/12.html Priscilla At 11:33 AM 4/17/02, Kane, Christopher A. wrote: The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Priscilla Oppenheimer http://www.priscilla.com [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41804t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
Really? I had never heard of this problem. I'm not aware that BGP negotiates MTU in any of its PDU's. Can you provide the RFC that discusses this problem? suaveguru wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes regards, suaveguru --- Priscilla Oppenheimer wrote: The problem happens when the routers try to exchange database description packets. One side can send packets that are too large for the other side to receive. Then the routers never achieve adjacency. It's an infamous problem. I was glad that Kevin brought it up. I was thinking we should have mentioned it in that other thread about OSPF Hellos (although this problem happens after the initial hellos). More here: http://www.cisco.com/warp/public/104/12.html Priscilla At 11:33 AM 4/17/02, Kane, Christopher A. wrote: The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Priscilla Oppenheimer http://www.priscilla.com [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41906t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
He didn't say that BGP negotiates the MTU in any of its PDUs. He just says that mismatched MTUs can be a problem, which is all I mentioned in my message about OSPF also (although OSPF does in fact also include the MTU in database description packets and refuse to become adjacent with a router that doesn't agree on the MTU). Did that have enough TLAs for you? ;-) Priscilla At 09:53 PM 4/18/02, nrf wrote: Really? I had never heard of this problem. I'm not aware that BGP negotiates MTU in any of its PDU's. Can you provide the RFC that discusses this problem? suaveguru wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes regards, suaveguru --- Priscilla Oppenheimer wrote: The problem happens when the routers try to exchange database description packets. One side can send packets that are too large for the other side to receive. Then the routers never achieve adjacency. It's an infamous problem. I was glad that Kevin brought it up. I was thinking we should have mentioned it in that other thread about OSPF Hellos (although this problem happens after the initial hellos). More here: http://www.cisco.com/warp/public/104/12.html Priscilla At 11:33 AM 4/17/02, Kane, Christopher A. wrote: The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Priscilla Oppenheimer http://www.priscilla.com [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41909t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... He didn't say that BGP negotiates the MTU in any of its PDUs. He just says that mismatched MTUs can be a problem, which is all I mentioned in my message about OSPF also (although OSPF does in fact also include the MTU in database description packets and refuse to become adjacent with a router that doesn't agree on the MTU). That's what I'm talking about - OSPFv2 does in fact include an MTU field in its PDU's (Ok, Ok, it's not really a negotiation per se, but still...), so if somebody starts a discussion about MTU and BGP, then it would stand to reason that BGP includes an MTU field somewhere, which I am not aware of. And besides, the idea of MTU problems in BGP is an interesting one, because of the fact that BGP peering often occurs between non-adjacent routers. What is the relevant MTU size of such a peering arrangement? The routers do not share a common network, so is it really relevant to talk about MTU? Did that have enough TLAs for you? ;-) I've read enough RFC's in my day to be impervious to TLA's. Priscilla At 09:53 PM 4/18/02, nrf wrote: Really? I had never heard of this problem. I'm not aware that BGP negotiates MTU in any of its PDU's. Can you provide the RFC that discusses this problem? suaveguru wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I am not wrong this problem also occurs for BGP peers with unmatched MTU sizes which causes BGP to flap when they exchange routing tables , especially if one neighbour is configured with full-routes regards, suaveguru --- Priscilla Oppenheimer wrote: The problem happens when the routers try to exchange database description packets. One side can send packets that are too large for the other side to receive. Then the routers never achieve adjacency. It's an infamous problem. I was glad that Kevin brought it up. I was thinking we should have mentioned it in that other thread about OSPF Hellos (although this problem happens after the initial hellos). More here: http://www.cisco.com/warp/public/104/12.html Priscilla At 11:33 AM 4/17/02, Kane, Christopher A. wrote: The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Priscilla Oppenheimer http://www.priscilla.com [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41911t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
oh yeah, it does, you can bet it does :) Try to set up a OSPF adjacency between 2 neighbors that have different MTU's in their interfaces and you will see it :) I went through a problem with that once, both routers had ATM int, but they had different MTU's (due some problems with the Passport ATM Net that we had). They would not form an adjacency, and the error message was about the DDP packets, which could not be exchanged once that the MTU didn't match. Persio - Original Message - From: Kane, Christopher A. To: Sent: Wednesday, April 17, 2002 12:33 PM Subject: RE: OSPF vs EIGRP [7:41613] The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41753t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
Kane, Christopher A. wrote in message news:[EMAIL PROTECTED]... The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Uh, excuse me? Go read RFC 2178 (OSPF v2), section G.9: When two neighboring routers have a different interface MTU for their common network segment, serious problems can ensue: large packets are prevented from being successfully transferred from one router to the other, impairing OSPF's flooding algorithm and possibly creating black holes for user data traffic. This memo [RFC2178] provides a fix for the interface MTU mismatch problem by advertising the interface MTU in Database Description packets. When a router receives a Database description packet advertising an MTU larger than the router can receive, the router drops the Database Description packet. This prevents an adjacency from forming, telling OSPF flooding and user data traffic to avoid the connection between the two routers. For more information, see Sections 10.6, 10.8, and A.3.3. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41756t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs EIGRP [7:41613]
The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Uh, excuse me? Go read RFC 2178 (OSPF v2), section G.9: When two neighboring routers have a different interface MTU for their common network segment, serious problems can ensue: large packets are prevented from being successfully transferred from one router to the other, impairing OSPF's flooding algorithm and possibly creating black holes for user data traffic. This memo [RFC2178] provides a fix for the interface MTU mismatch problem by advertising the interface MTU in Database Description packets. When a router receives a Database description packet advertising an MTU larger than the router can receive, the router drops the Database Description packet. This prevents an adjacency from forming, telling OSPF flooding and user data traffic to avoid the connection between the two routers. For more information, see Sections 10.6, 10.8, and A.3.3. Wow. The learning continues. I have never actually run into this problem. I have checked the RFC. That's RFC 2328 by the way, it obsoletes RFC 2178. Indeed, its during the Database Describtion Packet exchange that the MTU size is checked. The Database Description Packet format includes an Interface MTU field. But, why wait until the DDP phase of the neighbor/adjacency development? Why wouldn't this thing be a 'must match' situation and be included in the Hello packet? I just config'd it in my lab on a Point-to-Point and the neighbor state makes it to EXSTART and then stops. The router with the smaller MTU size reports the following in it's debug: Nbr x.x.x.x has larger interface MTU Only the router with the smaller MTU is upset by this. The router with the interface that has the larger MTU makes no mention of any problems. Quick search on CCO shows that Cisco has a work around for this: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr rp_r/1rfospf.htm#xtocid24 Again, learn something new everyday. Since MTU is never mentioned in the Hello packet, I thought it didn't matter. Sorry about posting inaccurate information. I appreciate the feedback pointing out my error. -chris Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41759t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs EIGRP [7:41613]
You got here just before I did. I was just about to say that RFC 2328 overrides 2178. Kane, Christopher A. wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Uh, excuse me? Go read RFC 2178 (OSPF v2), section G.9: When two neighboring routers have a different interface MTU for their common network segment, serious problems can ensue: large packets are prevented from being successfully transferred from one router to the other, impairing OSPF's flooding algorithm and possibly creating black holes for user data traffic. This memo [RFC2178] provides a fix for the interface MTU mismatch problem by advertising the interface MTU in Database Description packets. When a router receives a Database description packet advertising an MTU larger than the router can receive, the router drops the Database Description packet. This prevents an adjacency from forming, telling OSPF flooding and user data traffic to avoid the connection between the two routers. For more information, see Sections 10.6, 10.8, and A.3.3. Wow. The learning continues. I have never actually run into this problem. I have checked the RFC. That's RFC 2328 by the way, it obsoletes RFC 2178. Indeed, its during the Database Describtion Packet exchange that the MTU size is checked. The Database Description Packet format includes an Interface MTU field. But, why wait until the DDP phase of the neighbor/adjacency development? Why wouldn't this thing be a 'must match' situation and be included in the Hello packet? I just config'd it in my lab on a Point-to-Point and the neighbor state makes it to EXSTART and then stops. The router with the smaller MTU size reports the following in it's debug: Nbr x.x.x.x has larger interface MTU Only the router with the smaller MTU is upset by this. The router with the interface that has the larger MTU makes no mention of any problems. Quick search on CCO shows that Cisco has a work around for this: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr rp_r/1rfospf.htm#xtocid24 Again, learn something new everyday. Since MTU is never mentioned in the Hello packet, I thought it didn't matter. Sorry about posting inaccurate information. I appreciate the feedback pointing out my error. -chris Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41767t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs EIGRP [7:41613]
The problem happens when the routers try to exchange database description packets. One side can send packets that are too large for the other side to receive. Then the routers never achieve adjacency. It's an infamous problem. I was glad that Kevin brought it up. I was thinking we should have mentioned it in that other thread about OSPF Hellos (although this problem happens after the initial hellos). More here: http://www.cisco.com/warp/public/104/12.html Priscilla At 11:33 AM 4/17/02, Kane, Christopher A. wrote: The most frequently mismatched parameters relevant for OSPF configuration seem to be dead intervals mtu sizes. OSPF doesn't care about MTU size. Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41775t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs EIGRP [7:41613]
I currently manage a Large network (300) routers running OSPF and IPX. When I first got here the network was Proteon routers. The routers were severely limited in memory. Think 2500's with 8Mb RAM. We had a Cisco 5500 w/ RSM in the core and started to replace the Proteons with Bay ASN. So we had a Proteon/Cisco/Bay OSPF network. The only vendor compatibility problems were Proteon vs. everything else. The Bay's and Cisco's worked together fine. The IPX network is very large. 900 routes and 3500 SAP's. The Bay couldn't handle it. Honestly they were underspec'd (done before I got here). So the customer decided to replace the Bay with Cisco. We now have 2 7206VXR's in the core and 300+ 2600's in the remotes with about 20 3600's in regional centers. I like OSPF because or all the built in tweaks with different areas etc. I know of a much larger network here locally running BGP and EIGRP. You can do lot's with EIGRP in terms of different AS's and summarization. They have done some innovative things with the network and it works very well. In essence they have made an EIGRP network look and behave like an OSPF network. I would also look at IS-IS. It is a clean, neat protocol. I know many who aren't in the SP area are scared of IS-IS but it is a great protocol. Think OSPF without the Area 0 concept. You create different Areas of L1 routers and tie them together with L1/L2 routers. The primary problem in any large network is memory consumption on the routers. If all the routers must maintain full routing tables you can eat up a lot of memory. Whether you go OSPF, EIGRP, or IS-IS, you need to segment the network into logical summarization boundaries. I would draw out your network from a layer-2 perspective, find the logical boundaries for summarization, and then see what works for a routing protocol. In a poorly designed large network it doesn't matter if you are running OSPF, EIGRP, or IS-IS. Have I done a good job of not answering your question??? Email me if you want to discuss this further. Bill Carter CCIE 5022 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Madory Douglas C 1Lt 603 ACS/LGC Sent: Tuesday, April 16, 2002 10:21 AM To: [EMAIL PROTECTED] Subject: OSPF vs EIGRP [7:41613] What experiences have people had in setting up and maintaining OSPF vs EIGRP on a large network? I'm aware of the proprietary implications of EIGRP and the basic differences in design of the protocols - how they are _supposed_ to work, but, in practice, would you say one is more stable / dependable / manageable than the other? Also, what about OSPF between Cisco and non-Cisco products? Do they always work together like they're supposed to? If you have some first-hand experience with this, I'd really like to hear about it. Thanks, Doug. Douglas Madory,1st Lt Flt CC, C4I Systems 603 ACS / LGC UVA '99 WAHOOWA! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41620t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs EIGRP [7:41613]
Also, what about OSPF between Cisco and non-Cisco products? Do they always work together like they're supposed to? Doug, I've worked with OSPF in a multi-vendor environment and had no problems. All the required parameters in the Hello packets were met and neigh/adj's were established with no configuration changes needed. You need Area ID, Stub Flag, Auth and Hello/Dead Intervals to match. If you have problems getting neighbors to form, look for mismatches in the Hello packets. I can't answer your other questions from first hand experience. But I've heard other people comment that EIGRP tends to let you be 'sloppier' in your overall network design. OSPF works best when you can take advantage of multiple areas, summarization and use of stub networks. OSPF seems to require a little more thought and planning where as EIGRP seems to provide flexibility in a network that may not have been designed/or grown in the most optimal ways. -chris Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41629t=41613 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs. IS-IS
ospf. ISIS I have found is deployed mainly is Large Telcos. -Original Message- From: Jaeheon Yoo [mailto:[EMAIL PROTECTED]] Sent: 14 November 2000 09:02 To: [EMAIL PROTECTED] Subject: OSPF vs. IS-IS Which one is more widely deployed, OSPF or IS-IS? _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF vs. IS-IS
IS-IS is very stable and not so picky... ospf isnt the easiest to set up and isnt, in my opinion as stable. ospf on the other hand has more options... so its up to you :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of McCallum, Robert Sent: Tuesday, November 14, 2000 8:21 PM To: 'Jaeheon Yoo'; [EMAIL PROTECTED] Subject: RE: OSPF vs. IS-IS ospf. ISIS I have found is deployed mainly is Large Telcos. -Original Message- From: Jaeheon Yoo [mailto:[EMAIL PROTECTED]] Sent: 14 November 2000 09:02 To: [EMAIL PROTECTED] Subject: OSPF vs. IS-IS Which one is more widely deployed, OSPF or IS-IS? _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs. IS-IS
On Tue, 14 Nov 2000, Jaeheon Yoo wrote: Which one is more widely deployed, OSPF or IS-IS? I would say OSPF by far. But when it comes to very large scalable networks, I would say IS-IS. Brian _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] --- Brian Feeny, CCNP, CCDP [EMAIL PROTECTED] Network Administrator ShreveNet Inc. (ASN 11881) _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF vs ISIS
It looks to me that everybody prefers OSPF in our company, just wondering any reasons that we do not want to use ISIS? Thanks Kent For enterprise networks, there is no particular benefit to using ISIS. Many of the large ISPs do use it, in many cases for historical reasons. There are some cases where ISIS may have less overhead on the router than OSPF. Several vendors are deploying traffic engineering first with ISIS, but that is as much because their initial ISP customers have ISIS reasons as anything else. I'll be doing an ISIS tutorial next week at NANOG, and it will be posted under the notes for the June 2000 meeting at www.nanog.org On a practical certification basis, anyone that's aiming for the ISP market should know this protocol. ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
