RE: OSPF demand-circuit does not work [7:74954]
It will say multicast. Martijn -Oorspronkelijk bericht- Van: Devrim Yener KUCUK [mailto:[EMAIL PROTECTED] Verzonden: maandag 8 september 2003 16:38 Aan: [EMAIL PROTECTED] Onderwerp: Re: OSPF demand-circuit does not work [7:74954] what do you see when you do "sh dialer" on the calling router, as a dial reason? or debug dialer, debug isdn q931 will be telling you regards De - Original Message - From: "Lesly Verdier" To: Sent: Monday, September 08, 2003 2:25 PM Subject: OSPF demand-circuit does not work [7:74954] > Hello All, > > I've configured "ip ospf demand-circuit" on an ISDN connection and this > statement is supposed to supress the calls initiated by the Hello Packets. > Still my router keeps on dialing. > > Does anybody know what the reason might be? > > Thanks, > > Lesly Verdier > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=75250&t=74954 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF demand-circuit does not work [7:74954]
Devrim Yener KUCUK wrote: > what do you see when you do "sh dialer" on the calling router, as a dial > reason? > or debug dialer, debug isdn q931 will be telling you And "sh ip ospf stat" will show you activity of OSPF - remember that every change in OSPF topology can trigger dialer. -- EC Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=75038&t=74954 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF demand-circuit does not work [7:74954]
what do you see when you do "sh dialer" on the calling router, as a dial reason? or debug dialer, debug isdn q931 will be telling you regards De - Original Message - From: "Lesly Verdier" To: Sent: Monday, September 08, 2003 2:25 PM Subject: OSPF demand-circuit does not work [7:74954] > Hello All, > > I've configured "ip ospf demand-circuit" on an ISDN connection and this > statement is supposed to supress the calls initiated by the Hello Packets. > Still my router keeps on dialing. > > Does anybody know what the reason might be? > > Thanks, > > Lesly Verdier > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74967&t=74954 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: ospf type 5 lsas [7:74699]
someone requested the configs; i'm sorry, i'm not sure who. and the links are numbered, btw. 7500: interface atm 0/1/0.101 ip address 192.168.10.1 255.255.255.252 ! ! router ospf 120 network 192.168.10.0 0.0.0.3 area 0 network 10.64.0.0 0.0.0.255 area 14 ! 2500: interface ethernet 0 ip address 172.16.10.5 255.255.255.252 ! interface serial 0/0.101 point-to-point ip address 192.168.10.2 255.255.255.252 ! ! router ospf 120 network 192.168.10.0 0.0.0.3 area 0 network 172.16.10.4 0.0.0.3 area 15 area 15 nssa no-summary ! the only other router in area 15 is at 172.16.10.6, and is configured as an nssa asbr. the 7500 has all the type 5 lsas in its database, but none entered in its route table. eg: 7500#show ip ospf database external 200.88.200.220 OSPF Router with ID (200.55.10.244) (Process ID 20) Type-5 AS External Link States LS age: 2576 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 200.88.200.220 (External Network Number ) Advertising Router: 200.27.100.154 LS Seq Number: 8008 Checksum: 0x1A8B Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 2 Forward Address: 0.0.0.0 External Route Tag: 3221225472 7500#show ip route | include 200.88.200.220 7500# thomas - Original Message - From: Thomas Salmen To: [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 3:43 PM Subject: ospf type 5 lsas i have a problem with ospf that someone may be able to help with. i have a 2500 connected to a 7500 via a frame (2500 end) to atm (7500 end) link. the 2500 is an abr for area 15 (serial area 0, ethernet area 15); the 7500 is an abr for area 14 (atm area 0, other interfaces area 14). area 15 is configured as an nssa, as it is attached to another router which is redistributing static routes. area 14 is a standard ospf area, not stub or nssa. the 2500 (abr) is recieving type 7 lsas and converting them to type 5 and flooding them into area 0, no problems. the 7500 has them in its lsa database. the problem is that none of the type 5 lsas are being entered in the 7500s route table. i have run through everything i can think of, and i'm a bit stuck. the forwarding address of each lsa is 0.0.0.0. the network type is correct (ptp). the 7500 can reach the abr and the asbr. subnet masks are all correct. i'm not sure what to look for next... anyone? thomas **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74766&t=74699 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: ospf type 5 lsas [7:74699]
Looks like you have two OSPF processes on the 7500. Typical case of "less would be more"... :) Thanks, Zsombor Thomas Salmen wrote: > > someone requested the configs; i'm sorry, i'm not sure who. > > and the links are numbered, btw. > > > 7500: > > interface atm 0/1/0.101 > ip address 192.168.10.1 255.255.255.252 > > ! > > ! > router ospf 120 > network 192.168.10.0 0.0.0.3 area 0 > network 10.64.0.0 0.0.0.255 area 14 > > ! > > > > 2500: > > interface ethernet 0 > ip address 172.16.10.5 255.255.255.252 > ! > interface serial 0/0.101 point-to-point > ip address 192.168.10.2 255.255.255.252 > > ! > > ! > router ospf 120 > network 192.168.10.0 0.0.0.3 area 0 > network 172.16.10.4 0.0.0.3 area 15 > area 15 nssa no-summary > ! > > the only other router in area 15 is at 172.16.10.6, and is > configured as an > nssa asbr. > > the 7500 has all the type 5 lsas in its database, but none > entered in its > route table. > > eg: > > 7500#show ip ospf database external 200.88.200.220 > > OSPF Router with ID (200.55.10.244) (Process ID 20) > > Type-5 AS External Link States > > LS age: 2576 > Options: (No TOS-capability, DC) > LS Type: AS External Link > Link State ID: 200.88.200.220 (External Network Number ) > Advertising Router: 200.27.100.154 > LS Seq Number: 8008 > Checksum: 0x1A8B > Length: 36 > Network Mask: /32 > Metric Type: 2 (Larger than any link state path) > TOS: 0 > Metric: 2 > Forward Address: 0.0.0.0 > External Route Tag: 3221225472 > > 7500#show ip route | include 200.88.200.220 > > 7500# > > > > > thomas > > > > - Original Message - > From: Thomas Salmen > To: [EMAIL PROTECTED] > Sent: Tuesday, September 02, 2003 3:43 PM > Subject: ospf type 5 lsas > > > i have a problem with ospf that someone may be able to help > with. > > i have a 2500 connected to a 7500 via a frame (2500 end) to atm > (7500 end) > link. the 2500 is an abr for area 15 (serial area 0, ethernet > area 15); the > 7500 is an abr for area 14 (atm area 0, other interfaces area > 14). > > area 15 is configured as an nssa, as it is attached to another > router which is > redistributing static routes. area 14 is a standard ospf area, > not stub or > nssa. > > the 2500 (abr) is recieving type 7 lsas and converting them to > type 5 and > flooding them into area 0, no problems. the 7500 has them in > its lsa database. > the problem is that none of the type 5 lsas are being entered > in the 7500s > route table. > > i have run through everything i can think of, and i'm a bit > stuck. the > forwarding address of each lsa is 0.0.0.0. the network type is > correct (ptp). > the 7500 can reach the abr and the asbr. subnet masks are all > correct. i'm not > sure what to look for next... > > anyone? > > thomas > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74751&t=74699 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: ospf type 5 lsas [7:74699]
Mmm, looks like you have area 15 configured as a Not so stubby totally stubby area (NSSTSA) rather than as a not so stubby area (NSSA)...some slight differences as noted below; also, note how type 5 and 7 are (and are not) supportedLSA type 5 routes will not be used in a NSSA or NSSTSA; however, the same information conveyed by type 7 will (comes from ABR for the area). NSSA: If there is an ABR configured into this area (to area 0), it will convert the LSA type 7 to an LSA type 5. The LSA type 5 that was a LSA type 7 gets passed to the backbone area, where it gets distributed as a normal LSA type 5 to the rest of the OSPF routing domain. This LSA type 5 does not get sent into the NSSA because the NSSA does not allow LSA type 5 into the area.not to mention that the NSSA routers already have this information via the LSA type 7. By default, type 5 LSAs cannot be summarized at an ASBR or ABR, though Type 7 can. An area is configured as a NSSA with the following command in OSPF configuration mode. This command must be entered on all routers in the area in order for them to become neighbors. area 1 nssa About NSSTSA... The Not So Stubby Totally Stubby Area (NSSTSA) is a special definition of the NSSA. It is more restrictive regarding what it allows into the area. The NSSTSA is similar to the NSSA, except that it does not allow LSA type 3 and 4 into the area. Otherwise, the NSSTSA is just like a NSSA. The NSSTSA ASBR creates LSA type 7 for the routes that it is redistributing from another routing protocol into the NSSTSA. The NSSTSA ABR converts the 7 into a 5 for propagation to the rest of the OSPF domain. A default route, sent as a LSA type 3 summary, is the only exception to NSSTSA rule that no 3 or 4 is allowed into the area. To configure a NSSTSA, enter the following command on the NSSTSA ABR only. This configures the ABR not to send LSA type 3 and 4 into the NSSTSA. All routers will be configured with the NSSA command, as previously discussed. On the NSSTSA ABR only: area 1 nssa no-summary On all other NSSTSA routers: area 1 nssa HTH, Charles ""Thomas Salmen"" wrote in message news:[EMAIL PROTECTED] > someone requested the configs; i'm sorry, i'm not sure who. > > and the links are numbered, btw. > > > 7500: > > interface atm 0/1/0.101 > ip address 192.168.10.1 255.255.255.252 > > ! > > ! > router ospf 120 > network 192.168.10.0 0.0.0.3 area 0 > network 10.64.0.0 0.0.0.255 area 14 > > ! > > > > 2500: > > interface ethernet 0 > ip address 172.16.10.5 255.255.255.252 > ! > interface serial 0/0.101 point-to-point > ip address 192.168.10.2 255.255.255.252 > > ! > > ! > router ospf 120 > network 192.168.10.0 0.0.0.3 area 0 > network 172.16.10.4 0.0.0.3 area 15 > area 15 nssa no-summary > ! > > the only other router in area 15 is at 172.16.10.6, and is configured as an > nssa asbr. > > the 7500 has all the type 5 lsas in its database, but none entered in its > route table. > > eg: > > 7500#show ip ospf database external 200.88.200.220 > > OSPF Router with ID (200.55.10.244) (Process ID 20) > > Type-5 AS External Link States > > LS age: 2576 > Options: (No TOS-capability, DC) > LS Type: AS External Link > Link State ID: 200.88.200.220 (External Network Number ) > Advertising Router: 200.27.100.154 > LS Seq Number: 8008 > Checksum: 0x1A8B > Length: 36 > Network Mask: /32 > Metric Type: 2 (Larger than any link state path) > TOS: 0 > Metric: 2 > Forward Address: 0.0.0.0 > External Route Tag: 3221225472 > > 7500#show ip route | include 200.88.200.220 > > 7500# > > > > > thomas > > > > - Original Message - > From: Thomas Salmen > To: [EMAIL PROTECTED] > Sent: Tuesday, September 02, 2003 3:43 PM > Subject: ospf type 5 lsas > > > i have a problem with ospf that someone may be able to help with. > > i have a 2500 connected to a 7500 via a frame (2500 end) to atm (7500 end) > link. the 2500 is an abr for area 15 (serial area 0, ethernet area 15); the > 7500 is an abr for area 14 (atm area 0, other interfaces area 14). > > area 15 is configured as an nssa, as it is attached to another router which > is > redistributing static routes. area 14 is a standard ospf area, not stub or > nssa. > > the 2500 (abr) is recieving type 7 lsas and converting them to type 5 and > flooding them into area 0, no problems. the 7500 has them in its lsa > database. > the problem is that none of the type 5 lsas are being entered in the 7500s > route table. > > i have run through everything i can think of, and i'm a bit stuck. the > forwarding address of each lsa is 0.0.0.0. the network type is correct (ptp). > the 7500 can reach the abr and the asbr. subnet masks are all correct. i'm > not > sure what to look for next... > > anyone? > > thomas > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisc
Re: ospf type 5 lsas [7:74699]
someone requested the configs; i'm sorry, i'm not sure who. and the links are numbered, btw. 7500: interface atm 0/1/0.101 ip address 192.168.10.1 255.255.255.252 ! ! router ospf 120 network 192.168.10.0 0.0.0.3 area 0 network 10.64.0.0 0.0.0.255 area 14 ! 2500: interface ethernet 0 ip address 172.16.10.5 255.255.255.252 ! interface serial 0/0.101 point-to-point ip address 192.168.10.2 255.255.255.252 ! ! router ospf 120 network 192.168.10.0 0.0.0.3 area 0 network 172.16.10.4 0.0.0.3 area 15 area 15 nssa no-summary ! the only other router in area 15 is at 172.16.10.6, and is configured as an nssa asbr. the 7500 has all the type 5 lsas in its database, but none entered in its route table. eg: 7500#show ip ospf database external 200.88.200.220 OSPF Router with ID (200.55.10.244) (Process ID 20) Type-5 AS External Link States LS age: 2576 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 200.88.200.220 (External Network Number ) Advertising Router: 200.27.100.154 LS Seq Number: 8008 Checksum: 0x1A8B Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 2 Forward Address: 0.0.0.0 External Route Tag: 3221225472 7500#show ip route | include 200.88.200.220 7500# thomas - Original Message - From: Thomas Salmen To: [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 3:43 PM Subject: ospf type 5 lsas i have a problem with ospf that someone may be able to help with. i have a 2500 connected to a 7500 via a frame (2500 end) to atm (7500 end) link. the 2500 is an abr for area 15 (serial area 0, ethernet area 15); the 7500 is an abr for area 14 (atm area 0, other interfaces area 14). area 15 is configured as an nssa, as it is attached to another router which is redistributing static routes. area 14 is a standard ospf area, not stub or nssa. the 2500 (abr) is recieving type 7 lsas and converting them to type 5 and flooding them into area 0, no problems. the 7500 has them in its lsa database. the problem is that none of the type 5 lsas are being entered in the 7500s route table. i have run through everything i can think of, and i'm a bit stuck. the forwarding address of each lsa is 0.0.0.0. the network type is correct (ptp). the 7500 can reach the abr and the asbr. subnet masks are all correct. i'm not sure what to look for next... anyone? thomas Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74699&t=74699 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: ospf type 5 lsas [7:74632]
Can we see the configuration for the 2500 and 7500 (just the OSPF part). Also, is this route in the table at all? That is, is another protocol (like EIGRP) also advertising this route?? Thanks, Charles ""Thomas Salmen"" wrote in message news:[EMAIL PROTECTED] > i have a problem with ospf that someone may be able to help with. > > i have a 2500 connected to a 7500 via a frame (2500 end) to atm (7500 end) > link. the 2500 is an abr for area 15 (serial area 0, ethernet area 15); the > 7500 is an abr for area 14 (atm area 0, other interfaces area 14). > > area 15 is configured as an nssa, as it is attached to another router which > is > redistributing static routes. area 14 is a standard ospf area, not stub or > nssa. > > the 2500 (abr) is recieving type 7 lsas and converting them to type 5 and > flooding them into area 0, no problems. the 7500 has them in its lsa > database. > the problem is that none of the type 5 lsas are being entered in the 7500s > route table. > > i have run through everything i can think of, and i'm a bit stuck. the > forwarding address of each lsa is 0.0.0.0. the network type is correct (ptp). > the 7500 can reach the abr and the asbr. subnet masks are all correct. i'm > not > sure what to look for next... > > anyone? > > thomas > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74658&t=74632 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: ospf type 5 lsas [7:74632]
Are you using unnumbered on your serial interface? Try using an assigned IP address and see if that makes a difference. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Thomas Salmen [mailto:[EMAIL PROTECTED] Sent: Monday, September 01, 2003 11:44 PM To: [EMAIL PROTECTED] Subject: ospf type 5 lsas [7:74632] i have a problem with ospf that someone may be able to help with. i have a 2500 connected to a 7500 via a frame (2500 end) to atm (7500 end) link. the 2500 is an abr for area 15 (serial area 0, ethernet area 15); the 7500 is an abr for area 14 (atm area 0, other interfaces area 14). area 15 is configured as an nssa, as it is attached to another router which is redistributing static routes. area 14 is a standard ospf area, not stub or nssa. the 2500 (abr) is recieving type 7 lsas and converting them to type 5 and flooding them into area 0, no problems. the 7500 has them in its lsa database. the problem is that none of the type 5 lsas are being entered in the 7500s route table. i have run through everything i can think of, and i'm a bit stuck. the forwarding address of each lsa is 0.0.0.0. the network type is correct (ptp). the 7500 can reach the abr and the asbr. subnet masks are all correct. i'm not sure what to look for next... anyone? thomas **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74657&t=74632 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: ospf type 5 lsas [7:74632]
May be something related to default-originate. > -Original Message- > From: Thomas Salmen [SMTP:[EMAIL PROTECTED] > Sent: 02 September 2003 04:44 > To: [EMAIL PROTECTED] > Subject: ospf type 5 lsas [7:74632] > > i have a problem with ospf that someone may be able to help with. > > i have a 2500 connected to a 7500 via a frame (2500 end) to atm (7500 end) > link. the 2500 is an abr for area 15 (serial area 0, ethernet area 15); > the > 7500 is an abr for area 14 (atm area 0, other interfaces area 14). > > area 15 is configured as an nssa, as it is attached to another router > which > is > redistributing static routes. area 14 is a standard ospf area, not stub or > nssa. > > the 2500 (abr) is recieving type 7 lsas and converting them to type 5 and > flooding them into area 0, no problems. the 7500 has them in its lsa > database. > the problem is that none of the type 5 lsas are being entered in the 7500s > route table. > > i have run through everything i can think of, and i'm a bit stuck. the > forwarding address of each lsa is 0.0.0.0. the network type is correct > (ptp). > the 7500 can reach the abr and the asbr. subnet masks are all correct. i'm > not > sure what to look for next... > > anyone? > > thomas > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.UlsterBank.com ** This e-mail is for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mail messages are not necessarily secure. The Royal Bank of Scotland and each of its Group companies does not accept responsibility for changes made to this message after it was sent. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74640&t=74632 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF Cost [7:74098]
I think you got it wrong. 10^8 bites/second has cost 1. That means that cost 1 is 100 Mb/s. If you have higher bandwiths in you environment, you should set 'ospf auto-cost reference-bandwidth' to correct reference bandwith (if I get it right, this will then be cost 1 and all other costs will use this as a reference instead of 10^8). Be careful with this, especially with older IOSes and in multi-vendor env. Marko. - Original Message - From: To: Sent: Monday, August 18, 2003 9:31 AM Subject: OSPF Cost [7:74098] > Guys, > > Just to confirm that this is the correct costing default for OSPF :- > > 10*8 (1,,) \ bandwidth in kbps > > BW 1000 Kbit - 10Gig = OSPF Cost 10 > BW 100 Kbit - 1Gig= OSPF Cost 100 > BW 10 Kbit - 100Meg = OSPF Cost 1000 > BW1 Kbit - 10Meg = OSPF Cost 1 > BW 1544 Kbit - T1= OSPF Cost 64767 (rounded up) > BW 64 kbit - DS0 = OSPF Cost 1562500 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74099&t=74098 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF DR and BDR elections [7:73504]
If I am understanding this correctly. There are no routers up in the network. I turn on 3 routers simultaneously at the same time. The routers will first select the BDR. They will then look for the DR. Since none exist, the BDR will be promoted to DR. Then another election will be held to find a new BDR. Is this correct? -Original Message- From: Zsombor Papp [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 11:01 AM To: [EMAIL PROTECTED] Subject: RE: OSPF DR and BDR elections [7:73504] The DR is not chosen from the "remaining list." The DR is chosen from the list of routers that declared themselves designated routers (this is why a high-priority router that comes up late won't take over the DR role from an existing DR), or if no router declared itself DR, then the BDR will become DR (this is why a high-priority router that came up late won't necessarily become DR even if the existing DR dies). See RFC2328, Page 75 for more details. Thanks, Zsombor DeVoe, Charles (PKI) wrote: > > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle > from Sybex. In > the OSPF section under the discussion of DR and BDR (page 171) > he says that > the BDR is chosen first and that the DR is chosen from the > reaming list. > That seems illogical and backwards. Can someone please confirm > or deny and > explain it. Thanks **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73557&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF summary address with Null 0 [7:73500]
OSPF installs that summary route pointing to Null0 automatically. Thanks, Zsombor Shab Hanon wrote: > > Hi everybody > The case .. OSPF summary address with Null 0 > > In all the case studies for CCIE R & S we told don't use static > routes! . > While we need to have a static route to Null 0 with address > summarization. > "Page 548 Routing TCP/IP Vol. 1 > > The catch J > What we do? What is the best? > > Any idea??? > > > > Cheers, > Shab. > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73519&t=73500 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF summary address with Null 0 [7:73500]
It is easy to block other routes by using ACL with distribution-list FROM appearing in the routing table "in other word you can remove them from the routing table :)" No way to remove LSA from the ospf database. Soon I will try "no default-information originate always" :) Cheers, Shab. ""Zsombor Papp"" wrote in message news:[EMAIL PROTECTED] > Shab Hanon wrote: > > > > Can any one tell us how to block a default route? > > > > it is easy to block other routes by using ACL with > > distribution-list > > But > > how to remove the default route which is being advertised by " > > default-information originate always " command. > > 'no default-information originate always' :) > > Once it is in the OSPF database, you can't take it out. This is the same for > other routes as well, btw, so I am not quite sure I understand why you say > it's easy to block other routes. > > Thanks, > > Zsombor > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73625&t=73500 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF DR and BDR elections [7:73504]
That is the point I needed clarification on. Just seemed odd that the DR would not be established first, followed by the BDR. For a brief moment when the routers are first started, there is no DR, but there is a BDR. I wonder what the logic for that is. -Original Message- From: Zsombor Papp [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 8:20 PM To: [EMAIL PROTECTED] Subject: RE: OSPF DR and BDR elections [7:73504] Technically, the BDR is elected first. If no router is claiming to be a DR, then the BDR will be immediately promoted to DR. Nonetheless, the end result is pretty much what the web page referenced below describes. Thanks, Zsombor mccloud mike wrote: > > The DR is elected first by highest priority, the tie breaker is > highest RID. Then the process is repeated for the BDR. > > http://www.cisco.com/warp/customer/104/2.html#10.1 > > My understanding is that if the DR goes down then the BDR is > promoted to DR and an election is held for the new BDR. This > means that when the original DR comes back up it can not become > DR until both of the current DR and BDR go offline. > > Cheers, Mike > > DeVoe, Charles (PKI) wrote: > > > > If I am understanding this correctly. There are no routers up > > in the > > network. I turn on 3 routers simultaneously at the same > time. > > The routers > > will first select the BDR. They will then look for the DR. > > Since none > > exist, the BDR will be promoted to DR. Then another election > > will be held > > to find a new BDR. Is this correct? > > > > -Original Message- > > From: Zsombor Papp [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 05, 2003 11:01 AM > > To: [EMAIL PROTECTED] > > Subject: RE: OSPF DR and BDR elections [7:73504] > > > > > > The DR is not chosen from the "remaining list." The DR is > > chosen from the > > list of routers that declared themselves designated routers > > (this is why a > > high-priority router that comes up late won't take over the DR > > role from an > > existing DR), or if no router declared itself DR, then the BDR > > will become > > DR (this is why a high-priority router that came up late won't > > necessarily > > become DR even if the existing DR dies). > > > > See RFC2328, Page 75 for more details. > > > > Thanks, > > > > Zsombor > > > > DeVoe, Charles (PKI) wrote: > > > > > > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle > > > from Sybex. In > > > the OSPF section under the discussion of DR and BDR (page > > 171) > > > he says that > > > the BDR is chosen first and that the DR is chosen from the > > > reaming list. > > > That seems illogical and backwards. Can someone please > > confirm > > > or deny and > > > explain it. Thanks > > **Please support GroupStudy by purchasing from the GroupStudy > > Store: > > http://shop.groupstudy.com > > FAQ, list archives, and subscription info: > > http://www.groupstudy.com/list/cisco.html **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73597&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF DR and BDR elections [7:73504]
The OSPF interface priority is the parameter that controls DR election. Its default value is 1. When OSPF interface priority is 0, the router is not eligible to become a DR. If a router comes up on a network segment and there are no other routers there already, it will become a DR. If there is an existing DR (or BDR), the new router will NOT attempt to preempt them. If several routers come up at roughly the same time (or the DR fails), a new DR election process will be triggered. The router with the highest priority value then will become a DR. In short, the DR/BDR election process is not deterministic and depends on the sequence of events. Therefore it is important to be able to prevent routers from EVER becoming DR/BDR, when that is appropriate for the topology in which they are connected. This si accomplished by setting their OSPF interface priority to 0: ospf set interface priority 0 So there has to be a DR first and after that there will be an BDR If you start an router on itsself not yet connected to the network it will start as an BDR. Quoting "DeVoe, Charles (PKI)" : > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle from Sybex. In > the OSPF section under the discussion of DR and BDR (page 171) he says that > the BDR is chosen first and that the DR is chosen from the reaming list. > That seems illogical and backwards. Can someone please confirm or deny and > explain it. Thanks > **Please support GroupStudy by purchasing from the GroupStudy Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html > > Iwan Hoogendoorn Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73510&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF summary address with Null 0 [7:73500]
Can any one tell us how to block a default route? it is easy to block other routes by using ACL with distribution-list But how to remove the default route which is being advertised by " default-information originate always " command. ""Reimer, Fred"" wrote in message news:[EMAIL PROTECTED] > From the CCIE Power Session: > > "Unless a question says so, you are not permitted to use**: > > Static routes (of any kind) > > Default routes > > **Dynamic routes to null are permitted" > > Floating statics are also allowed: > > "ip route 2.2.2.0 255.255.255.0 1.1.1.2 240 > > * Uses a higher administrative distance so that dynamic protocols will take > precedence > > * Use only if explicitly allowed in a test question > > * Make sure the dynamic route actually exists when DDR is not active" > > HTH, > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary information which > may be legally privileged. It is intended only for the named recipient(s). > If an addressing or transmission error has misdirected the email, please > notify the author by replying to this message. If you are not the named > recipient, you are not authorized to use, disclose, distribute, copy, print > or rely on this email, and should immediately delete it from your computer. > > > -Original Message- > From: Shab Hanon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2003 5:30 AM > To: [EMAIL PROTECTED] > Subject: OSPF summary address with Null 0 [7:73500] > > Hi everybody > The case .. OSPF summary address with Null 0 > > In all the case studies for CCIE R & S we told don't use static routes! **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF DR and BDR elections [7:73504]
> > I wonder what the logic for that is. > > I wonder, too. :) The reason could be as simple as the possibility to reuse the code (or function-call). For that brief moment when there is BDR, but no DR, exactly the same code base can be used as if router has realized that DR just failed miserably :-). I just realized that my logic above actually makes sense. Of course, someone will correct me if I'm horribly wrong. Marko. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73628&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF summary address with Null 0 [7:73500]
Can you please give us the link to the CCIE power session. Cheers. ""Reimer, Fred"" wrote in message news:[EMAIL PROTECTED] > From the CCIE Power Session: > > "Unless a question says so, you are not permitted to use**: > > Static routes (of any kind) > > Default routes > > **Dynamic routes to null are permitted" > > Floating statics are also allowed: > > "ip route 2.2.2.0 255.255.255.0 1.1.1.2 240 > > * Uses a higher administrative distance so that dynamic protocols will take > precedence > > * Use only if explicitly allowed in a test question > > * Make sure the dynamic route actually exists when DDR is not active" > > HTH, > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary information which > may be legally privileged. It is intended only for the named recipient(s). > If an addressing or transmission error has misdirected the email, please > notify the author by replying to this message. If you are not the named > recipient, you are not authorized to use, disclose, distribute, copy, print > or rely on this email, and should immediately delete it from your computer. > > > -Original Message- > From: Shab Hanon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2003 5:30 AM > To: [EMAIL PROTECTED] > Subject: OSPF summary address with Null 0 [7:73500] > > Hi everybody > The case .. OSPF summary address with Null 0 > > In all the case studies for CCIE R & S we told don't use static routes! **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF DR and BDR elections [7:73504]
It may be stated that way in the RFC, I have not checked, but the logic of it is il, as in illogical. ;-) Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: DeVoe, Charles (PKI) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: RE: OSPF DR and BDR elections [7:73504] That is the point I needed clarification on. Just seemed odd that the DR would not be established first, followed by the BDR. For a brief moment when the routers are first started, there is no DR, but there is a BDR. I wonder what the logic for that is. -Original Message- From: Zsombor Papp [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 8:20 PM To: [EMAIL PROTECTED] Subject: RE: OSPF DR and BDR elections [7:73504] Technically, the BDR is elected first. If no router is claiming to be a DR, then the BDR will be immediately promoted to DR. Nonetheless, the end result is pretty much what the web page referenced below describes. Thanks, Zsombor mccloud mike wrote: > > The DR is elected first by highest priority, the tie breaker is > highest RID. Then the process is repeated for the BDR. > > http://www.cisco.com/warp/customer/104/2.html#10.1 > > My understanding is that if the DR goes down then the BDR is > promoted to DR and an election is held for the new BDR. This > means that when the original DR comes back up it can not become > DR until both of the current DR and BDR go offline. > > Cheers, Mike > > DeVoe, Charles (PKI) wrote: > > > > If I am understanding this correctly. There are no routers up > > in the > > network. I turn on 3 routers simultaneously at the same > time. > > The routers > > will first select the BDR. They will then look for the DR. > > Since none > > exist, the BDR will be promoted to DR. Then another election > > will be held > > to find a new BDR. Is this correct? > > > > -Original Message- > > From: Zsombor Papp [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 05, 2003 11:01 AM > > To: [EMAIL PROTECTED] > > Subject: RE: OSPF DR and BDR elections [7:73504] > > > > > > The DR is not chosen from the "remaining list." The DR is > > chosen from the > > list of routers that declared themselves designated routers > > (this is why a > > high-priority router that comes up late won't take over the DR > > role from an > > existing DR), or if no router declared itself DR, then the BDR > > will become > > DR (this is why a high-priority router that came up late won't > > necessarily > > become DR even if the existing DR dies). > > > > See RFC2328, Page 75 for more details. > > > > Thanks, > > > > Zsombor > > > > DeVoe, Charles (PKI) wrote: > > > > > > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle > > > from Sybex. In > > > the OSPF section under the discussion of DR and BDR (page > > 171) > > > he says that > > > the BDR is chosen first and that the DR is chosen from the > > > reaming list. > > > That seems illogical and backwards. Can someone please > > confirm > > > or deny and > > > explain it. Thanks > > **Please support GroupStudy by purchasing from the GroupStudy > > Store: > > http://shop.groupstudy.com > > FAQ, list archives, and subscription info: > > http://www.groupstudy.com/list/cisco.html **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73602&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF DR and BDR elections [7:73504]
At 8:08 PM + 8/6/03, Marko Milivojevic wrote: > > > I wonder what the logic for that is. >> >> I wonder, too. :) > > The reason could be as simple as the possibility to reuse the code (or >function-call). For that brief moment when there is BDR, but no DR, exactly >the same code base can be used as if router has realized that DR just failed >miserably :-). > > I just realized that my logic above actually makes sense. Of course, >someone will correct me if I'm horribly wrong. > That's the exact reason it's done that way. I think it's documented in the code in Moy's second book on implementation, but it might be the first. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73636&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF DR and BDR elections [7:73504]
The DR is not chosen from the "remaining list." The DR is chosen from the list of routers that declared themselves designated routers (this is why a high-priority router that comes up late won't take over the DR role from an existing DR), or if no router declared itself DR, then the BDR will become DR (this is why a high-priority router that came up late won't necessarily become DR even if the existing DR dies). See RFC2328, Page 75 for more details. Thanks, Zsombor DeVoe, Charles (PKI) wrote: > > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle > from Sybex. In > the OSPF section under the discussion of DR and BDR (page 171) > he says that > the BDR is chosen first and that the DR is chosen from the > reaming list. > That seems illogical and backwards. Can someone please confirm > or deny and > explain it. Thanks > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73524&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF summary address with Null 0 [7:73500]
Good question. Null0 will only be used if it can't find a particular address. It's used to prevent routing loops essentially. ""Shab Hanon"" wrote in message news:[EMAIL PROTECTED] > Hi everybody > The case .. OSPF summary address with Null 0 > > In all the case studies for CCIE R & S we told don't use static routes! **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF DR and BDR elections [7:73504]
> I wonder what the logic for that is. I wonder, too. :) Without answering your question, I would like to point out though that the "moment" for which there is BDR but no DR is *really* brief. The election process is not something that the routers need to discuss among themselves; every router elects the DR/BDR independently. This is a point that folks miss sometimes. So if there is no DR, then the router that eventually becomes the DR will know *immediately* that it needs to be the DR, because the DR selection is just a function call away from the BDR selection. It's not like the routers have a chit-chat to discuss who will be the BDR, and then they have a rest, and subsequently they discuss who will be the DR... :) In other words, there is no OSPF information exchange between the routers during the process described on Page 75 in RFC2328. Another slightly related thing is that, in the scenario you described below, ie. when all the routers on the same segment are booting up at the same time, then for a relatively long time (ie. the Dead interval) all of them will go into a Waiting state so there won't be any election process for long-long seconds to start with. Compared to this, I guess it is pretty insignificant whether the election process selects the DR a few microseconds sooner or later. Thanks, Zsombor DeVoe, Charles (PKI) wrote: > > That is the point I needed clarification on. Just seemed odd > that the DR > would not be established first, followed by the BDR. For a > brief moment > when the routers are first started, there is no DR, but there > is a BDR. I > wonder what the logic for that is. > > -Original Message- > From: Zsombor Papp [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2003 8:20 PM > To: [EMAIL PROTECTED] > Subject: RE: OSPF DR and BDR elections [7:73504] > > > Technically, the BDR is elected first. If no router is claiming > to be a DR, > then the BDR will be immediately promoted to DR. Nonetheless, > the end result > is pretty much what the web page referenced below describes. > > Thanks, > > Zsombor > > mccloud mike wrote: > > > > The DR is elected first by highest priority, the tie breaker > is > > highest RID. Then the process is repeated for the BDR. > > > > http://www.cisco.com/warp/customer/104/2.html#10.1 > > > > My understanding is that if the DR goes down then the BDR is > > promoted to DR and an election is held for the new BDR. This > > means that when the original DR comes back up it can not > become > > DR until both of the current DR and BDR go offline. > > > > Cheers, Mike > > > > DeVoe, Charles (PKI) wrote: > > > > > > If I am understanding this correctly. There are no routers > up > > > in the > > > network. I turn on 3 routers simultaneously at the same > > time. > > > The routers > > > will first select the BDR. They will then look for the DR. > > > Since none > > > exist, the BDR will be promoted to DR. Then another > election > > > will be held > > > to find a new BDR. Is this correct? > > > > > > -Original Message- > > > From: Zsombor Papp [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, August 05, 2003 11:01 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: OSPF DR and BDR elections [7:73504] > > > > > > > > > The DR is not chosen from the "remaining list." The DR is > > > chosen from the > > > list of routers that declared themselves designated routers > > > (this is why a > > > high-priority router that comes up late won't take over the > DR > > > role from an > > > existing DR), or if no router declared itself DR, then the > BDR > > > will become > > > DR (this is why a high-priority router that came up late > won't > > > necessarily > > > become DR even if the existing DR dies). > > > > > > See RFC2328, Page 75 for more details. > > > > > > Thanks, > > > > > > Zsombor > > > > > > DeVoe, Charles (PKI) wrote: > > > > > > > > I am reading the CCNP/CCIP BSCI Study Guide by Todd > Lammle > > > > from Sybex. In > > > > the OSPF section under the discussion of DR and BDR (page > > > 171) > > > > he says that > > > > the BDR is chosen first and that the DR is chosen from the > > > > reaming list. > > > > That seems illogical and backwards. Can someone please > > > confirm > > > > or deny and > > > &
RE: OSPF DR and BDR elections [7:73504]
Technically, the BDR is elected first. If no router is claiming to be a DR, then the BDR will be immediately promoted to DR. Nonetheless, the end result is pretty much what the web page referenced below describes. Thanks, Zsombor mccloud mike wrote: > > The DR is elected first by highest priority, the tie breaker is > highest RID. Then the process is repeated for the BDR. > > http://www.cisco.com/warp/customer/104/2.html#10.1 > > My understanding is that if the DR goes down then the BDR is > promoted to DR and an election is held for the new BDR. This > means that when the original DR comes back up it can not become > DR until both of the current DR and BDR go offline. > > Cheers, Mike > > DeVoe, Charles (PKI) wrote: > > > > If I am understanding this correctly. There are no routers up > > in the > > network. I turn on 3 routers simultaneously at the same > time. > > The routers > > will first select the BDR. They will then look for the DR. > > Since none > > exist, the BDR will be promoted to DR. Then another election > > will be held > > to find a new BDR. Is this correct? > > > > -Original Message- > > From: Zsombor Papp [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 05, 2003 11:01 AM > > To: [EMAIL PROTECTED] > > Subject: RE: OSPF DR and BDR elections [7:73504] > > > > > > The DR is not chosen from the "remaining list." The DR is > > chosen from the > > list of routers that declared themselves designated routers > > (this is why a > > high-priority router that comes up late won't take over the DR > > role from an > > existing DR), or if no router declared itself DR, then the BDR > > will become > > DR (this is why a high-priority router that came up late won't > > necessarily > > become DR even if the existing DR dies). > > > > See RFC2328, Page 75 for more details. > > > > Thanks, > > > > Zsombor > > > > DeVoe, Charles (PKI) wrote: > > > > > > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle > > > from Sybex. In > > > the OSPF section under the discussion of DR and BDR (page > > 171) > > > he says that > > > the BDR is chosen first and that the DR is chosen from the > > > reaming list. > > > That seems illogical and backwards. Can someone please > > confirm > > > or deny and > > > explain it. Thanks > > **Please support GroupStudy by purchasing from the GroupStudy > > Store: > > http://shop.groupstudy.com > > FAQ, list archives, and subscription info: > > http://www.groupstudy.com/list/cisco.html > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73575&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF summary address with Null 0 [7:73500]
Shab Hanon wrote: > > Can any one tell us how to block a default route? > > it is easy to block other routes by using ACL with > distribution-list > But > how to remove the default route which is being advertised by " > default-information originate always " command. 'no default-information originate always' :) Once it is in the OSPF database, you can't take it out. This is the same for other routes as well, btw, so I am not quite sure I understand why you say it's easy to block other routes. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73556&t=73500 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF DR and BDR elections [7:73504]
The DR is elected first by highest priority, the tie breaker is highest RID. Then the process is repeated for the BDR. http://www.cisco.com/warp/customer/104/2.html#10.1 My understanding is that if the DR goes down then the BDR is promoted to DR and an election is held for the new BDR. This means that when the original DR comes back up it can not become DR until both of the current DR and BDR go offline. Cheers, Mike DeVoe, Charles (PKI) wrote: > > If I am understanding this correctly. There are no routers up > in the > network. I turn on 3 routers simultaneously at the same time. > The routers > will first select the BDR. They will then look for the DR. > Since none > exist, the BDR will be promoted to DR. Then another election > will be held > to find a new BDR. Is this correct? > > -Original Message- > From: Zsombor Papp [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2003 11:01 AM > To: [EMAIL PROTECTED] > Subject: RE: OSPF DR and BDR elections [7:73504] > > > The DR is not chosen from the "remaining list." The DR is > chosen from the > list of routers that declared themselves designated routers > (this is why a > high-priority router that comes up late won't take over the DR > role from an > existing DR), or if no router declared itself DR, then the BDR > will become > DR (this is why a high-priority router that came up late won't > necessarily > become DR even if the existing DR dies). > > See RFC2328, Page 75 for more details. > > Thanks, > > Zsombor > > DeVoe, Charles (PKI) wrote: > > > > I am reading the CCNP/CCIP BSCI Study Guide by Todd Lammle > > from Sybex. In > > the OSPF section under the discussion of DR and BDR (page > 171) > > he says that > > the BDR is chosen first and that the DR is chosen from the > > reaming list. > > That seems illogical and backwards. Can someone please > confirm > > or deny and > > explain it. Thanks > **Please support GroupStudy by purchasing from the GroupStudy > Store: > http://shop.groupstudy.com > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73558&t=73504 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: OSPF summary address with Null 0 [7:73500]
under ospf no discard route internal (does not install the Null0 route in routing table) no discard route external (used whey you use the summary address command) Ronnie ""Shab Hanon"" wrote in message news:[EMAIL PROTECTED] > Hi everybody > The case .. OSPF summary address with Null 0 > > In all the case studies for CCIE R & S we told don't use static routes! **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF summary address with Null 0 [7:73500]
As far as I know, there isn't one. I consider it fair use to quote a small section of the handouts they provided, but it was a separate charge to attend at Networkers, so I don't believe it would be ethical to just type the whole thing (and I don't really feel like typing the whole thing ;-) If you have a specific question I'll try to answer it. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Shab Hanon [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 8:55 AM To: [EMAIL PROTECTED] Subject: Re: OSPF summary address with Null 0 [7:73500] Can you please give us the link to the CCIE power session. Cheers. ""Reimer, Fred"" wrote in message news:[EMAIL PROTECTED] > From the CCIE Power Session: > > "Unless a question says so, you are not permitted to use**: > > Static routes (of any kind) > > Default routes > > **Dynamic routes to null are permitted" > > Floating statics are also allowed: > > "ip route 2.2.2.0 255.255.255.0 1.1.1.2 240 > > * Uses a higher administrative distance so that dynamic protocols will take > precedence > > * Use only if explicitly allowed in a test question > > * Make sure the dynamic route actually exists when DDR is not active" > > HTH, > > Fred Reimer - CCNA > > > Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 > Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > > NOTICE; This email contains confidential or proprietary information which > may be legally privileged. It is intended only for the named recipient(s). > If an addressing or transmission error has misdirected the email, please > notify the author by replying to this message. If you are not the named > recipient, you are not authorized to use, disclose, distribute, copy, print > or rely on this email, and should immediately delete it from your computer. > > > -Original Message- > From: Shab Hanon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2003 5:30 AM > To: [EMAIL PROTECTED] > Subject: OSPF summary address with Null 0 [7:73500] > > Hi everybody > The case .. OSPF summary address with Null 0 > > In all the case studies for CCIE R & S we told don't use static routes! **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73530&t=73500 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF summary address with Null 0 [7:73500]
>From the CCIE Power Session: "Unless a question says so, you are not permitted to use**: Static routes (of any kind) Default routes **Dynamic routes to null are permitted" Floating statics are also allowed: "ip route 2.2.2.0 255.255.255.0 1.1.1.2 240 * Uses a higher administrative distance so that dynamic protocols will take precedence * Use only if explicitly allowed in a test question * Make sure the dynamic route actually exists when DDR is not active" HTH, Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Shab Hanon [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 5:30 AM To: [EMAIL PROTECTED] Subject: OSPF summary address with Null 0 [7:73500] Hi everybody The case .. OSPF summary address with Null 0 In all the case studies for CCIE R & S we told don't use static routes! . While we need to have a static route to Null 0 with address summarization. "Page 548 Routing TCP/IP Vol. 1 The catch J What we do? What is the best? Any idea??? Cheers, Shab. **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73507&t=73500 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: OSPF Book - Tom Thomas 2nd Edition [7:73318]
Tried Amazon? Martijn -Oorspronkelijk bericht- Van: Daniel Cotts [mailto:[EMAIL PROTECTED] Verzonden: donderdag 31 juli 2003 23:14 Aan: [EMAIL PROTECTED] Onderwerp: OSPF Book - Tom Thomas 2nd Edition [7:73318] I'm looking for an evaluation of the second edition of Tom Thomas' "OSPF Network Design Solutions". I have the first edition and am wondering if there are major differences/improvements between the editions. Thanks in advance. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=73330&t=73318 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF through PIX [7:72938]
OSPF doesn't generate broadcast packets. It genereates multicast packets; the ones addressed to 224.0.0.5 are received by all OSPF routers, and the ones addressed to 224.0.0.6 are received by all DRs. I suppose you should allow transport protocol number 89 - if you only allow TCP (6) and UDP (17), OSPF information just won't get through. That's my $0.02. Take my advice with a grain of salt, however, because I've only recently started to prepare for my Routing exam. Georger Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72953&t=72938 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF through PIX [7:72938]
Get PIXOS 6.3, enable OSPF on the firewall, and let it participate in OSPF routing...voila! OSPF "through" the firewall... Also, how about using neighbor statements (with no translation) which converts the OSPF multicasts to unicasts? Just a thoughtobviously, would need an ACL applied at key points. ""Robertson, Douglas"" wrote in message news:[EMAIL PROTECTED] > OSPF through a PIX firewall is not supported. There are two ways to > configure routing through a PIX. > 1) Configure a GRE tunnel between the two routers. > 2) Configure BGP between the two routers. > The two choices have different implications depending on your specific > network. > > Thanks Doug > > -Original Message- > From: Massucco Emanuele [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 11:28 AM > To: [EMAIL PROTECTED] > Subject: OSPF through PIX [7:72938] > > > Does anyone know if there are any problems configuring OSPF trhough PIX > interfaces? > I know PIX should block broadcast, so which is the way to make it work? > > thanks > LEle Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72958&t=72938 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF through PIX [7:72938]
Only possible way would be to have a tunnel interface through the PIX, and run OSPF over that. I think. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Massucco Emanuele [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:28 AM To: [EMAIL PROTECTED] Subject: OSPF through PIX [7:72938] Does anyone know if there are any problems configuring OSPF trhough PIX interfaces? I know PIX should block broadcast, so which is the way to make it work? thanks LEle Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72947&t=72938 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF through PIX [7:72938]
OSPF through a PIX firewall is not supported. There are two ways to configure routing through a PIX. 1) Configure a GRE tunnel between the two routers. 2) Configure BGP between the two routers. The two choices have different implications depending on your specific network. Thanks Doug -Original Message- From: Massucco Emanuele [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:28 AM To: [EMAIL PROTECTED] Subject: OSPF through PIX [7:72938] Does anyone know if there are any problems configuring OSPF trhough PIX interfaces? I know PIX should block broadcast, so which is the way to make it work? thanks LEle Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72952&t=72938 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF Neighbor State is "Flapping" [7:72874]
do the mtus all match? do big packets get through? /thomas > > > Hi all, > > I have 3 devices on an ethernet segment where all ethernet > interfaces are in > the same vlan and ospf area 0 > > catalyst 3550priority 0rid 1.1.1.1 > router5priority 2 rid 55.55.55.55BDR > router1priority 3 rid 11.11.11.11DR > > The problem is that the switch keeps changing it's state. For > example, from > the router 1 perspective I get the following: > ( sh ip ospf nei command ) > > > Neighbor ID Pri State Dead Time Address > Interface > 1.1.1.1 0 DOWN/DROTHER -150.50.15.8 > Ethernet0 > 55.55.55.55 2 FULL/BDR00:00:35150.50.15.5 > Ethernet0 > > Neighbor ID Pri State Dead Time Address > Interface > 1.1.1.1 0 EXSTART/DROTHER 00:00:35150.50.15.8 > Ethernet0 > 55.55.55.55 2 FULL/BDR00:00:38150.50.15.5 > Ethernet0 > > and on and on, back and forth etc. > > router 5 perspective: > > > Neighbor ID Pri State Dead Time Address > Interface > 1.1.1.1 0 EXSTART/DROTHER 00:00:38150.50.15.8 > Ethernet0/0 > 11.11.11.11 3 FULL/DR 00:00:30150.50.15.1 > Ethernet0/0 > > Neighbor ID Pri State Dead Time Address > Interface > 1.1.1.1 0 DOWN/DROTHER -150.50.15.8 > Ethernet0/0 > 11.11.11.11 3 FULL/DR 00:00:32150.50.15.1 > Ethernet0/0 > > ..switch perspective: > > Neighbor ID Pri State Dead Time Address > Interface > 55.55.55.55 2 INIT/DROTHER00:00:33150.50.15.5 > Vlan15 > 11.11.11.11 3 INIT/DROTHER00:00:39150.50.15.1 > Vlan15 > > Neighbor ID Pri State Dead Time Address > Interface > 55.55.55.55 2 INIT/DROTHER00:00:37150.50.15.5 > Vlan15 > 11.11.11.11 3 EXCHANGE/DR 00:00:36150.50.15.1 > Vlan15 > > Neighbor ID Pri State Dead Time Address > Interface > 55.55.55.55 2 EXCHANGE/BDR00:00:39150.50.15.5 > Vlan15 > 11.11.11.11 3 EXCHANGE/DR 00:00:39150.50.15.1 > Vlan15 > > So...it seems as though r1 and r5 are recognizing eachother's > roles as dr > and bdr correctly. But they see the switch as down or init or exchange > DROTHER. > The switch however, sees itelf as DROTHER and r1/r5 as DROTHER or > init/exchange dr and bdr. Here is the output from "sh ip ospf > int vlan15" on > the switch: > > Vlan15 is up, line protocol is up > Internet Address 150.50.15.8/24, Area 0 > Process ID 100, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 > Transmit Delay is 1 sec, State DROTHER, Priority 0 > No designated router on this network > No backup designated router on this network > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 > Hello due in 00:00:07 > Index 1/1, flood queue length 0 > Next 0x0(0)/0x0(0) > Last flood scan length is 0, maximum is 0 > Last flood scan time is 0 msec, maximum is 0 msec > Neighbor Count is 2, Adjacent neighbor count is 0 > Suppress hello for 0 neighbor(s) > > Then two seconds laterit changes... > > Vlan15 is up, line protocol is up > Internet Address 150.50.15.8/24, Area 0 > Process ID 100, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 > Transmit Delay is 1 sec, State DROTHER, Priority 0 > Designated Router (ID) 11.11.11.11, Interface address 150.50.15.1 > Backup Designated router (ID) 55.55.55.55, Interface > address 150.50.15.5 > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 > Hello due in 00:00:05 > Index 1/1, flood queue length 0 > Next 0x0(0)/0x0(0) > Last flood scan length is 0, maximum is 0 > Last flood scan time is 0 msec, maximum is 0 msec > Neighbor Count is 2, Adjacent neighbor count is 0 > Suppress hello for 0 neighbor(s) > > > Any ideas? > > Thanks, > > > -- > Dain Deutschman > CCNP, CSS-1, MCP, CNA > Data Communications Manager > New Star Sales and Service, Inc. > > > > > > > -- > Dain Deutschman > CCNP, CSS-1, MCP, CNA > Data Communications Manager > New Star Sales and Service, Inc. > 800.261.0475 > [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72881&t=72874 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Neighbor State is "Flapping" [7:72874]
Figured it out... It was an mtu mismatch ( router e0 mtu 1500, cat vlan15 mtu 1518 ). A "deb ip ospf adj" on r1 revealed the problem. Since changing mtu on lan interface is not possible in IOS...the interface command "ip ospf mtu-ignore" allowed OSPF to deal with the mismatch and just form the adjacency. The cisco url is:www.cisco.com/warp/public/104/12.pdf Thanks anyway! Dain ""Dain Deutschman"" wrote in message news:[EMAIL PROTECTED] > Hi all, > > I have 3 devices on an ethernet segment where all ethernet interfaces are in > the same vlan and ospf area 0 > > catalyst 3550priority 0rid 1.1.1.1 > router5priority 2 rid 55.55.55.55BDR > router1priority 3 rid 11.11.11.11DR > > The problem is that the switch keeps changing it's state. For example, from > the router 1 perspective I get the following: > ( sh ip ospf nei command ) > > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 0 DOWN/DROTHER -150.50.15.8 Ethernet0 > 55.55.55.55 2 FULL/BDR00:00:35150.50.15.5 Ethernet0 > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 0 EXSTART/DROTHER 00:00:35150.50.15.8 Ethernet0 > 55.55.55.55 2 FULL/BDR00:00:38150.50.15.5 Ethernet0 > > and on and on, back and forth etc. > > router 5 perspective: > > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 0 EXSTART/DROTHER 00:00:38150.50.15.8 > Ethernet0/0 > 11.11.11.11 3 FULL/DR 00:00:30150.50.15.1 > Ethernet0/0 > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 0 DOWN/DROTHER -150.50.15.8 > Ethernet0/0 > 11.11.11.11 3 FULL/DR 00:00:32150.50.15.1 > Ethernet0/0 > > ..switch perspective: > > Neighbor ID Pri State Dead Time Address Interface > 55.55.55.55 2 INIT/DROTHER00:00:33150.50.15.5 Vlan15 > 11.11.11.11 3 INIT/DROTHER00:00:39150.50.15.1 Vlan15 > > Neighbor ID Pri State Dead Time Address Interface > 55.55.55.55 2 INIT/DROTHER00:00:37150.50.15.5 Vlan15 > 11.11.11.11 3 EXCHANGE/DR 00:00:36150.50.15.1 Vlan15 > > Neighbor ID Pri State Dead Time Address Interface > 55.55.55.55 2 EXCHANGE/BDR00:00:39150.50.15.5 Vlan15 > 11.11.11.11 3 EXCHANGE/DR 00:00:39150.50.15.1 Vlan15 > > So...it seems as though r1 and r5 are recognizing eachother's roles as dr > and bdr correctly. But they see the switch as down or init or exchange > DROTHER. > The switch however, sees itelf as DROTHER and r1/r5 as DROTHER or > init/exchange dr and bdr. Here is the output from "sh ip ospf int vlan15" on > the switch: > > Vlan15 is up, line protocol is up > Internet Address 150.50.15.8/24, Area 0 > Process ID 100, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 > Transmit Delay is 1 sec, State DROTHER, Priority 0 > No designated router on this network > No backup designated router on this network > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 > Hello due in 00:00:07 > Index 1/1, flood queue length 0 > Next 0x0(0)/0x0(0) > Last flood scan length is 0, maximum is 0 > Last flood scan time is 0 msec, maximum is 0 msec > Neighbor Count is 2, Adjacent neighbor count is 0 > Suppress hello for 0 neighbor(s) > > Then two seconds laterit changes... > > Vlan15 is up, line protocol is up > Internet Address 150.50.15.8/24, Area 0 > Process ID 100, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 > Transmit Delay is 1 sec, State DROTHER, Priority 0 > Designated Router (ID) 11.11.11.11, Interface address 150.50.15.1 > Backup Designated router (ID) 55.55.55.55, Interface address 150.50.15.5 > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 > Hello due in 00:00:05 > Index 1/1, flood queue length 0 > Next 0x0(0)/0x0(0) > Last flood scan length is 0, maximum is 0 > Last flood scan time is 0 msec, maximum is 0 msec > Neighbor Count is 2, Adjacent neighbor count is 0 > Suppress hello for 0 neighbor(s) > > > Any ideas? > > Thanks, > > > -- > Dain Deutschman > CCNP, CSS-1, MCP, CNA > Data Communications Manager > New Star Sales and Service, Inc. > > > > > > > -- > Dain Deutschman > CCNP, CSS-1, MCP, CNA > Data Communications Manager > New Star Sales and Service, Inc. > 800.261.0475 > [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72877&t=72874 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 10:15 PM 7/12/2003 +, Hemingway wrote: >""Zsombor Papp"" wrote in message >news:[EMAIL PROTECTED] > > At 07:54 AM 7/12/2003 +, Hemingway wrote: > > >""hebn"" wrote in message > > >news:[EMAIL PROTECTED] > > > > layer 2 frame has a MTU of 1500 bytes. > > > >how does cisco router propagate router-lsa whose size exceed 1500 > > > > bytes(more than 122 links in one area)? > > > > > > > > >I've browsed through the other responses, and I did not see this >particular > > >piece of information, but it being late perhaps I missed it. I understand > > >this question to mean "what if there are lots of routes, so many that the > > >LSA would end up larger than the MTU" > > > > For the sake of clarity: OSPF, being a link-state protocol, doesn't > > advertise routes, and the size of the LSAs doesn't depend on the number of > > routes. Apologies if this is obvious; from the above statement and based >on > > the previous discussion I thought it might not be. > > >well, sure, but it advetises something, and those somethings end up in >routing tables, correct? :-> Sure. The point I was trying to make is that this information flow is not bi-directional: the information in the LSAs will be transformed into routes and those routes will be installed into the routing table, however the LSAs sent out by a router are not based on the routes installed into the routing table. Consequently there is no close relationship between the number of routes and the size of the individual LSAs. > > >As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, >beginning > > >on page 194 of said document, OSPF knows the link MTU, and would contruct > > >it's LSA's based on that information. > > > > My understanding is that the only thing that influences how the LSAs are > > constructed is the topology. I would be curious to see where the RFC says > > otherwise. LSAs are not equivalent to DD packets. > >IIRC, the RFC's state the result, but do not necessarily describe how the >result is to be obtained. Not having access to the code or to the >programmers, I can't say what is or is not done. I'm speculating that the >MTU information is available, and it would, to me at least, not be that >difficult to construct LSA's or DDP's such that packet fragmentation does >not have to occur. I think we are discussing a theoretical question, not the implementation, so all you need to have access to is the RFC. I claim that it is sometimes impossible to avoid IP-level fragmentation, regardless of how big your MTU or how good your OSPF implementation is. Specifically, if a router has a large enough number of interfaces in the same OSPF area, then that router will have to generate a huge (type 1) LSA, and that LSA (more exactly *any* LSA, but let's focus on a specific example) can be fragmented only at the IP layer. If you disagree, then please describe how your OSPF implementation will generate two LSAs that are individually smaller than the MTU, and that my (RFC2328 compliant) OSPF implementation must understand (and recognize the second one as an "extension" to the first). I would start at the top of Page 116, where it says: "The LSA header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the LSA." Based on this, if my OSPF implementation receives two LSAs, both having the same LS type (1), Link State ID (your router's OSPF ID), and Advertising Router (again, your router's OSPF ID), one describing the first half of your interfaces, the other describing the second half of your interfaces, then it would consider the second LSA a newer instance of the first one and conclude that the first half of your interfaces suddenly disappeared and at the same time the second half came to life. Now tell me where I violated the RFC. :) > > As for the OSPF *packets* being constructed based on MTU, that is surely a > > possibility. The IOS *implementation* however doesn't care about the MTU, > > as far as I can tell. > >I've never worked in a network with enough routes to know. I certainly can't >duplicate that in my home lab. Again, it's not the number of routes... also, you can change the MTU easily to a lower number if you just want to verify this particular statement. > or rather, I really have better things to do :-> Then you will have to believe me, hehe. :) > > Which part of the RFC says that the DD sequence numbers have something to > > do with the identification of LSAs? How will this identification method > > work if the same (instance of an) LSA reaches the router from two > > directions (see flooding)? > >well, I guess I'm being less than rigorous about my terminology. but the >sequence number is part of the "authentication" process, isn't it. if a >router receives a DDP with a lower sequence number than that which is >current in it's OSPF database, the DDR is rejected, is it not? I think we are one layer above DD sequence numbe
Re: OSPF max Router-LSA links [7:72024]
""Zsombor Papp"" wrote in message news:[EMAIL PROTECTED] > At 07:54 AM 7/12/2003 +, Hemingway wrote: > >""hebn"" wrote in message > >news:[EMAIL PROTECTED] > > > layer 2 frame has a MTU of 1500 bytes. > > >how does cisco router propagate router-lsa whose size exceed 1500 > > > bytes(more than 122 links in one area)? > > > > > >I've browsed through the other responses, and I did not see this particular > >piece of information, but it being late perhaps I missed it. I understand > >this question to mean "what if there are lots of routes, so many that the > >LSA would end up larger than the MTU" > > For the sake of clarity: OSPF, being a link-state protocol, doesn't > advertise routes, and the size of the LSAs doesn't depend on the number of > routes. Apologies if this is obvious; from the above statement and based on > the previous discussion I thought it might not be. well, sure, but it advetises something, and those somethings end up in routing tables, correct? :-> rereading after a good night's sleep plus another stimulating afternoon on my current remodeling project, I see that I misunderstood the original question. Still, this remains an interesting topic for conversation. ( I gotta get a life ) > > I would also like to mention that LSAs are not exchanged only between > neighbors, they are flooded throughout the OSPF domain (depending on type > and area configuration, as I am sure everybody knows :). I think this > simple fact has far-reaching consequences as far as the nature and handling > of LSAs are concerned. > > >As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, beginning > >on page 194 of said document, OSPF knows the link MTU, and would contruct > >it's LSA's based on that information. > > My understanding is that the only thing that influences how the LSAs are > constructed is the topology. I would be curious to see where the RFC says > otherwise. LSAs are not equivalent to DD packets. IIRC, the RFC's state the result, but do not necessarily describe how the result is to be obtained. Not having access to the code or to the programmers, I can't say what is or is not done. I'm speculating that the MTU information is available, and it would, to me at least, not be that difficult to construct LSA's or DDP's such that packet fragmentation does not have to occur. (And FWIW, page numbers > in the RFCs are on the bottom of the pages... :) that certainly explains why I have a hard time finding things. looking at large text files on screen is difficult for these old eyes :-> > > As for the OSPF *packets* being constructed based on MTU, that is surely a > possibility. The IOS *implementation* however doesn't care about the MTU, > as far as I can tell. I've never worked in a network with enough routes to know. I certainly can't duplicate that in my home lab. or rather, I really have better things to do :-> > > > Within the database description > >packet, there is the "M" bit, which indicates whether or not there are > >additional database description packets following. > > > >The receiving router would see that a particular DDP M bit is marked "on" > >and would expect more. When the last DDP is received ( M bit marked "off" ) > >then the current DD sequence number becomes the reference number for the > >link state database. Future LSA's would have to have a higher sequence > >number in order to be considered updates. > > Which part of the RFC says that the DD sequence numbers have something to > do with the identification of LSAs? How will this identification method > work if the same (instance of an) LSA reaches the router from two > directions (see flooding)? well, I guess I'm being less than rigorous about my terminology. but the sequence number is part of the "authentication" process, isn't it. if a router receives a DDP with a lower sequence number than that which is current in it's OSPF database, the DDR is rejected, is it not? I see that I'm tending to mix my DDP's and my LSA's, although a DDP contains any number of LSA's. So it states on page 196 > > IMHO, DDPs constitute the transport mechanism, while LSAs are the data to > be transported, so what you are saying above is alike to claiming that, for > example, web pages are identified by TCP sequence numbers. sorry for my sloppy terminology. that's what happens when attemptinh intelligent thought when tired from to much whatever.. > > Thanks, > > Zsombor > > > >Howard? > > > >I "think" this answers the original question, although one never can tell. > > > >-Hem- > > > > > > > > > > > __ > > > > > > === > > > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72189&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondis
Re: OSPF max Router-LSA links [7:72024]
At 07:54 AM 7/12/2003 +, Hemingway wrote: >""hebn"" wrote in message >news:[EMAIL PROTECTED] > > layer 2 frame has a MTU of 1500 bytes. > >how does cisco router propagate router-lsa whose size exceed 1500 > > bytes(more than 122 links in one area)? > > >I've browsed through the other responses, and I did not see this particular >piece of information, but it being late perhaps I missed it. I understand >this question to mean "what if there are lots of routes, so many that the >LSA would end up larger than the MTU" For the sake of clarity: OSPF, being a link-state protocol, doesn't advertise routes, and the size of the LSAs doesn't depend on the number of routes. Apologies if this is obvious; from the above statement and based on the previous discussion I thought it might not be. I would also like to mention that LSAs are not exchanged only between neighbors, they are flooded throughout the OSPF domain (depending on type and area configuration, as I am sure everybody knows :). I think this simple fact has far-reaching consequences as far as the nature and handling of LSAs are concerned. >As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, beginning >on page 194 of said document, OSPF knows the link MTU, and would contruct >it's LSA's based on that information. My understanding is that the only thing that influences how the LSAs are constructed is the topology. I would be curious to see where the RFC says otherwise. LSAs are not equivalent to DD packets. (And FWIW, page numbers in the RFCs are on the bottom of the pages... :) As for the OSPF *packets* being constructed based on MTU, that is surely a possibility. The IOS *implementation* however doesn't care about the MTU, as far as I can tell. > Within the database description >packet, there is the "M" bit, which indicates whether or not there are >additional database description packets following. > >The receiving router would see that a particular DDP M bit is marked "on" >and would expect more. When the last DDP is received ( M bit marked "off" ) >then the current DD sequence number becomes the reference number for the >link state database. Future LSA's would have to have a higher sequence >number in order to be considered updates. Which part of the RFC says that the DD sequence numbers have something to do with the identification of LSAs? How will this identification method work if the same (instance of an) LSA reaches the router from two directions (see flooding)? IMHO, DDPs constitute the transport mechanism, while LSAs are the data to be transported, so what you are saying above is alike to claiming that, for example, web pages are identified by TCP sequence numbers. Thanks, Zsombor >Howard? > >I "think" this answers the original question, although one never can tell. > >-Hem- > > > > > > __ > > > > === > > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72184&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
""hebn"" wrote in message news:[EMAIL PROTECTED] > layer 2 frame has a MTU of 1500 bytes. >how does cisco router propagate router-lsa whose size exceed 1500 > bytes(more than 122 links in one area)? I've browsed through the other responses, and I did not see this particular piece of information, but it being late perhaps I missed it. I understand this question to mean "what if there are lots of routes, so many that the LSA would end up larger than the MTU" As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, beginning on page 194 of said document, OSPF knows the link MTU, and would contruct it's LSA's based on that information. Within the database description packet, there is the "M" bit, which indicates whether or not there are additional database description packets following. The receiving router would see that a particular DDP M bit is marked "on" and would expect more. When the last DDP is received ( M bit marked "off" ) then the current DD sequence number becomes the reference number for the link state database. Future LSA's would have to have a higher sequence number in order to be considered updates. Howard? I "think" this answers the original question, although one never can tell. -Hem- > __ > > === > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72173&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
Howard C. Berkowitz wrote: > > At 5:48 AM -0700 7/10/03, Zsombor Papp wrote: > >I guess our views on OSPF are slightly different. > > > >I will now release the stage to the next "how to increase the > value > >of the CCIE certification" thread... :) > > > >Thanks, > > > >Zsombor > > Zsombor, I appreciate the discussion. I've been running at low > speed > due to a leg infection, but will talk to some developers and > reread > both 2328 and some of the OSPF working group archives. Will get > back > when I have useful information. > > ANYTHING but another one of THOSE threads... I learned a lot from the discussion. I'm still pondering the relationship between Type 1 and Type 2 LSAs and their tree topologies. And I'm pondering whether OSPF LSAs really need to be idempotent. I've always wanted to use that word in a sentence. :-) I hope your leg gets better and that the cats aren't sitting on it! :-) Priscilla > maybe a discussion > on > what happens to bits routed to the null interface? Is there a > true > astronomical black hole into which they are dumped? > Alternatively, > might there be a bit dump somewhere in Northern New Jersey, > which > someday may explode? > > > > >At 03:13 AM 7/10/2003 +, Howard C. Berkowitz wrote: > >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: > >>>At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: > At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single > LSA that is > >larger than 1500 bytes (think Type 1 LSA for a router with > 200 > >>interfaces). > >I can't see how such an LSA could be divided into multiple > OSPF messages > >>so > >the only logical (implementation independent) solution > seems to be to > >fragment the packet at the IP layer. Am I missing > something? > > I missed the point that the LSA was for the same router. > Without > testing it, however, I don't immediately see why it > wouldn't work to > have multiple LSAs for the same router, > >>> > >>>I am not sure what you mean by "multiple LSAs for the same > router", > >>>but if you mean "multiple type 1 LSAs originated by the same > >>>router", then my answer is "because it is impossible to > distinguish > >>>them". If I am mistaken here, then I would like to > understand how > >>>such LSAs can be distinguished. > >> > >>The relationship between type 1 and type 2 is essential in > developing > >>the SPF algorithm. If you think of the LSDB entries for > both, they > >>are trees. The type 1 bas the router ID as root and the > attached > >>interface IDs/prefixes as leaves. The type 2 has an interface > >>ID/prefix as root and routers connected to that prefix as > leaves. > >> > >>> > as long as no prefixes were > duplicated. Certainly, you send out a new type 2 when an > additional > prefix activates > >>> > >>>What is "prefix" in this context? Type 2 LSAs describe the > routers > >>>attached to a network. Are you saying that if an additional > router > >>>comes up on that network, then the DR should send only an > >>>"incremental" Type 2 LSA, containing a single entry, > describing the > >>>new router that just came up? Which bit in the OSPF packet > will let > >>>the receiver router know that this is an "incremental" LSA, > not a > >>>replacement (because all the other routers died and a new > one just > >>>came up)? > >> > >>The receiving router knows the sending router is still up, at > least > >>through the hello mechanism. One of the fundamental points of > using > >>hellos is so you know if the originating router has gone > down. Since > >>you know from context it's still up, you don't need an > incremental > >>flag -- you know the update is supplemental information. > >> > >>Remember also that you can withdraw routes without killing > the whole > >>LSDB entry. > >> > >>> > -- I don't immediately see why you couldn't send out > a new type 1 with the additional new prefix. Neither are in > an > existing LSDB, so they shouldn't purge anything. > >>> > >>>How do you mean "neither are in an existing LSDB"? If an > OSPF router > >>>receives two Type 1 LSAs, both originated by the same > router, how > >>>will it differentiate between the two so that it can install > both of > >>>them into the LSDB? IMHO the receiver will try to guess > which one of > >>>the two is newer and install only the newer one. In fact it > is not > >>>even correct to think about these two LSAs as "two LSAs"; > they are > >>>two instances of the same LSA. > >> > >>Think not of the transmitted LSAs but its entries. You can > have > >>updates on existing information, or changes to the basic > topology > >>conveyed (such as a new interface coming up). That doesn't > need a new > >>LSA. > >> > >>Look at it this way: LSUpdates are encodings of information > for > >>transmission. The decision to install information in the > LSDB is > >>done after the packet is parsed into its components. > >> > >>> >
Re: OSPF max Router-LSA links [7:72024]
At 07:41 PM 7/10/2003 +, Howard C. Berkowitz wrote: >At 5:48 AM -0700 7/10/03, Zsombor Papp wrote: > >I guess our views on OSPF are slightly different. > > > >I will now release the stage to the next "how to increase the value > >of the CCIE certification" thread... :) > > > >Thanks, > > > >Zsombor > >Zsombor, I appreciate the discussion. I've been running at low speed >due to a leg infection, but will talk to some developers and reread >both 2328 and some of the OSPF working group archives. Will get back >when I have useful information. Sounds good. Thanks, Zsombor >ANYTHING but another one of THOSE threads...maybe a discussion on >what happens to bits routed to the null interface? Is there a true >astronomical black hole into which they are dumped? Alternatively, >might there be a bit dump somewhere in Northern New Jersey, which >someday may explode? > > > > >At 03:13 AM 7/10/2003 +, Howard C. Berkowitz wrote: > >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: > >>>At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: > At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single LSA that is > >larger than 1500 bytes (think Type 1 LSA for a router with 200 > >>interfaces). > >I can't see how such an LSA could be divided into multiple OSPF messages > >>so > >the only logical (implementation independent) solution seems to be to > >fragment the packet at the IP layer. Am I missing something? > > I missed the point that the LSA was for the same router. Without > testing it, however, I don't immediately see why it wouldn't work to > have multiple LSAs for the same router, > >>> > >>>I am not sure what you mean by "multiple LSAs for the same router", > >>>but if you mean "multiple type 1 LSAs originated by the same > >>>router", then my answer is "because it is impossible to distinguish > >>>them". If I am mistaken here, then I would like to understand how > >>>such LSAs can be distinguished. > >> > >>The relationship between type 1 and type 2 is essential in developing > >>the SPF algorithm. If you think of the LSDB entries for both, they > >>are trees. The type 1 bas the router ID as root and the attached > >>interface IDs/prefixes as leaves. The type 2 has an interface > >>ID/prefix as root and routers connected to that prefix as leaves. > >> > >>> > as long as no prefixes were > duplicated. Certainly, you send out a new type 2 when an additional > prefix activates > >>> > >>>What is "prefix" in this context? Type 2 LSAs describe the routers > >>>attached to a network. Are you saying that if an additional router > >>>comes up on that network, then the DR should send only an > >>>"incremental" Type 2 LSA, containing a single entry, describing the > >>>new router that just came up? Which bit in the OSPF packet will let > >>>the receiver router know that this is an "incremental" LSA, not a > >>>replacement (because all the other routers died and a new one just > >>>came up)? > >> > >>The receiving router knows the sending router is still up, at least > >>through the hello mechanism. One of the fundamental points of using > >>hellos is so you know if the originating router has gone down. Since > >>you know from context it's still up, you don't need an incremental > >>flag -- you know the update is supplemental information. > >> > >>Remember also that you can withdraw routes without killing the whole > >>LSDB entry. > >> > >>> > -- I don't immediately see why you couldn't send out > a new type 1 with the additional new prefix. Neither are in an > existing LSDB, so they shouldn't purge anything. > >>> > >>>How do you mean "neither are in an existing LSDB"? If an OSPF router > >>>receives two Type 1 LSAs, both originated by the same router, how > >>>will it differentiate between the two so that it can install both of > >>>them into the LSDB? IMHO the receiver will try to guess which one of > >>>the two is newer and install only the newer one. In fact it is not > >>>even correct to think about these two LSAs as "two LSAs"; they are > >>>two instances of the same LSA. > >> > >>Think not of the transmitted LSAs but its entries. You can have > >>updates on existing information, or changes to the basic topology > >>conveyed (such as a new interface coming up). That doesn't need a new > >>LSA. > >> > >>Look at it this way: LSUpdates are encodings of information for > >>transmission. The decision to install information in the LSDB is > >>done after the packet is parsed into its components. > >> > >>> > Another argument about fragmentation hasn't been discussed. Consider > Hello packets. IIRC, about 47 router entries can fit into an OSPF > hello packet with a 1500 byte MTU. Consider the timing complexities > of waiting to defragment before you can tell if another router is > alive. Even scarier is if the load were heavy enough (unlikely, but > possible) that yo
Re: OSPF max Router-LSA links [7:72024]
At 5:48 AM -0700 7/10/03, Zsombor Papp wrote: >I guess our views on OSPF are slightly different. > >I will now release the stage to the next "how to increase the value >of the CCIE certification" thread... :) > >Thanks, > >Zsombor Zsombor, I appreciate the discussion. I've been running at low speed due to a leg infection, but will talk to some developers and reread both 2328 and some of the OSPF working group archives. Will get back when I have useful information. ANYTHING but another one of THOSE threads...maybe a discussion on what happens to bits routed to the null interface? Is there a true astronomical black hole into which they are dumped? Alternatively, might there be a bit dump somewhere in Northern New Jersey, which someday may explode? > >At 03:13 AM 7/10/2003 +, Howard C. Berkowitz wrote: >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: >>>At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: At 12:43 PM + 7/9/03, Zsombor Papp wrote: >The original question (as I understood) was about a single LSA that is >larger than 1500 bytes (think Type 1 LSA for a router with 200 >>interfaces). >I can't see how such an LSA could be divided into multiple OSPF messages >>so >the only logical (implementation independent) solution seems to be to >fragment the packet at the IP layer. Am I missing something? I missed the point that the LSA was for the same router. Without testing it, however, I don't immediately see why it wouldn't work to have multiple LSAs for the same router, >>> >>>I am not sure what you mean by "multiple LSAs for the same router", >>>but if you mean "multiple type 1 LSAs originated by the same >>>router", then my answer is "because it is impossible to distinguish >>>them". If I am mistaken here, then I would like to understand how >>>such LSAs can be distinguished. >> >>The relationship between type 1 and type 2 is essential in developing >>the SPF algorithm. If you think of the LSDB entries for both, they >>are trees. The type 1 bas the router ID as root and the attached >>interface IDs/prefixes as leaves. The type 2 has an interface >>ID/prefix as root and routers connected to that prefix as leaves. >> >>> as long as no prefixes were duplicated. Certainly, you send out a new type 2 when an additional prefix activates >>> >>>What is "prefix" in this context? Type 2 LSAs describe the routers >>>attached to a network. Are you saying that if an additional router >>>comes up on that network, then the DR should send only an >>>"incremental" Type 2 LSA, containing a single entry, describing the >>>new router that just came up? Which bit in the OSPF packet will let >>>the receiver router know that this is an "incremental" LSA, not a >>>replacement (because all the other routers died and a new one just >>>came up)? >> >>The receiving router knows the sending router is still up, at least >>through the hello mechanism. One of the fundamental points of using >>hellos is so you know if the originating router has gone down. Since >>you know from context it's still up, you don't need an incremental >>flag -- you know the update is supplemental information. >> >>Remember also that you can withdraw routes without killing the whole >>LSDB entry. >> >>> -- I don't immediately see why you couldn't send out a new type 1 with the additional new prefix. Neither are in an existing LSDB, so they shouldn't purge anything. >>> >>>How do you mean "neither are in an existing LSDB"? If an OSPF router >>>receives two Type 1 LSAs, both originated by the same router, how >>>will it differentiate between the two so that it can install both of >>>them into the LSDB? IMHO the receiver will try to guess which one of >>>the two is newer and install only the newer one. In fact it is not >>>even correct to think about these two LSAs as "two LSAs"; they are >>>two instances of the same LSA. >> >>Think not of the transmitted LSAs but its entries. You can have >>updates on existing information, or changes to the basic topology >>conveyed (such as a new interface coming up). That doesn't need a new >>LSA. >> >>Look at it this way: LSUpdates are encodings of information for >>transmission. The decision to install information in the LSDB is >>done after the packet is parsed into its components. >> >>> Another argument about fragmentation hasn't been discussed. Consider Hello packets. IIRC, about 47 router entries can fit into an OSPF hello packet with a 1500 byte MTU. Consider the timing complexities of waiting to defragment before you can tell if another router is alive. Even scarier is if the load were heavy enough (unlikely, but possible) that you might hit the next hello update interval before you had finished sending (or at least processing) all the segments. >>> >>>I think I am missing the point here. Yes, fragmentation is not good, >>>but there are circumstances when you have to live with it. >>> >>>Than
Re: OSPF max Router-LSA links [7:72024]
At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: >At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: >>At 12:43 PM + 7/9/03, Zsombor Papp wrote: >>>The original question (as I understood) was about a single LSA that is >>>larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). >>>I can't see how such an LSA could be divided into multiple OSPF messages so >>>the only logical (implementation independent) solution seems to be to >>>fragment the packet at the IP layer. Am I missing something? >> >>I missed the point that the LSA was for the same router. Without >>testing it, however, I don't immediately see why it wouldn't work to >>have multiple LSAs for the same router, > >I am not sure what you mean by "multiple LSAs for the same router", >but if you mean "multiple type 1 LSAs originated by the same >router", then my answer is "because it is impossible to distinguish >them". If I am mistaken here, then I would like to understand how >such LSAs can be distinguished. The relationship between type 1 and type 2 is essential in developing the SPF algorithm. If you think of the LSDB entries for both, they are trees. The type 1 bas the router ID as root and the attached interface IDs/prefixes as leaves. The type 2 has an interface ID/prefix as root and routers connected to that prefix as leaves. > >> as long as no prefixes were >>duplicated. Certainly, you send out a new type 2 when an additional >>prefix activates > >What is "prefix" in this context? Type 2 LSAs describe the routers >attached to a network. Are you saying that if an additional router >comes up on that network, then the DR should send only an >"incremental" Type 2 LSA, containing a single entry, describing the >new router that just came up? Which bit in the OSPF packet will let >the receiver router know that this is an "incremental" LSA, not a >replacement (because all the other routers died and a new one just >came up)? The receiving router knows the sending router is still up, at least through the hello mechanism. One of the fundamental points of using hellos is so you know if the originating router has gone down. Since you know from context it's still up, you don't need an incremental flag -- you know the update is supplemental information. Remember also that you can withdraw routes without killing the whole LSDB entry. > >> -- I don't immediately see why you couldn't send out >>a new type 1 with the additional new prefix. Neither are in an >>existing LSDB, so they shouldn't purge anything. > >How do you mean "neither are in an existing LSDB"? If an OSPF router >receives two Type 1 LSAs, both originated by the same router, how >will it differentiate between the two so that it can install both of >them into the LSDB? IMHO the receiver will try to guess which one of >the two is newer and install only the newer one. In fact it is not >even correct to think about these two LSAs as "two LSAs"; they are >two instances of the same LSA. Think not of the transmitted LSAs but its entries. You can have updates on existing information, or changes to the basic topology conveyed (such as a new interface coming up). That doesn't need a new LSA. Look at it this way: LSUpdates are encodings of information for transmission. The decision to install information in the LSDB is done after the packet is parsed into its components. > >>Another argument about fragmentation hasn't been discussed. Consider >>Hello packets. IIRC, about 47 router entries can fit into an OSPF >>hello packet with a 1500 byte MTU. Consider the timing complexities >>of waiting to defragment before you can tell if another router is >>alive. Even scarier is if the load were heavy enough (unlikely, but >>possible) that you might hit the next hello update interval before >>you had finished sending (or at least processing) all the segments. > >I think I am missing the point here. Yes, fragmentation is not good, >but there are circumstances when you have to live with it. > >Thanks, > >Zsombor > >> > >>>If you are asking about how LSAs that are individually smaller than 1500 >> >byte are grouped together, then my (moderately educated :) answer is this: >>>IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and >>>another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - >>>IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps >>>packing the LSAs into the same packet as long as their total length is >>>below MAX_OSPF_DATA, the net result being that the size of the IP packet >>>can be up to 1500 bytes (and will in fact be close to it if the individual >>>LSAs are not too big) if there are enough LSAs, regardless of the MTU. So >>>for example if you set the IP MTU on an Ethernet interface to 500 bytes, >>>and you have a large enough OSPF database, then you should see a lot of >>>fragmented OSPF packets, regardless of how big the individual LSAs are. >>> >>>I didn't write the code though, so take
Re: OSPF max Router-LSA links [7:72024]
At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: > >Hello packets. IIRC, about 47 router entries can fit into an OSPF > >hello packet with a 1500 byte MTU. Consider the timing complexities Btw, neighbors are identified by their 4-byte router ID, so it would take more than 350 neighbors to fill up a 1500 byte packet. I guess it is rather academical to ask what would happen to the hello packet if we had more than 350 neighbors on a single interface :), but I briefly looked at the code and I think it would be fragmented at the IP level. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72079&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: >At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single LSA that is > >larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). > >I can't see how such an LSA could be divided into multiple OSPF messages so > >the only logical (implementation independent) solution seems to be to > >fragment the packet at the IP layer. Am I missing something? > >I missed the point that the LSA was for the same router. Without >testing it, however, I don't immediately see why it wouldn't work to >have multiple LSAs for the same router, I am not sure what you mean by "multiple LSAs for the same router", but if you mean "multiple type 1 LSAs originated by the same router", then my answer is "because it is impossible to distinguish them". If I am mistaken here, then I would like to understand how such LSAs can be distinguished. > as long as no prefixes were >duplicated. Certainly, you send out a new type 2 when an additional >prefix activates What is "prefix" in this context? Type 2 LSAs describe the routers attached to a network. Are you saying that if an additional router comes up on that network, then the DR should send only an "incremental" Type 2 LSA, containing a single entry, describing the new router that just came up? Which bit in the OSPF packet will let the receiver router know that this is an "incremental" LSA, not a replacement (because all the other routers died and a new one just came up)? > -- I don't immediately see why you couldn't send out >a new type 1 with the additional new prefix. Neither are in an >existing LSDB, so they shouldn't purge anything. How do you mean "neither are in an existing LSDB"? If an OSPF router receives two Type 1 LSAs, both originated by the same router, how will it differentiate between the two so that it can install both of them into the LSDB? IMHO the receiver will try to guess which one of the two is newer and install only the newer one. In fact it is not even correct to think about these two LSAs as "two LSAs"; they are two instances of the same LSA. >Another argument about fragmentation hasn't been discussed. Consider >Hello packets. IIRC, about 47 router entries can fit into an OSPF >hello packet with a 1500 byte MTU. Consider the timing complexities >of waiting to defragment before you can tell if another router is >alive. Even scarier is if the load were heavy enough (unlikely, but >possible) that you might hit the next hello update interval before >you had finished sending (or at least processing) all the segments. I think I am missing the point here. Yes, fragmentation is not good, but there are circumstances when you have to live with it. Thanks, Zsombor > > > >If you are asking about how LSAs that are individually smaller than 1500 > >byte are grouped together, then my (moderately educated :) answer is this: > >IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and > >another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > >IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps > >packing the LSAs into the same packet as long as their total length is > >below MAX_OSPF_DATA, the net result being that the size of the IP packet > >can be up to 1500 bytes (and will in fact be close to it if the individual > >LSAs are not too big) if there are enough LSAs, regardless of the MTU. So > >for example if you set the IP MTU on an Ethernet interface to 500 bytes, > >and you have a large enough OSPF database, then you should see a lot of > >fragmented OSPF packets, regardless of how big the individual LSAs are. > > > >I didn't write the code though, so take all this with a grain of salt. :) > > > >Thanks, > > > >Zsombor > > > >At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > >>At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >> >The LSA will be fragmented at the IP layer. > >> > >>Do you know for certain this is what Cisco's implementation does? > >>The OSPF code is aware of the MTU and can build OSPF packets for it. > >>I don't think you're really going to simplify it by relieving it of > >>the need to keep track of lengths. > >> > >>On the other hand, if you send a LSupdate that is at the MTU, the > >>receiving router can immediately start checking and installing it in > >>the LSDB, without waiting for fragments. This allows some concurrency > >>between OSPF packet transmission and OSPF protocol processing. > >> > >> >At 11:39 AM 7/8/2003 +, hebn wrote: > >> >>layer 2 frame has a MTU of 1500 bytes. > >> >> how does cisco router propagate router-lsa whose size exceed 1500 > > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72078&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosu
Re: OSPF max Router-LSA links [7:72024]
Howard C. Berkowitz wrote: > > At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single LSA > that is > >larger than 1500 bytes (think Type 1 LSA for a router with 200 > interfaces). > >I can't see how such an LSA could be divided into multiple > OSPF messages so > >the only logical (implementation independent) solution seems > to be to > >fragment the packet at the IP layer. Am I missing something? > > I missed the point that the LSA was for the same router. > Without > testing it, however, I don't immediately see why it wouldn't > work to > have multiple LSAs for the same router, as long as no prefixes > were > duplicated. Are you saying the router could send out one Link State Advertisement saying this router has link 1, 2, 3, etc. etc., for example. And then send out another LSA, saying this same router has link 101, 102, 103, etc.? That should work I would think, unless the recipient thought it was supposed to replace the old one with this new one. But that doesn't seem to be what Cisco does. I couldn't easily try the Hello with lots of neighbors in it that you mention below, but I did try a single router with gobs of loopbacks that it advertises to another router in a Type 1 LSA. It sends the info in one oversized message, that the IP layer fragmented, as Zsombor said it would. I had about 140 loopbacks all part of OSPF Area 0. The sending router sent this to another router in Area 0. The sending router's IP layer put it in two IP packets, one with 1500 bytes, and one with a few hundred. IP did the fragmentation. OSPF didn't divide it up. But I agree that it shouldn't have to work that way?? But it does, and I *think* that was the original question. I said that before, but now I'm much more sure that this was what the original poster wanted to know. :-) Priscilla >Certainly, you send out a new type 2 when an > additional > prefix activates -- I don't immediately see why you couldn't > send out > a new type 1 with the additional new prefix. Neither are in an > existing LSDB, so they shouldn't purge anything. > > Another argument about fragmentation hasn't been discussed. > Consider > Hello packets. IIRC, about 47 router entries can fit into an > OSPF > hello packet with a 1500 byte MTU. Consider the timing > complexities > of waiting to defragment before you can tell if another router > is > alive. Even scarier is if the load were heavy enough > (unlikely, but > possible) that you might hit the next hello update interval > before > you had finished sending (or at least processing) all the > segments. > > > > >If you are asking about how LSAs that are individually smaller > than 1500 > >byte are grouped together, then my (moderately educated :) > answer is this: > >IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 > bytes and > >another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > >IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the > LSAs keeps > >packing the LSAs into the same packet as long as their total > length is > >below MAX_OSPF_DATA, the net result being that the size of the > IP packet > >can be up to 1500 bytes (and will in fact be close to it if > the individual > >LSAs are not too big) if there are enough LSAs, regardless of > the MTU. So > >for example if you set the IP MTU on an Ethernet interface to > 500 bytes, > >and you have a large enough OSPF database, then you should see > a lot of > >fragmented OSPF packets, regardless of how big the individual > LSAs are. > > > >I didn't write the code though, so take all this with a grain > of salt. :) > > > >Thanks, > > > >Zsombor > > > >At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > >>At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >> >The LSA will be fragmented at the IP layer. > >> > >>Do you know for certain this is what Cisco's implementation > does? > >>The OSPF code is aware of the MTU and can build OSPF packets > for it. > >>I don't think you're really going to simplify it by relieving > it of > >>the need to keep track of lengths. > >> > >>On the other hand, if you send a LSupdate that is at the MTU, > the > >>receiving router can immediately start checking and > installing it in > >>the LSDB, without waiting for fragments. This allows some > concurrency > >>between OSPF packet transmission and OSPF protocol processing. > >> > >> >At 11:39 AM 7/8/2003 +, hebn wrote: > >> >>layer 2 frame has a MTU of 1500 bytes. > >> >> how does cisco router propagate router-lsa whose > size exceed 1500 > > > >bytes(more than 122 links in one area)? > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72076&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 12:43 PM + 7/9/03, Zsombor Papp wrote: >The original question (as I understood) was about a single LSA that is >larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). >I can't see how such an LSA could be divided into multiple OSPF messages so >the only logical (implementation independent) solution seems to be to >fragment the packet at the IP layer. Am I missing something? I missed the point that the LSA was for the same router. Without testing it, however, I don't immediately see why it wouldn't work to have multiple LSAs for the same router, as long as no prefixes were duplicated. Certainly, you send out a new type 2 when an additional prefix activates -- I don't immediately see why you couldn't send out a new type 1 with the additional new prefix. Neither are in an existing LSDB, so they shouldn't purge anything. Another argument about fragmentation hasn't been discussed. Consider Hello packets. IIRC, about 47 router entries can fit into an OSPF hello packet with a 1500 byte MTU. Consider the timing complexities of waiting to defragment before you can tell if another router is alive. Even scarier is if the load were heavy enough (unlikely, but possible) that you might hit the next hello update interval before you had finished sending (or at least processing) all the segments. > >If you are asking about how LSAs that are individually smaller than 1500 >byte are grouped together, then my (moderately educated :) answer is this: >IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and >another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - >IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps >packing the LSAs into the same packet as long as their total length is >below MAX_OSPF_DATA, the net result being that the size of the IP packet >can be up to 1500 bytes (and will in fact be close to it if the individual >LSAs are not too big) if there are enough LSAs, regardless of the MTU. So >for example if you set the IP MTU on an Ethernet interface to 500 bytes, >and you have a large enough OSPF database, then you should see a lot of >fragmented OSPF packets, regardless of how big the individual LSAs are. > >I didn't write the code though, so take all this with a grain of salt. :) > >Thanks, > >Zsombor > >At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: >>At 10:46 PM + 7/8/03, Zsombor Papp wrote: >> >The LSA will be fragmented at the IP layer. >> >>Do you know for certain this is what Cisco's implementation does? >>The OSPF code is aware of the MTU and can build OSPF packets for it. >>I don't think you're really going to simplify it by relieving it of >>the need to keep track of lengths. >> >>On the other hand, if you send a LSupdate that is at the MTU, the >>receiving router can immediately start checking and installing it in >>the LSDB, without waiting for fragments. This allows some concurrency >>between OSPF packet transmission and OSPF protocol processing. >> >> >At 11:39 AM 7/8/2003 +, hebn wrote: >> >>layer 2 frame has a MTU of 1500 bytes. >> >> how does cisco router propagate router-lsa whose size exceed 1500 > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72074&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 05:14 PM 7/9/2003 +, Priscilla Oppenheimer wrote: >Zsombor Papp wrote: > > > > The original question (as I understood) was about a single LSA > > that is > > larger than 1500 bytes (think Type 1 LSA for a router with 200 > > interfaces). > > I can't see how such an LSA could be divided into multiple OSPF > > messages so > > the only logical (implementation independent) solution seems to > > be to > > fragment the packet at the IP layer. Am I missing something? > >OSPF could send multiple packets. How would the receiver know that the second packet holds the second half of the LSA whose first half was transmitted in the first packet? OSPF doesn't have a way of coalescing fragments of an LSA, does it? > That's what IP RIP would do. It used to be >pretty common to see bunches of RIP packets every 30 seconds. Even more >common for IPX RIP, (every 60 seconds). RIP doesn't have a concept of LSAs. A good analogy would be to say that RIP could advertise a single prefix distributed into multiple packets, which is not true. > > If you are asking about how LSAs that are individually smaller > > than 1500 > > byte are grouped together, then my (moderately educated :) > > answer is this: > > IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 > > bytes and > > another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > > IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs > > keeps > > packing the LSAs into the same packet as long as their total > > length is > > below MAX_OSPF_DATA, the net result being that the size of the > > IP packet > > can be up to 1500 bytes (and will in fact be close to it if the > > individual > > LSAs are not too big) if there are enough LSAs, regardless of > > the MTU. So > > for example if you set the IP MTU on an Ethernet interface to > > 500 bytes, > > and you have a large enough OSPF database, then you should see > > a lot of > > fragmented OSPF packets, regardless of how big the individual > > LSAs are. > >Thanks for the info. > >As another example, say that the MTU is 1500 and there is so much info to >advertise (links, routers, routes, depending on the type) that it requires >more than 1500 bytes. Then OSPF would just send multiple packets, wouldn't >it? Yes. >And there wouldn't be any IP fragmentation? Unless there is a single LSA larger than 1500 bytes, there wouldn't be any. In case it confused anyone, MAXOSPFPACKETSIZE (ie. 1500 bytes) is *not* the size of the largest OSPF packet that IOS can generate. > I think that was the original question. Well, if the term "router-lsa whose size exceed 1500 bytes" refers to a set of LSAs whose size individually does *not* exceed 1500 bytes (as opposed to a single Type 1 LSA whose size does exceed 1500 bytes), then I misunderstood the question. :) Thanks, Zsombor >According to Howard, if I understood him correctly in his message, that's >how Nortel, Bay, Wellfleet do it (send multiple messages). But is that what >Cisco does? > >I think it is what the RFC recommends too when it says this: "The OSPF >packet types that are likely to be large (Database Description Packets, Link >State Request, Link State Update, and Link State Acknowledgment packets) can >usually be split into several separate protocol packets, without loss of >functionality. This is recommended; IP fragmentation should be avoided >whenever possible." > >Sorry to beat this to death, but I'm not sure we have an answer yet. > >Priscilla > > > > > > I didn't write the code though, so take all this with a grain > > of salt. :) > > > > Thanks, > > > > Zsombor > > > > At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > > >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > > > >The LSA will be fragmented at the IP layer. > > > > > >Do you know for certain this is what Cisco's implementation > > does? > > >The OSPF code is aware of the MTU and can build OSPF packets > > for it. > > >I don't think you're really going to simplify it by relieving > > it of > > >the need to keep track of lengths. > > > > > >On the other hand, if you send a LSupdate that is at the MTU, > > the > > >receiving router can immediately start checking and installing > > it in > > >the LSDB, without waiting for fragments. This allows some > > concurrency > > >between OSPF packet transmission and OSPF protocol processing. > > > > > > >At 11:39 AM 7/8/2003 +, hebn wrote: > > > >>layer 2 frame has a MTU of 1500 bytes. > > > >> how does cisco router propagate router-lsa whose size > > exceed 1500 > > > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72068&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
Zsombor Papp wrote: > > The original question (as I understood) was about a single LSA > that is > larger than 1500 bytes (think Type 1 LSA for a router with 200 > interfaces). > I can't see how such an LSA could be divided into multiple OSPF > messages so > the only logical (implementation independent) solution seems to > be to > fragment the packet at the IP layer. Am I missing something? OSPF could send multiple packets. That's what IP RIP would do. It used to be pretty common to see bunches of RIP packets every 30 seconds. Even more common for IPX RIP, (every 60 seconds). > > If you are asking about how LSAs that are individually smaller > than 1500 > byte are grouped together, then my (moderately educated :) > answer is this: > IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 > bytes and > another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs > keeps > packing the LSAs into the same packet as long as their total > length is > below MAX_OSPF_DATA, the net result being that the size of the > IP packet > can be up to 1500 bytes (and will in fact be close to it if the > individual > LSAs are not too big) if there are enough LSAs, regardless of > the MTU. So > for example if you set the IP MTU on an Ethernet interface to > 500 bytes, > and you have a large enough OSPF database, then you should see > a lot of > fragmented OSPF packets, regardless of how big the individual > LSAs are. Thanks for the info. As another example, say that the MTU is 1500 and there is so much info to advertise (links, routers, routes, depending on the type) that it requires more than 1500 bytes. Then OSPF would just send multiple packets, wouldn't it? And there wouldn't be any IP fragmentation? I think that was the original question. According to Howard, if I understood him correctly in his message, that's how Nortel, Bay, Wellfleet do it (send multiple messages). But is that what Cisco does? I think it is what the RFC recommends too when it says this: "The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible." Sorry to beat this to death, but I'm not sure we have an answer yet. Priscilla > > I didn't write the code though, so take all this with a grain > of salt. :) > > Thanks, > > Zsombor > > At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > > >The LSA will be fragmented at the IP layer. > > > >Do you know for certain this is what Cisco's implementation > does? > >The OSPF code is aware of the MTU and can build OSPF packets > for it. > >I don't think you're really going to simplify it by relieving > it of > >the need to keep track of lengths. > > > >On the other hand, if you send a LSupdate that is at the MTU, > the > >receiving router can immediately start checking and installing > it in > >the LSDB, without waiting for fragments. This allows some > concurrency > >between OSPF packet transmission and OSPF protocol processing. > > > > >At 11:39 AM 7/8/2003 +, hebn wrote: > > >>layer 2 frame has a MTU of 1500 bytes. > > >> how does cisco router propagate router-lsa whose size > exceed 1500 > > > >bytes(more than 122 links in one area)? > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72065&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF max Router-LSA links [7:72024]
>hebn wrote: >> >> hello,everyone: > >>OSPF use raw socket (datagram) to communicate with peers. In >> general, layer 2 frame has a MTU of 1500 bytes. >>how does cisco router propagate router-lsa whose size exceed >> 1500 bytes(more than 122 links in one area)? > >Well, I don't have a definite answer, but I'll discuss it with >you in the >hopes of lighting a fire under one of the OSPF experts on this >list. Howard? >Chuck? Peter? Where's Pamela when we need her? :-) > >OSPF runs directly above IP. I don't know if that could be called "raw >socket" which is a UNIX thing? My perception is that with >Cisco IOS, OSPF >calls IP with a set of parameters and lets IP handle the rest. So maybe >that's sort of raw. > >I can say this: The OSPF packets I have seen coming out of >Cisco routers >have the IP fragmentation bit set to "May Fragment." This >makes me think >that Cisco's OSPF relies on IP to push the bytes into the >data-link-layer >frame and fragment if necessary. > >The OSPF RFC (RFC 2178) says this: > >"OSPF does not define a way to fragment its protocol packets, >and depends on >IP fragmentation when transmitting packets larger than the >network MTU. If >necessary, the length of OSPF packets can be up to 65,535 >bytes (including >the IP header). The OSPF packet types that are likely to be >large (Database >Description Packets, Link State Request, Link State Update, >and Link State >Acknowledgment packets) can usually be split into several >separate protocol >packets, without loss of functionality. This is recommended; IP >fragmentation should be avoided whenever possible." > >Unfortunately, that's not very clear. It implies that the >recommended method >is for OSPF to split its own protocol packets. But that the >method for doing >this is undefined and that's OK because OSPF can depend on IP to do >fragmentation. > >Cisco routers tell each other their MTU in database >description packets, per >RFC 2178. Until recently, if the routers didn't agree on the MTU, they >wouldn't become adjacent. A recent IOS version supports >telling a router to >ignore the other side's MTU so they can still become adjacent. This is true. I vaguely remember reading some notes from an IETF meeting from one of the developers of OSPF. They were discussing checks for the MTU. Basically OSPF checks whether a neighbor is using the same maximum transimission unit (mtu) on a common interface. This check is performed when neighbors exchange (exchange stage) (DD's) database description packet. If the receiving MTU in the DD packet was higher then the IP MTU configured on the incoming interface, OSPF will not establish an adjacency. The DD packet were dropped. This was done on the DD phase because initially MTU mismatches could cause flooding between 2 neighbors to fail with large LSU's being continually retransmitted. -Mario >That doesn't answer your question, but maybe there are some >hints in the >article that discusse the "ip ospf mtu-ignore" feature here: > >http://www.cisco.com/warp/public/104/12.html > >___ > >Priscilla Oppenheimer >www.priscilla.com > > >> __ > >> >> === >> [EMAIL PROTECTED] (http://bizsite.sina.com.cn) >Report misconduct >and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72059&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
The original question (as I understood) was about a single LSA that is larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). I can't see how such an LSA could be divided into multiple OSPF messages so the only logical (implementation independent) solution seems to be to fragment the packet at the IP layer. Am I missing something? If you are asking about how LSAs that are individually smaller than 1500 byte are grouped together, then my (moderately educated :) answer is this: IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps packing the LSAs into the same packet as long as their total length is below MAX_OSPF_DATA, the net result being that the size of the IP packet can be up to 1500 bytes (and will in fact be close to it if the individual LSAs are not too big) if there are enough LSAs, regardless of the MTU. So for example if you set the IP MTU on an Ethernet interface to 500 bytes, and you have a large enough OSPF database, then you should see a lot of fragmented OSPF packets, regardless of how big the individual LSAs are. I didn't write the code though, so take all this with a grain of salt. :) Thanks, Zsombor At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >The LSA will be fragmented at the IP layer. > >Do you know for certain this is what Cisco's implementation does? >The OSPF code is aware of the MTU and can build OSPF packets for it. >I don't think you're really going to simplify it by relieving it of >the need to keep track of lengths. > >On the other hand, if you send a LSupdate that is at the MTU, the >receiving router can immediately start checking and installing it in >the LSDB, without waiting for fragments. This allows some concurrency >between OSPF packet transmission and OSPF protocol processing. > > >At 11:39 AM 7/8/2003 +, hebn wrote: > >>layer 2 frame has a MTU of 1500 bytes. > >> how does cisco router propagate router-lsa whose size exceed 1500 > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72055&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 2:42 AM + 7/9/03, Priscilla Oppenheimer wrote: >Howard C. Berkowitz wrote: >> >> At 10:46 PM + 7/8/03, Zsombor Papp wrote: >> >The LSA will be fragmented at the IP layer. >> >> Do you know for certain this is what Cisco's implementation >> does? >> The OSPF code is aware of the MTU and can build OSPF packets >> for it. >> I don't think you're really going to simplify it by relieving >> it of >> the need to keep track of lengths. > >Can you think of a good way to test it in a lab?? Lots of loopback interfaces, with appropriate coding so they don't present as host routes, coupled with small MTUs. Part of the problem in testing will be that any practical configuration doesn't press the limits. IIRC, I ran some calculations a while back that imposed a more stringent limit on the number of routers per segment -- the number you could fit into a Hello packet was around 47, a smaller number than you could type 1 LSAs. > >The RFC says that dividing up the updates is recomended over letting IP do >the fragmentation and Cisco is generally good at doing things the >recommended way usually. The person that I know who wrote most of the _good_ OSPF code has left Cisco, but I'll hunt around on the IETF list and find out if I can find someone who knows definitively. There are a lot of things in OSPF (and, for that matter, BGP) that experience have taught are simply not good ideas in practice. You'll find the latest BGP draft (I think it's 21 now, if it's reached the editor) is both considerably different from the BGP route selection process described in RFC 1771, and is also much closer to what Cisco, Juniper, NextHop/gateD, and Zebra actually do. OSPF will continue to evolve. The classic Dijkstra algorithm won't continue to serve as faster convergence requirements are placed on OSPF. To the best of my knowledge, most implementations save at least some intermediate Dijkstra results, and the trend is to do at least some incremental updating before committing to a full SPF recomputation. > >Priscilla > > >> >> On the other hand, if you send a LSupdate that is at the MTU, >> the >> receiving router can immediately start checking and installing >> it in >> the LSDB, without waiting for fragments. This allows some >> concurrency >> between OSPF packet transmission and OSPF protocol processing. >> >> >At 11:39 AM 7/8/2003 +, hebn wrote: >> >>layer 2 frame has a MTU of 1500 bytes. >> >> how does cisco router propagate router-lsa whose size >> exceed 1500 >> > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72050&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
Howard C. Berkowitz wrote: > > At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >The LSA will be fragmented at the IP layer. > > Do you know for certain this is what Cisco's implementation > does? > The OSPF code is aware of the MTU and can build OSPF packets > for it. > I don't think you're really going to simplify it by relieving > it of > the need to keep track of lengths. Can you think of a good way to test it in a lab?? The RFC says that dividing up the updates is recomended over letting IP do the fragmentation and Cisco is generally good at doing things the recommended way usually. Priscilla > > On the other hand, if you send a LSupdate that is at the MTU, > the > receiving router can immediately start checking and installing > it in > the LSDB, without waiting for fragments. This allows some > concurrency > between OSPF packet transmission and OSPF protocol processing. > > >At 11:39 AM 7/8/2003 +, hebn wrote: > >>layer 2 frame has a MTU of 1500 bytes. > >> how does cisco router propagate router-lsa whose size > exceed 1500 > > >bytes(more than 122 links in one area)? > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72047&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
The original question (as I understood) was about a single LSA that is larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). I can't see how such an LSA could be divided into multiple OSPF messages so the only logical (implementation independent) solution seems to be to fragment the packet at the IP layer. Am I missing something? If you are asking about how LSAs that are individually smaller than 1500 byte are grouped together, then my (moderately educated :) answer is this: IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps packing the LSAs into the same packet as long as their total length is below MAX_OSPF_DATA, the net result being that the size of the IP packet can be up to 1500 bytes (and will in fact be close to it if the individual LSAs are not too big) if there are enough LSAs, regardless of the MTU. So for example if you set the IP MTU on an Ethernet interface to 500 bytes, and you have a large enough OSPF database, then you should see a lot of fragmented OSPF packets, regardless of how big the individual LSAs are. I didn't write the code though, so take all this with a grain of salt. :) Thanks, Zsombor At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >The LSA will be fragmented at the IP layer. > >Do you know for certain this is what Cisco's implementation does? >The OSPF code is aware of the MTU and can build OSPF packets for it. >I don't think you're really going to simplify it by relieving it of >the need to keep track of lengths. > >On the other hand, if you send a LSupdate that is at the MTU, the >receiving router can immediately start checking and installing it in >the LSDB, without waiting for fragments. This allows some concurrency >between OSPF packet transmission and OSPF protocol processing. > > >At 11:39 AM 7/8/2003 +, hebn wrote: > >>layer 2 frame has a MTU of 1500 bytes. > >> how does cisco router propagate router-lsa whose size exceed 1500 > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72048&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 10:46 PM + 7/8/03, Zsombor Papp wrote: >The LSA will be fragmented at the IP layer. Do you know for certain this is what Cisco's implementation does? The OSPF code is aware of the MTU and can build OSPF packets for it. I don't think you're really going to simplify it by relieving it of the need to keep track of lengths. On the other hand, if you send a LSupdate that is at the MTU, the receiving router can immediately start checking and installing it in the LSDB, without waiting for fragments. This allows some concurrency between OSPF packet transmission and OSPF protocol processing. >At 11:39 AM 7/8/2003 +, hebn wrote: >>layer 2 frame has a MTU of 1500 bytes. >> how does cisco router propagate router-lsa whose size exceed 1500 > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72046&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
The LSA will be fragmented at the IP layer. Thanks, Zsombor At 11:39 AM 7/8/2003 +, hebn wrote: >layer 2 frame has a MTU of 1500 bytes. >how does cisco router propagate router-lsa whose size exceed 1500 >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72045&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF max Router-LSA links [7:72024]
At 9:38 PM + 7/8/03, Priscilla Oppenheimer wrote: >hebn wrote: >> >> hello,everyone: > >> OSPF use raw socket (datagram) to communicate with peers. In > > general, layer 2 frame has a MTU of 1500 bytes. I'm not sure I'd call it a strict datagram protocol. In some cases, it's acknowledged datagram, either directly or indirectly acknowledged. In other cases, such as database initialization, there's clearly a connection -- just not a TCP connection. > >how does cisco router propagate router-lsa whose size exceed >> 1500 bytes(more than 122 links in one area)? > >Well, I don't have a definite answer, but I'll discuss it with you in the >hopes of lighting a fire under one of the OSPF experts on this list. Howard? >Chuck? Peter? Where's Pamela when we need her? :-) It's fairly simple in Wellfleet/Bay/Nortel code -- you send multiple LSAs. There's nothing that says all the database entries of one type have to fit in the same LSupdate. Certainly, in a large area, there will need to be more than one LSupdate to convey all the Type 2 LSAs. > >OSPF runs directly above IP. I don't know if that could be called "raw >socket" which is a UNIX thing? My perception is that with Cisco IOS, OSPF >calls IP with a set of parameters and lets IP handle the rest. So maybe >that's sort of raw. I'd have to go look at Moy's or another UNIX based implementation to see how the calling is done. IOS is not UNIX based. Several other vendor implementations run a realtime OS such as VXworks. > >I can say this: The OSPF packets I have seen coming out of Cisco routers >have the IP fragmentation bit set to "May Fragment." This makes me think >that Cisco's OSPF relies on IP to push the bytes into the data-link-layer >frame and fragment if necessary. > >The OSPF RFC (RFC 2178) says this: > >"OSPF does not define a way to fragment its protocol packets, and depends on >IP fragmentation when transmitting packets larger than the network MTU. If >necessary, the length of OSPF packets can be up to 65,535 bytes (including >the IP header). The OSPF packet types that are likely to be large (Database >Description Packets, Link State Request, Link State Update, and Link State >Acknowledgment packets) can usually be split into several separate protocol >packets, without loss of functionality. This is recommended; IP >fragmentation should be avoided whenever possible." > >Unfortunately, that's not very clear. It implies that the recommended method >is for OSPF to split its own protocol packets. But that the method for doing >this is undefined and that's OK because OSPF can depend on IP to do >fragmentation. Fragmentation gets scary when you are doing real-time control plane traffic. > >Cisco routers tell each other their MTU in database description packets, per >RFC 2178. Until recently, if the routers didn't agree on the MTU, they >wouldn't become adjacent. A recent IOS version supports telling a router to >ignore the other side's MTU so they can still become adjacent. > >That doesn't answer your question, but maybe there are some hints in the >article that discusse the "ip ospf mtu-ignore" feature here: > >http://www.cisco.com/warp/public/104/12.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72044&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF max Router-LSA links [7:72024]
hebn wrote: > > hello,everyone: >OSPF use raw socket (datagram) to communicate with peers. In > general, layer 2 frame has a MTU of 1500 bytes. >how does cisco router propagate router-lsa whose size exceed > 1500 bytes(more than 122 links in one area)? Well, I don't have a definite answer, but I'll discuss it with you in the hopes of lighting a fire under one of the OSPF experts on this list. Howard? Chuck? Peter? Where's Pamela when we need her? :-) OSPF runs directly above IP. I don't know if that could be called "raw socket" which is a UNIX thing? My perception is that with Cisco IOS, OSPF calls IP with a set of parameters and lets IP handle the rest. So maybe that's sort of raw. I can say this: The OSPF packets I have seen coming out of Cisco routers have the IP fragmentation bit set to "May Fragment." This makes me think that Cisco's OSPF relies on IP to push the bytes into the data-link-layer frame and fragment if necessary. The OSPF RFC (RFC 2178) says this: "OSPF does not define a way to fragment its protocol packets, and depends on IP fragmentation when transmitting packets larger than the network MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header). The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible." Unfortunately, that's not very clear. It implies that the recommended method is for OSPF to split its own protocol packets. But that the method for doing this is undefined and that's OK because OSPF can depend on IP to do fragmentation. Cisco routers tell each other their MTU in database description packets, per RFC 2178. Until recently, if the routers didn't agree on the MTU, they wouldn't become adjacent. A recent IOS version supports telling a router to ignore the other side's MTU so they can still become adjacent. That doesn't answer your question, but maybe there are some hints in the article that discusse the "ip ospf mtu-ignore" feature here: http://www.cisco.com/warp/public/104/12.html ___ Priscilla Oppenheimer www.priscilla.com > __ > > === > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72043&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF V-Link [7:71926]
192.168.11.9 is the address of the R2 interface pointing at R3. They are all serial interfaces. All of the Lo addresses (RIDs) are advertised in ospf. I swear I don't know what happened. I just this minute reinstituted the configuration that failed me all afternoon. It just spat out the error message above about ten times in a minute and stopped. Now everything seems to work fine. I have routes where they should be. I know I rebooted all of the routers twice this afternoon to try to make sure that it wasn't a hiccup. I even reconfigured a 4000M to replace the mc3810 at R2 - no avail. When you said to check the "show" outputs, I thought I'd go check it one more time to see if there was anything I hadn't noticed earlier and everything worked. Frustrating sometimes. At least it's not MS. Thanks for writing. Sometimes I think the boxes just need more attention than my cussin' at 'em. You gave it. Leaves me feeling like a right eejit, but it's working now. That's what's required. Nelson Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71933&t=71926 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF V-Link [7:71926]
""Nelson Herron"" wrote in message news:[EMAIL PROTECTED] > I have a failry generic three-router ospf set that I am trying to cross with > a virtual link: > > R1 (area0, area 3) R2 (area 3) R4 (area 3, 23) > (192.168.255.245/30)(192.168.255.254/30) > [area 3 virt 192.168.255.254] [area 3 virt 192.168.255.245] > > Traffic routes properly except the area 23 stuff because there is no > connection oto area 0. When I try to install the "area 3 virtual-link > 192.168.255.254 area 3 virtual-link 192.168.255.245" statement pair to link > area 23 across area 3 I get lots of these: > > %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone > area must be virtual-link but not found from 192.168.11.9, Serial1/1 > > The address 192.168.11.9 is on the intervening router. The link from R1 to > R2 is a F.R. link set to point-to-multipoint on each end. > > > Any ideas? reading the documentation regarding virtual links comes to mind: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r/1rfospf.htm#1017717 watch the wrap the error you are getting is telling you something important. another help might be to look at the output from the "show ip ospf" command 192.168.11.9 is what exactly? more than an interface address. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71929&t=71926 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF with passive interface [7:71395]
Shibu Nair wrote: > > If the interface configured as passive under OSPF routing > protocol, > will there be any neighbor relationship establish on that > interface ? No. Passive interface means it doesn't send Hellos, which it would need to do to establish a neighbor relationship. Priscilla > (assume OSPF is on both router interfaces connected with a T1 > circuit) > > Thank you > Shibu > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71405&t=71395 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF and ping [7:71349]
That does sound odd. Are you saying that, without the static default, in your routing table you have a gateway of last resort but it doesn;t work unless you statically define it on the MSFC? Dave riposi alessandro wrote: > i have this topology into my POP: > > two 6509( with MSFC2) which are connected with two juniper. The default > route of sc0 is ip_address of MSFC2, while the MSFC2 speaks with juniper > with OSPF process. The juniper originate the default always ad so the MSFC2 > receives the default by Ospf (External type2). > > my problem is the following: > with this configuration the MSFC can reach all ip of our backbone, while the > sc0 doesn't reach anyone ip (if we do a trace we see a series of * just by > first step). > If i configure the defualt manually into MSFC, with the command ip route > 0.0.0.0 0.0.0 next hop, the sc0 can reach all ip. > Do you know the cause of this behavior? > Best Regards > > Paolo -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "Government can do something for the people only in proportion as it can do something to the people." -- Thomas Jefferson Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71361&t=71349 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF and ping [7:71349]
What does traceroute show from the backbone to sc0 in both cases (when it works and when it doesn't)? Thanks, Zsombor At 02:04 PM 6/25/2003 +, riposi alessandro wrote: >i have this topology into my POP: > >two 6509( with MSFC2) which are connected with two juniper. The default >route of sc0 is ip_address of MSFC2, while the MSFC2 speaks with juniper >with OSPF process. The juniper originate the default always ad so the MSFC2 >receives the default by Ospf (External type2). > >my problem is the following: >with this configuration the MSFC can reach all ip of our backbone, while the >sc0 doesn't reach anyone ip (if we do a trace we see a series of * just by >first step). >If i configure the defualt manually into MSFC, with the command ip route >0.0.0.0 0.0.0 next hop, the sc0 can reach all ip. >Do you know the cause of this behavior? >Best Regards > >Paolo Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71359&t=71349 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Tricks of the Trade [7:66308]
See feedback inline. Eric - Original Message - From: "The Long and Winding Road" To: Sent: Thursday, March 27, 2003 7:09 AM Subject: OSPF Tricks of the Trade [7:66308] > After wrestling with Solie this afternoon, it suddenly occurred to me that > there is a typical instruction in the various practice labs that can end up > driving you nuts if you look at it from one direction, but which is really > simple if looked at from another. > > The topology: several routers over frame relay. Usually four routers. One > acts as hub, The others as spokes. > > the instruction: you must use subinterfaces only on the hub. On the spokes > you MUST use the physical interfaces. two of the spoke routes connect to the > hub via one subinterface. The other router connects to the hub on the other > subinterface. > > the catch: some bizarre restriction or other about network types, commands > that can or cannot be used, the usual BS. > > It occurs to me that working backwards, you can solve most problems, > whatever the restrictions and twists. > > Frame relay: OSPF default > - > > physical interface non broadcast > > subinterface - p2ppoint-to-point > > subinterface - multipoint non broadcast > > I think the knee jerk reaction is to create a multipoint subinterface for > the link to the two spoke routers, and a p2p subinterface for the link to > the single spoke router. Then moan in despair as you realize that the > instructions forbid the use of any ip ospf network commands anywhere. > > But if you look from the higher level viewpoint, you see that the physical > and the multipoint subinterface default to the same type of OSPF network. > Life is easier after that. Yes, that's the first thing I do: determine the default OSPF network type of involved interfaces After that investigate what this means for: - hello and dead timers (are they equal yes/no?); - DR/BDR election (yes/no); if yes: manual configuration required (by means of priority in neighbor statement), or is it automatic? - manual neighbor configuration required (yes/no)? > > Is this making sense? I'm at the end of a very long day, with too many > subtleties floating around in what's left of my brain. > > Good night, everyone. > > > > > > > > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71302&t=66308 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Topology Question - Parkhurst's Book [7:65532]
I haven't seen any feedback from others on your thoughts. See my comments below. Eric - Original Message - From: "The Long and Winding Road" To: Sent: Sunday, March 16, 2003 8:13 AM Subject: OSPF Topology Question - Parkhurst's Book [7:65532] > Ran into something in Parkhurst's OSPF book while studying tonight. Looking > for validation of my observation. > > The example: OSPF over frame relay > > The topology: hub and spoke, with a twist. The hub uses subinterfaces ( one > to each spoke router ) and the spokes use physical interfaces. > > Now, the Parkhurst examples show leaving the physical interfaces as ospf > type non-broadcast, change the ospf timers on the subinterfaces, place > neighbor statements on the spoke routers ( physical interfaces ) and all is > well. > > Except I don't believe it works this way. Neither do I, but I'm not sure. I wouldn't configure it like this. The spoke routers ( physical interfaces ) try to elect DR/BDR, which is not applicable for point-to-point interface on hub router. Note: if it were IS-IS, it would fail, since network types must match. > > The subinterfaces are point-to-point networks, and expect the other side to > be a point-to-point connection and adjacency. the physical interfaces are > non-broadcast, and expect DR elections to occur, something the router with > the subinterfaces will not do. Yep. > > I believe the correct solution is to make the physical interfaces ospf type > point-to-multipoint. If hub is p2p and spokes are p2m, then: - neither side requires DR/BDR election, which is good; - no manual neighbor configuration needed, which is good as well; - hello/dead timer are different (10/40 vs. 30/120 s), so you need to change one side, don't you? This should work. > > An alternative is to change the physical interfaces to ospf point-to-point. > Yes. > In any case - can anyone else verify what I see and do not see - that > Parkhurst chapter 11, example 3, pages 275-279 answer is incomplete? > I don't have that book. My still-to-read-pile is already too big. > thanks. > > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71301&t=65532 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over NMBA [7:70652]
sorry i forgot to show you my configurations becouse i dont have access to routers at these time, soon i must try some labs with multi-area do you have any lab examples 'configuratons or other things witch can be helpful' Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70667&t=70652 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over NMBA [7:70652]
""Nikolay Abromov"" wrote in message news:[EMAIL PROTECTED] > thanks for that link,but the problem was in that first i must advertise > major network (network witch i use to connect both routers) and then > configure neigbor, that was the reson. I guess I would have realized that if I had only read the configurations you supplied.. oh, that's right, you didn't provide configurations the question must have been for the psychics on the group :-> Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70663&t=70652 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over NMBA [7:70652]
thanks for that link,but the problem was in that first i must advertise major network (network witch i use to connect both routers) and then configure neigbor, that was the reson. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70662&t=70652 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over NMBA [7:70652]
""Nikolay Abromov"" wrote in message news:[EMAIL PROTECTED] > hello list, > > today i make a lab with tree routers,i try to configure ospf over > NBMA (frame-relay), the configuration is frame-relay switch and 2 routers > connect to him over serial lines, in other sides i describe the neighbor > and networks to advertise and when i wrote show running-config i dont see > any neighbor in the configuration of ospf, but in show ip ospf neigh i sow > the neighbor address, it's this bug? or it's a normal?! version of ios is > 12.1.7T. i forgot to reboot the router > to check it ;-) it depends on the network type. check out the chart I developed at: http://www.chuckslongroad.info/OSPF_Frame_Reference.htm it covers all the variations > > > and can anyone send me sample configuration of ospf router witch work over > frame-relay switch, i dont know it's that has any significance maybe my > configurations is wrong, i dont know. > > > > tnanks in advance Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70654&t=70652 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF Host Route [7:70439]
Colin, Can't remember if you got a reply. The classic case they are talking about is the Loopback address. Unless you have "ip ospf network point-to-multipoint" Loopback address are advertised as /32 routes. This might be tough to set up adjacencies with (since the neighbor won't be on the same segment) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Weiner Sent: Monday, June 09, 2003 10:58 PM To: [EMAIL PROTECTED] Subject: OSPF Host Route [7:70439] Ive been reading up on OSPF for the BSCI test and am confused as to what an OSPF Host Route is. RFC 2328 refers to OSPF host routes as "Hosts attached directly to routers". Is host route a route to a host? Am I missing something? Colin Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70638&t=70439 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Host Route [7:70439]
A host route is a route with all 1's as the mask... 255.255.255.255 JR -- Johnny Routin )?) - ""Colin Weiner"" wrote in message news:[EMAIL PROTECTED] > Ive been reading up on OSPF for the BSCI test and am confused as to what an > OSPF Host Route is. RFC 2328 refers to OSPF host routes as "Hosts attached > directly to routers". Is host route a route to a host? Am I missing > something? > > > Colin Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70454&t=70439 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF Host Route [7:70439]
Hi, Its nothing..its just that by default ospf advertises the loopback address as a host route i.e with a mask of /32. This default behaviour can be changed by giving the command ip ospf network point-to-multipoint under the interface config mode. Regards Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70446&t=70439 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over FR [7:70025]
you may want to check out the OSPF config guide on my website www.chuckslongroad.info hint - in the world of Cisco certification, it is essential that you master OSPF over NMBA in all its manifestations. ""Catherine Wu"" wrote in message news:[EMAIL PROTECTED] > I am testing Hub-Spoke for OSPF over FR, > > I verified the neighbor adjacency,but I couldn't see route 2.2.2.2 and > 3.3.3.3 in the routing table, > > RouterA#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 3.3.3.3 1 FULL/ -00:01:4110.1.1.6 > Serial0/0.2 > 2.2.2.2 1 FULL/ -00:01:3910.1.1.2 > Serial0/0.1 > RouterB#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 1 FULL/BDR00:01:3810.1.1.1 Serial0/0 > RouterC#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 1 FULL/BDR00:01:3410.1.1.5 Serial0/0 > > RouterA#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, ia - IS-IS inter > area >* - candidate default, U - per-user static route, o - ODR >P - periodic downloaded static route > > Gateway of last resort is not set > > 1.0.0.0/32 is subnetted, 1 subnets > C 1.1.1.1 is directly connected, Loopback0 > 10.0.0.0/30 is subnetted, 2 subnets > C 10.1.1.0 is directly connected, Serial0/0.1 > C 10.1.1.4 is directly connected, Serial0/0.2 > > Please help. > > Thanks > > Catherine > > RouterA > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > ! > interface Serial0/0 > no ip address > encapsulation frame-relay > frame-relay lmi-type ansi > no sh > ! > interface Serial0/0.1 point-to-point > ip address 10.1.1.1 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 101 > ! > interface Serial0/0.2 point-to-point > ip address 10.1.1.5 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 102 > ! > router ospf 1 > log-adjacency-changes > network 1.1.1.1 0.0.0.0 area 1 > network 10.1.1.0 0.0.0.3 area 0 > network 10.1.1.4 0.0.0.3 area 0 > > RouterB > ! > interface Loopback0 > ip address 2.2.2.2 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.2 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.1 110 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 2.2.2.2 0.0.0.0 area 2 > network 10.1.1.0 0.0.0.3 area 0 > neighbor 10.1.1.1 > ! > RouterC > interface Loopback0 > ip address 3.3.3.3 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.6 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.5 120 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 3.3.3.3 0.0.0.0 area 3 > network 10.1.1.4 0.0.0.3 area 0 > neighbor 10.1.1.5 > > [GroupStudy removed an attachment of type application/ms-tnef which had a > name of winmail.dat] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70297&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over FR [7:70025]
you may want to check out the OSPF config guide on my website www.chuckslongroad.info hint - in the world of Cisco certification, it is essential that you master OSPF over NMBA in all its manifestations. ""Catherine Wu"" wrote in message news:[EMAIL PROTECTED] > I am testing Hub-Spoke for OSPF over FR, > > I verified the neighbor adjacency,but I couldn't see route 2.2.2.2 and > 3.3.3.3 in the routing table, > > RouterA#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 3.3.3.3 1 FULL/ -00:01:4110.1.1.6 > Serial0/0.2 > 2.2.2.2 1 FULL/ -00:01:3910.1.1.2 > Serial0/0.1 > RouterB#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 1 FULL/BDR00:01:3810.1.1.1 Serial0/0 > RouterC#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 1 FULL/BDR00:01:3410.1.1.5 Serial0/0 > > RouterA#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, ia - IS-IS inter > area >* - candidate default, U - per-user static route, o - ODR >P - periodic downloaded static route > > Gateway of last resort is not set > > 1.0.0.0/32 is subnetted, 1 subnets > C 1.1.1.1 is directly connected, Loopback0 > 10.0.0.0/30 is subnetted, 2 subnets > C 10.1.1.0 is directly connected, Serial0/0.1 > C 10.1.1.4 is directly connected, Serial0/0.2 > > Please help. > > Thanks > > Catherine > > RouterA > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > ! > interface Serial0/0 > no ip address > encapsulation frame-relay > frame-relay lmi-type ansi > no sh > ! > interface Serial0/0.1 point-to-point > ip address 10.1.1.1 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 101 > ! > interface Serial0/0.2 point-to-point > ip address 10.1.1.5 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 102 > ! > router ospf 1 > log-adjacency-changes > network 1.1.1.1 0.0.0.0 area 1 > network 10.1.1.0 0.0.0.3 area 0 > network 10.1.1.4 0.0.0.3 area 0 > > RouterB > ! > interface Loopback0 > ip address 2.2.2.2 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.2 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.1 110 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 2.2.2.2 0.0.0.0 area 2 > network 10.1.1.0 0.0.0.3 area 0 > neighbor 10.1.1.1 > ! > RouterC > interface Loopback0 > ip address 3.3.3.3 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.6 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.5 120 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 3.3.3.3 0.0.0.0 area 3 > network 10.1.1.4 0.0.0.3 area 0 > neighbor 10.1.1.5 > > [GroupStudy removed an attachment of type application/ms-tnef which had a > name of winmail.dat] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70238&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF over FR [7:70025]
You can not mix point-to-point and non-broadcast network types which is what you are trying to do. You can make them neighbors but they will never install routes into the routing table. Look at their OSPF databases and you will see the LSA's but the routers will not install them in the routing table. Also note the "Adv Router is not-reachable" error message above each LSA. Network types that use a DR (broadcast and non-broadcast) can be mixed together just as network types that do not use a DR (point-to-point and point-to-multipoint) can mixed but DR types can NOT mix with non-DR types. Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Catherine Wu Sent: Monday, June 02, 2003 2:52 PM To: [EMAIL PROTECTED] Subject: OSPF over FR [7:70025] I am testing Hub-Spoke for OSPF over FR, I verified the neighbor adjacency,but I couldn't see route 2.2.2.2 and 3.3.3.3 in the routing table, RouterA#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 FULL/ -00:01:4110.1.1.6 Serial0/0.2 2.2.2.2 1 FULL/ -00:01:3910.1.1.2 Serial0/0.1 RouterB#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR00:01:3810.1.1.1 Serial0/0 RouterC#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR00:01:3410.1.1.5 Serial0/0 RouterA#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, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 10.0.0.0/30 is subnetted, 2 subnets C 10.1.1.0 is directly connected, Serial0/0.1 C 10.1.1.4 is directly connected, Serial0/0.2 Please help. Thanks Catherine RouterA interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0/0 no ip address encapsulation frame-relay frame-relay lmi-type ansi no sh ! interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.252 ip ospf hello-interval 30 frame-relay interface-dlci 101 ! interface Serial0/0.2 point-to-point ip address 10.1.1.5 255.255.255.252 ip ospf hello-interval 30 frame-relay interface-dlci 102 ! router ospf 1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 1 network 10.1.1.0 0.0.0.3 area 0 network 10.1.1.4 0.0.0.3 area 0 RouterB ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial0/0 ip address 10.1.1.2 255.255.255.252 encapsulation frame-relay frame-relay map ip 10.1.1.1 110 broadcast no frame-relay inverse-arp frame-relay lmi-type ansi no sh ! router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 2 network 10.1.1.0 0.0.0.3 area 0 neighbor 10.1.1.1 ! RouterC interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Serial0/0 ip address 10.1.1.6 255.255.255.252 encapsulation frame-relay frame-relay map ip 10.1.1.5 120 broadcast no frame-relay inverse-arp frame-relay lmi-type ansi no sh ! router ospf 1 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 3 network 10.1.1.4 0.0.0.3 area 0 neighbor 10.1.1.5 [GroupStudy removed an attachment of type application/ms-tnef which had a name of winmail.dat] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70028&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF over FR [7:70025]
Brian, Thank you very much for clarifying my concept. Catherine -Original Message- From: Brian Dennis [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 4:40 PM To: 'Catherine Wu'; [EMAIL PROTECTED] Subject: RE: OSPF over FR [7:70025] You can not mix point-to-point and non-broadcast network types which is what you are trying to do. You can make them neighbors but they will never install routes into the routing table. Look at their OSPF databases and you will see the LSA's but the routers will not install them in the routing table. Also note the "Adv Router is not-reachable" error message above each LSA. Network types that use a DR (broadcast and non-broadcast) can be mixed together just as network types that do not use a DR (point-to-point and point-to-multipoint) can mixed but DR types can NOT mix with non-DR types. Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Catherine Wu Sent: Monday, June 02, 2003 2:52 PM To: [EMAIL PROTECTED] Subject: OSPF over FR [7:70025] I am testing Hub-Spoke for OSPF over FR, I verified the neighbor adjacency,but I couldn't see route 2.2.2.2 and 3.3.3.3 in the routing table, RouterA#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 FULL/ -00:01:4110.1.1.6 Serial0/0.2 2.2.2.2 1 FULL/ -00:01:3910.1.1.2 Serial0/0.1 RouterB#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR00:01:3810.1.1.1 Serial0/0 RouterC#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR00:01:3410.1.1.5 Serial0/0 RouterA#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, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 10.0.0.0/30 is subnetted, 2 subnets C 10.1.1.0 is directly connected, Serial0/0.1 C 10.1.1.4 is directly connected, Serial0/0.2 Please help. Thanks Catherine RouterA interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0/0 no ip address encapsulation frame-relay frame-relay lmi-type ansi no sh ! interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.252 ip ospf hello-interval 30 frame-relay interface-dlci 101 ! interface Serial0/0.2 point-to-point ip address 10.1.1.5 255.255.255.252 ip ospf hello-interval 30 frame-relay interface-dlci 102 ! router ospf 1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 1 network 10.1.1.0 0.0.0.3 area 0 network 10.1.1.4 0.0.0.3 area 0 RouterB ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial0/0 ip address 10.1.1.2 255.255.255.252 encapsulation frame-relay frame-relay map ip 10.1.1.1 110 broadcast no frame-relay inverse-arp frame-relay lmi-type ansi no sh ! router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 2 network 10.1.1.0 0.0.0.3 area 0 neighbor 10.1.1.1 ! RouterC interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Serial0/0 ip address 10.1.1.6 255.255.255.252 encapsulation frame-relay frame-relay map ip 10.1.1.5 120 broadcast no frame-relay inverse-arp frame-relay lmi-type ansi no sh ! router ospf 1 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 3 network 10.1.1.4 0.0.0.3 area 0 neighbor 10.1.1.5 [GroupStudy removed an attachment of type application/ms-tnef which had a name of winmail.dat] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70047&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF redistribution question with BGP [7:69914]
Yes you can. Route maps are your friend. You can specify a routemap on the end of the "redistribute" command. As long as you block anything thats conflicting (you could always NAT that) the stuff that doesnt conflict should be fine :) TTFN Lauren Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70129&t=69914 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF over FR [7:70025]
Hi Catherine, Because you are using point to point sub interfaces on the one routea and one the other just using the real interface, OSPF behaves differently and has different helo / dead timers etc, and this is why you are not getting all your routes. You need to make sure that all ospf interfaces in the same area are of the same "network type" using the interface command ip ospf network Below is a link to a quick ref http://www.chuckslongroad.info/OSPF_Frame_Reference.htm Catherine Wu wrote: > > I am testing Hub-Spoke for OSPF over FR, > > I verified the neighbor adjacency,but I couldn't see route > 2.2.2.2 and > 3.3.3.3 in the routing table, > > RouterA#sh ip ospf nei > > Neighbor ID Pri State Dead Time > Address Interface > 3.3.3.3 1 FULL/ -00:01:4110.1.1.6 > Serial0/0.2 > 2.2.2.2 1 FULL/ -00:01:3910.1.1.2 > Serial0/0.1 > RouterB#sh ip ospf nei > > Neighbor ID Pri State Dead Time > Address Interface > 1.1.1.1 1 FULL/BDR00:01:38 > 10.1.1.1Serial0/0 > RouterC#sh ip ospf nei > > Neighbor ID Pri State Dead Time > Address Interface > 1.1.1.1 1 FULL/BDR00:01:34 > 10.1.1.5Serial0/0 > > RouterA#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, ia - > IS-IS inter > area >* - candidate default, U - per-user static route, o - ODR >P - periodic downloaded static route > > Gateway of last resort is not set > > 1.0.0.0/32 is subnetted, 1 subnets > C 1.1.1.1 is directly connected, Loopback0 > 10.0.0.0/30 is subnetted, 2 subnets > C 10.1.1.0 is directly connected, Serial0/0.1 > C 10.1.1.4 is directly connected, Serial0/0.2 > > Please help. > > Thanks > > Catherine > > RouterA > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > ! > interface Serial0/0 > no ip address > encapsulation frame-relay > frame-relay lmi-type ansi > no sh > ! > interface Serial0/0.1 point-to-point > ip address 10.1.1.1 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 101 > ! > interface Serial0/0.2 point-to-point > ip address 10.1.1.5 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 102 > ! > router ospf 1 > log-adjacency-changes > network 1.1.1.1 0.0.0.0 area 1 > network 10.1.1.0 0.0.0.3 area 0 > network 10.1.1.4 0.0.0.3 area 0 > > RouterB > ! > interface Loopback0 > ip address 2.2.2.2 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.2 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.1 110 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 2.2.2.2 0.0.0.0 area 2 > network 10.1.1.0 0.0.0.3 area 0 > neighbor 10.1.1.1 > ! > RouterC > interface Loopback0 > ip address 3.3.3.3 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.6 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.5 120 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 3.3.3.3 0.0.0.0 area 3 > network 10.1.1.4 0.0.0.3 area 0 > neighbor 10.1.1.5 > > [GroupStudy removed an attachment of type application/ms-tnef > which had a name of winmail.dat] > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70054&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over FR [7:70025]
Catherine, You forget to define ospf network type in each frame interface. Add this interface config command: ip ospf network point-to-point Thank, Rivalino Exactly right but you will have to do 2 more things: 1)Since you changed the hello-interval to 30 on Router A's point-to-point subinterfaces you will have to do the same for Router B and Router C's interfaces. 2) Remove the neighbor statement from Router B and Router C's OSPF process. Not needed. So just add the "ip ospf network point-to-point on Routers B and C frame relay physical interface and do steps 1 and 2. Best of luck. Danny Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70046&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over FR [7:70025]
Catherine, You forget to define ospf network type in each frame interface. Add this interface config command: ip ospf network point-to-point Thank, Rivalino On Mon, 2 Jun 2003, Catherine Wu wrote: > I am testing Hub-Spoke for OSPF over FR, > > I verified the neighbor adjacency,but I couldn't see route 2.2.2.2 and > 3.3.3.3 in the routing table, > > RouterA#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 3.3.3.3 1 FULL/ -00:01:4110.1.1.6 > Serial0/0.2 > 2.2.2.2 1 FULL/ -00:01:3910.1.1.2 > Serial0/0.1 > RouterB#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 1 FULL/BDR00:01:3810.1.1.1Serial0/0 > RouterC#sh ip ospf nei > > Neighbor ID Pri State Dead Time Address Interface > 1.1.1.1 1 FULL/BDR00:01:3410.1.1.5Serial0/0 > > RouterA#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, ia - IS-IS inter > area >* - candidate default, U - per-user static route, o - ODR >P - periodic downloaded static route > > Gateway of last resort is not set > > 1.0.0.0/32 is subnetted, 1 subnets > C 1.1.1.1 is directly connected, Loopback0 > 10.0.0.0/30 is subnetted, 2 subnets > C 10.1.1.0 is directly connected, Serial0/0.1 > C 10.1.1.4 is directly connected, Serial0/0.2 > > Please help. > > Thanks > > Catherine > > RouterA > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > ! > interface Serial0/0 > no ip address > encapsulation frame-relay > frame-relay lmi-type ansi > no sh > ! > interface Serial0/0.1 point-to-point > ip address 10.1.1.1 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 101 > ! > interface Serial0/0.2 point-to-point > ip address 10.1.1.5 255.255.255.252 > ip ospf hello-interval 30 > frame-relay interface-dlci 102 > ! > router ospf 1 > log-adjacency-changes > network 1.1.1.1 0.0.0.0 area 1 > network 10.1.1.0 0.0.0.3 area 0 > network 10.1.1.4 0.0.0.3 area 0 > > RouterB > ! > interface Loopback0 > ip address 2.2.2.2 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.2 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.1 110 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 2.2.2.2 0.0.0.0 area 2 > network 10.1.1.0 0.0.0.3 area 0 > neighbor 10.1.1.1 > ! > RouterC > interface Loopback0 > ip address 3.3.3.3 255.255.255.255 > ! > interface Serial0/0 > ip address 10.1.1.6 255.255.255.252 > encapsulation frame-relay > frame-relay map ip 10.1.1.5 120 broadcast > no frame-relay inverse-arp > frame-relay lmi-type ansi > no sh > ! > router ospf 1 > log-adjacency-changes > network 3.3.3.3 0.0.0.0 area 3 > network 10.1.1.4 0.0.0.3 area 0 > neighbor 10.1.1.5 > > [GroupStudy removed an attachment of type application/ms-tnef which had a > name of winmail.dat] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70036&t=70025 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF redistribution question with BGP [7:69914]
Hi John, I'm busy preparing for the CCIE written. I came across a very good example that is related to your problem in Routing TCP/IP Vol. 2 (Doyle) p.369. What it comes down to is that you have a merger between 2 companies that are both using the 10.0.0.0 network on their private networks - sounds familiar? The solution is to use NAT. It is however stated very clearly that this is an interim solution, and the best solution is to readdress the network. You'll see that once you implement the NAT solution it's really quite simple. Regards, (PS. I see that you are from Sydney. I have plans to move to Australia next year, and was wondering if you can tell me if you like living in Sydney?) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69966&t=69914 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF over FR [7:69527]
study sam halabi - ospf design guide -N ""ericbrouwers"" wrote in message news:[EMAIL PROTECTED] > Rivalino, > > Here are five examples I made when studying BSCI. I used a/o following > books: > - the Sybex BSCI book, > - Cisco Press Routing Cert. Guide, > - CCO IOS IP Configuration Guide, > - TAC OSPF design guide. > > This enabled me to reconstruct the following five cases. Also do a search in > the archive, there were several good contributions. Also check Chuck > Larrieu's OSPF Frame Relay WAN Reference Sheet. The link is somewhere in the > archive. I haven't checked Chuck's notes yet, so I don't know whether my > configs below are consistent with it. > > Have fun!!! > > OSPF in NBMA mode > = > Router(config)#int s0 > Router(config-if)#ip address 172.31.10.1 255.255.255.0 > Router(config-if)#encapsulation frame-relay > Router(config-if)#ip ospf network non-broadcast > ! optional since non-broadcast mode is default for serial FR interface!! > Router(config-if)#exit > Router(config)#router ospf 10 > Router(config-router)#network 172.31.10.0 0.0.0.255 area 0 > Router(config-router)#neighbor 172.31.10.2 priority 1 > Router(config-router)#neighbor 172.31.10.3 priority 1 > ! manual neighbour configuration and manual DR/BDR! > > > OSPF in broadcast mode > == > Router(config)#int s0 > Router(config-if)#ip address 172.31.10.1 255.255.255.0 > Router(config-if)#encapsulation frame-relay > Router(config-if)#ip ospf network broadcast > Router(config-if)#exit > Router(config)#router ospf 10 > Router(config-router)#network 172.31.10.0 0.0.0.255 area 0 > > > OSPF in point-to-point mode > === > Router(config)#int s0 > Router(config-if)#no ip address > Router(config-if)#encapsulation frame-relay > Router(config-if)#ip ospf network point-to-point > ! optional since p2p mode is default p2p sub interfaces!! > Router(config-if)#int s0.101 point-to-point > Router(config-subif)#ip address 172.31.10.1 255.255.255.252 > Router(config-subif)#frame-relay interface-dlci 101 > Router(config-if)#int s0.102 point-to-point > Router(config-subif)#ip address 172.31.20.1 255.255.255.252 > Router(config-subif)#frame-relay interface-dlci 102 > Router(config)#router ospf 10 > Router(config-router)#network 172.31.0.0 0.0.255.255 area 0 > > > OSPF in point-to-multipoint mode > > Router(config)#int s0 > Router(config-if)#ip address 172.31.10.1 255.255.255.0 > Router(config-if)#encapsulation frame-relay > Router(config-if)#ip ospf network point-to-multipoint > Router(config-if)#exit > Router(config)#router ospf 10 > Router(config-router)#network 172.31.10.0 0.0.0.255 area 0 > ! no manual neighbour configuration needed; no DR/BDR!!! > > > OSPF in point-to-multipoint non-broadcast mode > == > Router(config)#int s0 > Router(config-if)#ip address 172.31.10.1 255.255.255.0 > Router(config-if)#encapsulation frame-relay > Router(config-if)#ip ospf network point-to-multipoint non-broadcast > Router(config-if)#exit > Router(config)#router ospf 10 > Router(config-router)#network 172.31.10.0 0.0.0.255 area 0 > Router(config-router)#neighbor 172.31.10.2 > Router(config-router)#neighbor 172.31.10.3 > !only manual neighbour configuration needed; no DR/BDR!!! > > > Take care, > > Eric Brouwers > > > - Original Message - > From: "Rivalino YMT." > To: > Sent: Monday, May 26, 2003 4:49 AM > Subject: OSPF over FR [7:69527] > > > > Hi, > > > > Do you know 5 ways implementing OSPF over Frame relay? Or maybe you can > > advise me some books to study this matter? > > > > Thanks in advance, > > Rivalino Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69701&t=69527 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF NSSA [7:66957]
Yep. You'll need a virtual-link between R1 and R2. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66958&t=66957 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF Adjacency Question [7:66206]
Are both side of the link on sub interfaces? Do you have anything configure on the main interface or any unassigned DLCI's, which are automatically assigned to the default interface? With OSPF I tend to only inlcude networks to which the router is directly attached, so in your case, network x.x.x.12 0.0.0.3 area 1. Try doing a debug ospf and post the output from that .. may provide more insight. Cheers Troy CiscoNewbie wrote: > > Hi all. my cisco router keeps reporting this error when trying > to bring up an adjacency accross a P2P link. > > OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: > src not on the same network > > I am presuming that the issue here is the subnet mask that I > have specified the network statement as under OSPF. My serial > interface (frame-relay subinterface) has a /30 mask. How > should my network statement be configured if the IP address of > the interface is xxx.xxx.xxx.14? I have tried the following: > > network xxx.xxx.xxx.0 0.0.0.255 area 1 > > as well as: > > network xxx.xxx.xxx.12 0.0.0.3 area 1 > > Neither one seemed to work. I still got the same error. > > The other side is also on the same subnet and it has an IP > address of xxx.xxx.xxx.13/30 configured as a P2P as well. If > the network statement is not the issue, please advise. > > Thanks. > > > > - > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your > desktop! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66543&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF BGP redistiribution question [7:66430]
I hate to say what the problem appears to be. think summarization :- wrote in message news:[EMAIL PROTECTED] > Chuck, > My first thought is what does the "sh ip bgp for the > routes that does not show up in BGP indicate. > > I believe there is a requirement not to disable "sync" which suggest that > the routes not being added to the BGP, isn't sync'd with the IGP. Does any > of this have route information being propagated from an IBGP neighbor. > > Nigel > > > - Original Message - > From: "The Long and Winding Road" > To: > Sent: Saturday, March 29, 2003 2:27 AM > Subject: OSPF BGP redistiribution question [7:66430] > > > > NLI ( b..o..o..t..c..a..m..p.. lab 8 ) redistribution of OSPF and BGP > > > > I checked CCO and the "answer" key > > > > everything "appears" to be correct. > > > > So why is it that half my OSPF routes do not show up in the BGP table??? > > > > *> 137.20.0.0 0.0.0.0 0 32768 ? > > * i137.20.40.16/28 137.20.25.2164100 0 i > > *> 0.0.0.0110 32768 i > > *> 137.20.100.33/32 0.0.0.0138 32768 i > > *> 137.20.100.34/32 0.0.0.0 74 32768 i > > *> 137.20.100.35/32 0.0.0.0 74 32768 i > > *>i172.168.70.0/24 137.20.10.70 170100 0 3 i > > *> 172.168.80.0/24 137.20.86.1 0 0 1 i > > R# > > > > O IA 200.200.200.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > > 137.20.0.0/16 is variably subnetted, 12 subnets, 4 masks > > O E1137.20.200.16/28 [110/110] via 137.20.64.5, 02:27:46, Ethernet0 > > O IA137.20.30.0/24 [110/84] via 137.20.64.5, 02:27:46, Ethernet0 > > O IA137.20.25.0/24 [110/74] via 137.20.64.5, 02:27:46, Ethernet0 > > O IA137.20.20.0/24 [110/84] via 137.20.64.5, 02:27:46, Ethernet0 > > O E1137.20.40.16/28 [110/110] via 137.20.64.5, 02:27:46, Ethernet0 > > O IA137.20.88.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > > O IA137.20.100.33/32 [110/138] via 137.20.64.5, 02:19:42, Ethernet0 > > O IA137.20.100.35/32 [110/74] via 137.20.64.5, 02:19:42, Ethernet0 > > O IA137.20.100.34/32 [110/74] via 137.20.64.5, 02:19:42, Ethernet0 > > O IA137.20.100.0/24 [110/10] via 137.20.64.5, 02:19:42, Ethernet0 > > O IA 200.200.100.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > > > > lest you wonder, I am using the proper ( so I think ) form of the > > redistribute comand, covering OSPF internal and external ) > > > > router bgp 2 > > no synchronization > > bgp log-neighbor-changes > > network 137.20.20.0 mask 255.255.255.0 backdoor > > network 137.20.25.0 mask 255.255.255.0 backdoor > > network 137.20.30.0 mask 255.255.255.0 backdoor > > network 137.20.40.16 mask 255.255.255.240 > > network 137.20.88.0 mask 255.255.255.0 backdoor > > network 137.20.100.33 mask 255.255.255.255 > > network 137.20.100.34 mask 255.255.255.255 > > network 137.20.100.35 mask 255.255.255.255 > > network 137.20.100.0 mask 255.255.255.0 backdoor > > network 137.20.200.16 mask 255.255.255.240 backdoor > > network 200.200.100.0 backdoor > > network 200.200.200.0 backdoor > > redistribute ospf 239 match internal external 1 external 2 > ((( ---SEE > > I told you so! > > neighbor 137.20.25.1 remote-as 2 > > neighbor 137.20.25.1 ebgp-multihop 3 > > neighbor 137.20.86.1 remote-as 1 > > > > > > any help appreciated > > > > Chuck! > > > > -- > > TANSTAAFL > > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66495&t=66430 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF BGP redistribution question [7:66430]
My two cents Another thing that is very important and critical with redistribution is the metric being used in both directions... Juan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nigel Taylor Sent: Sunday, March 30, 2003 3:52 AM To: [EMAIL PROTECTED] Subject: Re: OSPF BGP redistiribution question [7:66430] Chuck, My first thought is what does the "sh ip bgp for the routes that does not show up in BGP indicate. I believe there is a requirement not to disable "sync" which suggest that the routes not being added to the BGP, isn't sync'd with the IGP. Does any of this have route information being propagated from an IBGP neighbor. Nigel - Original Message - From: "The Long and Winding Road" To: Sent: Saturday, March 29, 2003 2:27 AM Subject: OSPF BGP redistiribution question [7:66430] > NLI ( b..o..o..t..c..a..m..p.. lab 8 ) redistribution of OSPF and BGP > > I checked CCO and the "answer" key > > everything "appears" to be correct. > > So why is it that half my OSPF routes do not show up in the BGP table??? > > *> 137.20.0.0 0.0.0.0 0 32768 ? > * i137.20.40.16/28 137.20.25.2164100 0 i > *> 0.0.0.0110 32768 i > *> 137.20.100.33/32 0.0.0.0138 32768 i > *> 137.20.100.34/32 0.0.0.0 74 32768 i > *> 137.20.100.35/32 0.0.0.0 74 32768 i > *>i172.168.70.0/24 137.20.10.70 170100 0 3 i > *> 172.168.80.0/24 137.20.86.1 0 0 1 i > R# > > O IA 200.200.200.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > 137.20.0.0/16 is variably subnetted, 12 subnets, 4 masks > O E1137.20.200.16/28 [110/110] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.30.0/24 [110/84] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.25.0/24 [110/74] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.20.0/24 [110/84] via 137.20.64.5, 02:27:46, Ethernet0 > O E1137.20.40.16/28 [110/110] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.88.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.100.33/32 [110/138] via 137.20.64.5, 02:19:42, Ethernet0 > O IA137.20.100.35/32 [110/74] via 137.20.64.5, 02:19:42, Ethernet0 > O IA137.20.100.34/32 [110/74] via 137.20.64.5, 02:19:42, Ethernet0 > O IA137.20.100.0/24 [110/10] via 137.20.64.5, 02:19:42, Ethernet0 > O IA 200.200.100.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > > lest you wonder, I am using the proper ( so I think ) form of the > redistribute comand, covering OSPF internal and external ) > > router bgp 2 > no synchronization > bgp log-neighbor-changes > network 137.20.20.0 mask 255.255.255.0 backdoor > network 137.20.25.0 mask 255.255.255.0 backdoor > network 137.20.30.0 mask 255.255.255.0 backdoor > network 137.20.40.16 mask 255.255.255.240 > network 137.20.88.0 mask 255.255.255.0 backdoor > network 137.20.100.33 mask 255.255.255.255 > network 137.20.100.34 mask 255.255.255.255 > network 137.20.100.35 mask 255.255.255.255 > network 137.20.100.0 mask 255.255.255.0 backdoor > network 137.20.200.16 mask 255.255.255.240 backdoor > network 200.200.100.0 backdoor > network 200.200.200.0 backdoor > redistribute ospf 239 match internal external 1 external 2 ((( ---SEE > I told you so! > neighbor 137.20.25.1 remote-as 2 > neighbor 137.20.25.1 ebgp-multihop 3 > neighbor 137.20.86.1 remote-as 1 > > > any help appreciated > > Chuck! > > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66490&t=66430 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF BGP redistiribution question [7:66430]
Chuck, My first thought is what does the "sh ip bgp for the routes that does not show up in BGP indicate. I believe there is a requirement not to disable "sync" which suggest that the routes not being added to the BGP, isn't sync'd with the IGP. Does any of this have route information being propagated from an IBGP neighbor. Nigel - Original Message - From: "The Long and Winding Road" To: Sent: Saturday, March 29, 2003 2:27 AM Subject: OSPF BGP redistiribution question [7:66430] > NLI ( b..o..o..t..c..a..m..p.. lab 8 ) redistribution of OSPF and BGP > > I checked CCO and the "answer" key > > everything "appears" to be correct. > > So why is it that half my OSPF routes do not show up in the BGP table??? > > *> 137.20.0.0 0.0.0.0 0 32768 ? > * i137.20.40.16/28 137.20.25.2164100 0 i > *> 0.0.0.0110 32768 i > *> 137.20.100.33/32 0.0.0.0138 32768 i > *> 137.20.100.34/32 0.0.0.0 74 32768 i > *> 137.20.100.35/32 0.0.0.0 74 32768 i > *>i172.168.70.0/24 137.20.10.70 170100 0 3 i > *> 172.168.80.0/24 137.20.86.1 0 0 1 i > R# > > O IA 200.200.200.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > 137.20.0.0/16 is variably subnetted, 12 subnets, 4 masks > O E1137.20.200.16/28 [110/110] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.30.0/24 [110/84] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.25.0/24 [110/74] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.20.0/24 [110/84] via 137.20.64.5, 02:27:46, Ethernet0 > O E1137.20.40.16/28 [110/110] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.88.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > O IA137.20.100.33/32 [110/138] via 137.20.64.5, 02:19:42, Ethernet0 > O IA137.20.100.35/32 [110/74] via 137.20.64.5, 02:19:42, Ethernet0 > O IA137.20.100.34/32 [110/74] via 137.20.64.5, 02:19:42, Ethernet0 > O IA137.20.100.0/24 [110/10] via 137.20.64.5, 02:19:42, Ethernet0 > O IA 200.200.100.0/24 [110/75] via 137.20.64.5, 02:27:46, Ethernet0 > > lest you wonder, I am using the proper ( so I think ) form of the > redistribute comand, covering OSPF internal and external ) > > router bgp 2 > no synchronization > bgp log-neighbor-changes > network 137.20.20.0 mask 255.255.255.0 backdoor > network 137.20.25.0 mask 255.255.255.0 backdoor > network 137.20.30.0 mask 255.255.255.0 backdoor > network 137.20.40.16 mask 255.255.255.240 > network 137.20.88.0 mask 255.255.255.0 backdoor > network 137.20.100.33 mask 255.255.255.255 > network 137.20.100.34 mask 255.255.255.255 > network 137.20.100.35 mask 255.255.255.255 > network 137.20.100.0 mask 255.255.255.0 backdoor > network 137.20.200.16 mask 255.255.255.240 backdoor > network 200.200.100.0 backdoor > network 200.200.200.0 backdoor > redistribute ospf 239 match internal external 1 external 2 ((( ---SEE > I told you so! > neighbor 137.20.25.1 remote-as 2 > neighbor 137.20.25.1 ebgp-multihop 3 > neighbor 137.20.86.1 remote-as 1 > > > any help appreciated > > Chuck! > > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66474&t=66430 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Adjacency Question [7:66206]
""CiscoNewbie"" wrote in message news:[EMAIL PROTECTED] > Hi all. my cisco router keeps reporting this error when trying to bring up > an adjacency accross a P2P link. > > OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: src not on the > same network my eperience is that you should take this error literally. triple check the serial interface addresses on both sides of the link. the network prefix must match router---1.1.1.13/30--1.1.1.14/30---router for kicks, change the addresses on both sides to a /24 and see what happens. also - since you are using subinterfaces, do you have more than one router connected via different subinterfaces? got your dlcis crossed? > > I am presuming that the issue here is the subnet mask that I have specified > the network statement as under OSPF. My serial interface (frame-relay > subinterface) has a /30 mask. How should my network statement be configured > if the IP address of the interface is xxx.xxx.xxx.14? I have tried the > following: > > network xxx.xxx.xxx.0 0.0.0.255 area 1 > > as well as: > > network xxx.xxx.xxx.12 0.0.0.3 area 1 the network mask command places interfaces into the OSPF process, and nothing more. any interface which falls within the rage covered by the network / mask will be placed into OSPF, no matter what the interface address / mask may be. So even if you had 20 different interfaces with 20 different masks, so long as the interface address falls within the definition of the ospf network / mask it will be placed into the OSPF process and OSPF hellos will be sent out those interfaces. > > Neither one seemed to work. I still got the same error. > > The other side is also on the same subnet and it has an IP address of > xxx.xxx.xxx.13/30 configured as a P2P as well. If the network statement is > not the issue, please advise. > > Thanks. > > > > - > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66330&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF Adjacency Question [7:66206]
Are both side of the link on sub interfaces? Do you have anything configure on the main interface or any unassigned DLCI's, which are automatically assigned to the default interface? With OSPF I tend to only inlcude networks to which the router is directly attached, so in your case, network x.x.x.12 0.0.0.3 area 1. Try doing a debug ospf and post the output from that .. may provide more insight. Cheers Troy CiscoNewbie wrote: > > Hi all. my cisco router keeps reporting this error when trying > to bring up an adjacency accross a P2P link. > > OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: > src not on the same network > > I am presuming that the issue here is the subnet mask that I > have specified the network statement as under OSPF. My serial > interface (frame-relay subinterface) has a /30 mask. How > should my network statement be configured if the IP address of > the interface is xxx.xxx.xxx.14? I have tried the following: > > network xxx.xxx.xxx.0 0.0.0.255 area 1 > > as well as: > > network xxx.xxx.xxx.12 0.0.0.3 area 1 > > Neither one seemed to work. I still got the same error. > > The other side is also on the same subnet and it has an IP > address of xxx.xxx.xxx.13/30 configured as a P2P as well. If > the network statement is not the issue, please advise. > > Thanks. > > > > - > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your > desktop! > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66325&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Tricks of the Trade [7:66308]
Another good one!! Could also add that Ospf timers need to be kept in mind if the hub is using say for ex. a multipoint and the spoke a point-to-point and the task is NOT to configure any #ip ospf network cmd. on the spokes >From: "The Long and Winding Road" >Reply-To: "The Long and Winding Road" >To: [EMAIL PROTECTED] >Subject: OSPF Tricks of the Trade [7:66308] >Date: Thu, 27 Mar 2003 05:09:30 GMT > >After wrestling with Solie this afternoon, it suddenly occurred to me that >there is a typical instruction in the various practice labs that can end up >driving you nuts if you look at it from one direction, but which is really >simple if looked at from another. > >The topology: several routers over frame relay. Usually four routers. One >acts as hub, The others as spokes. > >the instruction: you must use subinterfaces only on the hub. On the spokes >you MUST use the physical interfaces. two of the spoke routes connect to >the >hub via one subinterface. The other router connects to the hub on the other >subinterface. > >the catch: some bizarre restriction or other about network types, commands >that can or cannot be used, the usual BS. > >It occurs to me that working backwards, you can solve most problems, >whatever the restrictions and twists. > >Frame relay: OSPF default >- > >physical interface non broadcast > >subinterface - p2ppoint-to-point > >subinterface - multipoint non broadcast > >I think the knee jerk reaction is to create a multipoint subinterface for >the link to the two spoke routers, and a p2p subinterface for the link to >the single spoke router. Then moan in despair as you realize that the >instructions forbid the use of any ip ospf network commands anywhere. > >But if you look from the higher level viewpoint, you see that the physical >and the multipoint subinterface default to the same type of OSPF network. >Life is easier after that. > >Is this making sense? I'm at the end of a very long day, with too many >subtleties floating around in what's left of my brain. > >Good night, everyone. > > > > > > > >-- >TANSTAAFL >"there ain't no such thing as a free lunch" _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66321&t=66308 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Adjacency Question [7:66206]
Hi, Probably I should have asked some more questions - Hello packet has the following important fields that should match on both routers trying to form adjacency - 1. Network Mask, 2. Hello Interval, 3. Options field 4. Router dead interval Make sure that the neighboring interfaces are of same network type. Are you using any authentications which may not be matching. There is a possibility of accesslist also. What does the debug ip ospf adj say ? Murali CiscoNewbie wrote: Hi and thanks for your reply. I had already attempted what you suggested and still the adjacency does not come up. Can you (or any list member) clarify for me whether the network command along with the wildcard mask have to match exactly as the interface for which you are enabling OSPF is configured for? Would the use of the network statement as follows work as well: network xxx.xxx.xxx.14 0.0.0.3 area 1 or does it have to be netowrk "aligned"? When the hello packets are exchanged, the mask is also carried, so where does the router get the mask for the interface it is advertising? Is it derived from the network statement? Can someone explain what the error that I was seeing means? Thanks. Murali Das wrote: CiscoNewbie wrote: Hi all. my cisco router keeps reporting this error when trying to bring up an adjacency accross a P2P link. OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: src not on the same network I am presuming that the issue here is the subnet mask that I have specified the network statement as under OSPF. My serial interface (frame-relay subinterface) has a /30 mask. How should my network statement be configured if the IP address of the interface is xxx.xxx.xxx.14? I have tried the following: network xxx.xxx.xxx.0 0.0.0.255 area 1 as well as: network xxx.xxx.xxx.12 0.0.0.3 area 1 try this network xx.xx.xx.14 0.0.0.0 area 1 Neither one seemed to work. I still got the same error. The other side is also on the same subnet and it has an IP address of xxx.xxx.xxx.13/30 configured as a P2P as well. If the network statement is not the issue, please advise. Thanks. - Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! - Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! - Do you Yahoo!? Yahoo! News - Today's headlines Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66268&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Adjacency Question [7:66206]
Hi and thanks for your reply. I had already attempted what you suggested and still the adjacency does not come up. Can you (or any list member) clarify for me whether the network command along with the wildcard mask have to match exactly as the interface for which you are enabling OSPF is configured for? Would the use of the network statement as follows work as well: network xxx.xxx.xxx.14 0.0.0.3 area 1 or does it have to be netowrk "aligned"? When the hello packets are exchanged, the mask is also carried, so where does the router get the mask for the interface it is advertising? Is it derived from the network statement? Can someone explain what the error that I was seeing means? Thanks. Murali Das wrote: CiscoNewbie wrote: Hi all. my cisco router keeps reporting this error when trying to bring up an adjacency accross a P2P link. OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: src not on the same network I am presuming that the issue here is the subnet mask that I have specified the network statement as under OSPF. My serial interface (frame-relay subinterface) has a /30 mask. How should my network statement be configured if the IP address of the interface is xxx.xxx.xxx.14? I have tried the following: network xxx.xxx.xxx.0 0.0.0.255 area 1 as well as: network xxx.xxx.xxx.12 0.0.0.3 area 1 try this network xx.xx.xx.14 0.0.0.0 area 1 Neither one seemed to work. I still got the same error. The other side is also on the same subnet and it has an IP address of xxx.xxx.xxx.13/30 configured as a P2P as well. If the network statement is not the issue, please advise. Thanks. - Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! - Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66256&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Adjacency Question [7:66206]
CiscoNewbie wrote: Hi all. my cisco router keeps reporting this error when trying to bring up an adjacency accross a P2P link. OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: src not on the same network I am presuming that the issue here is the subnet mask that I have specified the network statement as under OSPF. My serial interface (frame-relay subinterface) has a /30 mask. How should my network statement be configured if the IP address of the interface is xxx.xxx.xxx.14? I have tried the following: network xxx.xxx.xxx.0 0.0.0.255 area 1 as well as: network xxx.xxx.xxx.12 0.0.0.3 area 1 try this network xx.xx.xx.14 0.0.0.0 area 1 Neither one seemed to work. I still got the same error. The other side is also on the same subnet and it has an IP address of xxx.xxx.xxx.13/30 configured as a P2P as well. If the network statement is not the issue, please advise. Thanks. - Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66248&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Adjacency Question [7:66206]
network xxx.xxx.xxx.14 0.0.0.3 area 1 ""CiscoNewbie"" wrote in message news:[EMAIL PROTECTED] > Hi all. my cisco router keeps reporting this error when trying to bring up > an adjacency accross a P2P link. > > OSPF: Rcv pkt from xxx.xxx.xxx.13, Serial0/0.1, area 0.0.0.1: src not on the > same network > > I am presuming that the issue here is the subnet mask that I have specified > the network statement as under OSPF. My serial interface (frame-relay > subinterface) has a /30 mask. How should my network statement be configured > if the IP address of the interface is xxx.xxx.xxx.14? I have tried the > following: > > network xxx.xxx.xxx.0 0.0.0.255 area 1 > > as well as: > > network xxx.xxx.xxx.12 0.0.0.3 area 1 > > Neither one seemed to work. I still got the same error. > > The other side is also on the same subnet and it has an IP address of > xxx.xxx.xxx.13/30 configured as a P2P as well. If the network statement is > not the issue, please advise. > > Thanks. > > > > - > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66228&t=66206 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF Hellos on ATM interface Disappear [7:66096]
I was running 12.1.3 EA, I think it was on one of the routers. When I switched it to 12.2.7 it seems to have come around. Has been holding routes for several hours now. Make sense? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66214&t=66096 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Hellos on ATM interface Disappear [7:66096]
This sounds like a problem that was discussed here (or on the groupstudy ccielab list) in the last few days. The problem then was EIGRP over ATM. Now it's OSPF over ATM. Try specifying your OSPF neighbors manually, so unicasting occurs. There may be a better solution, but try this until someone chimes in with something better. Tom Larus ""Nelson Herron"" wrote in message news:[EMAIL PROTECTED] > Troubles with OSPF routing over an ATM interface. After about 15 - 20 > minutes the hellos from one of my routers disappear (w/ attendant chaos). > Tried swapping boards, same problem. I have three routers (7000 - 11.2.15 & > 2 RSP7000s - 12.2.x) running classical IP through a Madge Collage 750 ATM > switch. The 7000 and the hub RSP7000 work fine. The second RSP7000 works > fine immediately after a "shut/no shut" on the interface, but after 15 > minutes I no longer see hello messages from it at the hub router. I still > see hello messages from the hub RSP7000 router at the affected one. It's > hard to tell for sure but it appears that the svc is reset at about the same > time - may be incidental. ILMI works fine. This is a pretty plain > configuration - I'm using "ospf priority" and "ospf broadcast" on the atm > sub-if. Another thing that puzzles me is the fact that the highest "ospf > priority" does not seem to set the DR. Rather it still seems to follow the > highest loopback address. Reading books like Doyle led me to believe it > would follow the highest priority. Seems pretty brutal to have to reboot an > entire network to get the ATM DR in the correct location. Thoughts??? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66100&t=66096 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Virtual link authentication - observations [7:65628]
a comment or to in line ( like the states ) ""Nigel Taylor"" wrote in message news:[EMAIL PROTECTED] > Chuck, > Let's see if I can make any sense in my reply to your comments. > When I think of a "virtual-link" as it relates to opsf, I think of it in > terms of being a tunnel. Also, short of being able to use a virtual-link, a > tunnel is what's recommended to maintain connectivity for any non-area0 > connected areas. Nigel, you're making me grind my teeth. A virtual link is NOT a tunnel. Who started the "tunnel" idea? Even Moy backed away from the use of the term "tunnel" in his second book. :-> > > Here's a excerpt from rfc 2328 which describes a virtual link. > > 12.4.1.3. Describing virtual links > > For virtual links, a link description is added to the > router-LSA only when the virtual neighbor is fully > adjacent. In this case, add a Type 4 link (virtual link) > with Link ID set to the Router ID of the virtual > neighbor, Link Data set to the IP interface address > associated with the virtual link and cost set to the > cost calculated for the virtual link during the routing > table calculation (see Section 15). > > > And then this excerpt from section 15.. > > The virtual link is treated as if it were an unnumbered point-to-point > network belonging to the backbone and joining the two area border routers. > An attempt is made to establish an adjacency over the virtual link. When > this adjacency is established, the virtual link will be included in backbone > router-LSAs, and OSPF packets pertaining to the backbone area will flow over > the adjacency. Such an adjacency has been referred to in this document as a > "virtual adjacency". It occurs to me that most of us think / are told that a virtual link is in area 0. I can't remember all the stuff I've read about this over the years. This recent observation tells me that the virtual link is an odd animal that is really part of the transit area. It doesn't quite follow the other OSPF rules. I know what the VL is supposed to do. It links the non adjacent area directly to area 0. It would "seem" reasonable that the link would have to be area 0. Judging from the workings of authentication, it would appear that on Cisco routers that the link is treated as part of the transit area. > > So as you noted it would be safe to say that a virtual-link is governed by > the termination points of it's unnumbered p-2-p links. So where your > transit-area uses MD5 authentication so must your virtual-link. > > Alex Zinin's Cisco IP Routing [pg. 489] clearly states that the virtual-link > always belongs to the backbone. In saying this, the characteristics of the > transit area to identify the peering ABR and then receive > packets(encrypted/decrypted) would be the only things that associates the > virtual-link to the transit area. It wouldn't be the first time that someone was incorrect about the way things really work versus the way it appears they work. Recall my statement above. The virtual link is NOT a tunnel. It operates solely based on the presense of the V-bit in the OSPF header. I imagine that the router code is such that it passes packets based on the presence of the V-bit. The router code has to base it's operation on SOMETHING in the OSPF header. So when it comes to authentication, Cisco router code determines the need for authentication based on the various values of the headers involved. After all, there's nothing in the RFC that requires that authentication work in a certain manner. Someone asked me off line about how the Lab proctors might grade this kind of task. The answer of course is "who knows?" All you're given is a percentage of the general section. The key is understanding how to make it work without spending too much time "trying things" > > HTH > > Nigel :-) > > > > > - Original Message - > From: "The Long and Winding Road" > To: > Sent: Tuesday, March 18, 2003 12:04 AM > Subject: OSPF Virtual link authentication - observations [7:65628] > > > > Not sure I have this all sorted out correctly. Perhaps those with a bit > more > > experience might add their wisdom, not to mention their corrections. > > > > The ospf virtual link being what it is, it follows rules similar to any > > other interface. > > > > It does appear, though, that in terms of structure, it looks something > like > > this: > > > > ( commands under the ospf process ) > > > > area X authentication > > area X virtual-link y.y.y.y authentication > > area X virtual-link y.y.y.y authentication-key WORD > > > > where X is the non zero area number over which the virtual link transits. > > > > In other words, for purposes of structure, the virtual link is not really > > part of area 0. It is a point-to-point link that is part of the non zero > > transit area. > > > > Am I understanding this correctly? I have a setup working,
Re: OSPF Virtual link authentication - observation [7:65628]
To add to this: Here is another one that made me pull my hair out: Maybe you can help shed some light on this one for me: MD5 auth. in area 0 Specified #area 0 auth message-digest in the transit area (area 1) Only specified#area 1 virtual-link x.x.x.x Ditto config. on the other area 1 router: This works...but why?? I always thought that you had to specify the md5 authentication in the virtual-link cmd. but it appears not so. Here is what did catch my eye: When specifying the md5 key, the VL does use key 1 Ex. Message digest authentication enabled Youngest key id is 1 but when NOT specifying it, it uses the default-key 0 and this still works even though area 0 is using key 1 !!! Ex. Message digest authentication enabled No key configured, using default key id 0 But MOST IMPORTANT: will any points be deducted by the proctor god in the Lab if one does not specify the md5 keyword in the VL cmd?? >From: "The Long and Winding Road" >Reply-To: "The Long and Winding Road" >To: [EMAIL PROTECTED] >Subject: OSPF Virtual link authentication - observations [7:65628] >Date: Tue, 18 Mar 2003 05:04:47 GMT > >Not sure I have this all sorted out correctly. Perhaps those with a bit >more >experience might add their wisdom, not to mention their corrections. > >The ospf virtual link being what it is, it follows rules similar to any >other interface. > >It does appear, though, that in terms of structure, it looks something like >this: > >( commands under the ospf process ) > >area X authentication >area X virtual-link y.y.y.y authentication >area X virtual-link y.y.y.y authentication-key WORD > >where X is the non zero area number over which the virtual link transits. > >In other words, for purposes of structure, the virtual link is not really >part of area 0. It is a point-to-point link that is part of the non zero >transit area. > >Am I understanding this correctly? I have a setup working, where the area 0 >authentication is simple and the transit area authentication is MD5, and no >adjacency is formed across the virtual link with simple authentication, but >comes up just fine with MD5. > >Any comments are appreciated. > >-- >TANSTAAFL >"there ain't no such thing as a free lunch" _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65660&t=65628 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
