As both of these are on the blueprint, I thought it would help to write a blog post about the differences and how to configure them both.
In the real world however, I would not use either of them. If I wanted to firewall, I would use a dedicated firewall. I can see the benefits here and there of knowing how to actually configure up a quick firewall in IOS though.
CBAC (Context-Based Access Control) is the legacy type of firewall, though it’s perfactly acceptable to use it when you only have 2 interfaces. ZBF (Zone-Based Firewall) is the improved zone-based firewall. I much prefer this way simply because it’s more in line with Juniper firewalls which I work with daily. It may even match ASAs, but I’ve never actually used an ASA so I don’t know.
ZBF actually uses the CBAC engine in the background, but it’s easier to work out what you’re doing when you have multiple interfaces. There is also a fundamental difference with router generated traffic itself.
Let’s start with CBAC. Let’s use a simple topology:
R1 is our border router that is peering with our ISP with BGP. R3 is simply acting as a host in the LAN. We have a simple rule policy:
- Allow TCP and UDP traffic from LAN to the internet and allow return traffic
- Allow pings from externally to come in through R1
I’ve set up a very simple config. R3 has a default route pointing to R1. R2 is advertising a default route to R1 via BGP. R1 is advertising it’s directly connected interface to R2.
R3:
interface FastEthernet0/0 ip address 10.13.13.3 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 10.13.13.1
R1:
interface FastEthernet1/0 ip address 10.13.13.1 255.255.255.0 ! interface FastEthernet1/1 ip address 10.12.12.1 255.255.255.0 ! router bgp 100 network 10.13.13.0 mask 255.255.255.0 neighbor 10.12.12.2 remote-as 200
R2:
interface Loopback1 ip address 4.2.2.1 255.255.255.255 ! interface FastEthernet1/0 ip address 10.12.12.2 255.255.255.0 ! router bgp 200 neighbor 10.12.12.1 remote-as 100 neighbor 10.12.12.1 default-originate
So let’s start with the configuration. We need to allow TCP and UDP out, inspect that traffic, and then allow repsonses back in. We also need to allow ICMP inbound.
R1:
ip inspect name INSPECT tcp ip inspect name INSPECT udp ! interface FastEthernet1/1 ip access-group 101 in ip inspect INSPECT out ! access-list 101 permit icmp any any access-list 101 deny ip any any
As soon as this is configured we have a problem:
*Feb 24 16:43:08.303: %BGP-5-ADJCHANGE: neighbor 10.12.12.2 Down BGP Notification sent *Feb 24 16:43:08.307: %BGP-3-NOTIFICATION: sent to neighbor 10.12.12.2 4/0 (hold time expired) 0 bytes
We have an inspect policy configured on the outbound interface of R1. R1 has a BGP session which goes through that interface, but that is not inspected. With CBAC, router generated traffic is not inspected by default, and hence there is no exception made in the return ACL. CBAC does have the option of specifying router-generated traffic in the inspect rule, but it seems my version here does not support it! So I’ll have to make a manual exception:
access-list 101 permit icmp any any access-list 101 permit tcp any eq bgp any access-list 101 permit tcp any any eq bgp access-list 101 deny ip any any
BGP comes back up. Now let’s initiate a telnet to port 80 from inside the network to R2:
R3#telnet 4.2.2.1 80 Trying 4.2.2.1, 80 ... Open
R1# sh ip inspect sessions Established Sessions Session 689C0CB0 (10.13.13.3:60582)=>(4.2.2.1:80) tcp SIS_OPEN
R1 has inspected the session and allowed the return traffic to come back in. Let’s try and initiate a telnet to port 80 from the ISP:
R2#telnet 10.13.13.3 Trying 10.13.13.3 ... % Destination unreachable; gateway or host down R2#ping 10.13.13.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.13.13.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/69/100 ms
I can’t get to port 80, but I can ping. So everything is working exactly how I wanted it to.
Let’s now kick it up a tiny notch. You’ve decided to make a DMZ where you have a web server.
The problem with CBAC in this scenario is that you now need to have multiple inspection policies from each interface to each other interface. What happens if I get another LAN interface? Or perhaps another DMZ? Or why not an extra ISP interface? CBAC is configured per interface so it quickly get’s out of hand.
With ZBF though everything is configured per zone. At first the ZBF policy looks a bit more complicated, but as soon as you have more than 2 interfaces it makes a LOT more sense.
Let’s remove the ACLs and CBAC config from R1 and then configure R1 with ZBF to match the above requirements. We are also going to add the requirement that the ISP needs to be able to get to port 80 of our web server in the DMZ
ZBF uses the familiar MQC style config, so if you know your QoS it’s not that more complicated.
R1:
class-map type inspect match-all PORT80 match protocol http class-map type inspect match-all ICMP match protocol icmp class-map type inspect match-all UDP match protocol udp class-map type inspect match-all TCP match protocol tcp ! ! policy-map type inspect INSIDE_OUT class type inspect TCP inspect class type inspect UDP inspect class type inspect ICMP pass ! policy-map type inspect OUTISDE_IN class type inspect ICMP pass ! policy-map type inspect OUTISDE_DMZ class type inspect PORT80 inspect police rate 512000 burst 8000 ! zone security INSIDE zone security OUTSIDE zone security DMZ ! zone-pair security OUTSIDE_TO_IN source OUTSIDE destination INSIDE service-policy type inspect OUTISDE_IN zone-pair security INSIDE_TO_OUT source INSIDE destination OUTSIDE service-policy type inspect INSIDE_OUT zone-pair security OUTSIDE_TO_DMZ source OUTSIDE destination DMZ service-policy type inspect OUTISDE_DMZ ! interface FastEthernet1/0 ip address 10.13.13.1 255.255.255.0 zone-member security INSIDE ! interface FastEthernet1/1 ip address 10.12.12.1 255.255.255.0 zone-member security OUTSIDE ! interface FastEthernet2/0 ip address 10.14.14.1 255.255.255.0 zone-member security DMZ
I admit there is a lot of config, but if you break it down it’s not so difficult. We have defined our classes via MQC. The advantage of using MQC is that we can use NBAR to match all sorts of protocols. We then set up our service policies. Again as it’s MQC we can further police traffic directly in ZBF as I have done above.
We then set up our zones, our zone-pairs and match our created service policies into those pairs. Finally we put our interfaces into zones.
Let’s test the end result. Can we ping from LAN to WAN and vice versa:
R3#ping 4.2.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.2.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 220/257/296 ms R2#ping 10.13.13.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.13.13.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/92/128 ms
What about the DMZ? We should not be able to ping, but we should be able to get to port 80:
R2#ping 10.14.14.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.14.14.4, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R2#telnet 10.14.14.4 80 Trying 10.14.14.4, 80 ... Open
Perfect.
You’ll also notice BGP did not go down. When using ZBF, their is a ‘self’ zone created. By default all traffic is allowed to and from this zone, hence no reason to make exceptions for it to work.
The great thing about ZBF is that I can now add a bunch of interfaces to any zone, and those policies take effect without you having to add or change anything.
This is the second run of INE labs 1, 7-11. The first post is here: http://mellowd.co.uk/ccie/?p=1962
This is how I did the second time around.
Lab 1 – difficulty rating 6/10 (59/79)
- 2.1; 5.3; 7.7 and 8.1
Lab 7 – difficult rating 9/10 – (61/79)
- 1.2; 2.3; 2.5; 7.4 and 7.5
Lab 8 – difficult rating 8/10 – (71/79)
- 8.2
Lab 9 – difficulty rating 8/10 (65/79)
- 2.6; 5.3; 6.3 and 8.1
Lab 10 – difficult rating 8/10 (70/79)
- 5.3; 6.2 and 6.6
Lab 11 – difficult rating 9/10 – (55/79)
- 1.3; 2.2; 5.3; 5.4; 6.2; 7.1; 8.1 and 8.3
A lot better the second time around. A few things to note though. Lab 1 is rated as a 6, but I would rate it between 8 and 9. It’s really not that easy compared to other labs. Lab11 is also very difficult. Each and every task forces you to think outside the box to get some crazy thing to work.
Firstly, I’d like to see what I got right the first time round but wrong on the second.
Lab 1
- 2.1 and 5.3
Lab 7
- None
Lab 8
- None
Lab 9
- 2.6 and 8.1
Lab 10
- None
Lab 11
- None
4 tasks failed this time round that I passed on the first. Not good…
So what’s next? Well I don’t want to start memorising the solutions for these labs so I started up lab 12 last night. I’ll go through labs 12 – 16 and then do 1, 7 – 11 again. Then time permitting I’ll do 2 – 6 and then 1, 7-11 again.
I also received my US layout keyboard today. Unfortunately the keyboard used (even in the EU) is US layout and I use a UK layout keyboard. A number of things have moved places (including the all important pipe | key) hence it will be a good idea to get used to the US layout in the 10 weeks leading up to my lab attempt.
In my OSPF database blog entry here: http://mellowd.co.uk/ccie/?p=1999 – I mentioned that Type3, Type5 and Type7 LSAs are not very memory efficient. Each and every prefix needs a separate LSA, while with a Type1, multiple prefixes can be advertised.
So it stands to reason that perhaps Type1 are always better? Anything that reduces memory load in large topologies is good right? While not always…
Consider the following topology:
Granted, this is not a ‘large topology’, but the fundamentals are still the same. R1 and R2 are both OSPF speakers in Area 0 (yellow) – Both are linked to switches. Let’s pretend that each of these routers actually have 5 connections to each switch. Now there is 2 ways we can get these 5 subnets each into OSPF. If we put them in Area 0, but make them passive, they’ll also be part of the Type1 LSA that each router originates. We can also reditribute them into OSPF which will create a seperate Type5 for each subnet. What behaviour can we see for each?
Let’s start by creating 5 subinterfaces on each router, and then running OSPF passive on all of them.
This is the config on R1:
interface FastEthernet0/1 no ip address interface FastEthernet0/1.10 encapsulation dot1Q 10 ip address 10.10.10.10 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.20 encapsulation dot1Q 20 ip address 20.20.20.20 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.30 encapsulation dot1Q 30 ip address 30.30.30.30 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.40 encapsulation dot1Q 40 ip address 40.40.40.40 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.50 encapsulation dot1Q 50 ip address 50.50.50.50 255.255.255.0 ip ospf 1 area 0 ! router ospf 1 log-adjacency-changes passive-interface default no passive-interface FastEthernet0/0
R2:
interface FastEthernet0/1 no ip address interface FastEthernet0/1.10 encapsulation dot1Q 10 ip address 11.11.11.11 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.20 encapsulation dot1Q 20 ip address 21.21.21.21 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.30 encapsulation dot1Q 30 ip address 31.31.31.31 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.40 encapsulation dot1Q 40 ip address 41.41.41.41 255.255.255.0 ip ospf 1 area 0 interface FastEthernet0/1.50 encapsulation dot1Q 50 ip address 51.51.51.51 255.255.255.0 ip ospf 1 area 0 ! router ospf 1 log-adjacency-changes passive-interface default no passive-interface FastEthernet0/0
Let’s have a look at the database on R1:
R1#sh ip ospf database
OSPF Router with ID (10.12.12.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.12.12.1 10.12.12.1 0 0x8000000B 0x0029E7 7
10.12.12.2 10.12.12.2 154 0x8000000B 0x00FE01 7
R1#
Nice and neat. Only 2 Type1 LSAs as expected. If we dig into R2′s Type1 we can see:
R1#sh ip ospf database router 10.12.12.2
OSPF Router with ID (10.12.12.1) (Process ID 1)
Router Link States (Area 0)
LS age: 222
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.12.12.2
Advertising Router: 10.12.12.2
LS Seq Number: 8000000B
Checksum: 0xFE01
Length: 108
Number of Links: 7
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.12.12.1
(Link Data) Router Interface address: 10.12.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.12.12.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 51.51.51.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 41.41.41.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 31.31.31.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 21.21.21.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 11.11.11.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
All of R2′s networks are advertised in this single LSA. Nice and simple.
Let’s remove the interface OSPF config and instead redistribute the fa0/1 subinterfaces into OSPF and see what we get. Let’s first look at the OSPF database:
R1#sh ip ospf database
OSPF Router with ID (10.12.12.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.12.12.1 10.12.12.1 65 0x8000000E 0x00CE83 2
10.12.12.2 10.12.12.2 38 0x8000000E 0x00C28D 2
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.10.10.0 10.12.12.1 64 0x80000001 0x0069F5 0
11.11.11.0 10.12.12.2 37 0x80000001 0x003F1C 0
20.20.20.0 10.12.12.1 64 0x80000001 0x00FF41 0
21.21.21.0 10.12.12.2 37 0x80000001 0x00D567 0
30.30.30.0 10.12.12.1 64 0x80000001 0x00968C 0
31.31.31.0 10.12.12.2 37 0x80000001 0x006CB2 0
40.40.40.0 10.12.12.1 64 0x80000001 0x002DD7 0
41.41.41.0 10.12.12.2 38 0x80000001 0x0003FD 0
50.50.50.0 10.12.12.1 66 0x80000001 0x00C323 0
51.51.51.0 10.12.12.2 38 0x80000001 0x009949 0
A lot more than we had last time. Let’s have a look at the Router LSA and 1 External LSA:
R1#sh ip ospf database router 10.12.12.2
OSPF Router with ID (10.12.12.1) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 84
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.12.12.2
Advertising Router: 10.12.12.2
LS Seq Number: 8000000E
Checksum: 0xC28D
Length: 48
AS Boundary Router
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.12.12.1
(Link Data) Router Interface address: 10.12.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.12.12.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
R1#sh ip ospf database external 51.51.51.0
OSPF Router with ID (10.12.12.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 107
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 51.51.51.0 (External Network Number )
Advertising Router: 10.12.12.2
LS Seq Number: 80000001
Checksum: 0x9949
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
We are seeing exactly what we expected, but it’s just bloated everything a bit. So perhaps it’s better to put external interfaces into OSPF and run them as passive? Well, let’s take a closer look at something else. Let’s keep the Type5 LSA and check the SPF statistics on R2:
R2#sh ip ospf statistics
OSPF Router with ID (10.12.12.2) (Process ID 1)
Area 0: SPF algorithm executed 23 times
At this very moment the SPF algorithm has excecuted 23 times. Let’s shut 2 of R1′s subinterfaces and see what happens in R2.
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int fa0/1.10 R1(config-subif)#shut R1(config-subif)#int fa0/1.20 R1(config-subif)#shut
R2#sh ip ospf statistics
OSPF Router with ID (10.12.12.2) (Process ID 1)
Area 0: SPF algorithm executed 23 times
No change in the SPF calculation. Let’s now move everything back into Type1s again and do the same.
Everything has been changed back, so let’s take a before on R2:
R2#sh ip ospf statistics
OSPF Router with ID (10.12.12.2) (Process ID 1)
Area 0: SPF algorithm executed 31 times
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int fa0/1.10 R1(config-subif)#shut R1(config-subif)#int fa0/1.20 R1(config-subif)#shut
What do we now see on R2?
R2#sh ip ospf statistics
OSPF Router with ID (10.12.12.2) (Process ID 1)
Area 0: SPF algorithm executed 33 times
I removed the same 2 interfaces from OSPF, and this time SPF was run twice, once for each removal. What’s going on here?
If a router originates a Type1 LSA for all of it’s connected interfaces, each time 1 of those interfaces flap, it needs to originate the entire Type1 LSA again showing the removal of the prefix on that interface. Each time a Type1 LSA (and Type2 for that matter) is flooded into an area, all routers in the area need to run their SPF algorithm. A Type5 is inherently external to the OSPF domain, and so OSPF speakers in the area will believe whatever the ABRs and ASBRs tell them. The next-hop to these external routes will be to the ABR and ASBR in the area, of which the SPF algorithm has already been run to find a route to. This is part of OSPF’s DV behaviour when it gets outside the local area.
So now we see advantages and disadvantages to both methods. Type1′s keep the database small and clean, while Type5′s allow SPF to run far less when externally facing interfaces go up and down.
You can tweak OSPF with Incremental OSPF. This allows the OSPF process to only recalculate certain portions of the SPF tree when a Type1 or Type2 is flooded into the area. SPF still needs to be run, but at least in a much more optimised state.
A lot of people troubleshoot OSPF, without ever once looking at the OSPF database and understanding the LSA types. I think this has more to do with the fact that they do not understand it properly and how to actually get information from it.
I hope to demystify it and show what a powerful troubleshooting tool it can be.
OSPFv2 for IPv4 has 7 main LSA types. You’ll probably only have experience with 6 of them as LSA type 6 was for Multicast Extensions which isn’t supported in IOS and a number of other vendors implementations.
I’ll attempt to show database output for Cisco IOS, Juniper JUNOS as well as Brocade/Foundry’s code. I can’t show all the types with Brocade as I don’t have a Brocade lab handy to create them all.
Let’s first have a look at what each OS gives as as viewable database options. Note that I’ve changed my public IPs and DNS names as appropriate.
Cisco:
CISCO#sh ip ospf database ? adv-router Advertising Router link states asbr-summary ASBR summary link states database-summary Summary of database external External link states internal Internal LSA information multicast Multicast Topology network Network link states nssa-external NSSA External link states opaque-area Opaque Area link states opaque-as Opaque AS link states opaque-link Opaque Link-Local link states router Router link states self-originate Self-originated link states summary Network summary link states topology Unicast Topology
Juniper:
darren@JUNOS> show ospf database ? Possible completions: <[Enter]> Execute this command advertising-router Router ID of advertising router area OSPF area ID asbrsummary Summary AS boundary router link-state advertisements brief Display brief output (default) detail Display detailed output extensive Display extensive output external External link-state advertisements instance Name of OSPF instance link-local Link local link-state advertisements logical-system Name of logical system, or 'all' lsa-id Link-state advertisement ID netsummary Summary network link-state advertisements network Network link-state advertisements nssa Not-so-stubby area link-state advertisements opaque-area Opaque area-scope link-state advertisements router Router link-state advertisements summary Display summary output
Brocade:
SSH@BROCADE#show ip ospf database link-state ? advertise Display link state by advertisement asbr Display link state by asbr link extensive Display detailed info of entries in OSPF database link-state-id Display link state by link-state ID network Display link state by network link nssa Display link state by NSSA opaque-area Display link state by opaque area router Display link state by router link router-id Display link state by router ID self-originate Display self-originated links-states sequence-number Display link state by sequence number summary Display link state by summary link
The database allows us to see information in all of the needed LSAs. Hence it is important to also know what each LSA actually does, and what information it’s supposed to contain. We’ll go through each of them and extract the required information from the database itself. Each time you look at the database itself and specify a type, you need to give an argument. That argument will depend on the lsa type.
Type 1 – Router LSA:
The router LSA is the lsa that each router originates. It contains information about the local router, it’s attached links and associated costs of those links, and routers it is adjacent to. This LSA is kept within the local area in which it is originated from. The argument is the router ID (RID) of each router
Cisco:
CISCO#sh ip ospf database router 10.100.0.33
OSPF Router with ID (196.196.196.196) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1611
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.100.0.33
Advertising Router: 10.100.0.33
LS Seq Number: 80001FEB
Checksum: 0x6B0C
Length: 48
Area Border Router
AS Boundary Router
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 196.196.196.196
(Link Data) Router Interface address: 10.100.0.33
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.100.0.32
(Link Data) Network Mask: 255.255.255.252
Number of MTID metrics: 0
TOS 0 Metrics: 1
Juniper:
darren@JUNOS> show ospf database router advertising-router 10.100.0.33 extensive
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.100.0.33 10.100.0.33 0x80001feb 1778 0x22 0x6b0c 48
bits 0x3, link count 2
id 196.196.196.196, data 10.100.0.33, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 10.100.0.32, data 255.255.255.252, Type Stub (3)
Topology count: 0, Default metric: 1
Topology default (ID 0)
Type: PointToPoint, Node ID: 196.196.196.196
Metric: 1, Bidirectional
Aging timer 00:30:22
Installed 00:29:35 ago, expires in 00:30:22, sent 00:29:33 ago
Last changed 10w5d 20:28:57 ago, Change count: 3
Brocade:
SSH@BROCADE#show ip ospf database link-state router 10.100.0.33 Area ID Type LS ID Adv Rtr Seq(Hex) Age Cksum SyncState 0 Rtr 10.100.0.33 10.100.0.33 80001feb 1829 0x6b0c Done LSA Header: options: 0x22, seq-nbr: 0x80001feb, length: 48, flags:0x0300 link id = 196.196.196.196, link data = 10.100.0.33, type = point-to-point(1) tos count = 0, tos0_metric = 1 link id = 10.100.0.32, link data = 255.255.255.252, type = stub(3) tos count = 0, tos0_metric = 1
All of the above pretty much tell us the same thing. The router with the RID of 10.100.0.33 has 2 links in OSPF. 1 is a point-to-point link and the other is a stub link. Pretty simple stuff.
Type 2 – Network LSA:
A network LSA is originated by the DR on the segment. DRs are only required on segment in which there are more than 2 OSPF speakers. OSPF treats ethernet segments as non point-to-point by default, so even if there are only 2 routers on there, there will still be a DR. You can change this behaviour by configuring the links as point-to-point. Type 2′s are local to the area in which they originate. The argument is the IP address of the physical interface on the segment of the DR
Cisco:
CISCO#sh ip ospf database network 10.0.10.6
OSPF Router with ID (248.248.248.248) (Process ID 1)
Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 1196
Options: (No TOS-capability, No DC)
LS Type: Network Links
Link State ID: 10.0.10.6 (address of Designated Router)
Advertising Router: r1.company.com
LS Seq Number: 8000706A
Checksum: 0xDCE8
Length: 32
Network Mask: /30
Attached Router: 196.196.196.196
Attached Router: 248.248.248.248
Juniper:
darren@JUNOS> show ospf database network lsa-id 10.0.10.6 extensive
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Network 10.0.10.6 196.196.196.196 0x8000706a 1374 0x2 0xdce8 32
mask 255.255.255.252
attached router 196.196.196.196
attached router 248.248.248.248
Topology default (ID 0)
Type: Transit, Node ID: 248.248.248.248
Metric: 0, Bidirectional
Type: Transit, Node ID: 196.196.196.196
Metric: 0, Bidirectional
Aging timer 00:37:06
Installed 00:22:50 ago, expires in 00:37:06, sent 00:22:49 ago
Last changed 10w5d 18:09:57 ago, Change count: 1
Brocade:
SSH@BROCADE#show ip ospf database link-state network 10.0.10.6 Area ID Type LS ID Adv Rtr Seq(Hex) Age Cksum SyncState 0 Net 10.0.10.6 196.196.196.196 8000706a 1411 0xdce8 Done LSA Header: options: 0x02, seq-nbr: 0x8000706a, length: 32 NetworkMask: 255.255.255.252 attached router: 196.196.196.196 attached router: 248.248.248.248
All 3 of the above outputs tell us that 10.0.10.6 is originating a type 2 lsa which says on that particular segment there are 2 routers attached.
Type 3 – Network Summary LSA:
Type 3′s are originated by ABRs. The Type3 tells OSPF speakers in 1 area how to reach prefixes in another area, through the advertising ABR. The argument is the network prefix itself.
Cisco:
CISCO#sh ip ospf database summary 1.1.1.0
OSPF Router with ID (248.248.248.248) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 258
Options: (No TOS-capability, No DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.0 (summary Network Number)
Advertising Router: r2.company.com
LS Seq Number: 80000001
Checksum: 0x9D57
Length: 28
Network Mask: /31
TOS: 0 Metric: 1000
Juniper:
darren@JUNOS> show ospf database netsummary lsa-id 1.1.1.0 extensive
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 1.1.1.0 196.196.196.196 0x80000001 314 0x2 0x9d57 28
mask 255.255.255.254
Topology default (ID 0) -> Metric: 1000
Aging timer 00:54:46
Installed 00:05:09 ago, expires in 00:54:46, sent 00:05:09 ago
Last changed 00:05:09 ago, Change count: 1
Brocade:
SSH@BROCADE#show ip ospf database link-state summary 1.1.1.0 Area ID Type LS ID Adv Rtr Seq(Hex) Age Cksum SyncState 0 Summ 1.1.1.0 196.196.196.196 80000001 341 0x9d57 Done LSA Header: options: 0x02, seq-nbr: 0x80000001, length: 28 NetworkMask: 255.255.255.254 TOS 0: metric: 1000
All 3 of the above show me the network address and subnet mask of the network, the ABR who originated the LSA as well as the ABRs cost to the network. Note that a Typ3 LSA can only contain a single network. A new type 3 lsa needs to be generated for each and every network that an ABR is advertising. i.e. not very efficient. A type 3 is flooded to all areas.
Type 4 – ASBR Summary LSA:
Type4′s can be a little bit confusing. When an ASBR advertises an external prefix, the next-hop will be the ASBR’s IP address. OSPF speakers in other areas need to know how to get to this ASBR. A Type4 will be originated by an ABR attatched to the same area an an ASBR, and will have information of how to get to the ASBR. An ABR will also advertise a Type4 from another ABR if the ASBR is 2 areas away and so on. Take a quick look at the image below that I used for the Type7 example. Both R3 and R2 originate Type4′s that R1 and R6 will be able to see:
Cisco:
R6#sh ip ospf database asbr-summary 10.34.34.3
OSPF Router with ID (10.16.16.6) (Process ID 1)
Summary ASB Link States (Area 2)
Routing Bit Set on this LSA
LS age: 415
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 10.34.34.3 (AS Boundary Router address)
Advertising Router: 10.13.13.1
LS Seq Number: 80000001
Checksum: 0xAB1
Length: 28
Network Mask: /0
TOS: 0 Metric: 10
Type 5 – External LSA:
Type5 LSA’s are originated by ASBRs. Each LSA contains information about the external prefix. The argument needed is the prefix itself. Like Type3s, ASBRs need to originate a separate LSA for each and every prefix it needs to advertise.
Cisco:
CISCO#sh ip ospf database external 10.0.2.112
OSPF Router with ID (248.248.248.248) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 1382
Options: (No TOS-capability, No DC)
LS Type: AS External Link
Link State ID: 10.0.2.112 (External Network Number )
Advertising Router: r3.company.com
LS Seq Number: 80004DCD
Checksum: 0x6065
Length: 36
Network Mask: /29
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0
Juniper:
darren@JUNOS> show ospf database external lsa-id 10.0.2.112 extensive
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.0.2.112 196.196.196.196 0x80004dcd 1546 0x2 0x6065 36
mask 255.255.255.248
Topology default (ID 0)
Type: 2, Metric: 1, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:34:13
Installed 00:22:43 ago, expires in 00:34:14, sent 00:22:41 ago
Last changed 19w1d 19:03:40 ago, Change count: 1
Brocade:
SSH@BROCADE#show ip ospf database external-link-state link-state-id 10.0.2.112
Ospf ext link-state by link-state ID 10.0.2.112 are in the following:
Type-5 AS External Link States
Index Age LS ID Router Netmask Metric Flag Fwd Address SyncState
587 1500 10.0.2.112 196.196.196.196 fffffff8 00000001 0000 0.0.0.0 Done
LSA Header: age: 1500, options: 0x02, seq-nbr: 0x80004dcd, length: 36
NetworkMask: 255.255.255.248
TOS 0: metric_type: 2, metric: 1
forwarding_address: 0.0.0.0
external_route_tag: 0
Type 7 – NSSA External LSA:
Type7′s can also be a bit confusing. A Type7 is originated by an ASBR into it’s local areas. It tell other routers in the area about how to get to external prefixes. Like the Type3 and Type5, a separate LSA is needed for each prefix. The argument is the prefix. When a Type7 LSA reaches an ABR, the ABR will convert that Type7 into a Type5 LSA. It’ll also change the forwarding address. But what happens if the ASBR is also the ABR itself? Does it convert itself? Well, let’s lab it up to see. I can only do this on the Cisco as I have that lab. I’ll add Junos output sometime in the future.
Let’s use the following topology:
Area 1 is an NSSA area. Router 4 is redistributing it’s loopback interface (4.4.4.4/32) into area 1.
Cisco:
R2#sh ip ospf database nssa-external 4.4.4.4
OSPF Router with ID (10.24.24.2) (Process ID 1)
Type-7 AS External Link States (Area 1)
LS age: 726
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 4.4.4.4 (External Network Number )
Advertising Router: 10.34.34.4
LS Seq Number: 80000001
Checksum: 0x29CC
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.24.24.4
External Route Tag: 0
The contents of the LSA show us the prefix and mask. It also tells us where to send the packets to. In this case 10.24.24.4.
what about R1 though?
R1#sh ip ospf database nssa-external 4.4.4.4
OSPF Router with ID (10.13.13.1) (Process ID 1)
There is no Type7 for it to see. This is because the ABRs converted that Type7 into a Type5. Let’s check this:
R1#sh ip ospf database nssa-external 4.4.4.4
OSPF Router with ID (10.13.13.1) (Process ID 1)
R1#sh ip ospf database external 4.4.4.4
OSPF Router with ID (10.13.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 899
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 4.4.4.4 (External Network Number )
Advertising Router: 10.34.34.3
LS Seq Number: 80000001
Checksum: 0xC33D
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.24.24.4
External Route Tag: 0
R1 sees this information as a Type5 LSA. But there is a very important change here. Notice the forward address. This is R4′s address. If you look at the Type5 example in the post above, you’ll see that the forward address is 0.0.0.0 – This tells the router that the next-hop will be the ABR that advertised the LSA. This LSA is coming from R3, but it keeps the next-hop to 10.24.24.4 – You can actually change this behaviour if you somehow require it:
R3(config)#router ospf 1
R3(config-router)#area 1 nssa translate type7 suppress-fa
R1#sh ip ospf database external 4.4.4.4
OSPF Router with ID (10.13.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 22
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 4.4.4.4 (External Network Number )
Advertising Router: 10.34.34.3
LS Seq Number: 80000002
Checksum: 0xC07D
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Not only that, but surely both R2 and R3 converting and advertising into the same area is a waste of resource? It certainly is! There is an election that takes place that tells the ABRs which one will actually be doing the translations. Maybe I’ll do a blog post in future detailing this.
RIPv2:
- ip rip triggered is an interface command to only send rip updates when there is a change. Only works on P2P links
- passive interface in RIP only stops the router sending updates out, it’ll still receive updates in from neighbours. If you have configured a static neighbour it’ll send unicast updates even if passive-interface has been configured. i.e. if you want to limit the neighbour relationship out an interface, you can use passive-interface as well as the neighbour command
- ip rip v2-broadcast is an interface command to allow you to broadcast RIPv2 updates out
- Use the no validate update-source interface command if the neighbour is speaking to the router using an IP not on the local subnet (secondary address is an example)
EIGRP:
- k1 = bandwidth
- k2 = load
- k3 = delay
- k4 = reliability
- k5 = MTU
- By default, only bandwidth and delay are used
- K values need to match in EIGRP AS domain in order for neighbours to form
- Many ways to allow EIGRP to use equal or unequal paths. Can use offset-lists to increase metric, change bandwidth/delay, add additional K values into metric, increase K multiplier and so on
- IOS allows up to 16 paths to be used, but only 4 by default. Changed using the maximum-paths eigrp process command
- eigrp stub receive-only tells the local router to receive eigrp routes, but don’t send anything
OSPF:
- FLOOD-WAR means that 2 routers (not directly connected) share the same router-id. If they were directly connected the neighbour relationship would not form
- Router-id’s can change depending on the lab, this is important as virtual-links and certain other filtering mechanisms are configured using the RID. If the RID changes, your configuration needs to change
- Virtual-links are in Area 0, hence if you need to authenticate all Area 0 links, you need to authenticate the virtual-link
- Authentication is configured on the interface, however virtual-link authentication is configured under the ospf process itself using area (x) virtual-link (x.x.x.x) (message-digest-key|authentication-key) (…)
- If you need to configure an interface in area 0, but not allowed to use area 0 command, you can always use area 0.0.0.0 – More info on this 32bit area number here: http://mellowd.co.uk/ccie/?p=910
- Virtual links are on-demand links. Hence if you don’t do authentication on one side, you’ll not notice until packets actually needs to go down the link.
- When router A sends router B an LSA, it includes router B’s cost to the destination. It does NOT include the local shared link. Router A will add the local link cost itself. This is the same as spanning-tree costs
- max-lsa (options) – configured the maximum amount of non self generated lsa’s the local router can have. Can drop peer or warn when lsa amount is breached
- ip ospf flood-reduction – stops an OSPF speaker from updating LSA’s every 30 minutes. If configured you’ll need to do it on all OSPF speakers
- show ip ospf border-routers is a handy command to use when checking costs to border routers (perhaps for load-balancing to external destinations)
- Watch out for strange frame-relay set ups. You may need to have frame-relay maps to certain other spokes, depending on the ospf network type
- OSPF routes are always chosen in the order: O; O IA; E1; E2; N1; and N2 regardless of metric. You can however tell ospf to use different ADs for each of these types with the distance ospf [options] command which is handy for complex redistribution labs
Redistribution:
- distribute-list out on DV protocols will of course affect what DV routes go INTO another protocol
- Use debug ip routing
- Use tags wherever possible
- When redistributing from OSPF into BGP, it will only redistribute internal OSPF routes by default. You need to specify the external routes if you want them redistributed
- When reditributing through a route-map, you can specify in the route-map that certain routes will be E1 and others E2. Can also specify the metric itself
Policy-based routing:
- ip policy route-map will be configured on the interface in which traffic is coming in on
- ip local policy route-map is used for policy routing locally generated traffic by the router
Changing AD:
- router (eigrp|rip|ospf)
- distance (#) x.x.x.x x.x.x.x (ACL)
- RIP – x.x.x.x = advertising neighbours IP address
- EIGRP x.x.x.x = advertising neighbours router-id
- OSPF x.x.x.x = router-id of router originating the LSA into the area
- If you use 0.0.0.0 255.255.255.255 then you’re telling the router not to care WHERE the route came from
Comments