|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
I think I'm allergic to something in it, perhaps the pine nuts. Although the anaphylactic reaction appears to be a mild one (just very annoying, and lasts for a few hours), it's no big loss because I hate the taste of pesto sauce anyway.
Ran into a weird one today…
I've been toying with a spare Juniper M10i in our lab, lately. It has a couple Gigabit Ethernet interfaces, as well as two OC-12 SONET PICs. I assigned each of the SONET interfaces into separate logical routers, along with a couple VLANs off the other Gigabit Ethernet interfaces. Looping them up, I figured I'd try OSPFv3, just for kicks.
At first, the SONET interfaces didn't pass IPv6 traffic at all. PPP is the default encapsulation for these interfaces (it should have worked, since JUNOS supposedly supports RFC 2472?), so I had to change it to frame-relay on both, and enable dce on one of the interfaces.
Next problem: OSPFv3 wasn't working. No neighbors were being formed over the interfaces, but HELLOs were definitely being transmitted and received. Closer inspection revealed that the link-local addresses for each SONET interface were the same. Since both of the connected interfaces are on the same box (as I said before, they're just looped up), and SONET has no unique hardware address like Ethernet, they both borrowed the same EUI-64 from another interface on the box. In this case, the fxp0 management interface. Here's what it looked like:
prox@purell> show interfaces terse
Interface Admin Link Proto Local Remote
[...]
so-0/3/0 up up
so-0/3/0.0 up up inet 10.0.0.1/30
inet6 fd00::1/126
fe80::2a0:a5ff:fe5c:7a33/64
mpls
so-1/3/0 up up
so-1/3/0.0 up up inet 10.0.0.2/30
inet6 fd00::2/126
fe80::2a0:a5ff:fe5c:7a33/64
mpls
[...]
lo0.16385 up up inet
inet6 fe80::2a0:a5ff:fe5c:7a33
[...]
So, question was: how do you change the link-local address on JUNOS?
Answer is: just create a new one! It apparently overrides the generated one. So, I did:
prox@purell> show configuration logical-routers cr0 interfaces so-0/3/0
unit 0 {
dlci 1;
family inet {
address 10.0.0.1/30;
}
family inet6 {
address fd00::1/126;
address fe80::100/64;
}
family mpls;
}
prox@purell> show configuration logical-routers cr1 interfaces so-1/3/0
unit 0 {
dlci 1;
family inet {
address 10.0.0.2/30;
}
family inet6 {
address fd00::2/126;
address fe80::200/64;
}
family mpls;
}
And it works!
prox@purell> show interfaces terse
Interface Admin Link Proto Local Remote
[...]
so-0/3/0 up up
so-0/3/0.0 up up inet 10.0.0.1/30
inet6 fd00::1/126
fe80::100/64
mpls
so-1/3/0 up up
so-1/3/0.0 up up inet 10.0.0.2/30
inet6 fd00::2/126
fe80::200/64
mpls
[...]
prox@purell> show ospf3 neighbor logical-router cr0
ID Interface State Pri Dead
10.0.99.3 fe-1/1/0.200 Full 128 31
Neighbor-address fe80::217:cb00:c872:949e
10.0.99.4 fe-1/1/1.201 Full 128 39
Neighbor-address fe80::217:cb00:ca72:949d
10.0.99.2 so-0/3/0.0 Full 128 39
Neighbor-address fe80::200
So, if you ever needed to do that, now you know :)
I decided to get my Juniper SSG 5 and Quagga to talk IBGP (NOT iBGP; it's not an Apple product) today. As expected, I ran into a couple problems, but eventually succeeded.
Juniper SSG 5 Quagga
/--------------------\ /----------------\
| 10.3.4.21/32 | | 10.3.4.5/32 |
| loopback.1 | | lo:0 |
| | | | | |
\---------|----------/ \-------|--------/
10.3.253.2/29 10.3.253.6/29
ethernet0/0 eth1
| |
\-----------[ switch ]--------/
Both systems run OSPF as the IGP, and reside in the backbone area. Routing between loopback interfaces is in place (both can be PINGed using the correct source interfaces).
The autonomous system number is 65301, a member-AS belonging to a confederation with ID 65003. The entire BGP topology is out of scope for this, so let's just keep it at that, and accept this is plain-old IBGP, just with some confederation statements. The SSG 5 is a route reflector client to Quagga, too.
On the SSG 5, both the loopback.1 and ethernet0/0 interfaces reside in the Trust zone, which is a member of the trust-vr. Here's the BGP configuration on the SSG 5:
e(trust-vr/bgp)-> get config set protocol bgp 65301 set confederation id 65003 set enable unset synchronization set neighbor 10.3.4.5 remote-as 65301 src-interface loopback.1 set neighbor 10.3.4.5 enable set confederation peer 65300 set confederation peer 65302 set confederation peer 65303 set confederation peer 65304 exit set interface ethernet0/0 protocol bgp
Here's the relevant neighbor configuration from Quagga's bgpd:
router bgp 65301 bgp router-id 10.3.4.5 bgp confederation identifier 65003 bgp confederation peers 65300 65302 65303 65304 bgp bestpath as-path confed neighbor IBGP peer-group neighbor IBGP remote-as 65301 neighbor IBGP update-source 10.3.4.5 neighbor IBGP route-reflector-client neighbor IBGP next-hop-self neighbor IBGP soft-reconfiguration inbound neighbor 10.3.4.21 peer-group IBGP neighbor 10.3.4.21 description Connection to e.prolixium.com.
Fairly self-explanatory. I use a peer-group configuration here, since there are some other IBGP neighbors configured.
With the configuration above, it didn't work, simple as that. Some tcpdumps and debugs on both sides gave me a little more insight into what was happening, but not why it was.
Here's a piece of the packet capture (slighty edited to fit on the screen):
15:50:26.172512 IP 10.3.4.5.39533 > 10.3.4.21.179: S 2248654264:2248654264(0) win 5840
15:50:32.172469 IP 10.3.4.5.39533 > 10.3.4.21.179: S 2248654264:2248654264(0) win 5840
15:50:44.172496 IP 10.3.4.5.39533 > 10.3.4.21.179: S 2248654264:2248654264(0) win 5840
15:50:46.655847 IP 10.3.4.21.1065 > 10.3.4.5.179: S 3296298904:3296298904(0) win 8192
15:50:46.656517 IP 10.3.4.5.179 > 10.3.4.21.1065: S 2267892974:2267892974(0) ack 3296298905 win 5840
15:50:46.659102 IP 10.3.4.21.1065 > 10.3.4.5.179: . ack 1 win 8192
15:50:47.190300 IP 10.3.4.21.1065 > 10.3.4.5.179: P 1:42(41) ack 1 win 8192: BGP, length: 41
Open Message (1), length: 41
Version 4, my AS 65301, Holdtime 180s, ID 10.3.4.21
Optional parameters, length: 12
Option Capabilities Advertisement (2), length: 10
Multiprotocol Extensions (1), length: 4
AFI IPv4 (1), SAFI Unicast (1)
15:50:47.190620 IP 10.3.4.5.179 > 10.3.4.21.1065: . ack 42 win 5840
15:50:47.193043 IP 10.3.4.5.179 > 10.3.4.21.1065: P 1:22(21) ack 42 win 5840: BGP, length: 21
Notification Message (3), length: 21, Cease (6), subcode Connection Rejected (5)
15:50:47.193785 IP 10.3.4.5.179 > 10.3.4.21.1065: F 22:22(0) ack 42 win 5840
15:50:47.197039 IP 10.3.4.21.1065 > 10.3.4.5.179: FP 42:63(21) ack 22 win 8192: BGP, length: 21
Notification Message (3), length: 21, Finite State Machine Error (5)
15:50:47.197450 IP 10.3.4.5.179 > 10.3.4.21.1065: R 2267892996:2267892996(0) win 0
15:50:47.197521 IP 10.3.4.21.1065 > 10.3.4.5.179: FP 63:63(0) ack 22 win 8192
15:50:47.197710 IP 10.3.4.5.179 > 10.3.4.21.1065: R 2267892996:2267892996(0) win 0
15:50:47.197759 IP 10.3.4.21.1065 > 10.3.4.5.179: FP 63:63(0) ack 23 win 8192
15:50:47.197899 IP 10.3.4.5.179 > 10.3.4.21.1065: R 2267892997:2267892997(0) win 0
There are a couple problems, there.
First, it doesn't look like Quagga can connect to the loopback.1 interface on the SSG 5. Enabling the bgp protocol on the loopback.1 interface didn't help. Anyway, according to BGP rules in RFC4271 (section 6.8), if both BGP connections were established in parallel, the one initiated with the lower router ID (Quagga, in this case) will be torn down. So, who cares about that connection, I guess (it's still not acting right, but I can live with that).
Secondly, Quagga is immediately rejecting the connection from the SSG 5. Why? Who knows. the debug on Quagga's bgpd sheds absolutely no light on the situation:
2008/01/27 06:26:47 BGP: [Event] BGP connection from host 10.3.4.21 2008/01/27 06:26:47 BGP: [Event] Make dummy peer structure until read Open packet 2008/01/27 06:26:47 BGP: 10.3.4.21 [FSM] TCP_connection_open (Active->OpenSent) 2008/01/27 06:26:47 BGP: 10.3.4.21 passive open 2008/01/27 06:26:47 BGP: 10.3.4.21 went from Active to OpenSent 2008/01/27 06:26:47 BGP: 10.3.4.21 rcv message type 1, length (excl. header) 22 2008/01/27 06:26:47 BGP: 10.3.4.21 rcv OPEN, version 4, remote-as 65301, holdtime 180, id 10.3.4.21 2008/01/27 06:26:47 BGP: 10.3.4.21 peer status is Connect close connection 2008/01/27 06:26:47 BGP: 10.3.4.21 sending NOTIFICATION 6/5 (Cease/Connection Rejected) 0 bytes 2008/01/27 06:26:47 BGP: 10.3.4.21 send message type 3, length (incl. header) 21 2008/01/27 06:26:47 BGP: 10.3.4.21 [Event] Accepting BGP peer delete 2008/01/27 06:26:47 BGP: 10.3.4.21 went from OpenSent to Deleted
That basically tells me that Quagga's bgpd said "I just received an OPEN message, but I guess I didn't like it" or something. Absolutely no information indicating WHY the peer was dumped.
Anyway, back to the tcpdump output, the third (relatively minor) thing I see wrong is that the SSG 5 threw a FSM error after it received the cease (6) message, which instructs the peer to tear down the connection immediately. Both systems then exchange a couple odd-looking TCP RSTs, and give up. The FSM error is clearly a problem with the BGP implementation on ScreenOS. If you receive a cease (6), don't bother sending other messages to the peer!
Since that didn't help too much, here's a little more detail on the OPEN message from the SSG 5:
OPEN Message
Marker: 16 bytes
Length: 41 bytes
Type: OPEN Message (1)
Version: 4
My AS: 65301
Hold time: 180
BGP identifier: 10.3.4.21
Optional parameters length: 12 bytes
Optional parameters
Capabilities Advertisement (12 bytes)
Parameter type: Capabilities (2)
Parameter length: 10 bytes
Multiprotocol extensions capability (6 bytes)
Capability code: Multiprotocol extensions capability (1)
Capability length: 4 bytes
Capability value
Address family identifier: IPv4 (1)
Reserved: 1 byte
Subsequent address family identifier: Unicast (1)
Route refresh capability (2 bytes)
Capability code: Route refresh capability (2)
Capability length: 0 bytes
Route refresh capability (2 bytes)
Capability code: Route refresh capability (128)
Capability length: 0 bytes
Nothing out of the ordinary, there. I compared this to the other OPEN messages on some of my other connections, and it's identical. JUNOS advertises graceful restart (64), but it's not negotiated by Quagga.
I then started changing random knobs in the Quagga configuration, and found one that worked: setting the peer to passive only. This tells bgpd to never initiate connections to the other neighbor, only accept them. Bingo, the next connection from the SSG 5 was accepted, each system sent an OPEN message, and the RIB on the SSG 5 became populated.
Here's the one-liner that made it possible:
neighbor 10.3.4.21 passive
I still think BOTH implementations are somewhat broken. Quagga, definitely, since setting the passive option shouldn't make a difference whether it accepts a connection, or not. ScreenOS, because it won't accept any connections.
It's possible I may need a policy from Trust to Trust, permitting TCP port 179, but that too seems like a bad workaround.
Well, there it is. Probably more information than you wanted.
All of mine expired at 18:00 EDT, today, unfortunately. CACert hasn't been emailing me, lately, and I don't bother writing these things down. Sorry.
Anyway, they're all renewed now.
Nice. The path from dax to cvsup5.freebsd.org. is significantly better over IPv6:
IPv4 PING:
% ping -nc4 cvsup5.freebsd.org. PING oliver.cse.buffalo.edu (128.205.32.21): 56 data bytes 64 bytes from 128.205.32.21: icmp_seq=0 ttl=45 time=41.178 ms 64 bytes from 128.205.32.21: icmp_seq=1 ttl=45 time=40.831 ms 64 bytes from 128.205.32.21: icmp_seq=2 ttl=45 time=41.330 ms 64 bytes from 128.205.32.21: icmp_seq=3 ttl=45 time=42.071 ms
IPv6 PING:
% ping6 -nc4 cvsup5.freebsd.org. PING6(56=40+8+8 bytes) 2001:4830:1200:78::2 --> 2001:468:902:201:209:3dff:fe11:442c 16 bytes from 2001:468:902:201:209:3dff:fe11:442c, icmp_seq=0 hlim=51 time=25.061 ms 16 bytes from 2001:468:902:201:209:3dff:fe11:442c, icmp_seq=1 hlim=51 time=24.957 ms 16 bytes from 2001:468:902:201:209:3dff:fe11:442c, icmp_seq=2 hlim=51 time=25.038 ms 16 bytes from 2001:468:902:201:209:3dff:fe11:442c, icmp_seq=3 hlim=51 time=25.430 ms
This is progress. Even better than my previous post.
RANCID (Really Awesome New Cisco confIg Differ) is a collection of backup scripts for Cisco, Juniper, NetScreen, Force10, etc. routers and firewalls. We used it at work over a year ago, before going with some other shiny-looking commercial application. Back then, the Debian packages weren't all that mature, so we ended up doing a source-based install, which worked, but didn't allow for easy upgrading.
Since a year has passed, and I figured the Debian packages were better, I decided to try it out on my network. Here's a blazing fast howto using the official Debian packages, without any bad hacks:
Simple, just get the required packages:
# apt-get install rancid-core rancid-utils
When asked by debconf if this is a new installation, please answer yes. The rancid user will be created, assigned no shell (why?), and given a home directory of /var/lib/rancid. There should only be two symlinks in that directory:
atlantis:/var/lib/rancid# ls -lah total 32K drwxr-xr-x 6 rancid rancid 4.0K 2008-01-24 00:05 . drwxr-xr-x 35 root root 4.0K 2008-01-23 22:42 .. lrwxrwxrwx 1 root root 19 2008-01-23 22:42 bin -> /usr/lib/rancid/bin lrwxrwxrwx 1 root root 16 2008-01-23 22:42 logs -> ../../log/rancid
That's it, RANCID is installed. Now, you need to configure it.
Let's say you want to backup four devices, 2x Juniper routers, 1x Cisco router, and 1x Juniper firewall (NetScreen). For simplicity, let's also say they contact some central authentication server (e.g. RADIUS) and all share the same credentials. Let's simplify the situation even further, and assume that this set of credentials is given level 15 access from the authentication server, so logging into the Cisco router automatically gives you enable access. Oh yeah, let's also assume that every device accepts SSH logins.
Knowing this, we create a cloginrc file in /var/lib/rancid/.cloginrc. We're going to define our credentials and authentication method in here. The third argument is the devices we want to apply these options to, in our case * is everything:
add autoenable * 1 add user * ranciduser add password * rancidpass add method * ssh
Replace ranciduser and rancidpass with your credentials. The do the following to make RANCID happy, and a little more secure:
# chown rancid:rancid /var/lib/rancid/.cloginrc # chmod 640 /var/lib/rancid/.cloginrc
We'll call the two Juniper routers cesium and chromium, the Cisco router carbon, and the Juniper firewall xenon (I hope your routers are labeled something like cr0.nycmny1, and not random elements from the periodic table). Anyway…
RANCID needs groups for devices, so the three routers will go into the routers group, and the firewall, firewalls. Edit /etc/rancid/rancid.conf, and add this line:
LIST_OF_GROUPS="routers firewalls"
Now, let's tell RANCID to create the CVS (RANCID uses CVS by default) repositories:
sudo -u rancid -H /var/lib/rancid/bin/rancid-cvs
You need to use sudo w/the -H flag, since the rancid user has no shell. It'll spit out a couple messages that will hopefully indicate success.
Now, you need to edit the router.db file for each group. Here's what they should look like:
# cat /var/lib/rancid/firewalls/router.db xenon:netscreen:up # cat /var/lib/rancid/routers/router.db cesium:cisco:up chromium:cisco:up carbon:juniper:up
The file is hostname (or IP):type:status. Let's assume DNS is setup, in this case.
Now, run a test:
# sudo -u rancid -H /usr/bin/rancid-run
Wait a minute or so, and then check the log file for each group. Hopefully it'll look like this:
# cat /var/lib/rancid/logs/routers.20080123.234959 starting: Wed Jan 23 23:49:59 EST 2008 Trying to get all of the configs. All routers sucessfully completed. cvs diff: Diffing . cvs diff: Diffing configs cvs commit: Examining . cvs commit: Examining configs /var/lib/rancid/CVS/routers/configs/chromium,v <-- configs/chromium new revision: 1.2; previous revision: 1.1 /var/lib/rancid/CVS/routers/configs/cesium,v <-- configs/cesium new revision: 1.2; previous revision: 1.1 /var/lib/rancid/CVS/routers/configs/carbon,v <-- configs/carbon new revision: 1.2; previous revision: 1.1
The firewall one should look similar, but only with one device. Great success!
The Debian package comes with a sample crontab in /usr/share/doc/rancid-core/examples/cron.example. It seems appropriate, so you can place its contents into a crontab for the rancid user:
sudo -u rancid -H crontab -e
I assume you have Apache installed. If not, grab apache2-mpm-prefork, or one of the threading models. Then:
% sudo apt-get install cvsweb
According to README.Debian, you'll have to add an alias to your Apache configuration (/etc/apache2/sites-enabled/000-default, if you don't have any other vhosts) to get the icond and stylesheets:
Alias /cvsweb/ /usr/share/cvsweb/
And, if you want to protect your configurations, I suggest either only allowing certain subnets (below) or creating an htdigest:
<LocationMatch "^/cgi-bin/cvsweb"> Order deny,allow Deny from all Allow from 10.22.33.0/24 </LocationMatch>
Put that in 000-default, too.
That's it, you're done!
This is hilarious. However, for an instant I thought seriously about doing the same thing:
Because there are fewer and fewer of us, I must help keep our lineage alive. I am looking for someone to help me do this. I need a woman (obviously) who is willing to raise a child with me in the method of Unix. Our child will be introduced to computers at a young age, and will be setting emacs mode before any other child can even read. I earn a sufficient income to support a family in modest comfort. Other than the fact our child will be bright, text-based and sarcastic, we will otherwise be a normal family. We will even go to Disney World and see Mickey Mouse.
http://www.craigslist.org/about/best/nyc/485967082.html
(Not to nitpick, but he needs two spaces between sentences)
As you've all heard, all CompUSA stores are closing. I passed by one, today, and wasn't overly impressed. 20% off, is that the best they can do?
I got a mousepad. *shrug*
Displaying page 46 of 121 of 965 results
     |
This HTML for this page was generated in 0.007 seconds. |