Screen OS

 View Only
last person joined: 11 months ago 

This is a legacy community with limited Juniper monitoring.
  • 1.  OSPF external LSA in ScreenOS

    Posted 01-31-2009 02:47

     

     

    Hi all,

     

    Does anyone have an idea why ScreenOS (v5.1.0r1.0, NS-204) doesn't install an LSA type 5 as a route in a local routing table when shows it in ospf database and floods it to neighbors.

     

     

     

    The scheme is like following:

     

     {static route 172.17.1.0/24}

    |

    [NS-1]

    |

    [cisco router]

    |

    [NS-204]

    |

    ------IPSec-------

    |                 |

    [SSG-1]          [SSG-2]

     

    Form top to down: NS-1 generates an external LSA reditributing 172.17.1.0/24, cisco router proceeds it normally, installs it in its table and floods to NS-204. NS-204 sees the LSA, flods it to SSG boxes but doesn't install it to its own routing table. All this is in a single area 0.

     

    Some more techical explanation:

     


    NS-1

     

     

    NS-1-> get vr trust protocol ospf config
    VR: trust-vr RouterId: 172.16.255.3
    ----------------------------------
    set protocol ospf
    set enable
    set reject-default-route
    exit
    set protocol ospf
    set redistribute route-map "rmap1" protocol static
    exit
    set interface ethernet1 protocol ospf area 0.0.0.0
    [... let's skip interfaces
    config ...]

    Route map looks like:

    set route-map name "rmap1" permit 10
    set match ip 1
    set next-hop 172.16.1.11
    set tag 172.17.1.0
    exit
    access list 1 permites 172.17.1.0/24

    Router


     

     

    cisco-router#sh ip route ospf | i 172.17.1.0
    O E1    172.17.1.0 [110/11] via 172.16.1.11, 00:07:14, Ethernet0/1

    cisco-router#show ip ospf database external 172.17.1.0

                OSPF Router with ID (172.16.255.2) (Process ID 100)

                    Type-5 AS External Link States

      Routing Bit Set on this LSA
      LS age: 1265
      Options: (No TOS-capability, DC)
      LS Type: AS External Link
      Link State ID: 172.17.1.0 (External Network Number )
      Advertising Router: 172.16.255.3
      LS Seq Number: 80000016
      Checksum: 0x30E6
      Length: 36
      Network Mask: /24
            Metric Type: 1 (Comparable directly to link state metric)
            TOS: 0
            Metric: 1
            Forward Address: 172.16.1.11
            External Route Tag: 2886795520

    NS-204


     

     

    NS-204-> get vr trust protocol ospf config
    VR: trust-vr RouterId: 172.16.255.1
    ----------------------------------
    set protocol ospf
    set enable
    set advertise-def-route metric 50 metric-type 2
    set reject-default-route
    exit
    [... interfaces ...]
    NS-204-> get vr trust pro o data detail ext link-state-id 172.17.1.0
    VR: trust-vr RouterId: 172.16.255.1
    ----------------------------------
                            AS External LSA(s)
                            --------------------------------
    Age:  3600
    Seq Number: 0x80000017
    Checksum: 0x2ee7
    Advertising Router: 172.16.255.3
    Link State ID: 172.17.1.0
    Length: 36
    Options:   Extern     DC
    Network Mask: 255.255.255.0
                    Metric Type: 1
                    TOS: 0
                    Metric: 1
                    Forward Address: 172.16.1.11
                    External Route Tag: -1408171776
    NS-204-> get vr trust route pro o | i 172.17.1.0
    [empty]

    SSG


     

     

    ssg-1-> get route pro o | i 172.17.1.0
    * 294      172.17.1.0/24       tunnel.2    172.18.253.6  E1   60     22     Root

     The LSA itself looks here just the same as on cisco-router and NS-204, so there is no need to show it once again.

     


    --

    Kind regards,

    Pavel


    #redistribution
    #lsa
    #ospf
    #external
    #screenos


  • 2.  RE: OSPF external LSA in ScreenOS
    Best Answer

    Posted 01-31-2009 03:39

    Ups!

     

    Just upgraded NS-204 to 5.4.0r12.0. 

     

    NS-204-> get route protocol ospf | i 172.17.1.0
    *  41      172.17.1.0/24           eth4        10.0.1.2  E1   60     12     Root

     

    🙂

     

    It wasn't so easy due to quite heavy work the box does in production environment. I also thought it might me some explanation based on OSPF theory in which I'm not a guru.

     

    I'll keep this thread, if someone once bump into this issue, it might be useful for him.