fredrik's thread

fredrikjjfredrikjj Member Posts: 879
I guess I should upgrade from the CCNP forum since I've started on Doyle's books. Inspiratonal intro, huh?
«134

Comments

  • fredrikjjfredrikjj Member Posts: 879
    I'm looking forward to some hardcore RIP talk in the coming weeks.
  • reaper81reaper81 Member Posts: 631
    Good luck!
    Daniel Dib
    CCIE #37149
  • gorebrushgorebrush Member Posts: 2,743 ■■■■■■■□□□
    RIP still has some "weird" things you can pull off with it.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    gorebrush wrote: »
    RIP still has some "weird" things, you can pull off with it.

    I prefer to look at hot chicks for that!
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • gorebrushgorebrush Member Posts: 2,743 ■■■■■■■□□□
  • fredrikjjfredrikjj Member Posts: 879
    Guys, name my blog. I have a feeling that "just another boring ccie blog" is taken though...
  • ScalesScales Member Posts: 95 ■■□□□□□□□□
    fredrikjj wrote: »
    Guys, name my blog. I have a feeling that "just another boring ccie blog" is taken though...

    fred-IE
  • fredrikjjfredrikjj Member Posts: 879
    I've covered the first 200 page of Routing TCP/IP Vol 1, and it does in fact live up to the hype. It's hard to pinpoint exactly what makes it such an enjoyable read, but it probably has something to do with it being at just the right level of difficulty for some who has completed the CCNP. Most of the concepts have been familiar so far, but I've picked up a few things:

    1) More details on static routing. How/when/why they are installed in the routing table.
    2) Sequence numbers, and how their are used in link state protocols.
    3) How to connect discontiguous major networks with RIP version 1 using secondary addresses. I don't expect this to ever be relevant knowledge, but I found it very neat.
    Scales wrote: »
    fred-IE

    That's clever :)
  • fredrikjjfredrikjj Member Posts: 879
    Why you shouldn't roll over OSPF keys in a live environment

    A paranoid manager comes to you and asks you to change the OSPF password. The manager wants it done yesterday and has heard that you can do this without affecting the operation of the network. Here's is why you probably don't want to do that unless absolutely necessary.

    OSPF's MD5 Authentication operates using numbered keys, where each key has a corresponding password. Our baseline for this experiment is this configuration:

    Router 1
    interface GigabitEthernet1/0
     ip address 192.168.1.1 255.255.255.0
     ip ospf message-digest-key 1 md5 password1 
    
    Router 2
    interface GigabitEthernet1/0
     ip address 192.168.1.2 255.255.255.0
     ip ospf message-digest-key 1 md5 password1
    

    #debug ip ospf adj gives us:
    OSPF-1 ADJ   Gi1/0: Send with youngest Key 1
    

    The idea behind rolling keys over is that as you enter a new key (OSPF calls this a younger key - it doesn't have to be a higher key number) on one router, that router starts sending multiple copies of OSPF packets going out that interface. Once a new key number has been agreed upon by both routers, only packets with this new key is sent. It sounds easy enough, but there is one big caveat that we need to be aware of.

    You enter a new key on router 1:
    R1
    interface GigabitEthernet1/0
     ip address 192.168.1.1 255.255.255.0
     ip ospf message-digest-key 1 md5 password1
     ip ospf message-digest-key 2 md5 password2
    

    OSPF starts sending copies of packets with both key 1 and key 2.
    OSPF-1 ADJ   Gi1/0: Send with key 1
    OSPF-1 ADJ   Gi1/0: Send with key 2
    

    So far so good.

    You go to the second router and enter the same key:
    R2
    interface GigabitEthernet1/0
     ip address 192.168.1.2 255.255.255.0
     ip ospf message-digest-key 1 md5 password1
     ip ospf message-digest-key 2 md5 password3
    

    We now get the following debug output from R1:
    OSPF-1 ADJ   Gi1/0: Send with key 1
    OSPF-1 ADJ   Gi1/0: Send with key 2
    OSPF-1 ADJ   Gi1/0: Rcv pkt from 192.168.1.2 : Mismatched Authentication Key - Message Digest Key 2
    OSPF-1 ADJ   Gi1/0: Send with youngest Key 2
    OSPF-1 ADJ   Gi1/0: Rcv pkt from 192.168.1.2 : Mismatched Authentication Key - Message Digest Key 2
    ....
    OSPF-1 ADJ   Gi1/0: 2.2.2.2 address 192.168.1.2 is dead, state DOWN
    

    Note how it stops sending key 1 after hearing about key 2 from router 2.

    Despite the fact that we had a working key (key 1) and didn't remove it, the typo we made on router 2 still brought down the neighbor relationship. Basically, OSPF does not verify that the new key is actually correct before it stop transmitting the old key(s).
  • fredrikjjfredrikjj Member Posts: 879
    OSPF Transit Capability In A Nutshell

    I've started working on the OSPF section in INE Volume 1, and the first section that I got stuck on was 6.13 that deals with the OSPF Transit Capability. It's not something that I've encountered in Doyle or any of the CCNP books.

    I've read this post Understanding OSPF Transit Capability and this is basically a short summary, leaving out all the details and just focusing on the concepts. We have this topology:



    Normal OSPF behavior is that inter-area data must flow through the backbone and cannot take shortcuts through other areas:



    In this topology, that leads to an unfavorable traffic pattern from R4 to R1 because traffic must use the slow links R4-R5 and R5-R2.

    In CCNP you learn that virtual links are used to a) fix a discontiguous backbone and b) attach areas to the backbone that do not have a physical connection to it. A third use is to create shortcuts through non-backbone areas. For example, if we create a virtual link between R4 and R3, R3 has an interface in area 0, and R4-R3-R2 becomes a valid pattern.

    The Transit Capability sounds fancy, but it's just the default behavior of OSPF. Essentially it means that data does not have to follow the same path as the virtual links across the transit area. For example, if we establish virtual links between R4-R5 and R5-R3, traffic can still take the shorter R4-R3 path:




    However, if we disable the transit capability with the command router(config-router)#no capability transit on R4 and R5, traffic must follow the virtual links:

  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    ... and you understand this? Cripes, maybe I don't belong in this section of the forums.
    Latest Completed: CISSP

    Current goal: Dunno
  • fredrikjjfredrikjj Member Posts: 879
    I don't know what to say to that, but there's obviously a reason why my post is a few pictures and 200 words and Lapukhov's original is a 10 page essay. There are different levels of understanding, and acquiring conceptual understanding is much easier than the detailed fundamentals that you'll find in his blog post.

    You could probably argue that it's good enough to know what I now know about the transit capability, but it seems equally likely that someone with very deep OSPF knowledge could construct a scenario where I will make a mistake because don't have the real fundamentals.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    The basic idea is learn the type 3 flooding rules, i.e. you cant accept a type 3 lsa that comes from non-area 0. But when the transit capability is enabled you can. This becomes tricky when you can start preferring type 3 lsa's over type 1. icon_smile.gif
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • fredrikjjfredrikjj Member Posts: 879
    EdTheLad wrote: »
    The basic idea is learn the type 3 flooding rules, i.e. you cant accept a type 3 lsa that comes from non-area 0. But when the transit capability is enabled you can. This becomes tricky when you can start preferring type 3 lsa's over type 1. icon_smile.gif

    Strictly speaking, the transit capability is the ability for OSPF to use different next hops than the virtual link. This is on by default. You need the virtual link to accept the type 3 across the non-backbone, and the transit capability is an additional feature to enhance the VL.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    I've played around allot with VLs and transit capability, can't remember all the details without reviewing it, no time. The different next-hops what you mention are the type 3 lsa's accepted via non area 0. Without transit capability enabled, the abr doesn't accept the type 3 lsa's from the transit area and hence the only path is via the type 3 received over the VL.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • fredrikjjfredrikjj Member Posts: 879
    You probably mean type 3 received over the VL?
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    Yup, i'll edit it. icon_smile.gif
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    Actually, once I spent some time going through it (slowly), I mostly get it. Some of the explanations escape me - stuff like "it relies on the fact that the inter-area routes flooded into the transit area are “congruent” to the virtual-link", and my skin itches at the whole "here's a terribly inefficient design. Make it work efficiently without actually fixing it" of the example from the link (that I've labbed to tinker with). I'll stop with the hijacking of your thread though :)
    Latest Completed: CISSP

    Current goal: Dunno
  • fredrikjjfredrikjj Member Posts: 879
    EdTheLad wrote: »
    I've played around allot with VLs and transit capability, can't remember all the details without reviewing it, no time. The different next-hops what you mention are the type 3 lsa's accepted via non area 0. Without transit capability enabled, the abr doesn't accept the type 3 lsa's from the transit area and hence the only path is via the type 3 received over the VL.

    The ABR will still accept and install the LSAs even without the transit capability (TC) as long as you have triggered their flooding with a virtual link. When you enable TC, the router is capable of changing the nexthop of the route to align with a shortcut advertised by another router than the virtual link neighbor. It's unclear to me how this happens since the LSDB looks largely the same even if you disable TC.

    Maybe we're just discussing semantics here, I'm not sure, but to me the VL seems like the primary variable, with the TC adjusting the forwarding behaviour slightly if a shorter path exists through the transit area than over the virtual link.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    fredrikjj wrote: »
    The ABR will still accept and install the LSAs even without the transit capability (TC) as long as you have triggered their flooding with a virtual link. When you enable TC, the router is capable of changing the nexthop of the route to align with a shortcut advertised by another router than the virtual link neighbor.

    Those LSAs will be accepted and installed but not used i.e. the "routing bit" isn't set. This is normal for type 3 lsa's arriving via non Area 0. But when transit capability is enabled the "routing bit" will be set.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • fredrikjjfredrikjj Member Posts: 879
    Yes, that would make sense, right. But the routing bit is set on the summary in area 0 learned over the virtual link, TC or no TC. That is, if another summary advertises a shortcut, it's still not the one installed in the RIB, if the routing bit is to be believed. If that's even a meaningful distinction to make.

    PS.
    Of course, there's also the possibility that I've broken dynamips.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    Yes, it should be. So then you have type 3 lsa's learned via the VL and via the transit area, whichever is lowest metric wins.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • xnxxnx Do they matter? UKMember Posts: 464 ■■■□□□□□□□
    I look forward to following this, i'm currently studying QoS(IntServ and DiffServ) and BGP, it seems reading RFC's can be useful if you want to find the actual definition for a term rather than a paraphased one!
    Getting There ...

    Lab Equipment: Using Cisco CSRs and 4 Switches currently
  • reaper81reaper81 Member Posts: 631
    Just a note on the routing bit. It's just an indicator that it's a valid LSA, it doesn't mean that the LSA will get installed into the RIB. It's a quick check as opposed to going through each LSA each time if it is valid or not.
    Daniel Dib
    CCIE #37149
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    reaper81 wrote: »
    Just a note on the routing bit. It's just an indicator that it's a valid LSA, it doesn't mean that the LSA will get installed into the RIB. It's a quick check as opposed to going through each LSA each time if it is valid or not.

    Yes normally, but when it comes to transit capability, it's not always the case. I'll show an example in my next post.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    My topology

    R1 <---> R2 <
    > R3,R4

    R1
    hostname R1
    !
    interface Ethernet0/0
     ip address 10.0.12.1 255.255.255.0
     ip ospf network point-to-point
    !
    router ospf 1
     router-id 1.1.1.1
     network 10.0.12.1 0.0.0.0 area 0
    !        
    

    R2
    !
    hostname R2
    !
    interface Ethernet0/0
     ip address 10.0.12.2 255.255.255.0
     ip ospf network point-to-point
    !         
    interface Ethernet0/1
     ip address 10.0.23.2 255.255.255.0
     ip ospf network point-to-point
     ip ospf cost 10
    !
    interface Ethernet0/2
     ip address 10.0.24.2 255.255.255.0
     ip ospf network point-to-point
     ip ospf cost 5
    !
    router ospf 1
     router-id 2.2.2.2
     area 1 virtual-link 3.3.3.3
     network 10.0.12.2 0.0.0.0 area 0
     network 10.0.23.2 0.0.0.0 area 1
     network 10.0.24.2 0.0.0.0 area 1
    !
    

    R3
    !
    hostname R3
    !
    interface Loopback100
     ip address 100.100.100.100 255.255.255.255
    !
    interface Ethernet0/1
     ip address 10.0.23.3 255.255.255.0
     ip ospf network point-to-point
    !
    router ospf 1
     router-id 3.3.3.3
     area 1 virtual-link 2.2.2.2
     network 10.0.23.3 0.0.0.0 area 1
     network 100.100.100.100 0.0.0.0 area 2
    !
    

    R4
    hostname R4
    !
    interface Loopback100
     ip address 100.100.100.100 255.255.255.255
    !
    interface Ethernet0/2
     ip address 10.0.24.4 255.255.255.0
     ip ospf network point-to-point
    !
    router ospf 1
     router-id 4.4.4.4
     network 10.0.24.4 0.0.0.0 area 1
     network 100.100.100.100 0.0.0.0 area 0
    !
    

    So as per the configs, i have a VL between R2 and R3 with area 1 being the transit area. Prefix 100.100.100.100/32 is in area 2 on R3, with VL, R3 becomes an ABR and sends 100.100.100.100/32 as a type 3 lsa over the VL and also into area 1.

    R2#sh ip ospf 1 database summary 100.100.100.100 ADv-router 3.3.3.3

    OSPF Router with ID (2.2.2.2) (Process ID 1)

    Summary Net Link States (Area 0)

    Routing Bit Set on this LSA in topology Base with MTID 0
    LS age: 6 (DoNotAge)
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 3.3.3.3
    LS Seq Number: 80000001
    Checksum: 0x2F6F
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1


    Summary Net Link States (Area 1)

    LS age: 1455
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 3.3.3.3
    LS Seq Number: 80000001
    Checksum: 0x2F6F
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1

    As a hack to advertise another 100.100.100.100 type 3 lsa into area 1, i configured R4 with 100.100.100.100 in area 0. R4 will then advertise this prefix into area 1.

    R2#sh ip ospf 1 database summary 100.100.100.100 ADv-router 4.4.4.4

    OSPF Router with ID (2.2.2.2) (Process ID 1)

    Summary Net Link States (Area 1)

    LS age: 1021
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 4.4.4.4
    LS Seq Number: 80000001
    Checksum: 0x1189
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1


    So looking at 100.100.100.100/32 in the database from all neighbors

    R2#sh ip ospf database summary 100.100.100.100

    OSPF Router with ID (2.2.2.2) (Process ID 1)

    Summary Net Link States (Area 0)

    Routing Bit Set on this LSA in topology Base with MTID 0
    LS age: 6 (DoNotAge)
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 3.3.3.3
    LS Seq Number: 80000001
    Checksum: 0x2F6F
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1


    Summary Net Link States (Area 1)

    LS age: 5
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 3.3.3.3
    LS Seq Number: 80000002
    Checksum: 0x2D70
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1

    LS age: 1413
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 4.4.4.4
    LS Seq Number: 80000001
    Checksum: 0x1189
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1






    Due to the VL, R2 is transit capable by default, which means it can receive type 3 lsa's from nonArea 0, i.e. coming from area 1.

    R2#sh ip ospf | b Area 1
    Area 1
    Number of interfaces in this area is 2
    This area has transit capability: Virtual Link Endpoint
    Area has no authentication
    SPF algorithm last executed 00:18:00.178 ago
    SPF algorithm executed 17 times
    Area ranges are
    Number of LSA 6. Checksum Sum 0x033478
    Number of opaque link LSA 0. Checksum Sum 0x000000
    Number of DCbitless LSA 0
    Number of indication LSA 0
    Number of DoNotAge LSA 0
    Flood list length 0


    R2#sh ip ospf int bri
    Interface PID Area IP Address/Mask Cost State Nbrs F/C
    VL0 1 0 10.0.23.2/24 10 P2P 1/1
    Et0/0 1 0 10.0.12.2/24 10 P2P 1/1
    Et0/2 1 1 10.0.24.2/24 100 P2P 1/1
    Et0/1 1 1 10.0.23.2/24 10 P2P 1/1
    R2#


    R2#sh ip route 100.100.100.100
    Routing entry for 100.100.100.100/32
    Known via "ospf 1", distance 110, metric 11, type inter area
    Last update from 10.0.23.3 on Ethernet0/1, 00:00:50 ago
    Routing Descriptor Blocks:
    * 10.0.23.3, from 3.3.3.3, 00:00:50 ago, via Ethernet0/1
    Route metric is 11, traffic share count is 1
    R2#

    R2#sh ip ospf border-routers

    OSPF Router with ID (2.2.2.2) (Process ID 1)


    Base Topology (MTID 0)

    Internal Router Routing Table
    Codes: i - Intra-area route, I - Inter-area route

    i 4.4.4.4 [100] via 10.0.24.4, Ethernet0/2, ABR, Area 1, SPF 19
    i 3.3.3.3 [10] via 10.0.23.3, Ethernet0/1, ABR, Area 0, SPF 11
    i 3.3.3.3 [10] via 10.0.23.3, Ethernet0/1, ABR, Area 1, SPF 19
    R2#

    At the moment R2 prefers the path via R3 due to the egress interface metric.


    Now i'll reduce the ospf cost on eth 0/2 to 5.

    R2#sh ip ospf int brie
    Interface PID Area IP Address/Mask Cost State Nbrs F/C
    VL0 1 0 10.0.23.2/24 10 P2P 1/1
    Et0/0 1 0 10.0.12.2/24 10 P2P 1/1
    Et0/2 1 1 10.0.24.2/24 5 P2P 1/1
    Et0/1 1 1 10.0.23.2/24 10 P2P 1/1
    R2#
    R2#sh ip route 100.100.100.100
    Routing entry for 100.100.100.100/32
    Known via "ospf 1", distance 110, metric 6, type inter area
    Last update from 10.0.24.4 on Ethernet0/2, 00:00:17 ago
    Routing Descriptor Blocks:
    * 10.0.24.4, from 3.3.3.3, 00:00:17 ago, via Ethernet0/2
    Route metric is 6, traffic share count is 1

    As you can see, R2 now prefers the path via R4, the funny part is, it still thinks its learned via 3.3.3.3 i.e. the routing bit is still set in the database for R3.

    R2#sh ip ospf database summary 100.100.100.100

    OSPF Router with ID (2.2.2.2) (Process ID 1)

    Summary Net Link States (Area 0)

    Routing Bit Set on this LSA in topology Base with MTID 0
    LS age: 6 (DoNotAge)
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 3.3.3.3
    LS Seq Number: 80000001
    Checksum: 0x2F6F
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1


    Summary Net Link States (Area 1)

    LS age: 167
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 3.3.3.3
    LS Seq Number: 80000002
    Checksum: 0x2D70
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1

    LS age: 1574
    Options: (No TOS-capability, DC, Upward)
    LS Type: Summary Links(Network)
    Link State ID: 100.100.100.100 (summary Network Number)
    Advertising Router: 4.4.4.4
    LS Seq Number: 80000001
    Checksum: 0x1189
    Length: 28
    Network Mask: /32
    MTID: 0 Metric: 1


    Now i'll disable transit capability on R2 and even though the lowest cost is to R4, the preferred route will be to R3. This is because R2 will no longer accept type 3 lsa's arriving from nonArea 0.

    R2(config)#router ospf 1
    R2(config-router)#no ca
    R2(config-router)#no capability tr
    R2(config-router)#no capability transit
    R2(config-router)#do sh ip ospf | b Area 1
    Area 1
    Number of interfaces in this area is 2
    Area has no authentication
    SPF algorithm last executed 00:00:00.433 ago
    SPF algorithm executed 22 times
    Area ranges are
    Number of LSA 7. Checksum Sum 0x03CE74
    Number of opaque link LSA 0. Checksum Sum 0x000000
    Number of DCbitless LSA 0
    Number of indication LSA 0
    Number of DoNotAge LSA 0
    Flood list length 0

    R2#sh ip ospf int br
    Interface PID Area IP Address/Mask Cost State Nbrs F/C
    VL0 1 0 10.0.23.2/24 10 P2P 1/1
    Et0/0 1 0 10.0.12.2/24 10 P2P 1/1
    Et0/2 1 1 10.0.24.2/24 5 P2P 1/1
    Et0/1 1 1 10.0.23.2/24 10 P2P 1/1
    R2#
    R2#sh ip route 100.100.100.100
    Routing entry for 100.100.100.100/32
    Known via "ospf 1", distance 110, metric 11, type inter area
    Last update from 10.0.23.3 on Ethernet0/1, 00:00:37 ago
    Routing Descriptor Blocks:
    * 10.0.23.3, from 3.3.3.3, 00:00:37 ago, via Ethernet0/1
    Route metric is 11, traffic share count is 1
    R2#
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • fredrikjjfredrikjj Member Posts: 879
    As a hack to advertise another 100.100.100.100 type 3 lsa into area 1, i configured R4 with 100.100.100.100 in area 0. R4 will then advertise this prefix into area 1.

    A cool thing that I discovered when I labbed it up yesterday is that it's enough to just enter a virtual link statement for the transit area for the type 3s to get flooded in that scenario. You don't have to put an interface in area 0, or create an actual virtual link adjacency.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    fredrikjj wrote: »
    A cool thing that I discovered when I labbed it up yesterday is that it's enough to just enter a virtual link statement for the transit area for the type 3s to get flooded in that scenario. You don't have to put an interface in area 0, or create an actual virtual link adjacency.

    You mean config a VL towards R4, which would make R4 an ABR and hence R4 would send summarizes into the transit area. Yes i could have done that but it wouldn't have been as clear as creating area 0 on R4. With a VL to R4, R2 would have seen R4 type 3 lsa's describing 100.100.100.100/32 prefix and then you could say R2 was using the type 3 coming over the VL from R4.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • fredrikjjfredrikjj Member Posts: 879
    EdTheLad wrote: »
    You mean config a VL towards R4, which would make R4 an ABR and hence R4 would send summarizes into the transit area. Yes i could have done that but it wouldn't have been as clear as creating area 0 on R4. With a VL to R4, R2 would have seen R4 type 3 lsa's describing 100.100.100.100/32 prefix and then you could say R2 was using the type 3 coming over the VL from R4.

    I'm saying that if your only goal is to make a router an ABR so that it floods type 3s into the transit area, you can configure a virtual link statement under the router process pointing to an ABR, and that alone will make the router an ABR. The VL doesn't have to actually connect. Of course, you already have another virtual link between two different routers. I'm only talking about making a router an ABR so that it can be used for the transit capability.

    I don't claim that there's any advantage to this compared to creating an interface in area 0 to accomplish the same thing. And if you input the virtual link command on one side, you might as well do it on the other side as well to have redundant virtual links.

    Essentially, a virtual link is an interface in area 0, and it's technically "up" even before it creates an adjacency with the other side of the link as long as it points to a valid router-id.

    Virtual Link configured:
    R12#show run | s router ospf 1
    router ospf 1
     router-id 2.2.2.2
     area 1 virtual-link 1.1.1.1
    

    It's an interface in area 0:
    R12#show ip ospf int brief
    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
    VL5          1     0               192.168.1.2/24     64    P2P   0/0
    Se1/0        1     1               192.168.1.2/24     64    P2P   1/1
    Lo0          1     2               10.2.2.2/24        1     P2P   0/0
    

    The virtual link interface is not adjacent with anything:
    R12#show ip ospf neighbor 
    Neighbor ID     Pri   State           Dead Time   Address         Interface
    1.1.1.1           0   FULL/  -        00:00:38    192.168.1.1     Serial1/0
    

    The router is still an ABR:
    R12#show ip ospf | inc area border
     It is an area border router
    
  • fredrikjjfredrikjj Member Posts: 879
    I finished OSPF in INE Workbook Volume 1 (v4) a few days ago. I'm also working on an OSPF mind map where I feel like I've covered most topics but there are still some loose ends that I need to tie up. I'm currentinly in the process of adding the troubleshooting scenarios from the 2002 book Troubleshooting IP Routing Protocols which I expect to finish later tonight. Here's the mind map, but keep in mind that it's very much a work in progress, and it desperately needs to be improved aesthetically.

    https://drive.google.com/file/d/0B2bdhZFpmd44YzRXSWZ5RTlFTEU/edit?usp=sharing

    PS.
    Once I feel like I'm done with OSPF, I'm probably going to move to BGP. The logical choice for the next protocol to study would be EIGRP since it's also an IGP, but being stronger on BGP would be a lot more useful in real life I imagine as EIGRP has little to no deployment in Sweden from what I've heard. Plus, I already kind of know EIGRP from CCNP. Or I might just quickly run through the INE EIGRP labs, who knows. I guess I haven't decided.
Sign In or Register to comment.