Index:


Networking

  • IETF Draft Editing Tips and Tricks.

    This contains a bunch of tips and tricks for editing IETF Drafts, beating XML2RFC into submission, etc… 

    Referencing an I-D

    It is (reference.I-D.<draft name without “draft-” and without version>):
    <?rfc include=’reference.I-D.ietf-dnsop-sutld-ps.xml’?>

    And to reference this reference: I-D.ietf-dnsop-sutld-ps

     

    More information can be found here: https://xml2rfc.tools.ietf.org/

     

     

  • Mode reset a Cisco AP from the command line…

    Often you want to mode reset a Cisco AP, but don’t want to walk over and physically poke it. 

     

    This seems to work (at least in my experience):

    erase /all nvram:
    write default-config
    reload

     

    or, from a script:

    echo -e “erase /all nvram:\ny\nwrite default-config\ny\nreload\n\n” | ssh <ap>

  • Juniper: Connecting to the FEB

    In order to connect directly to the FEB (or CFEB), drop to the shell, su to root and then do:

    vty cfeb

    You can also connect to an FPC directly with:

    vty fpc<number>

    Useful commands from here:

    show nvram

    You may also want to check out Connecting to SSB directly

  • Gamers are weird

    Many years ago I worked for a small Mom-and-Pop type ISP in New York state (I was the only network / technical person there) — it was a very free wheeling place and I built the network by doing whatever made sense at the time.

    One of my “favorite” customers (Joe somebody) was somehow related to the owner of the ISP and was a gamer. This was back in the day when the gaming magazines would give you useful tips like “Type ‘tracert $gameserver’ and make sure that there are less than N hops”.  Joe would call up tech support, me, the owner, etc and complain that there was N+3 hops and most of them were in our network. I spent much time explaining things about packet-loss, latency, etc but couldn’t shake his belief that hop count was the only metric that mattered.

    Finally, one night he called me at home well after midnight (no, I didn’t give him my home phone number, he looked me up in the phonebook!) to complain that his gaming was suffering because it was “too many hops to get out of your network”. I finally snapped and built a static GRE tunnel from the RAS box that he connected to all over the network — it was a thing of beauty, it went through almost every device that we owned and took the most convoluted path I could come up with. “Yay!”, I figured, “now I can demonstrate that latency is more important than hop count” and I went to bed.

    The next morning I get a call from him. He is ecstatic and wildly impressed by how well the network is working for him now and how great his gaming performance is. “Oh well”, I think, “at least he is happy and will leave me alone now”. I don’t document the purpose of this GRE anywhere and after some time forget about it.

    A few months later I am doing some routine cleanup work and stumble across a weird looking tunnel — its bizarre, it goes all over the place and is all kinds of crufty — there are static routes and policy routing and bizarre things being done on the RADIUS server to make sure some user always gets a certain IP… I look in my pile of notes and old configs and then decide to just yank it out.

    That night I get an enraged call (at home again) from Joe *screaming* that the network is all broken again because it is now way too many hops to get out of the network and that people keep shooting him…

    What I learnt from this:

    1: Make sure you document everything (and no, the network isn’t documentation)
    2: Gamers are weird.
    3: Making changes to your network in anger provides short term pleasure but long term pain.

  • Juniper: Using or replacing Compact Flash

    Notes on using and / or replacing compact flash in a Juniper router.

    dd if=/dev/zero of=/dev/rad3 bs=64k
    disklabel -w -r ad3 auto
    newfs /dev/rad3c
    mount /dev/ad3c /mnt
    (then copy files over)
    root@R3%
    root@R3% dd if=/dev/zero of=/dev/rad3 bs=64k
    dd: /dev/rad3: end of device
    1961+0 records in
    1960+0 records out
    128450560 bytes transferred in 127.336640 secs
    (1008748 bytes/sec)
    root@R3% disklabel -w -r ad3 auto
    root@R3% newfs /dev/rad3c
    Warning: 3072 sector(s) in last cylinder unallocated
    /dev/rad3c: 250880 sectors in 62 cylinders of 1tracks, 4096 sectors
    122.5MB in 4 cyl groups (16 c/g, 32.00MB/g, 7616 i/g)
    super-block backups (for fsck -b #) at:
    32, 65568, 131104, 196640
    root@R3% mount /dev/ad3c /mnt
    root@R3% cli show sys stora
    Filesystem Size Used Avail Capacity Mounted on
    /dev/ad0s1a 77M 35M 36M 49% /
    devfs 16K 16K 0B 100% /dev/
    /dev/vn0 13M 13M 0B 100% /packages/mnt/jbase
    /dev/vn1 41M 41M 0B 100% /packages/mnt/jkernel-7.0R2.7
    /dev/vn2 7.4M 7.4M 0B 100% /packages/mnt/jpfe-M10-7.0R2.7
    /dev/vn3 2.1M 2.1M 0B 100% /packages/mnt/jdocs-7.0R2.7
    /dev/vn4 15M 15M 0B 100% /packages/mnt/jroute-7.0R2.7
    /dev/vn5 4.8M 4.8M 0B 100% /packages/mnt/jcrypto-7.0R2.7
    mfs:172 1.5G 6.0K 1.3G 0% /tmp
    /dev/ad0s1e 12M 5.0K 11M 0% /config
    procfs 4.0K 4.0K 0B 100% /proc
    /dev/ad1s1f 9.4G 1.8G 6.8G 21% /var
    /dev/ad3c 119M 1.0K 109M 0% /mnt
    *****

    Here you can see that the pcmcia is labled as /dev/ad3c. To actually view the contents you would need to look at the mount point or ls-l /mnt.

     
  • Using TACACS for enable access

    When Cisco (and many similar) devices need to check if a user is allowed into enable mode they send an authorization request for a specific username.

    This username (and associated password) need to be in the password file as bellow:

    $enab15$:<ENC PASSWD>:1000:499:Exec:/:/bin/false

    where “15” is the authentication level being requested.

  • Gigabit Ethernet (GigE) crossover pinouts

    It is a common misconception that the Gigabit Ethernet spec requires Auto-MDIX capabilities — it doesn’t!

     A (copper) GE cable has all four pairs crossed over: 1-3 2-6 3-1 6-2 4-7 5-8 7-4 8-5 — this is different to 10/100 BaseT which only requires 2 pairs.

    Pin Signal Color Pin Signal Color
    1 BI_DA+ white/green 1 BI_DA+ white/orange
    2 BI_DA- green 2 BI_DA- orange
    3 BI_DB+ white/orange 3 BI_DB+ white/green
    4 BI_DC+ blue 4 BI_DC+ white/brown
    5 BI_DC- white/blue 5 BI_DC- brown
    6 BI_DB- orange 6 BI_DB- green
    7 BI_DD+ white/brown 7 BI_DD+ blue
    8 BI_DD- brown 8 BI_DD- white/blue
  • Juniper: Connecting to the SSB

    To connect directly to the SSB do

    [edit]
    root@router# run start shell pfe network ssb
    SSB platform (200/266Mhz PPC 603e processor, 64MB
    memory, 256KB flash)
    SSB0(router vty)# show syslog messages
    SSB0(router vty)# show nvram
  • Juniper: Using FXP0 as a routed interface

    WARNING — THIS IS ALMOST ALWAYS A BAD IDEA!!!!

    The FXP0 interface (on the front of the routing-engine) is designed to be use for OOB access only and usually does not route. 

    For emergency use you may be able to make if route by doing the following:

    sysctl -w net.pfe.transit_re=1 

    Keep in mind that the packet forwarding is then performed by the routing engine itself (the control plane). This means that:

    • Your CPU will run hot
    • Forwarding will be slow
    • Under load your protocols might not converge
    • Lots of other unhappy things will happen

    Only use this for low speed, emergency use.

  • What happens when a Foundry loses its mind

    At a previous company we had a large number of Foundry Networks layer-3 switches. They participated in our OSPF network and had a really annoying bug. Every now and then one of them would get somewhat confused and would corrupt its OSPF database (there seemed to be some pointer that would end up off by one). It would then cleverly realize that its LSDB was different to everyone else’s and so would flood this corrupt database to all other OSPF speakers. Some vendors would do a better job of sanity checking the LSAs and would ignore the bad LSAs, other vendors would install them — now you have different link state databases on different devices and OSPF becomes unhappy.

    Nov 24 22:23:53.633 EST: %OSPF-4-BADLSAMASK: Bad LSA mask: Type 5, LSID 0.9.32.5 
    Mask 10.160.8.0 from 10.178.255.252 
    NOTE: This route will not be installed in the routing table.
    Nov 26 11:01:32.997 EST: %OSPF-4-BADLSAMASK: Bad LSA mask: Type 5, LSID 0.4.2.3
    Mask 10.2.153.0 from 10.178.255.252 
    NOTE: This route will not be installed in the routing table.
    Nov 27 23:14:00.660 EST: %OSPF-4-BADLSAMASK: Bad LSA mask: Type 5, LSID 0.4.2.3
    Mask 10.2.153.0 from 10.178.255.252 
    NOTE: This route will not be installed in the routing table.

     If you look at the output, you can see that there is some garbage in the LSID field and the bit that should be there is now in the Mask section. I also saw some more extreme version of the same bug, in my favorite example the mask was 115.104.111.119 and further down there was 105.110.116.114 — if you take these as decimal number and look up thier ASCII values we get “show” and “inte” — I wrote a tool to scrape bits from these errors and ended up with a large amount of the CLI help text.