Category Archives: Juniper

Open Shortest Path First Notes

Reading Time: 15 minutes

As part of studies, this post will be my notes on the Routing Protocol Open Shortest Path First

OSPF Basics

  • What is OSPF?
  • OSPF Structure

Neighbour Discovery

  • Inter-Node Communication
  • OSPF Packet Details
  • OSPF Hello Messages Details
  • Router-ID Selection Process
  • OSPF Neighbour Adjacency Process
  • Designated Router & Backup Designated Router
  • Designated Router Election

Network Types

  • Broadcast
  • Non-Broadcast Multi-Access
  • Point-to-Point
  • Point-to-Multipoint
  • Loopback

Scaling OSPF

  • Areas
  • Router Types
  • OSPF Route Types
  • Link-State Advertisement Types
  • Area Types

OSPF Basics

What is OSPF

Open Shortest Path First (OSPF) is an Open-Standard Interior Gateway Protocol (IGP) routing protocol. Unlike other Routing Protocols such as Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP) or Border Gateway Protocol (BGP), OSPF uses the Link State Algorithm in conjunction with Edsger W. Dijkstra Shortest Path First (SPF) algorithm to send out OSPF advertisements, known as Link-State Advertisements (LSAs), to share its Local Link-State Database (LSDB) with OSPF enabled devices to create an overall topology of every router, link state and link metric within a network. OSPF is defined in RFC2328:

OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System’s topology. From this database, a routing table is calculated by constructing a shortest-path tree.

OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.

OSPF advertises and receives LSAs to/from neighbouring routers; these LSAs are stored with the router’s local LSDB. Whenever there is a change in the network new LSA’s will be flooded across the routing domain and all the routers will have to update their LSDB. This is due to the nature of the Link State and SPF Algorithms; essentially all OSPF routers have to same synchronized identical copy of the Link State Database to have a complete loop-free map of the network topology.

OSPF Structure

OSPF can be described as a two-tier hierarchical structure. This is because you have two main area types: Backbone Area and Non-Backbone Areas. The Backbone Area is known as Area 0 and Non-Backbone Areas are all other Areas. All Non-Backbone Areas MUST connect to Area 0. It is important to note, that OSPF routers in different Areas DO NOT have the same synchronized identical copy of each Link State Database however routers within the same Area will have an identical Link State Database. This is because; Area 0 provides transit for All Non-Backbone Areas. Non-Backbone Areas advertise their routes into Area 0 and Area 0 will advertise all routes learnt to the other Areas, as shown here

Neighbour Discovery

Inter-Node Communication

Communication between OSPF routers is done, dependent on network type, over IP using it own protocol number 89 sending multicast OSPF packets between each other. There are two multicast addresses that have been defined for OSPF enabled routers/interfaces to dynamically find neighbours. RFC2328 defines them as:

AllSPFRouters: This multicast address has been assigned the value 224.0.0.5. All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPF protocol packets are sent to this address during the flooding procedure.

AllDRouters: This multicast address has been assigned the value 224.0.0.6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure.

OSPF Packet Details

As stated above, OSPF has it own dedicated IP protocol as reserved by Internet Assigned Number Authority (IANA) within the protocol, OSPF exchanges 5 types of packets:

Type Packet Name Packet Function
1 Hello Discovers and Maintains Neighbours
Hello are sent to ensure that neighbours are still available and online
2 Database Description
(DBD/DDP)
Summarize Database contents
When an adjacency is being formed, this packet will describe the content of the Link-State Database being received
3 Link-State Request (LSR) Database Download
These are used to request more detail about a portion of LSDB from one router to another, when some details are regarded as stale
4 Link-State Update (LSU) Database Update
This packet is normally in response to LSR packet, it provides an update to the LSDB as requested by a neighbour
5 Link-state Ack Flooding Acknowledgment
When the router receives a LSA flood, it will response to the flood to ensure OSPF reliable

OSPF Hello Messages Details

As stated earlier, an OSPF Packet will be exchanged between routers to allow them to have the same synchronizes OSPF database. For Adjacency discovery and maintenance; an OSPF Hello Message is flooded to all enabled interfaces, two routers that have the same matching hello messages will create an OSPF adjacency. The table below shows all the parameters that are within a Hello Message, with the first eight parameters needing to match for an adjacency to form:

Parameter Function
Hello Interval Amount of time between hello packets being sent and recieved
Dead Interval How long to wait between hello packets before marking the neighbour as dead, by default the dead interval is 4x the hello interval. Essentially, the router can miss for hello interval before updating that the neighbour is down
Area ID Both neighbour in the same OSPF Area.
Subnet Mask This is for connectivity both neighbours will need to be in the same subnet
Stub Area Flag This is for when the neighbour has been defined as Stub Area. Within OSPF all Areas that have been defined as Stub Areas mark their hello messages with the Stub Flag
Authentication Securing communication between neighbours. This can be configured with None, Clear Text or MD5
OSPF Router ID An unique 32-bit ID number that’s set in dotted-decimal format
Maximum Transmission Unit (MTU) As OSPF doesn’t support packet fragmentation, the MTU must be the same on both side.
From my experiences this is only changed if you are using Jumbo Packet sizing
Router Priority Used to determine Designated and Backup Designated Routers
Designated Router &
Backup Designated Router
The IP addresses of the Designated and Backup Designated Routers
Active Neighbours List of all the neighbours (the router) has recieved a Hello Message from, within the dead interval

OSPF uses its ALLSPFRouters address to send out hello messages across all OSPF enabled interfaces. It is important to add that if you have an interface that has been set as a passive OSPF interface, this interface will still be advertised into an OSPF routing domain however hello messages ARE NOT sent out. From my experiences this is commonly used on loopback address or external/customer facing interfaces. As you would want to advertise the subnet into OSPF however you wouldn’t want to have start an OSPF Neighbour Relationship between your ISPs or Customers.

The OSPF Router-ID is an important attribute when it comes to identifying a router within the OSPF domain. Each OSPF router has a Router-ID that is associated with the OSPF process, so it is possible to have to have two different processes active on single router with two different Router-IDs. The OSPF Router-ID has to be configured in 32-bit dotted decimal format, this is case whether you are using OSPFv2 (IPv4) or OSPFv3 (IPv4 and IPv6). As discussed in RFC2328

As each router will be getting an ID number, it is important to note, that these IDs have to be unique and no neighbour in the same OSPF domain can have same Router-ID. If two routers were to have same Router-ID, they wouldn’t be able to create a neighbour relationship. Additionally other neighbours peered with the both will have an issues with OSPF updates that come from the same Router-ID however the link-state databases are different, this can cause OSFP Flood War

OSPF Router-ID Selection Process

The process of selecting the Router-ID within OSPF follows this order:

  1. Hard Coding the Router-ID: If the Router-ID manually configured under the OSPF process this take precedence over everything. This is recommended and best practice
  2. Highest Logical IP Address: This will be the highest loopback address configured on the router
  3. Highest Active Physical IP address: This will be the highest IP address configured on a physical interface on the router

If you don’t hard code the router-id you will need to always remember, when you are making IP address updates on the router if you configure a new loopback or interface IP address that is higher than the currently OSPF Router-ID, it will change the Router-ID and can cause OSPF re-convergence, if the process is cleared or the device is reloaded.

OSPF Neighbour Adjacency Process

With OSPF, unlike, other IGPs has 2 Neighbour Adjacency states:
OSPF Neighbours: OSPF Neighbours are when two routers/devices have stop at the 2-Way neighbour state. At this state the neighbours bidirectional connectivity and all the OSPF parameters match. But it is important to note that the neighbours DO NOT exchange their link-state databases at this state.

OSPF Fully Adjacent Neighbours: OSPF Fully Adjacent Neighbours is when the two routers have the same bidirectional connectivity and all OSPF parameters match, however with Fully Adjacent Neighbours, each router will exchange their full link-state database with its neighbours and advertise the relationship in a link-state update packets.

Within OSPF there are 8 neighbour states that two neighbours can go through to become Fully Adjacent Neighbours. These states are:

State Description
Down This is the start state of neighbour communications. No Hello Messages have been exchanged
Attempt This state is valid only for Non-Broadcast Multi-Access (NBMA) networks. It is when a hello packet has not been received from the neighbour and the local router is going to send a unicast hello packet to that neighbour within the specified hello interval period.
Init The router has received a Hello Message from a neighbour, but has not received its own Router-ID from the neighbour. This means that Bidirectional communications have not been established yet.
2-Way Bidirectional communication between the neighbours have been established, no Link State information has been exchanged. At this state an OSPF Neighbourship has been created
ExStart This is where the neighbours start the process of becoming Fully Adjacent OSPF Neighbours and exchange Link State Databases
Exchange At this state, Link State Database details has been sent to the adjacent neighbour. At this state, a router is capable to exchange all OSPF routing protocol packets.
Loading At this state, the neighbour has exchanged its own LSDB, however has not fully requested/received LSA’s from its neighbour
Full Both LSDB’s have been exchanged and are fully synchronized. Each neighbour will have the full OSPF Network Topology available now

Designated Router & Backup Designated Router

OSPF has the concept of Designated and Backup Designated Routers (DR and BDR) for Multi-Access Networks that use technologies such as Ethernet and Frame Relay, as on the LAN you can have more than two OSPF enabled router. By having DR and BDRs, it assists in scalable of an OSPF segment, in addition to reducing OSPF LSA flooring across the network. This is because the other routers (OSPF DROthers) on the LAN, only create a Full OSPF Adjacency with the DR and BDR rather than with other DRothers. The DR is the solely responsible for flooding the LAN with LSA updates during a topology change. The flooring by the DR is controlled, as stated above, by the AllSPFRouters and AllDRouters multicast addresses. DR will flood LSAs to the AllSPFRouters destination address to communicate with other routers on the LAN; and DROthers will communicate their LSAs to DR and BDR using the AllDRouters destination address.

As the name suggests the BDR role is to be the secondary router in case the DR was the fail or be un-contactable, it will take over as the DR and another BDR will be elected. The BDR has a full OSPF Adjacency just like the DROthers with the BR, however unlike them, the BDR can listen on the ALLDRouters address. This means, in a situation of a DR failure, the BDR can take over as DR quicker and there will be less re-convergence across the network, as it already synchronized to the DR and the DROthers as they will all have the same LSDB.

Designated Router Election Method

The DR/BDR Election process is done during the 2-Way State, where bidirectional communications has been established between the routers and have received Hello Messages. OSPF uses Interface Priority and Router-ID to determine, which routers will be elected as DR and BDR. An OSPF router can have its interface priority set between 0-255, (an interface priority set to 0 means it is prohibited from entering DR/BDR election process) with the highest priority taking the role as the DR and the secondary highest priority becoming the BDR. If the priorities are all the same, the highest Router-ID will be used as the tiebreaker.

By default, OSPF’s priority is 1 on Cisco IOS/XR and 128 on Juniper. With Cisco IOS XR, you are able to set the priority for all interface within an area globally and under the interface, whereas Junos and Cisco IOS you can only set priority under the interface.

IMPORTANT NOTE
If an OSPF router receives a Hello Packet with the Router-ID for the DR or BDR isn’t 0.0.0.0, it will assume that DR and BDR have been elected already and will become a DROther.

Network Types

Depending on what the Layer-2 topology looks like within a network can have affect on the behaviour of OSPF. A Topology that uses Ethernet commonly allow multiple node on a LAN, in this case a Designated Router (DR) and Backup Designated Router (BDR) are used to cut down the OSPF LSA flooding, due to both supporting broadcast domains. Whereas other media such as serial links or Frame Relay don’t support broadcast domains meaning DR/BDR are not needed.

With this in mind OSPF has 5 different network types:

Broadcast

A Broadcast network is where an OSPF router is able to send a single message (broadcast message) that is able to communicate to more than 2 other OSPF routers on the same multi-access segment. i.e. Router A, B and C are connected to a Switch when Router A sends out a Hello Message it will be broadcasted across the segment via the Switch. With in this in mind, the need for DR/BDR will be required to control the LSA flooding across the segment. By default OSPF uses broadcast as the network type when configured on Ethernet LAN. The hello timers by 10/40 by default.

Non-Broadcast Multi-Access (NBMA)

This network type is used on links that do not support broadcast domain, media such as Frame Relay, ATM and X.25, or topologies like a hub and spoke where a router can connect to multiple nodes out of a single interface however isn’t fully meshed. A Non-Broadcast network will need to have DR/BDR configured, as you could have multiple nodes on the segment. However, Non-Broadcast network (as the name would suggest) doesn’t support broadcast or multicast, this means that OSPF’s normal way of sending hellos via the multicast address 224.0.0.5 to flood LAN looking for neighbours will not work. Instead it sends out unicast hello messages to statically configured neighbours. The hello timers are 30/120 by default.

Point-to-Point

This network type is commonly used when you only have two devices on the segment, ie if you have Router A connected to Router B using /31 or /30 that will be regarded as Point-to-Point (P2P) network. This network type doesn’t require DR/DBR as the two devices only have each other to communication and forming a DR/BDR would be a waste of Router resources. In addition, it important to note that P2P OSPF Adjacency form quicker as DR election is ignored and there is no wait timer. The hello timers by 10/40 by default and it supports OSPF Multicast Hello Messages.

Point-to-Multipoint

This network is commonly used when in a partially mesh network or hub and spoken network, where the Layer-2 topology doesn’t logically match the Layer-3 topology. I.e. in a hub and spoke or frame-relay network, Router A will be connected to Routers B and C, all on the same subnet, the Layer-3 will assume Routers B and C will be able directly connected on the same LAN, whereas the Layer-2 determines that Router B can only communicate with Router C by going via Router A. By using Point-to-Multipoint, it will advertise all each neighbour as a /32 endpoint forcing the Layer-3 routing to matches the Layer-2 by using Longest prefix match. The hello timers are 30/120 by default, doesn’t require DR/DBR and it supports OSPF Multicast Hello Messages.

Loopback

This network type is by default enabled on all loopback interfaces and can only be configured on loopback addresses. OSPF will always advertise loopback addresses as /32 route, even if the interface has been configured with a different prefix length. Hello messages, Timers and DR/BDR are not associated with Loopback network types.

Scaling OSPF

Areas

The wider a network gets, the wider OSPF domain will become. This can be an issue as all of these routers will need to maintain the same LSDB, and with a larger network more resources will be used processing LSA flooding and running SPF algorithm, which in turn will make the router run inefficient and possible start dropping packets. A way of easing this issue is to introduce OSPF Areas. OSPF Areas are used reduce the amount of the routers in a single area, in turn shrinking the LSDB size, restricts LSA flooding within/between areas, allows route summarization between Areas and increases SPF calculations. This is because routers maintain their own LSDB on a per-area basis. Essentially, Areas hide the their own topology and any LSA flooding or SPF calculations will same local to that area whilst the rest of the network stays unaware. Routers within the same area will have the same synchronized LSDB with Routers with interfaces in multiples area will hold LSDBs.

Router Types

Along with Area Types, OSPF has 4 different types of roles that an OSPF router could be, and dependent on the topology, multiple types at once. The table below describes the different Router types and you can see where each of these router types could sit within a simple topology here

Router Type Function
Backbone Router A router that is located and/or has a link(s) within Area 0 is known as a Backbone router. If this router has links to non backbone routers, it can also be known as an Internal router.
Internal Router An internal router is an OSPF router that only have links within a single area. If this router is within Area 0, it will also be known as Backbone Router.
Area Border Router (ABR) An Area Border Router (ABR) is a router that has links between 2 areas. ABRs are role is to inject routes from non-backbone areas into Backbone. For a router to be an ABR, it HAS to have a link to Area 0, if it doesn’t then it wont be an ABR. It is considered a member of all areas it is connected to. An ABR keeps multiple copies of the link-state database in memory, one for each area to which that router is connected.
Autonomous System Boundary Router (ASBR) An OSPF router that learns routes from external routing protocols (BGP, IS-IS, EIGRP, OSPF), Static Routes and/or both and injects them into OSPF via redistribution. ASBRs are special types of routers, as you have can ASBR that isn’t ABR as these ASBR functions are independent to ABR functions, but dependant on the topology, you could have router that is both an ASBR and ABR.

OSPF Route Types

OSPF has a unique relationship between how routes are exchanged between areas and how these routes are ranked in importance. There’s 3 types of the Routes that are exchanged within OSPF Inter-Area, Intra-Area and External Routes, and in regards with the External Routes, you have 2 different types of External Routes:

Intra-Area Routes: these are routes that are learnt from Routers that are within the same area. They are also known as internal routes
Inter-Area Routes: these are routes that have been learnt from different areas. These routes have been injected via an ABR. They are also known as summary routes.
External Routes: are routes that are learnt outside of the OSPF domain. These routes have been learnt via redistribution by an ASBR. External routes have 2 classifications Type 1 and Type 2.

  1. Type 1 Routes: Type 1 routes, metric value equals the Redistribution Metric + Total Path Metric. This means that the metric values will increase the further the route goes into the network from the injecting ASBR. Type 1 routes are also known as E1 and N1 External Routes
  2. Type 2 Routes: Type 2 routes, metric value is only the Redistribution Metric. This means that the metric value will stay the same, no matter the how far the route goes into the network (within in 30 hops) from the injecting ASBR. By default, type 2 is the metric type used by OSPF. Type 2 routes are also known as E2 and N2 External Routes
NOTE
The order of preference for these route types are as followed:

  1. Intra-Area
  2. Inter-Area
  3. External Type 1
  4. External Type 2

Link-State Advertisement Types

Devices in an OSPF domain use LSAs to build their local areas LSDB. These LSDBs are identical for devices in the same area and different areas and different router types can produce different type of LSAs. There is 11 types of LSAs however typically there are 6 LSAs that are commonly used and that should be known. These are:

Type 1 – Router

Every OSPF Router will advertise Type 1 Router LSA, these LSAs are used to essentially build the LSDB. Type 1 LSAs are entries that describe the interfaces and neighbours of each and every OSPF router within the same area. In addition, these LSAs ARE NOT forward outside its own area, making the intra-area topology invisible to other areas.

Type 2 – Network

A Type 2 Network LSA, are used over Broadcast OSFP domain with a DR. Network LSAs are always advertised by the DR and is used to identify all the routers (BDR and DRothers) across the multi-access segment. As with Type 1 LSAs, Network LSAs ARE NOT advertised outside of its own area, making the intra-area topology invisible to other areas.

Type 3 – Summary

Summary LSAs are the prefixes that are learnt from Type 1 and 2 LSAs and advertised by an ABR into other areas. ABRs DO NOT forward Type 1 and 2 LSAs to other areas, any Network and/or Router LSAs are received by an ABR, it will be converted into Type 3 LSA with Type 1 and 2 information referenced within. If an ABR receives a Type 3 LSA from a Backbone router, it will regenerate a new Type 3 LSA and list itself as the advertising router and forward the new Summary LSA to non-backbone area. This is how inter-area traffic is process via ABR.

Type 5 – External

An External Type 5 LSA are flooded throughout an OSPF domain when route(s) from another routing protocol is Redistributed via an ASBR. These LSAs are not associated to any area and are flooded unchanged to all areas, with the expectation to Stub and Not-So-Stubby Areas.

Type 4 – Autonomous System Boundary Router (ASBR) Summary

When a Type 5 LSAs is flooded to all areas, the next-hop information may not be available to other areas because the route(s) would have been redistributed from another routing protocol. To solve this ABR will flood the Router ID of the originating ASBR in a Type 4 ASBR Summary LSA. The link-state ID is the router ID of the described ASBR for type 4 LSAs. Essentially, any routes that are redistributed into OSPF, when, the first ABR receives the Type 5 LSA, it will generate and flood a Type 4 LSA.

Type 7 – Not So Stubby Area (NSSA) External

Routers in a Not-so-stubby-area (NSSA) do not receive external LSAs from Area Border Routers, but are allowed to send external redistributed routes to other areas. As ABR DO NOT advertise Type 7 LSAs outside of their local. The ABR will covert the Type 7 LSA into a Type 5 LSA and flood the Type 5 LSA across the OSPF domain, as normal.

In addition to the LSA types above, the other 6 LSA types that are within OSPF are:

  • Type 6 – Multicast Extension LSA
  • Type 8 – OSPFv2 External Attributes LSA, OSPFv3 Link-Local Only LSA
  • Type 9 – OSPFv2 Opaque LSA, OSPFv3 Intra-Area Prefix LSA
  • Type 10 – Opaque LSA
  • Type 11 – Autonomous System Opaque LSA

Types 9 – 11 are defined in RFC5250 and RFC2370. They are typically used as MPLS Traffic Engineering OSPF Extension. I personally, haven’t looked into as of yet however will update once I have done more reading into them.

Area Types

OSPF defines several special area types:

Backbone

As described earlier, the Backbone Area also know as Area 0, this is the most important area in OSPF and there always has to be a Backbone Area. The Backbone Area MUST connect to all areas, as non-backbone area have to use Area 0 as transit area to communicate to other non-backbone areas. This is because the Backbone has all the routing information inject into it and advertises them out. This design is important to prevent routing loops.

Stub Area

A Stub Area DOES NOT allow External Routes to be advertised within the area. This means when an ABR to a Stub Area receives a Type 5 (External) and Type 4 (ASBR Summary) LSAs, the ABR will generate a default route for the area as Type 3 Summary LSA.

Not So Stubby Area (NSSA)

A Not So Stubby Area are similar to Stub Areas as they DO NOT allow Type 5 External however unlike Stub Areas, Not So Stubby Areas DO redistributed external routes via an ASBR into the area. As described above when route is redistributed into the NSSA, a Type 7 NSSA External LSA is flooded throughout the area and once an ABR receives the Type 7 LSA, it is converted into a Type 5 LSA and flooded into other areas. It is important to add, by default the NSSA does not advertise a default route automatically when Type 5 or Type 7 LSAs are blocked by an ABR.

Totally Stubby Area (TSA)

A Totally Stubby Area DOES NOT allow any Inter-Area or External Routes to advertised with the area. Essentially, if a Type 3 Summary or Type 5 External LSA, by the ABR, it will generate default route and inject it to the area. Totally Stubby Areas only allow Intra-Area and Default Routes within the area. The only way for traffic to get routed outside of the area is a default route, which is the only Type-3 LSA, advertised into the area.

Totally Not So Stubby Area (TNSSA)

Totally Not So Stubby Areas DOES NOT permit Type 3 Summary, Type 4 ASBR and Type 5 External LSAs being received into the area. However just like a NSSA, it allows redistributed external routes into the area via an ASBR. Just like NSSA when route is redistributed into the NSSA, a Type 7 NSSA External LSA is flooded throughout the area and once an ABR receives the Type 7 LSA, it is converted into a Type 5 LSA and flooded into other areas, but unlike a NSSA when TNSSA ABR receives a Type 3 LSA from the backbone, it will automatically generate a default route and inject into the area.

Share this:
Share

Configuring IPv4 DHCP Juniper SRX

Reading Time: 1 minute

After configuring a Dual Stacked DHCP server and DHCPv6 on Juniper SRX, it’s only right that I did something on Configuring DCHPv4 on a Juniper SRX.

This wont be a long or detailed post, as the configuration is very much the same as my previous post on how to configure DHCPv6 on a SRX, and I’ve went thought quite a lot before about how DHCP works etc.

First, under the system services dhcp-local-server stanza, you will need to create group and set a physical or logical interface that will have DHCP enabled

[email protected]# show system services dhcp-local-server    
group dhcpv4-group {
    interface vlan.3407;
}

Next, under the access address-assignment stanza, you will need to set the network, the DHCP range and set the IP address that the router will be using within the DCHP pool. The propagate-settings will take configuration from the client DHCP on vlan.3407, if not otherwise specified, most importantly name-server which changes from ISP to ISP and is very important otherwise name resolutions on the LAN won’t work.

[email protected]# show access   
address-assignment {
    pool v4 {
        family inet {
            network 172.31.106.16/29;
            range v4-range {
                low 172.31.106.18;
                high 172.31.106.22;
            }
            dhcp-attributes {
                router {
                    172.31.106.17;
                }
                propagate-settings vlan.3407;
            }
        }
    }
}

This will be all configuration needed to have DHCPv4 on Juniper SRX220. For troubleshooting DHCP you will be able to use the commands below:

[email protected]> show dhcp ? 
Possible completions:
  client               Show DHCP client information
  relay                Show DHCP relay information
  server               Show DHCP server information
  snooping             Show DHCP snooping information
  statistics           Show DHCP service statistics

As I said, this is the quick post :p

I have included the set commands used in my example below:

DHCP Set Commands
set system services dhcp-local-server group dhcpv4-group interface vlan.3407
set access address-assignment pool v4 family inet network 172.31.106.16/29
set access address-assignment pool v4 family inet range v4-range low 172.31.106.18
set access address-assignment pool v4 family inet range v4-range high 172.31.106.22
set access address-assignment pool v4 family inet dhcp-attributes router 172.31.106.17
set access address-assignment pool v4 family inet dhcp-attributes propagate-settings vlan.3407
Share this:
Share

IPv6 and Junos – Stateful Auto-configuration with DHCPv6

Reading Time: 4 minutes

As part of my on-going IPv6 testing, I was asked to look into stateful auto-configuration for devices and host using DHCPv6. I had already looked into Stateless Address Auto configuration and looked into another method of providing stateful auto-configuration using a Dual Stacked DHCP server. This time I’ll be looking into how this could be done using Juniper hardware, to be specific Juniper SRX series routers. If you haven’t used DHCP before my other DHCP related post gave an explanation on what DHCP is and how DHCPv6 communications work slightly different to DHCPv4. With that in mind, I won’t be going over what DHCP is again, but instead I’ll be going straight into the good stuff!

Lets get cracking 😀

For this test I had simple topology; I used a Juniper SRX220 as the DHCP server and a single ESXi Ubuntu 14.04LTS hosts connected on port ge-0/0/0 as the client.

Firstly, with the SRX, I had to enabled IPv6 flow mode. By default, IPv6 IS NOT enabled. You enable IPv6 flow mode by running the command set security forwarding-options family inet6 mode flow-based, once committed you’ll need to reboot the device for the change to take effect. When the SRX is finished booting you can confirm IPv6 flows will be able to be permitted by using show security flow status:

[email protected]> show security flow status 
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: RR-based
  Flow ipsec performance acceleration: off
  Flow packet ordering
    Ordering mode: Hardware

Now that we know we can actually get stateful IPv6 flows traversing the SRX, we can start with enabling the SRX as a DHCPv6 server.

Under the system services dhcp-local-server stanza, we will need to confirm that we’ll be using DHCPv6 and set the interface(s) that will be requesting addresses. Additionally there are a few optional commands. For my example I’ve set the max limit of DHCP clients to 100 by using the interface-client-limit statement, and by default there are no limits on amount of clients that can request an address.

[email protected]# show system services 
dhcp-local-server {
    dhcpv6 {
        overrides {
            interface-client-limit 100;
        }
        group v6 {
            interface vlan.100;
        }
    }
}

Next, under the access address-assignment stanza is where we’ll set the prefix pool that will be advertised to host, and your IP range. In addition, within this stanza you’re able to set other DHCP details such as lease time, grace period and dns-server under dhcp-attributes. The attributes are optional however they should be looked into and configured according to your own requirements.

[email protected]# show access   
address-assignment {
    pool v6 {
        family inet6 {
            prefix 2001:192:168:1::/64;
            range dhcpv6-range {
                low 2001:192:168:1::200/128;
                high 2001:192:168:1::299/128;
            }
            dhcp-attributes {
                maximum-lease-time 120;
                grace-period 3600;
            }
        }
    }
}

We need to set the SRX so that the router advertises our IPv6 prefix on the correct interface, and in addition, by adding the statement managed-configuration, the router will be both stateful (DHCP) and stateless (SLAAC) address assignments. Finally, in order for the DHCPv6 server to allow DHCPv6 requests, a security policy is needed to enable DHCPv6 traffic.

ProtocolsSecurity Zone
[email protected]# show protocols 
router-advertisement {
    interface vlan.100 {
        managed-configuration;
        prefix 2001:192:168:1::/64;
    }
}
[email protected]# show security zone security-zone internal {
    tcp-rst;
    interfaces {
        vlan.100 {
            host-inbound-traffic {
                system-services {
                    dhcpv6;
                }
            }
        }
    }
}

With SRX configured, we can now check the client side to make sure it’s enabled for DHCP. On the client, we have to set its interface to listening for DHCP packets. For IPv6 we’ll need to set the interface to DHCP under /etc/network/interfaces.

[email protected]:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
{...}
auto eth1
iface eth1 inet dhcp

# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto eth1
iface eth1 inet6 dhcp

Now that we have both the SRX and the client configured, we can bring it all together and run some tests!

Verification Testing

On the client, we’ll request an IP address from the SRX by running dhclient eth1 -6 -v and can confirm that an address has been successful assigned by doing an ifconfig

Requesting an addressifconfig eth1
[email protected]:~$ sudo dhclient eth1 -6 -v 
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT:  | X-- Request address 2001:192:168:1::111.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT:  | X-- Request address 2001:192:168:1::200.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT: Solicit on eth1, interval 1060ms.
RCV: Advertise message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1452250973
RCV:  | X-- t1 - renew  +60
RCV:  | X-- t2 - rebind +96
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::200
RCV:  | | | X-- Preferred lifetime 120.
RCV:  | | | X-- Max lifetime 120.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32 (s: 153, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 2001:192:168:1::200
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth1, interval 930ms.
RCV: Reply message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1452250974
RCV:  | X-- t1 - renew  +60
RCV:  | X-- t2 - rebind +96
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::200
RCV:  | | | X-- Preferred lifetime 120.
RCV:  | | | X-- Max lifetime 120.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
PRC: Bound to lease 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38:31.
[email protected]:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          inet6 addr: 2001:192:168:1::200/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12342 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4052626 (4.0 MB)  TX bytes:3303461 (3.3 MB)

Having confirmed that an IP address from DHCP pool has been assigned on the client, we can now look on SRX to see what has happened there!

Firstly, I checked to see if I could see the session flow from the client to SRX by running show security flow session. As the output below shows, as per RFC3315, DHCPv6 communications are done on UDP ports 546 (clients) and 547 (server/relay) and via link-local addresses.

[email protected]> show security flow session       
Session ID: 1, Policy name: self-traffic-policy/1, Timeout: 1800, Valid
  In: 10.1.0.17/46789 --> 10.1.0.158/22;tcp, If: ge-0/0/7.0, Pkts: 5631, Bytes: 416401
  Out: 10.1.0.158/22 --> 10.1.0.17/46789;tcp, If: .local..0, Pkts: 3109, Bytes: 389005

Session ID: 9, Policy name: self-traffic-policy/1, Timeout: 54, Valid
  In: fe80::120e:7eff:fe4e:2e88/547 --> fe80::20c:29ff:fe4f:26c5/546;udp, If: .local..0, Pkts: 2, Bytes: 288
  Out: fe80::20c:29ff:fe4f:26c5/546 --> fe80::120e:7eff:fe4e:2e88/547;udp, If: vlan.100, Pkts: 0, Bytes: 0
Total sessions: 2

We only get two show commands with a DHCP server, whether it’s v4 or v6, show dhcpv6 server binding and show dhcpv6 server statistics.

  • show dhcpv6 server binding provides details on the address that has been assigned to a client, which including; MAC address, Prefix, Lease time, current state and interface.
  • show dhcpv6 server statistics, as the name suggests, provides figures on sent and receive messages between the server and clients.
DHCPv6 BindingsDHCPv6 Statistics
[email protected]> show dhcpv6 server binding        
Prefix                  Session Id  Expires  State    Interface    Client DUID
2001:192:168:1::200/128 2           74       BOUND    vlan.100     LL_TIME0x1-0x1ddd0462-00:0c:29:4f:26:c5
[email protected]> show dhcpv6 server statistics 
Dhcpv6 Packets dropped:
    Total               0

Messages received:
    DHCPV6_DECLINE             0
    DHCPV6_SOLICIT             1
    DHCPV6_INFORMATION_REQUEST 0
    DHCPV6_RELEASE             0
    DHCPV6_REQUEST             1
    DHCPV6_CONFIRM             0
    DHCPV6_RENEW               0
    DHCPV6_REBIND              0
    DHCPV6_RELAY_FORW          0
    DHCPV6_RELAY_REPL          0

Messages sent:
    DHCPV6_ADVERTISE           1
    DHCPV6_REPLY               1
    DHCPV6_RECONFIGURE         0
    DHCPV6_RELAY_REPL          0

For completeness, I had the client release the assigned address to check the statistics, just to make sure I did see an increment change.

Releasing Assigned AddressDHCPv6 Statistics
[email protected]:~$ sudo dhclient -6 -v -r eth1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
XMT: Forming Release, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Release Address 2001:192:168:1::200
XMT:  V IA_NA appended.
XMT: Release on eth1, interval 1070ms.
RCV: Reply message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
[email protected]> show dhcpv6 server statistics    
Dhcpv6 Packets dropped:
    Total               0

Messages received:
    DHCPV6_DECLINE             0
    DHCPV6_SOLICIT             1
    DHCPV6_INFORMATION_REQUEST 0
    DHCPV6_RELEASE             1
    DHCPV6_REQUEST             1
    DHCPV6_CONFIRM             0
    DHCPV6_RENEW               1
    DHCPV6_REBIND              0
    DHCPV6_RELAY_FORW          0
    DHCPV6_RELAY_REPL          0

Messages sent:
    DHCPV6_ADVERTISE           1
    DHCPV6_REPLY               3
    DHCPV6_RECONFIGURE         0
    DHCPV6_RELAY_REPL          0

And with that a DHCPv6 Server has been configured using a Juniper SRX series router!

I’ve included a useful show command and the set commands that I used in my example below 🙂

Operational CommandsSet Commands
show security flow session
show dhcpv6 server binding
show dhcpv6 server statistics
clear dhcpv6 server binding
clear dhcpv6 server statistics
set security forwarding-options family inet6 mode flow-based

set system services dhcp-local-server dhcpv6 overrides interface-client-limit 200
set system services dhcp-local-server dhcpv6 group v6 interface vlan.100

set protocols router-advertisement interface vlan.100 prefix 2001:192:168:1::/64

set access address-assignment pool v6 family inet6 prefix 2001:192:168:1::/64
set access address-assignment pool v6 family inet6 range dhcpv6-range low 2001:192:168:1::200/128
set access address-assignment pool v6 family inet6 range dhcpv6-range high 2001:192:168:1::299/128
set access address-assignment pool v6 family inet6 dhcp-attributes maximum-lease-time 120
set access address-assignment pool v6 family inet6 dhcp-attributes grace-period 3600

set security zones security-zone internal interfaces vlan.100 host-inbound-traffic system-services dhcpv6

More in-depth detailed information can be found on Juniper’s TechLibrary pages

Share this:
Share

Leaking Routes into a Routing-Instance

Reading Time: 4 minutes

In a previous post I wrote about how I went about configuring a NTP server and setting NTP clients. A few days later, when speaking with my senior, the plan changed slightly and we weren’t configuring our own NTP server using Linux based OS, but get satellite feeds running our own LANTIME Stratum 1 Server o_O! In other words that previous post is now invalid haha!

For now I don’t know if I’ll be involved in that side of the project, I hope I am, but that’s for another day! Back to my actual point, because of the environment we run in our datacentres, our firewalls run with Virtual-Router Routing-Instances. A Virtual Router is similar than Cisco’s VRF concept however, with Juniper’s a Virtual Router is used for non-VPN related applications. So, I was asked to investigate if it was possible for our firewalls to be NTP clients to a NTP server via the master instance and also be able to act as a NTP server to attached clients within a routing-instance.

Note
You can get more detail about Juniper’s Routing-Instance Types on their TechLibrary Routing Instances Overview

Although it sounds a bit of a mouthful, the topology itself is quite straightforward. The diagram below shows the topology I’ll be testing with:

Routing

As the diagram shows, I’ll be using a standalone Juniper SRX220h and two ESXi Ubuntu 14.04LTS servers. The SRX will be a NTP client of the NTP server (km-vm4) via the master inet.0 table. The second client km-vm1 will be located within the Routing-Instance “test” and will be using the SRX220 as its NTP server. Security policies will need to be defined, as the stateful functionalities of the SRX will still be in use. Without creating security between the zones all traffic will be dropped.

Note
The Base configuration used in this topology is below. (I using this SRX for IPv6 testing as well, so ignore the vlan name lol)
Base Config
set interfaces ge-0/0/0 enable
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members internal-v6
set interfaces ge-0/0/1 enable
set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members ntp-server
set interfaces vlan unit 100 family inet address 192.168.1.1/24
set interfaces vlan unit 101 family inet address 192.168.2.1/24

set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match source-address any
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match destination-address any
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match application junos-ntp
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp then permit

set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match source-address any
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match destination-address any
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match application junos-ntp
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp then permit

set security zones security-zone vlan100 interfaces vlan.100 host-inbound-traffic system-services any-service
set security zones security-zone vlan101 interfaces vlan.101 host-inbound-traffic system-services any-service

set routing-instances test instance-type virtual-router
set routing-instances test interface vlan.100

set vlans internal-v6 vlan-id 100
set vlans internal-v6 l3-interface vlan.100
set vlans ntp-server vlan-id 101
set vlans ntp-server l3-interface vlan.101

With this setup, the overall goal of this testing is to see if it’s possible to advertise specific routes from the inet.0 table to another routing table, to allow end to end connectivity between routing instances.

This post will not show/explain how the stateful functionalities of the SRX series firewall works. That will be in another post :p

With all that talk and background out of the way… Let’s get cracking 🙂

With the NTP server already configured, the SRX need to set as an NTP client. This configuration is done under system ntp stanza. We set the remote server, ntp version and preference. In addition, I set two other statements; one is optional and the other had to be set. The statements, boot-server and source-address, Juniper defines these statements as:

  • boot-server: When the router or switch boots, it immediately synchronizes with the boot server even if the NTP process is explicitly disabled or if the time difference between the client and the boot server exceeds the threshold value of 1000 seconds.
  • source-address: This is statement useful for controlling which source address NTP will use to access your network when it is either responding to an NTP client request from your network or when it itself is sending NTP requests to your network.

As described above, and in a nutshell, by adding the source-address this will allow other clients/devices to set an IP address that’s located on the SRX as their remote NTP server. Thus providing a /32 address that can be advertised. For my example the address 192.168.2.1, the gateway address for the ntp server, will be the address used as the source address.

[email protected]# show system ntp 
boot-server 192.168.2.100;
server 192.168.2.100 version 4 prefer;
source-address 192.168.2.1;

We can verify the NTP association by using the command show ntp assocication.

[email protected]# run show ntp associations                      
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.2.100   43.255.190.16    3 -  148  256  377    2.313    0.748   0.063

With NTP verified on the SRX, we have to leak the NTP source address for the SRX 192.168.2.1 from the inet.0 table to the test.inet.0 table. As we can see, when we look at the routing instance’s routing table, we don’t have the route installed into the table:

[email protected]# run show route table test.inet.0      

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

192.168.1.0/24     *[Direct/0] 04:02:28
                    > via vlan.100
192.168.1.1/32     *[Local/0] 06:31:31
                      Local via vlan.100

To get the route installed into the test.inet.0 table, we’ll need to leak the 192.168.2.1/32 route into the test.inet.0 table, and we’ll do this by creating two policy statements. For my example I’ve named them master and instance just for ease!

  • Master: This statement allows all routes from routing instance test to be accepted into the master routing table.
  • Instance: This statement has two terms. Term 1 only allows the exact route 192.168.2.1/32 from the master instance to be accepted. Term 2 denies all other routes from master instance.
[email protected]# show policy-options 
policy-statement master {
    from instance test;
    then accept;
}
policy-statement instance {
    term 1 {
        from {
            instance master;
            route-filter 192.168.2.1/32 exact;
        }
        then accept;
    }
    term 2 {
        then reject;
    }
}

Now we’ll need to import the relevant policy into each instance, under the routing-options stanza for the inet.0 table and routing-instance test routing-options for the test.inet.0 table.

Master Instance Routing-OptionsRouting-Instance Routing-Options
[email protected]# show routing-options 
static {
    route 0.0.0.0/0 {
        next-hop 10.1.0.1;
        no-readvertise;
    }
}
instance-import master;
[email protected]# show routing-instances test routing-options 
instance-import instance;

Having committed the policy statements, when we check both routing tables we can see the 192.168.1.0/24 route have been leaked into the inet.0 table, and that only the 192.168.2.1/32 route has been installed into the test.inet.0 table. All other routes have not been leaked.

inet.0 tabletest.inet.0 table
[email protected]> show route table inet.0 

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


0.0.0.0/0          *[Static/5] 1w2d 09:40:34
                    > to 10.1.0.1 via ge-0/0/7.0
10.1.0.0/24        *[Direct/0] 1w2d 09:40:34
                    > via ge-0/0/7.0
10.1.0.158/32      *[Local/0] 1w2d 09:40:39
                      Local via ge-0/0/7.0
192.168.1.0/24     *[Direct/0] 2d 04:15:32
                    > via vlan.100
192.168.1.1/32     *[Local/0] 2d 04:15:32
                      Local via vlan.100
192.168.2.0/24     *[Direct/0] 2d 07:20:32
                    > via vlan.101
192.168.2.1/32     *[Local/0] 3d 08:44:24
                      Local via vlan.101
[email protected]> show route table test.inet.0   

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

192.168.1.0/24     *[Direct/0] 09:32:22
                    > via vlan.100
192.168.1.1/32     *[Local/0] 12:01:25
                      Local via vlan.100
192.168.2.1/32     *[Local/0] 05:28:32
                      Local via vlan.101

Finally, on the client we’ll need to set a static route so that the host knows if it wants to get the 192.168.2.0/24 subnet it will need to use the gateway 192.168.1.1 via eth1

[email protected]:~$ sudo route add -net 192.168.2.0/24 gw 192.168.1.1 dev eth1
[email protected]:~$ ip route
default via 10.1.0.1 dev eth0 
10.1.0.0/24 dev eth0  proto kernel  scope link  src 10.1.0.137 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.100 
192.168.2.0/24 via 192.168.1.1 dev eth1

Once that route has been installed we can see that the host has now become a NTP client to the SRX by running the command ntpq -p. In addition on the SRX, we can see the flow session between inet.0 and test.inet.0 routing tables.

NTP AssociationSRX flow Session
[email protected]:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.2.1     192.168.2.100    4 u   15   64    3    2.086   -0.094   0.109
[email protected]> show security flow session destination-prefix 192.168.2.1 
Session ID: 21218, Policy name: allow-ntp/4, Timeout: 40, Valid
  In: 192.168.1.100/123 --> 192.168.2.1/123;udp, If: vlan.100, Pkts: 7, Bytes: 532
  Out: 192.168.2.1/123 --> 192.168.1.100/123;udp, If: .local..5, Pkts: 7, Bytes: 532
Total sessions: 1

And with that we’ve been able to route between routing instances! The most important thing that I found whilst do this testing is that you need to remember to add the static route on the host or device that is directly connected to router with the routing-instance. This same setup would work with a switch in between the SRX and end host, just have the static route and you’ll be sorted. In addition to having the right security policies, as they’ll bite you in the bum as well :p

I’ve included the set commands that I used in my example below, if you wanted to give it a try for yourself 🙂

Set Commands
set system ntp boot-server 192.168.2.100
set system ntp server 192.168.2.100 version 4
set system ntp server 192.168.2.100 prefer
set system ntp source-address 192.168.2.1

set routing-options instance-import p1

set policy-options policy-statement p1 from instance test
set policy-options policy-statement p1 then accept

set policy-options policy-statement p2 term 1 from instance master
set policy-options policy-statement p2 term 1 from route-filter 192.168.2.1/32 exact
set policy-options policy-statement p2 term 1 then accept
set policy-options policy-statement p2 term 2 then reject

set routing-instances test routing-options instance-import p2

Reference

Juniper Knowledge Base: NTP over routing-instance on EX-series switches
Juniper TechLibrary: NTP Configuring

Share this:
Share

SNMP Polling over a Routing Instance

Reading Time: 3 minutes

Polling SNMP over a Routing Instance is quite straightforward once you understand the syntax necessary to specify that you want to poll the routing-instance. But when I tried this the first time, I didn’t have a clue why it didn’t work!

For a bit of background, we had a request from another team who’s network we manage, asking if they could SNMP details so they could poll an edge pair of SRX240’s. We use a routing instance to keep the management traffic separate from production traffic, so configured a SMNPv2 community and asked them to test it, but and they said it wasn’t working… BALLS :S

I set this up in the lab for testing; I used a Juniper SRX220 with Routing-Instance that had a Ubuntu 14.04LTS host directly connected to poll SNMP

I had configured SNMPv2 and enabled it to allow the relevant routing-instance to have access under the community stanza and enabled routing instance access under the overall stanza as well, thinking that this would be enough:

[edit]
[email protected]# show snmp 
community test {
    authorization read-only;
    routing-instance test {
        clients {
            192.168.1.0/24;
        }
    }
}
routing-instance-access;

However, when I did a snmpwalk….. I got nothing :/

[email protected]:~$ snmpwalk -v2c -ctest 192.168.1.1
^C

Not Good 🙁

I messed about with the configuration and asked a few colleagues and a senior, but none of them could see the issue. So, as you do when you don’t have a clue…. Time to Google! From my searches managed to find Juniper KB page that explained the different variations of syntax when polling SNMPv1/v2c with Routing Instances

There are 3 variations:

  • community string – which works if the user polls directly from inet.0
  • [email protected] string – which polls information for specific routing instance
  • [email protected] string – which allows polling information about inet.0 only

In essence when I was tried to SNMP poll the SRX with the syntax snmpwalk -v2c -ctest 192.168.1.1, it wasn’t referencing the routing instance because snmpwalk was trying to poll the master instance, which routing-instance had no access to.

For the syntax, I should have been using was snmpwalk -v2c [email protected] 192.168.1.1. By referencing the routing instance I was able to SNMP poll the SRX and all the interfaces that were within the routing-instance:

[email protected]:~$ snmpwalk -v2c [email protected] 192.168.1.1
\iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. srx220h2 internet router, kernel JUNOS 12.1X47-D30.4 #0: 2015-11-13 14:16:02 UTC     [email protected]:/volume/build/junos/12.1/service/12.1X47-D30.4/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel Build date: 2015-11-13 15:4"

SNMPv3 Polling

For SNMPv3 when configuring your user, under snmp v3 access group stanza, the context-prefix HAS to be the same name as the Routing-Instance

[email protected]# show snmp 
v3 {
    usm {
        local-engine {
            user keeran {
                authentication-sha {
                    authentication-key "$9$WS8LdbYgojk.aJDkqmF3Ap01cyevWXNdleZUDjq.hSyKLx-VwoaUbwgJGU.m1RESrvXxdsYohSvLxNY2z3n/p0REylvW1IxN-VY2JGDk5Q/Ct01RUjqfzFAt8XxdYgDikf5FGU69CA0OLx7NdsUjHTFniHmTznCA8Xx7s2aJDmPQjiCt0ORE-VbsYo"; ## SECRET-DATA
                }
                privacy-des {
                    privacy-key "$9$qmz3/CtIhSpu1hcyW8-Vw2JGjHqPTzDj0B1IcSaZGimfQFntpB3nCuOBSy24oZUHPfz6/taZHmfT/9M8LxVw4oGDHq2gfTQF/9uO1hevxNdw24BIclMW-d.Pfz/C1RhleWOBX7N-wsmf5Tz6BIEKWLREyKMLN-.Pf569pu1yrvIRNdws4oQF36/t"; ## SECRET-DATA
                }
            }
        }
    }
    vacm {
        security-to-group {
            security-model usm {
                security-name keeran {
                    group view-all;
                }
            }
        }
        access {                        
            group view-all {
                context-prefix test {
                    security-model usm {
                        security-level privacy {
                            read-view view-all;
                            notify-view view-all;
                        }
                    }
                }
            }
        }
    }
}
view view-all {
    oid .1 include;
}
routing-instance-access;

Then when you run the snmpwalk you’ll need to add the flag -n to specify the context name, which will be the routing-instance. If you’ve used the same authentication and privacy types as me, your syntax should look something like this: snmpwalk -v 3 -u keeran -l authPriv -a SHA -A test1234 -x DES -X test1234 -n test 192.168.1.1

snmpwalk -v 3 -u keeran -l authPriv -a SHA -A test1234 -x DES -X test1234 -n test 192.168.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. srx220h2 internet router, kernel JUNOS 12.1X47-D30.4 #0: 2015-11-13 14:16:02 UTC     [email protected]:/volume/build/junos/12.1/service/12.1X47-D30.4/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel Build date: 2015-11-13 15:4"

This was pretty frustrating as there was no clear reason why it wasn’t working, and something that should have taken a few moments took days! So I’m hoping this will help you so that you don’t end up in a bit of a rage like I was lol

References

Juniper Knowledge Base: SNMP Polling SNMPv1/v2c via Routing Instance
Juniper Knowledge: SNMP Polling SNMPv3 via Routing Instance
Snmpwalk Man Page
snmpwalk -h

Share this:
Share