myITmicroblog

Network design is not fixed process. Every time when we add or change something in the network, we should analyze if the network is still resilient, as it was in the original design. Let's analyze below scenario: Firewall - Fortigate 5.x Core switch - Nexus 5k NX-OS 7.X  Routing between core and firewalls - static With direct connection between FW01-Core01 and FW02-Core02 we can detect link failure easily. Firewalls here are in HA Active-Passive mode, what means the secondary box doesn't process any traffic. In case of Port1, Port2 or device failure - the secondary takes its role and sends ARP updates to the core switch. The same situation when Core01 or Core02 fails, FW01/02 can notice it and triggers failover. Let's imagine your are tasked to put IDS between core switches and perimeter firewalls, like on the diagram below: What is wrong with this scenario? Let's think if following failure scenarios are backed up: 1) FW01/Port1/Port2 failure -...

sw1# sh port-channel load-balance forwarding-path interface port-channel 5 vlan 330 dst-mac 8c60.4f65.f13c Missing params will be substituted by 0's. Load-balance Algorithm on switch: source-dest-ip crc8_hash: 63   Outgoing port id  Ethernet1/5 Param(s) used to calculate load-balance:         src-interface: None         lu-mc-qnum: 40 sw1# sh port-channel load-balance forwarding-path interface port-channel 5 vlan 830 dst-mac 0050.569b.2cd8 Missing params will be substituted by 0's. Load-balance Algorithm on switch: source-dest-ip crc8_hash: 80   Outgoing port id: Ethernet1/7 Param(s) used to calculate load-balance:         dst-mac:  0050.569b.2cd8         src-mac:  0000.0000.0000 sw1#

Today I review my OSPF notes and I'd like to share below pdf, I think it can be useful to understand what is the impact on the reachability between nodes when we change area type.

This is the second part of 'EIGRP - routing optimalization' series. Before reading this one, please review part 1 availab le here . This is the network and as I said in part 1 I'm going to enable 'stub' feature to see what is the impact and how EIGRP works: R5(config-router)# R5(config-router)#router eigrp 100 R5(config-router)#eigrp stub R5(config-router)# The same configuration I add to R6, R9 and R10. The test I'm going to perform is the same from previous post. I shutdown 10.5.2.0/24 network and I check the query scope. R5(config)#int loop2 R5(config-if)#sh R5(config-if)# R3# *Feb 19 23:47:06.411: DUAL: AS(100) rcvquery: 10.5.2.0/24 via 8.1.7.5 metric 72057594037927935/72057594037927935, RD is 156160 for tid 0 *Feb 19 23:47:06.411: EIGRP-IPv4(100): Find FS for dest 10.5.2.0/24. FD is 156160, RD is 156160 on tid 0 *Feb 19 23:47:06.415: EIGRP-IPv4(100):  8.1.7.5 metric 72057594037927935/72057594037927935 not found Dmin is 72057594037927935 *Feb 1...

Today I would like to test EIGRP optimalization by using different features like summarization or stub to see what are the limitations we should be aware of. We have 4 sites with one access router on every site. There are 5 subnets connected to every access device and every device can see all prefixes:   Below you can see routing table from R1, R3 and R5 as it will be the same logic on rest of them: R1#sh ip route eigrp Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2        ia - IS-IS inter area, * - candidate default, U - ...