Things I notice, preparing our minds, and leading our lives.
To get the RPC command for “show version”, pipe output to “| display xml rpc”
lab@aristotle-re0> show version | display xml rpc
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/12.3R2/junos">
<rpc>
<get-software-information>
</get-software-information>
</rpc>
<cli>
<banner></banner>
</cli>
</rpc-reply>
This yields “get-software-information”. Easy!
You can use “show system uptime” to determine the time that the system last booted but if you need to know about how long the system was up prior to the last boot you have to dig a bit deeper.
fluong@re0.mx960-1.eng> show system uptime
Feb 01 11:26:13
Current time: 2013-02-01 11:26:13 EST
System booted: 2013-01-04 10:34:28 EST (4w0d 00:51 ago)
Protocols started: 2013-02-01 11:17:44 EST (00:08:29 ago)
Last configured: 2013-02-01 11:17:45 EST (00:08:28 ago) by root
11:26AM up 28 days, 52 mins, 1 user, load averages: 0.02, 0.15, 0.13
The “messages” log, though handy, is also very noisy. Because of this, we can try to use the “chassisd” log instead and look for the “built by” string, which occurs each time the chassis control process initiates itself.
That line, unfortunately, is on the line after the timestamp, so we need some other nearby log messages to determine the rough time of system startup.
Also important to note is that the “built by” string occurs when you “restart chassis-control”, so we need to inspect those logs to see if a SIGTERM occurred within seconds of chassisd restarting. If it is a few minutes apart, that is probably a reboot. If it is seconds apart, that means someone triggered a process restart.
fluong@re0.mx960-1.eng> show log chassisd | match "(built by|rtsock_init s|sigterm)"
Feb 01 11:28:45
Dec 19 11:14:52 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
Dec 19 11:14:58 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
CHASSISD release 10.4R3.4 built by builder on 2011-03-19 21:10:47 UTC
Dec 19 11:22:37 rtsock_init synchronous socket
Jan 4 10:27:25 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
Jan 4 10:27:31 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
CHASSISD release 11.4R6.5 built by builder on 2012-11-28 21:35:45 UTC
Jan 4 10:35:54 rtsock_init synchronous socket
Feb 1 11:17:31 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
CHASSISD release 11.4R6.5 built by builder on 2012-11-28 21:35:45 UTC
Feb 1 11:17:32 rtsock_init synchronous socket
We can tell from looking at these logs:
When configuring MP-BGP over an ipv4 peering session, you probably already know that you have to enable family inet6 on your interface. But you also have to make sure to configure an ipv4-mapped inet6 address for your interface because your Juniper device will probably be setting the next-hop to that address unless you’re running older code.
Here is an example of config to get you going.
Diagram
R2 Config
set interfaces ge-0/0/0 description “Connection to R1”
set interfaces ge-0/0/0 unit 0 family inet address 172.27.0.2/30
set interfaces ge-0/0/0 unit 0 family inet6 address ::ffff:172.27.0.2/126
set protocols bgp group R1-R2 type external
set protocols bgp group R1-R2 family inet unicast
set protocols bgp group R1-R2 family inet6 unicast
set protocols bgp group R1-R2 peer-as 1
set protocols bgp group R1-R2 neighbor 172.27.0.1
R1 Config
set interfaces ge-0/0/0 description “Connection to R2”
set interfaces ge-0/0/0 unit 0 family inet address 172.27.0.1/30
set interfaces ge-0/0/0 unit 0 family inet6 address ::ffff:172.27.0.1/126
set protocols bgp group R1-R2 type external
set protocols bgp group R1-R2 family inet unicast
set protocols bgp group R1-R2 family inet6 unicast
set protocols bgp group R1-R2 peer-as 2
set protocols bgp group R1-R2 neighbor 172.27.0.2
One Last Note
You may need an extra bit of config to get your router to forward packets addressed to ipv4-mapped-addresses:
set system allow-v4mapped-packets
Older versions of JUNOS used IPv4-Compatible addresses for the next-hop field of a BGP update. This would have been something like “::172.27.0.1”.
If you try to configure IPv4-compatible addresses on your interfaces, you will probably see a log message which looks like this:
Jan 16 13:19:02 mrgarrison rpd[1197]: bgp_nexthop_sanity: peer 172.27.0.1 (External AS 701) next hop ::ffff:172.27.0.1 unexpectedly remote, ignoring routes in this update.
Do yourself a favor and check your logs for sanity messages if it looks like you’re not receiving any IPv6 routes that the other route claims it is advertising.
See also: JNCIE-SP: IPv6 NLRIs over IPv4 BGP Peering When You’re Not Using Mapped Addresses.
General tips
- Get to know the diagram/topology. Mark it up: add notes and draw AS boundaries so that you don’t get your numbers mixed up.
- Read the requirements carefully and, as you are reading, start forming a list of requirements to validate.
- Traceoptions will probably take too long to be useful so if you can use show commands, the messages log, or “monitor traffic…” you are better off.
Getting Established - IBGP
- Check pings from all loopbacks, to all other loopbacks. Remember to specify the loopback address as the source or “set system default-address-selection”.
- Be prepared to troubleshoot the IGP and protocol-independent routing configs.
- For adjacency issues, check the messages log and grep on the host IP.
- Misconfigured authentication may cause problems.
Getting Established - EBGP
- As with IBGP, check pings and look in the messages log for entries matched against the peer address.
- Make sure multihop is configured where needed and supporting static routes are active.
- Prefix limits can make for problems staying established. These are logged in “messages”.
- Look for mismatched AS configurations.
Verifying Policy and Routing
- Hopefully you took good notes on which peers must be preferred over others because that will come in handy now.
- Use “show route receive-protocol bgp <neighbor_addr> all” to identify key routes that you can use to verify that prefixes are received and reachable from your whole network. Make sure you check against the requirements so that you don’t pick a route that is supposed to be filtered.
- Use “show route resolution unresolved” to deal with problems with unresolvable next-hops.
- Use “show route receive-protocol bgp <neighbor_addr> hidden” to verify that the policy is not filtering routes which should be permitted per the requirements.
- Verify that advertisements to customers are as expected:
* Summary Aggregates may need to be advertised, possibly with specific routes suppressed.
* a missing address-family configuration in BGP may mean that you are not advertising IPv6 when you need to. ditto IPv4.