Hello, To be able to have a clear view of the entire OSPF topology, LSA's need to be broken down. And type 4 LSA's not only tell you where the ASBR is, but type 4 LSA's indicate that this particular OSPF router is redistributing Type 5 LSA's into the OSPF domain. The type 3 LSA doesn't tell you that this router is an ASBR, but just tells you how to get to the router (not the ASBR, persay). The type 4 LSA signal's to routers that it is redistributing routes from another routing protocol into OSPF, where type 3 LSA's do not do that. > From: [email protected] > Subject: CCIE_RS Digest, Vol 79, Issue 25 > To: [email protected] > Date: Wed, 15 Aug 2012 07:42:01 -0400 > > Send CCIE_RS mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://onlinestudylist.com/mailman/listinfo/ccie_rs > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CCIE_RS digest..." > > > Today's Topics: > > 1. Re: OSPF LSA Type 3 and Type 4 Confusion ? ([email protected]) > 2. Re: OSPF LSA Type 3 and Type 4 Confusion ? (Keller Giacomarro) > 3. Route Target and VPN Label (Karan Sagar) > 4. Tunnel interfaces (robert shepherd) > 5. Re: Route Target and VPN Label (Keller Giacomarro) > 6. Re: Tunnel interfaces (Keller Giacomarro) > 7. Re: Tunnel interfaces (leon brockway) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Aug 2012 19:26:14 -0700 > From: <[email protected]> > To: "MANISH" <[email protected]>, [email protected] > Subject: Re: [OSL | CCIE_RS] OSPF LSA Type 3 and Type 4 Confusion ? > Message-ID: > > <20120814192614.bcf41bfd7d67e476f5ae5016554e5dd3.11d90c4edb....@email18.secureserver.net> > > Content-Type: text/plain; charset="utf-8" > > After some thought, I labbed this up and now have the same doubts > again... Here's a type 5 LSA: > > Berta#sh ip ospf database external 1.1.1.0 > > OSPF Router with ID (192.168.24.4) (Process ID 1) > > Type-5 AS External Link States > > Routing Bit Set on this LSA > LS age: 20 > Options: (No TOS-capability, DC) > LS Type: AS External Link > Link State ID: 1.1.1.0 (External Network Number ) > Advertising Router: 192.168.13.1 > LS Seq Number: 80000001 > Checksum: 0x5A52 > Length: 36 > Network Mask: /24 > Metric Type: 2 (Larger than any link state path) > TOS: 0 > Metric: 20 > >>>>>>>>Forward Address: 192.168.13.3 <<<<<<<<<<<<<<<<<<<<<<<<<< > External Route Tag: 0 > > Notice the forward address above, 192.168.13.3. On the same router: > > Berta#sh ip ospf database summary 192.168.13.0 > > OSPF Router with ID (192.168.24.4) (Process ID 1) > > Summary Net Link States (Area 2) > > Routing Bit Set on this LSA > LS age: 1660 > Options: (No TOS-capability, DC, Upward) > LS Type: Summary Links(Network) > Link State ID: 192.168.13.0 (summary Network Number) > Advertising Router: 192.168.24.2 > LS Seq Number: 80000001 > Checksum: 0x9BA5 > Length: 28 > Network Mask: /24 > TOS: 0 Metric: 2 > > So this Type 3 LSA has all the reach-ability information needed to > forward this packet to the ASBR without a Type4 LSA. Speaking of the > Type 4 LSA, here it is: > > Berta#sh ip ospf database asbr-summary > > OSPF Router with ID (192.168.24.4) (Process ID 1) > > Summary ASB Link States (Area 2) > > Routing Bit Set on this LSA > LS age: 1902 > Options: (No TOS-capability, DC, Upward) > LS Type: Summary Links(AS Boundary Router) > Link State ID: 192.168.13.1 (AS Boundary Router address) > Advertising Router: 192.168.24.2 > LS Seq Number: 80000001 > Checksum: 0x79C6 > Length: 28 > Network Mask: /0 > TOS: 0 Metric: 1 > > This type 4 LSA doesn't have any information that we don't already have > with the type 3. So now I'm back to where Manish began... When/why do we > need the type 4? > > Thanks! > > Doug > > > -------- Original Message -------- > Subject: [OSL | CCIE_RS] OSPF LSA Type 3 and Type 4 Confusion ? > From: MANISH <[email protected]> > Date: Tue, August 14, 2012 9:40 am > To: [email protected] > > Hi All, > > can some one please explain me the difference in LSA Type 3 and LSA Type > 4 > > as per my understanding > > LSA Type 3 is used for inter area routes ........meaning all the Type > 1/2 > inside an area when crosses in to other area will be advertised using > type > 3 > > LSA Type 4 is the IP address of ASBR. > > my confusion is if we already know about ip add of ASBR through Type 3 > since every thing gets flooded in to other areas why do we need type 4 > explicitly to define ip add of ASBR. > > > I read many blogs and other sources but still could not undersdtand. > > take a look at this blog explanation, will fa0/0 of R6 not be known to > other areas using type 3 lsa ? > > http://blog.ipexpert.com/2009/11/04/ospf-type-4-lsa-the-forward-address-part-1/ > > > > Thank You. > Manish > _______________________________________________ > For more information regarding industry leading CCIE Lab training, > please visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > > ------------------------------ > > Message: 2 > Date: Tue, 14 Aug 2012 21:02:19 -0600 > From: Keller Giacomarro <[email protected]> > To: [email protected] > Cc: [email protected] > Subject: Re: [OSL | CCIE_RS] OSPF LSA Type 3 and Type 4 Confusion ? > Message-ID: > <CACSX_jUkisFyEyPDnHLp=6dp7cy3jc4o1zng7uxh3os7tw4...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Set the router ID of the ASBR to 127.0.0.1. The router ID of the ASBR > does not have to be routable. Or is there something else in your > question I'm not understanding? > > Keller Giacomarro > [email protected] > > > On Tue, Aug 14, 2012 at 8:26 PM, <[email protected]> wrote: > > After some thought, I labbed this up and now have the same doubts > > again... Here's a type 5 LSA: > > > > Berta#sh ip ospf database external 1.1.1.0 > > > > OSPF Router with ID (192.168.24.4) (Process ID 1) > > > > Type-5 AS External Link States > > > > Routing Bit Set on this LSA > > LS age: 20 > > Options: (No TOS-capability, DC) > > LS Type: AS External Link > > Link State ID: 1.1.1.0 (External Network Number ) > > Advertising Router: 192.168.13.1 > > LS Seq Number: 80000001 > > Checksum: 0x5A52 > > Length: 36 > > Network Mask: /24 > > Metric Type: 2 (Larger than any link state path) > > TOS: 0 > > Metric: 20 > >>>>>>>>>Forward Address: 192.168.13.3 <<<<<<<<<<<<<<<<<<<<<<<<<< > > External Route Tag: 0 > > > > Notice the forward address above, 192.168.13.3. On the same router: > > > > Berta#sh ip ospf database summary 192.168.13.0 > > > > OSPF Router with ID (192.168.24.4) (Process ID 1) > > > > Summary Net Link States (Area 2) > > > > Routing Bit Set on this LSA > > LS age: 1660 > > Options: (No TOS-capability, DC, Upward) > > LS Type: Summary Links(Network) > > Link State ID: 192.168.13.0 (summary Network Number) > > Advertising Router: 192.168.24.2 > > LS Seq Number: 80000001 > > Checksum: 0x9BA5 > > Length: 28 > > Network Mask: /24 > > TOS: 0 Metric: 2 > > > > So this Type 3 LSA has all the reach-ability information needed to > > forward this packet to the ASBR without a Type4 LSA. Speaking of the > > Type 4 LSA, here it is: > > > > Berta#sh ip ospf database asbr-summary > > > > OSPF Router with ID (192.168.24.4) (Process ID 1) > > > > Summary ASB Link States (Area 2) > > > > Routing Bit Set on this LSA > > LS age: 1902 > > Options: (No TOS-capability, DC, Upward) > > LS Type: Summary Links(AS Boundary Router) > > Link State ID: 192.168.13.1 (AS Boundary Router address) > > Advertising Router: 192.168.24.2 > > LS Seq Number: 80000001 > > Checksum: 0x79C6 > > Length: 28 > > Network Mask: /0 > > TOS: 0 Metric: 1 > > > > This type 4 LSA doesn't have any information that we don't already have > > with the type 3. So now I'm back to where Manish began... When/why do we > > need the type 4? > > > > Thanks! > > > > Doug > > > > > > -------- Original Message -------- > > Subject: [OSL | CCIE_RS] OSPF LSA Type 3 and Type 4 Confusion ? > > From: MANISH <[email protected]> > > Date: Tue, August 14, 2012 9:40 am > > To: [email protected] > > > > Hi All, > > > > can some one please explain me the difference in LSA Type 3 and LSA Type > > 4 > > > > as per my understanding > > > > LSA Type 3 is used for inter area routes ........meaning all the Type > > 1/2 > > inside an area when crosses in to other area will be advertised using > > type > > 3 > > > > LSA Type 4 is the IP address of ASBR. > > > > my confusion is if we already know about ip add of ASBR through Type 3 > > since every thing gets flooded in to other areas why do we need type 4 > > explicitly to define ip add of ASBR. > > > > > > I read many blogs and other sources but still could not undersdtand. > > > > take a look at this blog explanation, will fa0/0 of R6 not be known to > > other areas using type 3 lsa ? > > > > http://blog.ipexpert.com/2009/11/04/ospf-type-4-lsa-the-forward-address-part-1/ > > > > > > > > Thank You. > > Manish > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, > > please visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > > ------------------------------ > > Message: 3 > Date: Wed, 15 Aug 2012 09:39:05 +0530 > From: Karan Sagar <[email protected]> > To: CCIE ONLINE STUDY LIST <[email protected]> > Subject: [OSL | CCIE_RS] Route Target and VPN Label > Message-ID: > <cano7my78wjvpw3nurkswmmg8d3wytceqvr_xfa+fzdm3wfs...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Everyone > > I'm finding it difficult to understand the role of Route target and VPN > labels. > > Between the PE Routers there is a MP-BGP Session . The MP-BGP protocal > carries the Route Distinguisher to uniquely identify routes in the > MBGP route table > and Route Targets Extended Communtiy are used to determine which > interface to forward packets to based on the import and export > targets. > When there is a neighbor relationship between the CE and PE, Vpn > labels are also sent across the PE. The PE router forwards the packet > out an interface based on the VPN label. > > Is the RT required when the VPN label is used to forward packets ? > > Thanks, > Karan > > > ------------------------------ > > Message: 4 > Date: Tue, 14 Aug 2012 21:36:19 -0700 (PDT) > From: robert shepherd <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [OSL | CCIE_RS] Tunnel interfaces > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=us-ascii > > I know that we cannot learn the endpoint of a tunnel through the tunnel. > Let say we have R1 and R2 on different ends of the network running > eigrp. The rest of the network is running ospf. By default we will have > recursive routing happening due to the default AD's. In a case like this > would it be ok (if no restrictions are given) to always munipulate the AD > of eigrp to a distance of 255? Doing this would make sure that the end > point of the tunnel will never learn about itself through the tunnel. Is my > logic here correct? > > ------------------------------ > > Message: 5 > Date: Tue, 14 Aug 2012 22:55:39 -0600 > From: Keller Giacomarro <[email protected]> > To: Karan Sagar <[email protected]> > Cc: CCIE ONLINE STUDY LIST <[email protected]> > Subject: Re: [OSL | CCIE_RS] Route Target and VPN Label > Message-ID: > <cacsx_jwpic_4+azwfdmvqrx6wxx3m-6jugayv-nx0rkqbe1...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Without the RT, how would MP-BGP know which VRF to assign a VPN label to? > > Keller Giacomarro > [email protected] > > > On Tue, Aug 14, 2012 at 10:09 PM, Karan Sagar <[email protected]> wrote: > > Hi Everyone > > > > I'm finding it difficult to understand the role of Route target and VPN > > labels. > > > > Between the PE Routers there is a MP-BGP Session . The MP-BGP protocal > > carries the Route Distinguisher to uniquely identify routes in the > > MBGP route table > > and Route Targets Extended Communtiy are used to determine which > > interface to forward packets to based on the import and export > > targets. > > When there is a neighbor relationship between the CE and PE, Vpn > > labels are also sent across the PE. The PE router forwards the packet > > out an interface based on the VPN label. > > > > Is the RT required when the VPN label is used to forward packets ? > > > > Thanks, > > Karan > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > > ------------------------------ > > Message: 6 > Date: Tue, 14 Aug 2012 23:26:49 -0600 > From: Keller Giacomarro <[email protected]> > To: robert shepherd <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [OSL | CCIE_RS] Tunnel interfaces > Message-ID: > <cacsx_juwn7jsthlcbxfwmi9x6keyjtnq6qnri1vyelgotb+...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > So, you're almost in an ISP/customer situation here. The ISP routers > are running OSPF, and your customer routers are running EIGRP with > their respective parts of the network. > > Based on your question, it sounds like you would be doing EIGRP across > the tunnel, correct? And you also have other EIGRP routes behind both > R1 and R2 that I assume you want to share between R1 and R2. > > However, you shouldn't have a recursive routing problem in this > scenario if you don't activate EIGRP on the physical interface being > used for the tunnel. Recursive routing only applies to the tunnel > endpoints. Unless there's a design requirement that says otherwise, > you could advertise the physical interface only in OSPF, and the > tunnel interface in EIGRP (and OSPF too, if desired). You would just > need to be sure that the physical interface doesn't somehow end up in > EIGRP (redistribution, etc). > > If there IS a design requirement to put the physical interface into > EIGRP, you'll need to do some sort of route filtering to prevent R2 > from learning R1's physical interface route via the tunnel. Distance > is one option -- you could universally make EIGRP's AD higher than > OSPF's on both routers. Your suggestion of 255, however, would make > EIGRP unreachable and would cause no EIGRP routes to be entered into > either routing table! You could also do an AD change on a specific > set of prefixes, and could set the physical interface prefixes to have > AD 255 or something higher than OSPF. > > Personally, I'd just put a distribute-list filter on both routers > preventing them from learning the physical interfaces via EIGRP. > > Disclaimer: I'm still studying, so some of the above may be partially > or fully wrong! Please consult your friendly neighborhood CCIE before > taking anything that I say as fact. > > Keller Giacomarro > [email protected] > > > On Tue, Aug 14, 2012 at 10:36 PM, robert shepherd > <[email protected]> wrote: > > I know that we cannot learn the endpoint of a tunnel through the tunnel. > > Let say we have R1 and R2 on different ends of the network running > > eigrp. The rest of the network is running ospf. By default we will have > > recursive routing happening due to the default AD's. In a case like this > > would it be ok (if no restrictions are given) to always munipulate the AD > > of eigrp to a distance of 255? Doing this would make sure that the end > > point of the tunnel will never learn about itself through the tunnel. Is my > > logic here correct? > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > > ------------------------------ > > Message: 7 > Date: Wed, 15 Aug 2012 04:41:59 -0700 (PDT) > From: leon brockway <[email protected]> > To: Keller Giacomarro <[email protected]>, robert shepherd > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [OSL | CCIE_RS] Tunnel interfaces > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=iso-8859-1 > > Wouldn't an EIGRP distribution-list work here.? > I have a similar configuration?and I just use a distribution-list to block > the tunnel iterface subnet from being advertised back out the tunnel > interface. > > > ________________________________ > From: Keller Giacomarro <[email protected]> > To: robert shepherd <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Wednesday, August 15, 2012 1:26 AM > Subject: Re: [OSL | CCIE_RS] Tunnel interfaces > > So, you're almost in an ISP/customer situation here.? The ISP routers > are running OSPF, and your customer routers are running EIGRP with > their respective parts of the network. > > Based on your question, it sounds like you would be doing EIGRP across > the tunnel, correct?? And you also have other EIGRP routes behind both > R1 and R2 that I assume you want to share between R1 and R2. > > However, you shouldn't have a recursive routing problem in this > scenario if you don't activate EIGRP on the physical interface being > used for the tunnel.? Recursive routing only applies to the tunnel > endpoints.? Unless there's a design requirement that says otherwise, > you could advertise the physical interface only in OSPF, and the > tunnel interface in EIGRP (and OSPF too, if desired).? You would just > need to be sure that the physical interface doesn't somehow end up in > EIGRP (redistribution, etc). > > If there IS a design requirement to put the physical interface into > EIGRP, you'll need to do some sort of route filtering to prevent R2 > from learning R1's physical interface route via the tunnel.? Distance > is one option -- you could universally make EIGRP's AD higher than > OSPF's on both routers.? Your suggestion of 255, however, would make > EIGRP unreachable and would cause no EIGRP routes to be entered into > either routing table!? You could also do an AD change on a specific > set of prefixes, and could set the physical interface prefixes to have > AD 255 or something higher than OSPF. > > Personally, I'd just put a distribute-list filter on both routers > preventing them from learning the physical interfaces via EIGRP. > > Disclaimer: I'm still studying, so some of the above may be partially > or fully wrong! Please consult your friendly neighborhood CCIE before > taking anything that I say as fact. > > Keller Giacomarro > [email protected] > > > On Tue, Aug 14, 2012 at 10:36 PM, robert shepherd > <[email protected]> wrote: > > I know that we cannot learn the endpoint of a tunnel through the tunnel. > > Let say we have R1 and R2 on different ends of the network running > > eigrp. The rest of the network is running ospf. By default we will have > > recursive routing happening due to the default AD's. In a case like this > > would it be ok (if no restrictions are given) to always munipulate the AD > > of eigrp to a distance of 255? Doing this would make sure that the end > > point of the tunnel will never learn about itself through the tunnel. Is my > > logic here correct? > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit http://www.ipexpert.com/ > > > > Are you a CCNP or CCIE and looking for a job? Check out > > http://www.platinumplacement.com/ > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > > End of CCIE_RS Digest, Vol 79, Issue 25 > *************************************** _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
