SRX

last person joined: yesterday 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  RIB groups behaviour

     
    Posted 01-11-2014 08:43

    Hi All,

     

    Hope everyone's doing good. 

     

    I'm currently playing around with RIB groups for the JNCIP-SEC exam and have noticed an odd behaviour which I am not sure if it's expetected or not.

     

    My topology is as follows

     

    Client (VR1)---SRX1----SRX2----Loopback

     

    SRX1 has two routing tables inet.0 and VR1.inet.0. Client machine connected to VR1 and the link between SRX1 and SRX2 is in inet.0 with ospf enabled.  

     

    inet.0 can see the loop back address of SRX2 via OSPF.

     

    I created a rib group to share inet.0s routes to VR1 and from the client I can ping across to the loopback.  So all is working as inteded.  However, what I noticed is if I try to ping the loopback address from VR1 routing instance locally it time's out.  This doesn't make any sense becuase the routes are there and it works from the client, it should be able to ping.  The only conslusion I can think is the SRX does not allow it for whatever reason, maybe loop preventions of some sort?  It's no big deal but would be interesting to know if anyone else has come across this.

     

    Config:

     

    root# run show route | no-more

    inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both

    2.2.2.2/32         *[OSPF/10] 00:00:38, metric 1
                        > to 10.0.2.1 via fe-0/0/0.0
    10.0.2.0/30        *[Direct/0] 01:50:15
                        > via fe-0/0/0.0
    10.0.2.2/32        *[Local/0] 01:50:15
                          Local via fe-0/0/0.0
    224.0.0.5/32       *[OSPF/10] 01:16:08, metric 1
                          MultiRecv

    VR1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both

    1.1.1.1/32         *[Direct/0] 01:37:53
                        > via lo0.1
    2.2.2.2/32         *[OSPF/10] 00:00:38, metric 1
                        > to 10.0.2.1 via fe-0/0/0.0
    192.168.10.0/24    *[Direct/0] 01:35:32
                        > via fe-0/0/1.0
    192.168.10.1/32    *[Local/0] 01:35:32
                          Local via fe-0/0/1.0

    [edit]
    root# run ping rapid 2.2.2.2 routing-instance VR1 source 192.168.10.1
    PING 2.2.2.2 (2.2.2.2): 56 data bytes
    .....
    --- 2.2.2.2 ping statistics ---
    5 packets transmitted, 0 packets received, 100% packet loss

    root# show | display set | no-more
    set version 12.1X45
    set system root-authentication encrypted-password "$1$tEeFObR6$adMM.r/wwG57baDwADCF4."
    set interfaces fe-0/0/0 unit 0 family inet address 10.0.2.2/30
    set interfaces fe-0/0/1 unit 0 family inet address 192.168.10.1/24
    set interfaces lo0 unit 1 family inet address 1.1.1.1/32
    set routing-options rib-groups Inet-VR import-rib inet.0
    set routing-options rib-groups Inet-VR import-rib VR1.inet.0
    set protocols ospf rib-group Inet-VR
    set protocols ospf area 0.0.0.0 interface fe-0/0/0.0
    set security policies default-policy permit-all
    set security zones security-zone rib host-inbound-traffic system-services all
    set security zones security-zone rib host-inbound-traffic protocols all
    set security zones security-zone rib interfaces fe-0/0/0.0
    set security zones security-zone VR1 host-inbound-traffic system-services all
    set security zones security-zone VR1 host-inbound-traffic protocols all
    set security zones security-zone VR1 interfaces lo0.1
    set security zones security-zone VR1 interfaces fe-0/0/1.0
    set routing-instances VR1 instance-type virtual-router
    set routing-instances VR1 interface fe-0/0/1.0
    set routing-instances VR1 interface lo0.1

     

    Laptop output:

     

    C:\Users\root>tracert 2.2.2.2

    Tracing route to 2.2.2.2 over a maximum of 30 hops

      1    <1 ms    <1 ms    <1 ms  192.168.10.1
      2     2 ms     2 ms     2 ms  2.2.2.2

    Trace complete.

    Thanks!

    Mas

     

     

     



  • 2.  RE: RIB groups behaviour

    Posted 01-11-2014 10:44

    When you send ping request with source option , source IP is set as 192.168.10.1 and ping request reach other firewall looback IP. Now during return master routing instance (in firewall where ping was initiated)  does not know how to reach 192.168.10.0/24 subnet . You need to share interface routes from VR1 to master routing instance. Slight modification to your configuration will resolve your issue

     
    set routing-instances VR1 routing-options interface-routes rib-group inet Inet-VR

     

     

    Rib group earlier configured by you is simply being used with interface-route in VR1 routing instances to share interface routes with master routing instance.

     

     

     

    Please mark this as accepted solution if it works for you

    A kudos is a good way of appreciation

     

    Kashif Nawaz

    JNCIP-Sec ,JNCIP-Ent

    JNCIS-Ent, JNCIS-Sec

    JNCIA-Junos



  • 3.  RE: RIB groups behaviour
    Best Answer

    Posted 01-11-2014 11:44

    Witout sharing interface routes from VR1 with master routing instance if you  ping 192.168.10.1 source 10.0.2.2
    PING 192.168.10.1 (192.168.10.1): 56 data bytes
    ping: sendto: No route to host
    ping: sendto: No route to host
    ping: sendto: No route to host
    And if send ping request to 192.168.10.1 from other firewall

    ping 192.168.10.1
    PING 192.168.10.1 (192.168.10.1): 56 data bytes
    36 bytes from 10.0.2.2: Destination Net Unreachable
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 0054 1bfe   0 0000  40  01 8801 10.0.2.1  192.168.10.1

    The responce is obvious as master routing instance does not have route to 192.168.10.0/24 subnet and interface route sharing from VR1 to master routing instance resolve the issue

     

    read following KB for reference:

     http://kb.juniper.net/InfoCenter/index?page=content&id=KB25190

     

     

    Please mark this as accepted solution if it works for you

    A kudos is a good way of appreciation

     

    Kashif Nawaz

    JNCIP-Sec ,JNCIP-Ent

    JNCIS-Ent, JNCIS-Sec

    JNCIA-Junos