|
|
JUNOS software supports the deployment of point-to-point interfaces that are not assigned IP network numbers. For these links to become functional, they must be associated with the router ID for advertisement to adjacent routers using your IGP. The router will use the system's default address as the source address for packets that originate on an unnumbered link, and the routing process will try to use the default address as the source of the router ID for protocols like BGP and OSPF. It is recommended that you assign a non-Martian address to the router's lo0 interface for use as the default address even though the default address can be obtained from any interface with a valid address. In the event that a usable address is not found on the lo0 interface, the router will use the primary address associated with the system's primary interface as the default address. By default, the system's primary interface will be fxp0 unless the primary keyword is specified under another router interface.
Note | For more information on Martian and non-Martian addresses, refer to Chapter 6, 'EBGP Configuration and Testing.' Additional information on filtering packets due to invalid source or destination address (Martians) can also be found in section 5.3.7 of RFC 1812, 'Requirements for IP Version 4 Routers,' F. Baker (June 1995). |
Figure 2.12 illustrates a typical unnumbered interface application. In this example, packets sent over the unnumbered interface from r3 to r5 will use r3's lo0 address as the packet's source address.
Figure 2.12: Unnumbered interfaces
To configure an unnumbered interface, simply omit the address from the inet protocol family as shown in the following example. Also, make sure that at least one interface, preferably the router's lo0, has an address that does not appear in the router's Martian address table so that the address may be used to source packets sent over the unnumbered link.
[edit interfaces] lab@r3# show so-0/2/0 unit 0 { family inet; } [edit interfaces] lab@r3# show lo0 unit 0 { family inet { address 192.168.0.5/32; } }
![]() |
Juniper Networks M-series and T-series routers come from the factory with a default Martian table that causes common Martian addresses to be hidden. The following command is used to display the default Martian entries for the inet.0 routing table:
lab@router> show route martians table inet.0 inet.0: 0.0.0.0/0 exact -- allowed 0.0.0.0/8 orlonger -- disallowed 127.0.0.0/8 orlonger -- disallowed 128.0.0.0/16 orlonger -- disallowed 191.255.0.0/16 orlonger -- disallowed 192.0.0.0/24 orlonger -- disallowed 223.255.255.0/24 orlonger -- disallowed 240.0.0.0/4 orlonger -- disallowed
![]() |
Unnumbered interfaces are tested and verified in the same way as their numbered counterparts, with the exception that an IGP (or static) route is needed to conduct ping testing due to the source address being 'remote' from the perspective of the peer that is directly attached to the unnumbered link. Also, because the link itself is unnumbered, you will have to ping an address associated with the remote router to generate traffic across the unnumbered link.
Because traceroute will no longer indicate that packets have visited the unnumbered link, you may ask whether a particular unnumbered link is being used for data transport, especially if multiple unnumbered links have been provisioned between a pair of routers. To verify which unnumbered link is being used for a particular destination address, you can inspect the router's forwarding table, or you can force traffic over the unnumbered link of choice using the bypass- routing option on the ping command line to allow the specification of the egress interface for the ICMP packet.
![]() |
JNCIP candidates often make 'silly' mistakes when dealing with the time pressures and stress of a lab-based examination. The fact that JUNOS software will allow you to configure nonexistent interfaces, with no warnings or alarms, means that it is possible to spend a lot of time on an interface configuration, only to later find that the configuration has had no effect because it was applied to the wrong interface. Rather than deleting the bogus configuration and re-creating it under the correct interface, you should consider using the JUNOS software CLI rename feature, which will often save you valuable lab time. Using rename is also an excellent way to correct IP addressing mistakes, because it allows you to correct an address without first having to delete the incorrect address assignment.
The use of rename is demonstrated here, where we determine that the operator has incorrectly configured r4's Frame Relay interface as so-0/2/0.
[edit interfaces] lab@r4# show so-0/2/0 dce; hold-time up 20 down 20; encapsulation frame-relay; lmi { n392dce 2; n393dce 3; lmi-type itu; } sonet-options { fcs 32; path-trace "JNCIP test bed"; } unit 0 { dlci 100; family inet { mtu 1600; address 192.168.0.4/32 { destination 172.16.0.3; } } }
Recognizing the mistake, the operator now saves the day with a quick rename command:
[edit interfaces] lab@r4# rename so-0/2/0 to so-0/1/0
The results of the renaming operation are now confirmed:
lab@r4# show so-0/1/0 dce; hold-time up 20 down 20; encapsulation frame-relay; lmi { n392dce 2; n393dce 3; lmi-type itu; } sonet-options { fcs 32; path-trace "JNCIP test bed"; } unit 0 { dlci 100; family inet { mtu 1600; address 192.168.0.4/32 { destination 172.16.0.3; } } }
![]() |
|
|