Building upon our last post we have been able partition our SRX up and create three virtual routing-instances. We found that due to creating these on an SRX , they needed their own security zones to be applied also. We defined, applied security permission, then assign interfaces to the zones. Now we have the foundation to the lab that we built we can lab to our hearts content. Routing, Security, IDS, VPN. I am going to put this SRX110 through its paces and the PFE/ASICs are going to wish they didn’t come to this lab!
Below we set the ospf process under each routing instance for the lt-0/0/0 interfaces.
set routing-instances R1 protocols area 0 interface lt-0/0/0.0 set routing-instances R1 protocols area 0 interface lt-0/0/0.5 set routing-instances R2 protocols area 0 interface lt-0/0/0.1 set routing-instances R2 protocols area 0 interface lt-0/0/0.2 set routing-instances R3 protocols area 0 interface lt-0/0/0.3 set routing-instances R3 protocols area 0 interface lt-0/0/0.4
Here the routing table shows our OSPF network forming over our lt-0/0/0.* interfaces. This
[email protected]> show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.200/32 *[Local/0] 00:53:52 Reject 192.168.2.1/32 *[Local/0] 00:54:01 Reject R1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.1/32 *[Direct/0] 00:54:26 > via lo0.1 192.168.10.0/30 *[Direct/0] 00:53:51 > via lt-0/0/0.0 192.168.10.1/32 *[Local/0] 00:53:51 Local via lt-0/0/0.0 192.168.10.4/30 *[OSPF/10] 00:04:35, metric 2 > to 192.168.10.2 via lt-0/0/0.0 to 192.168.10.9 via lt-0/0/0.5 192.168.10.8/30 *[Direct/0] 00:53:50 > via lt-0/0/0.5 192.168.10.10/32 *[Local/0] 00:53:50 Local via lt-0/0/0.5 224.0.0.5/32 *[OSPF/10] 00:05:31, metric 1 MultiRecv R2.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2.2.2.2/32 *[Direct/0] 00:54:25 > via lo0.2 192.168.10.0/30 *[Direct/0] 00:53:50 > via lt-0/0/0.1 192.168.10.2/32 *[Local/0] 00:53:50 Local via lt-0/0/0.1 192.168.10.4/30 *[Direct/0] 00:53:50 > via lt-0/0/0.2 192.168.10.5/32 *[Local/0] 00:53:50 Local via lt-0/0/0.2 192.168.10.8/30 *[OSPF/10] 00:04:30, metric 2 > to 192.168.10.1 via lt-0/0/0.1 to 192.168.10.6 via lt-0/0/0.2 224.0.0.5/32 *[OSPF/10] 00:05:31, metric 1 MultiRecv R3.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 3.3.3.3/32 *[Direct/0] 00:54:25 > via lo0.3 192.168.10.0/30 *[OSPF/10] 00:04:31, metric 2 > to 192.168.10.5 via lt-0/0/0.3 to 192.168.10.10 via lt-0/0/0.4 192.168.10.4/30 *[Direct/0] 00:53:50 > via lt-0/0/0.3 192.168.10.6/32 *[Local/0] 00:53:50 Local via lt-0/0/0.3 192.168.10.8/30 *[Direct/0] 00:53:50 > via lt-0/0/0.4 192.168.10.9/32 *[Local/0] 00:53:50 Local via lt-0/0/0.4 224.0.0.5/32 *[OSPF/10] 00:05:31, metric 1 MultiRecv
Now lets confirm that the router and network LSA’s have been advertised correctly. Remember that OSPF uses loopback adapters over interface IPs for the router-id if it isn’t specified. This is the same as Cisco. I could have issued set routing-instances R1 routing-options router-id x.x.x.x if I wanted to. I would suggest this in a production environment to ensure a stable OSPF database.
[email protected]> show ospf database instance R1 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *1.1.1.1 1.1.1.1 0x80000009 725 0x22 0xf13d 48 Router 2.2.2.2 2.2.2.2 0x80000009 721 0x22 0xee3f 48 Router 3.3.3.3 3.3.3.3 0x80000009 1720 0x22 0xad69 48 Network 192.168.10.2 2.2.2.2 0x80000006 731 0x22 0x8925 32 Network 192.168.10.6 3.3.3.3 0x80000005 721 0x22 0x9906 32 Network 192.168.10.9 3.3.3.3 0x80000006 2719 0x22 0x4758 32 [email protected]> show ospf database instance R2 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 1.1.1.1 1.1.1.1 0x80000009 729 0x22 0xf13d 48 Router *2.2.2.2 2.2.2.2 0x80000009 723 0x22 0xee3f 48 Router 3.3.3.3 3.3.3.3 0x80000009 1723 0x22 0xad69 48 Network *192.168.10.2 2.2.2.2 0x80000006 733 0x22 0x8925 32 Network 192.168.10.6 3.3.3.3 0x80000005 724 0x22 0x9906 32 Network 192.168.10.9 3.3.3.3 0x80000006 2722 0x22 0x4758 32 [email protected]> show ospf database instance R3 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 1.1.1.1 1.1.1.1 0x80000009 732 0x22 0xf13d 48 Router 2.2.2.2 2.2.2.2 0x80000009 727 0x22 0xee3f 48 Router *3.3.3.3 3.3.3.3 0x80000009 1725 0x22 0xad69 48 Network 192.168.10.2 2.2.2.2 0x80000006 737 0x22 0x8925 32 Network *192.168.10.6 3.3.3.3 0x80000005 726 0x22 0x9906 32 Network *192.168.10.9 3.3.3.3 0x80000006 2724 0x22 0x4758 32
The best part about OSPF databases on JUNOS? The logical and neat way the output sits. You can see the name of the LSA types. Fantastic. So recapping on all this we have just configured OSPF on our virtual routing instances. This means we have a great self-contained lab but mind you, I feel another LT needs to be created and I will get internet access into this virtual network. This admittedly is my first Juniper OSPF experience. I am getting there and cannot wait to explore some more labs and share them with you all.
Great writeup! I’m am tailing your blog. Thought i’d mention though that I could not get full connectivity until I enabled the following policies on the SRX.
From zone: trust-R1, To zone: trust-R1
Policy: trust-to-trust, State: enabled, Index: 11, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
From zone: trust-R2, To zone: trust-R2
Policy: trust-to-trust, State: enabled, Index: 12, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
From zone: trust-R3, To zone: trust-R3
Policy: trust-to-trust, State: enabled, Index: 13, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit