Thought you guys would like the title. Sorry for the lack of content lately, I’ve been very busy.
Today we’re going to explore the “archive” feature in IOS with a small “archive tutorial”. This was sparked by a recent comment on one of my JUNOS posts. The commenter said that the “archive” command in IOS is the same as “rollback” in JUNOS. They are similar, but “rollback” is there by default where you need to do some tinkering with “archive”. I’ve used it in the past, but never with the intention of mimicking JUNOS’s “rollback”.
Here’s the config:
EDGE(config)#archive EDGE(config-archive)#? Archive configuration commands: default Set a command to its defaults exit Exit from archive configuration mode log Logging commands maximum maximum number of backup copies no Negate a command or set its defaults path path for backups rollback Rollback parameters time-period Period of time in minutes to automatically archive the running-config write-memory Enable automatic backup generation during write memory EDGE(config-archive)#path disk0:config-backup EDGE(config-archive)#max 14 EDGE(config-archive)#write-memory
To enter the config, we simply type “archive” in global config. There are quite a few options, as we can see. First we’ll need to set our path to store the archived configs, this is a 7200, so I’m using disk0 and a simple naming convention. Next we specify how many configs we want to backup, I’m using the maximum on my device, which is 14. Finally we set the “write-memory” command, which tells the router to archive the config anytime we save.
Today we’ll go over another important BGP topic: MED. From Cisco:
“MED is an optional nontransitive attribute. MED is a hint to external neighbors about the preferred path into an autonomous system (AS) that has multiple entry points. The MED is also known as the external metric of a route. A lower MED value is preferred over a higher value.”
So, to summarize, MED is used to influence incoming traffic from a multi-homed neighbor AS.
Here’s our diagram:
In this case we’ll say that the link between PE1 and CE1 is only a T1, while the link between PE2 and CE1 is a DS3. Obviously we will want traffic to use the faster link, the PE2-CE1 DS3.
First we’ll configure our interfaces and basic BGP:
PE1: hostname PE1 ! interface Loopback0 ip address 22.214.171.124 255.255.255.255 ! interface Serial0/0 description To PE2 ip address 10.1.1.2 255.255.255.254 ! interface Serial0/1 description To CE1 bandwidth 1500 ip address 172.16.1.2 255.255.255.254 ! router bgp 5300 no synchronization bgp log-neighbor-changes neighbor 126.96.36.199 remote-as 5300 neighbor 188.8.131.52 update-source Loopback0 neighbor 184.108.40.206 next-hop-self neighbor 172.16.1.3 remote-as 1200 no auto-summary ! ip route 220.127.116.11 255.255.255.255 10.1.1.3 PE2: hostname PE2 ! interface Loopback0 ip address 18.104.22.168 255.255.255.255 ! interface Serial0/0 description To PE1 ip address 10.1.1.3 255.255.255.254 ! interface Serial0/2 description To CE1 bandwidth 45000 ip address 172.16.1.4 255.255.255.254 ! router bgp 5300 no synchronization bgp log-neighbor-changes neighbor 22.214.171.124 remote-as 5300 neighbor 126.96.36.199 update-source Loopback0 neighbor 188.8.131.52 next-hop-self neighbor 172.16.1.5 remote-as 1200 no auto-summary ! ip route 184.108.40.206 255.255.255.255 10.1.1.2 CE1: hostname CE1 ! interface Loopback0 ip address 220.127.116.11 255.255.255.255 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Loopback2 ip address 192.168.2.1 255.255.255.0 ! interface Loopback3 ip address 192.168.3.1 255.255.255.0 ! interface Loopback4 ip address 192.168.4.1 255.255.255.0 ! interface Serial0/1 description To PE1 bandwidth 1500 ip address 172.16.1.3 255.255.255.254 ! interface Serial0/2 description To PE2 bandwidth 45000 ip address 172.16.1.5 255.255.255.254 ! router bgp 1200 no synchronization bgp log-neighbor-changes network 192.168.1.0 network 192.168.2.0 network 192.168.3.0 network 192.168.4.0 neighbor 172.16.1.2 remote-as 5300 neighbor 172.16.1.4 remote-as 5300 no auto-summary
Today’s post is about BGP Communities. Here is an explanation of them from Cisco:
“A community is a group of prefixes that share some common property and can be configured with the BGP community attribute. The BGP Community attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values that specify a community. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers.”
Here is a table listing the Well Known Communities from Cisco:
Just a short article today on BGP Peer Groups. I’ve been using them while practice labbing for the CCIP exams, thought I’d toss up a short post.
BGP Peer Groups “reduce the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group.” (-Cisco.com) They can also greatly reduce administrative overhead. They’re somewhat self-explanatory, you specify a Peer Group for two or more neighbors, then apply config to the group instead of each individual neighbor. We’re going to use my CCIP topology, but we’ll just focus on the iBGP peers:
We see that all of our PE routers are running iBGP and they’re fully meshed. Let’s look at PE1′s config without Peer Groups:
router bgp 6500 neighbor 18.104.22.168 remote-as 6500 neighbor 22.214.171.124 update-source Loopback0 neighbor 126.96.36.199 next-hop-self neighbor 188.8.131.52 remote-as 6500 neighbor 184.108.40.206 update-source Loopback0 neighbor 220.127.116.11 next-hop-self neighbor 18.104.22.168 remote-as 6500 neighbor 22.214.171.124 update-source Loopback0 neighbor 126.96.36.199 next-hop-self
Awhile ago a friend asked me for a write up on IOS Firewall/CBAC. At the time I hadn’t felt like writing about it as I don’t use it much, but I recently had to configure it, so I thought I may as well take a break from Juniper posts and do the article.
The IOS Firewall uses CBAC (Context-Based Access Control) to inspect traffic flows at the upper layers. CBAC will inspect the outgoing traffic while maintaining stateful intformation for each session. It will then open pinholes in the firewall/incoming ACL to allow appropriate traffic back in. Something I forgot to point out, CBAC can be very CPU intensive, your traffic. Keep that in mind before and do some testing before deploying it on your network. Here’s the topology:
We have our router running IOS firewall, its WAN connection is on Fa0/1 out to the internet, and its LAN connection is on Fa0/0, which connects to some servers and workstations. Let’s configure the firewall: