DHCP Snooping and IP Source Guard

This Blog posting will cover DHCP Snooping and IP Source Guard.

The example topology will be using three routers and one switch as shown below:

 Here are the associated configurations for us to start with:

R1hostname R1
interface FastEthernet0/0
 mac-address 0000.0000.0001
 ip dhcp client client-id hex ABCD0123
 ip address dhcp
 duplex auto
 speed auto
 shutdown
end

R2hostname R2
ip dhcp pool R1
   host 10.1.123.1 255.255.255.0
   client-identifier abcd.0123
   lease infinite
!
interface FastEthernet0/0
 mac-address 0000.0000.0002
 ip address 10.1.123.2 255.255.255.0
 duplex auto
 speed auto
 no shutdown
end

R3hostname R3
ip dhcp pool R1
   host 10.1.123.11 255.255.255.0
   client-identifier abcd.0123
   lease infinite
!
interface FastEthernet0/0
 mac-address 0000.0000.0003
 ip address 10.1.123.3 255.255.255.0
 duplex auto
 speed auto
 no shutdown
end


SW1
hostname SW1
vtp mode transparent
vlan 123
 name DHCP
interface range fa1/0/1 - 3
 switchport mode access
 switchport access vlan 123
 spanning-tree portfast
 no shutdown
interface range Fa1/0/4 - 24 , gi1/0/1 - 2
 shutdown



So far R2 and R3 will both be competing to provide R1 with it's IP Address.  R2 is our legitimate DHCP Server and R3 is a rogue.

R2#deb ip dhcp server packet
R3#deb ip dhcp server packet

We have debugs on the DHCP servers turned on and we'll bring our DHCP client online:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config-if)#int fa0/0
R1(config-if)#no shut
R1(config-if)#end
*Mar  1 00:00:53.403: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:00:54.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar  1 00:00:59.539: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.1.12.11, mask 255.255.255.0, hostname R1

We can see that R3 and not R2 was the successful DHCP Server here:

R2#
*Mar  1 04:53:04.454: DHCPD: DHCPDISCOVER received from client abcd.0123 on interface FastEthernet0/0.
*Mar  1 04:53:04.458: DHCPD: Sending DHCPOFFER to client abcd.0123 (10.1.12.1).
*Mar  1 04:53:04.458: DHCPD: broadcasting BOOTREPLY to client 0000.0000.0001.
*Mar  1 04:53:04.482: DHCPD: DHCPREQUEST received from client abcd.0123.
*Mar  1 04:53:04.482: DHCPD: client rejected 10.1.12.1, sent 10.1.12.11.

R3#
*Mar  1 04:52:45.714: DHCPD: DHCPDISCOVER received from client abcd.0123 on interface FastEthernet0/0.
*Mar  1 04:52:45.718: DHCPD: Sending DHCPOFFER to client abcd.0123 (10.1.12.11).
*Mar  1 04:52:45.718: DHCPD: broadcasting BOOTREPLY to client 0000.0000.0001.
*Mar  1 04:52:45.742: DHCPD: DHCPREQUEST received from client abcd.0123.
*Mar  1 04:52:45.742: DHCPD: No default domain to append - abort update
*Mar  1 04:52:45.742: DHCPD: Sending DHCPACK to client abcd.0123 (10.1.12.11).
*Mar  1 04:52:45.742: DHCPD: broadcasting BOOTREPLY to client 0000.0000.0001.


Okay, the use of DHCP snooping can help here if we activate the feature and tell the switch who is trusted:

R1#release dhcp fa0/0
R1#sh ip int bri | exc unassigned
Interface                  IP-Address      OK? Method Status                Protocol

R3#
*Mar  1 00:24:22.639: DHCPD: DHCPRELEASE message received from client abcd.0123 (10.1.123.11).
*Mar  1 00:24:22.643: DHCPD: Finding a relay for client abcd.0123 on interface FastEthernet0/0.
*Mar  1 00:24:24.623: DHCPD: DHCPRELEASE message received from client abcd.0123 (10.1.123.11).
*Mar  1 00:24:24.631: DHCPD: Finding a relay for client abcd.0123 on interface FastEthernet0/0

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#ip dhcp snooping
SW1(config)#ip dhcp snooping vlan 123
SW1(config)#int fa1/0/2
SW1(config-if)#ip dhcp snooping trust
SW1(config-if)#end
SW1#
01:03:36: %SYS-5-CONFIG_I: Configured from console by console
 
SW1#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
123
DHCP snooping is operational on following VLANs:
123
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled
   circuit-id format: vlan-mod-port
    remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
FastEthernet1/0/2            yes         unlimited

So let's see if this now works so only R2's DHCP server is allowed by the switch

SW1#deb ip dhcp snooping 0.0.1
R2#deb ip dhcp server packet
R3#deb ip dhcp server packet

R1#renew dhcp fa0/0
Not in Bound state.

SW1#
*Mar  1 05:48:08.220: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Fa1/0/1, MAC da: ffff.ffff.ffff, MAC sa: 0000.0000.0001, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.0000.0001
*Mar  1 05:48:08.220: DHCP_SNOOPING: add relay information option.
*Mar  1 05:48:08.220: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x3 0x2 0x8 0x0 0x6 0x0 0x1A 0x6C 0xCC 0x73 0x80
*Mar  1 05:48:08.220: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (123)
R2#
*Mar  1 00:29:16.827: DHCPD: inconsistent relay information.
*Mar  1 00:29:16.827: DHCPD: relay information option exists, but giaddr is zero.



This time R3 didn't even receive the DHCP discover packet, however R2 is having a problem with the DHCP options inserted by the Switch - specificy the DHCP relay information, which we can fix in two ways:

Option 1 - tell the DHCP server not to get upset about the relay options

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip dhcp relay information trust-all
R2(config)#end

R1#renew dhcp fa0/0
*Mar  1 00:36:33.939: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.1.123.1, mask 255.255.255.0, hostname R1

R2#
*Mar  1 00:34:28.011: DHCPD: DHCPDISCOVER received from client abcd.0123 on interface FastEthernet0/1.
*Mar  1 00:34:28.015: DHCPD: Sending DHCPOFFER to client abcd.0123 (10.1.123.1).
*Mar  1 00:34:28.015: DHCPD: broadcasting BOOTREPLY to client 0000.0000.0001.
*Mar  1 00:34:28.639: DHCPD: DHCPREQUEST received from client abcd.0123.
*Mar  1 00:34:28.643: DHCPD: No default domain to append - abort update
*Mar  1 00:34:28.647: DHCPD: Sending DHCPACK to client abcd.0123 (10.1.123.1).
*Mar  1 00:34:28.647: DHCPD: broadcasting BOOTREPLY to client 0000.0000.0001.

SW1#
01:11:15: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Fa1/0/1, MAC da: ffff.ffff.ffff, MAC sa: 0000.0000.0001, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.0000.0001
01:11:15: DHCP_SNOOPING: add relay information option.
01:11:15: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x15 0x2 0x8 0x0 0x6 0x0 0x1A 0xE3 0x65 0xA0 0x80
01:11:15: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (123)
01:11:15: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Fa1/0/2, MAC da: ffff.ffff.ffff, MAC sa: 0000.0000.0003, IP da: 255.255.255.255, IP sa: 10.1.123.2, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 10.1.123.1, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.0000.0001
01:11:15: DHCP_SNOOPING: binary dump of option 82, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x15 0x2 0x8 0x0 0x6 0x0 0x1A 0xE3 0x65 0xA0 0x80
01:11:15: DHCP_SNOOPING: binary dump of extracted circuit id, length: 8 data:
0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x15
01:11:15: DHCP_SNOOPING: binary dump of extracted remote id, length: 10 data:
0x2 0x8 0x0 0x6 0x0 0x1A 0xE3 0x65 0xA0 0x80
01:11:15: DHCP_SNOOPING: remove relay information option.
01:11:15: DHCP_SNOOPING: direct forward dhcp reply to output port: FastEthernet1/0/1.
01:11:16: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Fa1/0/1, MAC da: ffff.ffff.ffff, MAC sa: 0000.0000.0001, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.0000.0001
01:11:16: DHCP_SNOOPING: add relay information option.
01:11:16: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x15 0x2 0x8 0x0 0x6 0x0 0x1A 0xE3 0x65 0xA0 0x80
01:11:16: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (123)
01:11:16: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface: Fa1/0/2, MAC da: ffff.ffff.ffff, MAC sa: 0000.0000.0003, IP da: 255.255.255.255, IP sa: 10.1.123.2, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 10.1.123.1, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.0000.0001
01:11:16: DHCP_SNOOPING: binary dump of option 82, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x15 0x2 0x8 0x0 0x6 0x0 0x1A 0xE3 0x65 0xA0 0x80
01:11:16: DHCP_SNOOPING: binary dump of extracted circuit id, length: 8 data:
0x1 0x6 0x0 0x4 0x0 0x7B 0x1 0x15
01:11:16: DHCP_SNOOPING: binary dump of extracted remote id, length: 10 data:
0x2 0x8 0x0 0x6 0x0 0x1A 0xE3 0x65 0xA0 0x80
01:11:16: DHCP_SNOOPING: remove relay information option.
01:11:16: DHCP_SNOOPING: direct forward dhcp reply to output port: FastEthernet1/0/1.

R1#release dhcp fa0/0




Option 2 - tell the switch not to add any dhcp options

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#no ip dhcp relay information trust-all
R3(config)#end

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW2(config)#no ip dhcp snooping information option
SW2(config)#end
01:14:49: %SYS-5-CONFIG_I: Configured from console by console
SW2#show ip dhcp snooping | i option
Insertion of option 82 is disabled

So lets check this method works:

R1#renew dhcp fa0/0
R1#
*Mar  1 00:40:31.927: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.1.123.1, mask 255.255.255.0, hostname R1

Okay, so we're protected against DHCP servers that shouldn't be hooked up to our network, what else can we do with this information?  Since the Switch is inspecting the DHCP transactions, it is therefore possible for the switch to know what IP addresses should be associated with particular interfaces, and protect our network against spoofed end devices.

Let's set up our DHCP client (R1) port on the switch to support ip source guard:

R1#release dhcp fa0/0

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#int fa1/0/1
SW1(config-if)#ip verify source
SW1(config-if)#end

SW1#sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       deny-all                            123

Currently Fa1/0/1 is set to deny all incoming ip traffic

R1#renew dhcp fa0/0
*Mar  1 03:17:54.843: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.1.123.1, mask 255.255.255.0, hostname R1

DHCP Snooping has learnt about the end device contected to Fa1/0/1

SW1#sh ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:00:00:00:00:01   10.1.123.1        infinite    dhcp-snooping   123   FastEthernet1/0/1
Total number of bindings: 1
IP source guard has used this information to open a pin hole for the end host IP Address 10.1.123.1

SW1#sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       10.1.123.1                          123

R1#ping 10.1.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.123.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/10/28 ms

If we manually set an IP Address the network should be protected against an end device with an unauthorised IP address allocation:

R1#release dhcp fa0/0
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int fa0/0
R1(config-if)#ip add 10.1.123.100 255.255.255.0
R1(config-if)#do ping 10.1.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.123.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)


SW1#sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       deny-all                            123

Traffic is being dropped by the switch, so let's return R1 to obtaining it's IP address back with DHCP

R1(config-if)#ip address dhcp
R1(config-if)#end
R1#
*Mar  1 03:59:28.379: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 03:59:30.275: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.1.123.1, mask 255.255.255.0, hostname R1

SW1#sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       10.1.123.1                          123

Let's see if we can protect Fa1/0/2

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#int fa1/0/2
SW1(config-if)#ip verify source
SW1(config-if)#do sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       10.1.123.1                          123
Fa1/0/2    ip           inactive-trust-port

Due to the "ip dhcp snooping trust" configuration on Fa1/0/2 - IP Source Guard filters are disabled since the port is already considered trusted.  Let's try protecting a static IP allocated port.


SW1(config-if)#int fa1/0/3
SW1(config-if)#ip verify source
SW1(config-if)#do sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       10.1.12.1                           123
Fa1/0/2    ip           inactive-trust-port
Fa1/0/3    ip           active       deny-all                            123



Without DHCP snooping able to provide the means to feed the IP Source Guard filters, a static configuration is required:

SW1(config-if)#ip source binding 0000.0000.0003 vlan 123 10.1.12.3 interface fa1/0/3
SW1(config)#do sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       10.1.12.1                           12
Fa1/0/2    ip           inactive-trust-port
Fa1/0/3    ip           active       10.1.12.3                           12

R1#ping 10.1.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Although we have specified the MAC address for the binding, the filter is only of the type IP, this suggests that we could change the MAC address on R3 and things should still work:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int fa0/0
R3(config-if)#mac 0.0.33
R3(config-if)#end
*Mar  1 04:29:34.026: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 04:29:36.890: %SYS-5-CONFIG_I: Configured from console by console
R3#
R3#ping 10.1.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

R1#sh arp 10.1.123.3
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.123.3              0   0000.0000.0033  ARPA   FastEthernet0/0

To force IP Source Guard to take into consideration the MAC address as well, we need to enable port security.

SW1(config)#int fa1/0/3
SW1(config-if)#switchport port-security maximum 2
SW1(config-if)#switchport port-security violation shutdown
SW1(config-if)#switchport port-security mac-address sticky
SW1(config-if)#switchport port-security
SW1(config-if)#ip verify source port-security
SW1(config-if)#do sh ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
---------  -----------  -----------  ---------------  -----------------  ----------
Fa1/0/1    ip           active       10.1.12.1                           123
Fa1/0/2    ip           inactive-trust-port
Fa1/0/3    ip-mac       active       10.1.12.3        00:00:00:00:00:03  123

We can see that both the IP and MAC now need to be in alignment

R3#sh int fa0/0 | i bia
  Hardware is Gt96k FE, address is 0000.0000.0033 (bia c202.0497.0000)
R3#ping 10.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Although the IP lines up, the MAC doesn't and therefore fails - let's restore the MAC

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int fa0/0
R3(config-if)#mac 0.0.3
*Mar  1 04:34:06.814: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
R3(config-if)#end
R3#sh int fa0/0 | i bia
  Hardware is Gt96k FE, address is 0000.0000.0003 (bia c202.0497.0000)
R3#ping 10.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/11/32 ms

Cisco Focused Again

After successfully passing 8 written exams and 1 lab exam - I have gained the Alcatel-Lucent 3RP Certification.  This certification is part of the Service Router Certification Program with the top level being the Service Router Architect which to obtain requires another 3 written and another lab exam knocked over and it definitely something I'm interested in pursuing but not on the card until I clear my plate on achieving CCIE status.

Yes, after approximately 4 months of taking a bit of a break from study and then working with other network studies, I'm coming back to work on getting that CCIE.  I haven't set a target as to when I plan to give it another shot but it most likely will be the early second half of this year.

I'm not sure exactly what topics I'll be blogging about yet - however I think I'll do the obvious thing and start hitting the blueprint from the top hitting the tech topics before looking at doing full blown labs.  I certainly haven't forgotten everything but there are some cobwebs that need removing and some speed and agility that needs to come back.

It seems like it's timely for me that recently Ruhann's Routing-Bits has been updated and it seems to be a fairly extensive one at that.

Fortinet Firewall Material

Fortinet make a wide range of security appliances that work in the Unified Threat Management (UTM) environment (a fancy way to describe the consolidation a number of security features that might be standalone in some cases into a single appliance). From what I can tell compared with other vendors out there, the FortiGates are priced fairly competitively and have a pretty good feature sets on models that scale from a small home office to a Telco's Central Office.  To be perfectly honest, the most important things to me is their portfolio is less about the firewall itself assuming that the top contenders are within the ball park of each other on capability and more about the management environment - specifically the FortiManager appliance which allows you to centrally manage a farm of FortiGates (maybe not such a big deal if you have a handful of these things) in the network and the FortiAnalyzer which provides a much richer level of detailed reporting capability than syslog alone provides.

Although that could be considered a bit of a sales pitch there, it was really just meant to be a quick and dirty introduction to the product lines before the proper posting itself - there's a lot of evaluation criteria that needs to be considered when identifying candidate products and I would strongly recommend you do that before selecting this or any other vendors products - so lets park any further hints of a pitch and make the assumption that you have a need to look after a cluster of these beasts, just like most vendors Fortinet have their own training and certification program.  Recently I attempted and passed the first level examination (Fortinet Certifiied Network Security Administator aka FCNSA).  There are training courses that can help but to be honest just doing the course on its own doesn't appear to touch all of the areas that the exam can hit - so the product documentation is definitely required reading and understanding - particularly the CLI reference guide and the Administation Guide as well as fiddling around with some of the boxes will make a huge difference.

I wasn't going to necessarily blog about this topic at all but during my revision I found a pretty good Network and Security blog that touches some of the topics you may find in the exam as well as general information that may be useful in your day to day operations, so I thought it may be worth spreading the word just that little bit more if there's someone interested in this area.

Taking a break from Junos

Playing around with Junos was a nice diversion and all but now that I have passed the JNCIP-SP exam, unless there's a project that demands it, I'll be giving it a break for the time being.

In the olden days, the JNCIP-M was a lab exam with the JNCIS-M being the roughly the equivalent of the CCIE written but recognised as a certification in of itself.  The JNCIE-M was the pinnacle of the M/T series track with another lab exam in of itself.  With the new SP track to only the JNCIE-SP exam has a hands on lab component which meant that when it came time to renewing my JNCIS-M I could either go for the JNCIS-SP or upgrade to the JNCIP-SP (and I chose the latter)

I'm not quite back on the CCIE train yet - through work I have been exposed to Fortinet firewalls and have a Fortinet certification exam (FCNSA) coming up soon and there's one last Alcatel-Lucent exam (Triple Play Services) to knock over in the next month or so and then it's diving back into IOS. 

I'm not sure if I feel like blogging about those topics at the moment, so it may be quiet here until the end of April...

So I still like playing with routers, just not IOS routers right now...

Junos Incongruent Unicast and Multicast routing

Continuing the break from IOS for the time being, this post is covering Multicast on Junos.  Specifically I am playing around with Olive's which do not seem to support multicast on ethernet interfaces directly, however GRE tunnels support it fine.


This is the unicast topology description we're starting with:

• R1 connects to R2 and R3
• R2 connects to R1 and R3
• R3 connects to R1, R2 and R4
• R4 connects to R3

R1, R2 and R3 are using OSPF as their IGP, while R4 has a static default route pointing to R3 (R3's interface facing R4 is passively added to OSPF)

R1

root@R1> show configuration | display set
set system host-name R1
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.1/24
set interfaces em1 unit 13 vlan-id 13
set interfaces em1 unit 13 family inet address 10.1.13.1/24
set interfaces gre unit 12 tunnel source 10.1.12.1
set interfaces gre unit 12 tunnel destination 10.1.12.2
set interfaces gre unit 12 family inet address 10.11.12.1/24
set interfaces gre unit 13 tunnel source 10.1.13.1
set interfaces gre unit 13 tunnel destination 10.1.13.3
set interfaces gre unit 13 family inet address 10.11.13.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface gre.12
set protocols ospf area 0.0.0.0 interface gre.13

R2

root@R2> show configuration | display set
set system host-name R2
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.2/24
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces gre unit 12 tunnel source 10.1.12.2
set interfaces gre unit 12 tunnel destination 10.1.12.1
set interfaces gre unit 12 family inet address 10.11.12.2/24
set interfaces gre unit 23 tunnel source 10.1.23.2
set interfaces gre unit 23 tunnel destination 10.1.23.3
set interfaces gre unit 23 family inet address 10.11.23.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface gre.12
set protocols ospf area 0.0.0.0 interface gre.23

R3

root@R3> show configuration | display set
set system host-name R3
set interfaces em1 vlan-tagging
set interfaces em1 unit 13 vlan-id 13
set interfaces em1 unit 13 family inet address 10.1.13.3/24
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.3/24
set interfaces gre unit 13 tunnel source 10.1.13.3
set interfaces gre unit 13 tunnel destination 10.1.13.1
set interfaces gre unit 13 family inet address 10.11.13.3/24
set interfaces gre unit 23 tunnel source 10.1.23.3
set interfaces gre unit 23 tunnel destination 10.1.23.2
set interfaces gre unit 23 family inet address 10.11.23.3/24
set interfaces gre unit 34 tunnel source 10.1.34.3
set interfaces gre unit 34 tunnel destination 10.1.34.4
set interfaces gre unit 34 family inet address 10.11.34.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface gre.13
set protocols ospf area 0.0.0.0 interface gre.23
set protocols ospf area 0.0.0.0 interface gre.34 passive

R4

root@R4> show configuration | display set
set system host-name R4
set interfaces em1 vlan-tagging
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.4/24
set interfaces gre unit 34 tunnel source 10.1.34.4
set interfaces gre unit 34 tunnel destination 10.1.34.3
set interfaces gre unit 34 family inet address 10.11.34.4/24
set routing-options static route 0.0.0.0/0 next-hop 10.11.34.3

R4 will be our multicast source in this example, so lets enable PIM-SM on R1/R2/R3

root@R1> configure
Entering configuration mode

[edit]
root@R1# set protocols pim interface lo0.0 mode sparse
root@R1# set protocols pim interface gre.12 mode sparse
root@R1# set protocols pim interface gre.13
root@R1# commit
commit complete

root@R2> configure
Entering configuration mode

[edit]
root@R2# set protocols pim interface lo0.0 mode sparse
root@R2# set protocols pim interface gre.12 mode sparse
root@R2# set protocols pim interface gre.23 mode sparse
root@R2# commit
commit complete

root@R3> configure
Entering configuration mode

[edit]
root@R3# set protocols pim interface lo0.0 mode sparse
root@R3# set protocols pim interface gre.13 mode sparse
root@R3# set protocols pim interface gre.23 mode sparse
root@R3# set protocols pim interface gre.34 mode sparse
root@R3# commit
commit complete

Let's make sure R1/R2/R3 see each other

root@R1# run show pim neighbors
Instance: PIM.master
B = Bidirectional Capable, G = Generation Identifier,
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority

Interface           IP V Mode        Option      Uptime Neighbor addr
gre.12               4 2             HPLG      00:03:28 10.11.12.2
gre.13               4 2             HPLG      00:01:33 10.11.13.3

root@R2# run show pim neighbors
Instance: PIM.master
B = Bidirectional Capable, G = Generation Identifier,
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority

Interface           IP V Mode        Option      Uptime Neighbor addr
gre.12               4 2             HPLG      00:02:47 10.11.12.1
gre.23               4 2             HPLG      00:00:52 10.11.23.3

root@R3# run show pim neighbors
Instance: PIM.master
B = Bidirectional Capable, G = Generation Identifier,
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority

Interface           IP V Mode        Option      Uptime Neighbor addr
gre.13               4 2             HPLG      00:00:57 10.11.13.1
gre.23               4 2             HPLG      00:00:56 10.11.23.2

Fine, so let's make this a PIM-ASM topology with R2 as our RP.  We'll use BSR in this example though we could use Auto-RP (It's not just for Cisco) and static RPs

root@R2# set protocols pim rp bootstrap family inet priority 1

root@R2# commit

root@R1# run show pim bootstrap
Instance: PIM.master

BSR                     Pri Local address           Pri State      Timeout
2.2.2.2                   1 1.1.1.1                   0 InEligible      77
None                      0 (null)                    0                  0

[edit]
root@R1# run show pim rps
Instance: PIM.master
Address family INET

Address family INET6

So we have our BSR sorted, we just need to set up the cRP.  In Junos this is configured as if we were setting a static RP

root@R2# set protocols pim rp local address 2.2.2.2
root@R2# commit
commit complete
root@R2# run show pim rps
Instance: PIM.master
Address family INET
RP address               Type        Holdtime Timeout Groups Group prefixes
2.2.2.2                  bootstrap        150    None      0 224.0.0.0/4
2.2.2.2                  static             0    None      0 224.0.0.0/4

As we can see, we can see R2 is the cRP on R1 through BSR

root@R1# run show pim rps
Instance: PIM.master
Address family INET
RP address               Type        Holdtime Timeout Groups Group prefixes
2.2.2.2                  bootstrap        150     143      0 224.0.0.0/4

Now, setting up a Juniper router to join a multicast group is unfortunately not as straightforward as it is with an IOS based device (ip igmp join-group a.b.c.d) however we can take advantage of SAP and make the Junos device become a SAP listener which is nearly as useful.

root@R1# set protocols sap listen 239.0.0.1
root@R1# commit
commit complete

root@R1# run show pim join
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 224.2.127.254
    Source: *
    RP: 2.2.2.2
    Flags: sparse,rptree,wildcard
    Upstream interface: gre.12

Group: 239.0.0.1
    Source: *
    RP: 2.2.2.2
    Flags: sparse,rptree,wildcard
    Upstream interface: gre.12

Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

When you enable SAP listener, the router joins the group 224.2.127.254 global scope group plus anything elese you specifically request.

R4 will now ping 239.0.0.1, and we should recieve a unicast response to the ping:

root@R4> ping 239.0.0.1 bypass-routing interface gre.34 ttl 5 count 5
PING 239.0.0.1 (239.0.0.1): 56 data bytes
64 bytes from 10.11.13.1: icmp_seq=0 ttl=63 time=6.852 ms
64 bytes from 10.11.13.1: icmp_seq=1 ttl=63 time=2.854 ms
64 bytes from 10.11.13.1: icmp_seq=2 ttl=63 time=3.180 ms
64 bytes from 10.11.13.1: icmp_seq=3 ttl=63 time=2.673 ms
64 bytes from 10.11.13.1: icmp_seq=4 ttl=63 time=2.984 ms

--- 239.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.673/3.709/6.852/1.580 ms

We should be able to see that once R1 identified the source for 239.0.0.1 (10.11.34.4) , it established a SPT to it, which in this case is a different path than the wild card entry

root@R1# run show pim join inet
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 224.2.127.254
    Source: *
    RP: 2.2.2.2
    Flags: sparse,rptree,wildcard
    Upstream interface: gre.12

Group: 239.0.0.1
    Source: *
    RP: 2.2.2.2
    Flags: sparse,rptree,wildcard
    Upstream interface: gre.12

Group: 239.0.0.1
    Source: 10.11.34.4
    Flags: sparse,spt
    Upstream interface: gre.13

To simply demonstrate the value of multicast, lets make R2 and R3 also set up SAP listeners for 239.0.0.1 and then get R4 to ping the multicast address

root@R2# set protocols sap listen 239.0.0.1
root@R2# commit

root@R3# set protocols sap listen 239.0.0.1
root@R3# commit


root@R4> ping 239.0.0.1 bypass-routing interface gre.34 ttl 5 count 5
PING 239.0.0.1 (239.0.0.1): 56 data bytes
64 bytes from 10.11.34.3: icmp_seq=0 ttl=64 time=5.850 ms
64 bytes from 10.11.13.1: icmp_seq=0 ttl=63 time=6.765 ms (DUP!)
64 bytes from 10.11.23.2: icmp_seq=0 ttl=63 time=6.853 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=1 ttl=64 time=2.408 ms
64 bytes from 10.11.13.1: icmp_seq=1 ttl=63 time=3.983 ms (DUP!)
64 bytes from 10.11.23.2: icmp_seq=1 ttl=63 time=4.158 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=2 ttl=64 time=2.443 ms
64 bytes from 10.11.13.1: icmp_seq=2 ttl=63 time=4.377 ms (DUP!)
64 bytes from 10.11.23.2: icmp_seq=2 ttl=63 time=4.767 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=3 ttl=64 time=4.849 ms
64 bytes from 10.11.23.2: icmp_seq=3 ttl=63 time=8.193 ms (DUP!)
64 bytes from 10.11.13.1: icmp_seq=3 ttl=63 time=8.320 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=4 ttl=64 time=2.570 ms

--- 239.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, +8 duplicates, 0% packet loss
round-trip min/avg/max/stddev = 2.408/5.041/8.320/1.958 ms

Okay, this is all pretty straight forward.  Things start to get more complicated when we look at making our multicast topology different (incongruent) to our unicast topology.

If we make the link between R2 and R3 (gre.23) unicast only we are going to have to make some changes to our multicast RPF topology, which up until now is using the unicast (inet.0) table.

First lets disable pim between R2 and R3

root@R2# delete protocols pim interface gre.23
root@R2# commit
commit complete

root@R3# delete protocols pim interface gre.23
root@R3# commit
commit complete



If we recall, R4 (10.11.34.4) is our multicast source and R2 (2.2.2.2) is our RP.

For R3 to reach the RP via multicast, we need to go via R1
For R2 to recieve multicast traffic from R4 we need to go via R1

Right now OSPF will utilise the direct link between R2 and R3, so static multicast routes are what we will use to resolve this. We will use the inet.2 routing table to store our RPF information which will import the unicast routing table (inet.0) but be overriden where necessary.

Firstly we'll crate a rib-group called if-rib that will be used to associate direct and local interface based routes into inet.2 (as we are changing the default behaviour we need to also include importing into inet.0 so we don't break our unicast routing)

[edit]
root@R2# set routing-options rib-groups if-rib import-rib [ inet.0 inet.2 ]
root@R2# set routing-options interface-routes rib-group inet if-rib

then we need to work with OSPF to populate inet.2 with its dynamic routes which is configured under traffic engineering

[edit]
root@R2# set protocols ospf traffic-engineering multicast-rpf-routes
root@R2# set protocols ospf traffic-engineering shortcuts

root@R2# run show route table inet.2 10.11.34.0

inet.2: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.11.34.0/24      *[OSPF/10] 00:29:57, metric 2
                    > via gre.23
 

root@R2# run show multicast rpf 10.11.34.0
Multicast RPF table: inet.0 , 17 entries

10.11.34.0/24
    Protocol: OSPF
    Interface: gre.23
    Neighbor: (null)


Now that we have populated inet.2, we need to get PIM to use it instead of inet.0 for its RPF checks

[edit]
root@R2# set routing-options rib-groups mcast-rib export-rib inet.2
root@R2# set routing-options rib-groups mcast-rib import-rib [ inet.2 inet.0 ]
root@R2# set protocols pim rib-group inet mcast-rib

root@R2# run show multicast rpf 10.11.34.0
Multicast RPF table: inet.2 , 13 entries

10.11.34.0/24
    Protocol: OSPF
    Interface: gre.23
    Neighbor: (null)


Finally we can configure our static-route in inet.2 to override the default next hop used for the RPF check (currently learnt by OSPF)

root@R2# set routing-options rib inet.2 static route 10.11.34.0/24 next-hop 10.11.12.1

root@R2# commit and-quit
commit complete
Exiting configuration mode


root@R2> show route table inet.0 10.11.34.4

inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.11.34.0/24      *[OSPF/10] 00:14:39, metric 2
                    > via gre.23

root@R2> show route table inet.2 10.11.34.4

inet.2: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.11.34.4/32      *[Static/5] 00:04:32
                    > to 10.11.12.1 via gre.12



root@R2> show multicast rpf 10.11.34.0
Multicast RPF table: inet.2 , 13 entries

10.11.34.0/24
    Protocol: Static
    Interface: gre.12
    Neighbor: 10.11.12.1

R2 now uses the interface facing R1 for its RPF check for R4



This is half the battle,  R3 needs to be able to resolve its RPF check for R2, so that the BSR and RP RPF checks pass

root@R3# set routing-options rib-groups if-rib import-rib [ inet.0 inet.2 ]
root@R3# set routing-options interface-routes rib-group inet if-rib
root@R3# set routing-options rib inet.2 static route 2.2.2.2/32 next-hop 10.11.13.1
root@R3# set routing-options rib-groups mcast-rib export-rib inet.2
root@R3# set routing-options rib-groups mcast-rib export-rib inet.2
root@R3# set protocols pim rib-group inet mcast-rib
root@R3# set protocols ospf traffic-engineering multicast-rpf-routes
root@R3# set protocols ospf traffic-engineering shortcuts
root@R3# commit and-quit
commit complete
Exiting configuration mode

root@R3> show route 2.2.2.2

inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2.2.2.2/32         *[OSPF/10] 00:25:51, metric 1
                    > via gre.23

inet.2: 16 destinations, 20 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2.2.2.2/32         *[Static/5] 00:25:51
                    > to 10.11.13.1 via gre.13
                    [OSPF/10] 00:25:51, metric 1
                    > via gre.23


root@R3> show multicast rpf 2.2.2.2
Multicast RPF table: inet.2 , 16 entries

2.2.2.2/32
    Protocol: Static
    Interface: gre.13
    Neighbor: 10.11.13.1
 
R1 doesn't require any changes to its configuration as it has optimal routes to both R2 and R3 via it's direct connections.

Lets verify our multicast flows:

root@R4> ping 239.0.0.1 bypass-routing interface gre.34 ttl 5 count 5
PING 239.0.0.1 (239.0.0.1): 56 data bytes
64 bytes from 10.11.34.3: icmp_seq=0 ttl=64 time=11.228 ms
64 bytes from 10.11.23.2: icmp_seq=0 ttl=63 time=15.762 ms (DUP!)
64 bytes from 10.11.13.1: icmp_seq=0 ttl=63 time=15.944 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=1 ttl=64 time=3.023 ms
64 bytes from 10.11.23.2: icmp_seq=1 ttl=63 time=4.673 ms (DUP!)
64 bytes from 10.11.13.1: icmp_seq=1 ttl=63 time=4.829 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=2 ttl=64 time=4.700 ms
64 bytes from 10.11.23.2: icmp_seq=2 ttl=63 time=6.255 ms (DUP!)
64 bytes from 10.11.13.1: icmp_seq=2 ttl=63 time=6.407 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=3 ttl=64 time=2.658 ms
64 bytes from 10.11.23.2: icmp_seq=3 ttl=63 time=4.857 ms (DUP!)
64 bytes from 10.11.13.1: icmp_seq=3 ttl=63 time=4.891 ms (DUP!)
64 bytes from 10.11.34.3: icmp_seq=4 ttl=64 time=2.191 ms

--- 239.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, +8 duplicates, 0% packet loss
round-trip min/avg/max/stddev = 2.191/6.724/15.944/4.445 ms

Lets verify the multicast path from R4 to R2 using the mtrace command:

root@R2> mtrace from-source source 10.11.34.4 group 239.0.0.1
Mtrace from 10.11.34.4 to 10.11.12.2 via group 239.0.0.1
Querying full reverse path... * *
  0  ? (10.11.12.2)
 -1  ? (10.11.12.1)  PIM  thresh^ 1
 -2  ? (10.11.13.3)  PIM  thresh^ 1
 -3  ? (10.11.34.4)
Round trip time 5 ms; total ttl of 2 required.

Waiting to accumulate statistics...Results after 10 seconds:

  Source        Response Dest    Overall     Packet Statistics For Traffic From
10.11.34.4      10.11.12.2       Packet      10.11.34.4 To 239.0.0.1
     v       __/  rtt    3 ms     Rate       Lost/Sent = Pct  Rate
10.11.34.3
10.11.13.3      ?
     v     ^      ttl    2                      0/0    = --    0 pps
10.11.13.1
10.11.12.1      ?
     v      \__   ttl    3                      ?/0            0 pps
10.11.12.2      10.11.12.2
  Receiver      Query Source

The Multicast path goes R4 -> R3 -> R1 -> R2

root@R4> traceroute 2.2.2.2
traceroute to 2.2.2.2 (2.2.2.2), 30 hops max, 40 byte packets
 1  10.11.34.3 (10.11.34.3)  4.967 ms  4.494 ms  1.837 ms
 2  2.2.2.2 (2.2.2.2)  0.912 ms  0.997 ms  1.119 ms

While the unicast path goes R4 -> R3 -> R2