All things geeky

Geek stuff
My general geeky rambles about networking, coding, Linux or anything else I might get beaten up for.

Multicast - Querying router, DR and Assert PDF Print E-mail
Written by Jason Neatherway   
Sunday, 12 April 2009 03:19

A few notes to clear up the purpose and selection of the PIM DR, IGMP Querying router and PIM Assert.

A few show commands are used to support the explanation, they reflect a topology with three routers (R2, R4, R6) connected on a ethernet segment (subnet 10.1.246.0/24) running PIM-DM.

 

PIM Designated Router (DR)

 DR is a PIM function relevant to SM, used to elect a router on a multi access network responsible for sending register/prune messages towards the RP.  The DR is elected by,

  • The router with the highest priority is elected, or if the priority is equal
  • The router with the highest IP address is elected

 R2#show ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable

Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.1.25.5         Serial2/0.25             00:46:53/00:01:42 v2    1 / S
10.1.246.6        FastEthernet0/0          00:45:03/00:01:26 v2    1 / DR S
10.1.246.4        FastEthernet0/0          00:45:39/00:01:28 v2    1 / S

 

IGMP Querying router

 The IGMP Querying Router is the router on a multi access network that is responsible for sending IGMP host queries.  The IGMP query is used to determine/confirm the need to forward a multicast group to the LAN interface.  IGMPv2 uses a election process to determine the querying router, where,

  • The router with the lowest IP address is elected

 R2#sho ip igmp int fa0/0

FastEthernet0/0 is up, line protocol is up
  Internet address is 10.1.246.2/24
  IGMP is enabled on interface
  Current IGMP host version is 2
  Current IGMP router version is 2
  IGMP query interval is 60 seconds
  IGMP querier timeout is 120 seconds
  IGMP max query response time is 10 seconds
  Last member query count is 2
  Last member query response interval is 1000 ms
  Inbound IGMP access group is not set
  IGMP activity: 2 joins, 0 leaves
  Multicast routing is enabled on interface
  Multicast TTL threshold is 0
  Multicast designated router (DR) is 10.1.246.6 
  IGMP querying router is 10.1.246.2 (this system)
  No multicast groups joined by this system

 

IGMPv1 does not support querying router election, instead inheriting the DR from PIM as the querying router.

 !You can see this if we change our example to use IGMPv1 on the segment.

R2(config)#int fa0/0
R2(config-if)#ip igmp version 1

R4(config)#int fa0/0
R4(config-if)#ip igmp version 1

R6(config)#int fa0/0
R6(config-if)#ip igmp version 1

 

R2(config-if)#do sho ip igmp int fa0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 10.1.246.2/24
  IGMP is enabled on interface
  Current IGMP host version is 1
  Current IGMP router version is 1
  IGMP query interval is 60 seconds
  Inbound IGMP access group is not set
  IGMP activity: 2 joins, 0 leaves
  Multicast routing is enabled on interface
  Multicast TTL threshold is 0
  Multicast designated router (DR) is 10.1.246.6
  IGMP querying router is 10.1.246.6 (this system)
  No multicast groups joined by this system

 

PIM Assert

When two or more multi-cast routers on a multi-access segment (LAN) have a path (presumably equal, but not neccessarily) to the multi-cast source, both routers would forward traffic to the LAN.  This is obviously a waste of resources as only one is neccessary.  Routers on the mulit-access segment send a PIM Assert message to claim the right to forward on the segment.  Routers compare any recieved Assert messages to their own properties to determine the winner.  Comparison is made against,

  • Admin distance of the routers route to the group source (lowest wins), if a tie
  • Routing protocol metric to the group source (lowest wins), if a tie
  • The router with the highest IP address wins

In the example output bellow, our routers R2 and R4 have equal cost path to the multicast source 1.1.1.1, and both have Fa0/0 (a common segment) on their outgoing interface list (OIL).  As a result they send a PIM Assert, with the election process comming down to the highest IP address.  R4 has the highest IP address on the LAN segment.  So as seen in the mroute table, R4 is forwarding and R2 sends a prunes to the router upstream and does not forward to the Fa0/0 interface

R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:44:59/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 01:44:59/00:00:00
    Serial2/0.25, Forward/Dense, 01:44:59/00:00:00

(1.1.1.1, 224.1.1.1), 00:00:07/00:02:55, flags: PT
  Incoming interface: Serial2/0.25, RPF nbr 10.1.25.5
  Outgoing interface list:
    FastEthernet0/0, Prune/Dense, 00:00:07/00:02:52

(*, 224.0.1.40), 01:49:09/00:02:21, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 01:48:03/00:00:00
    Serial2/0.25, Forward/Dense, 01:49:09/00:00:00

R2#

 

 

R4#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:48:41/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 01:48:41/00:00:00
    Serial2/0.45, Forward/Dense, 01:48:41/00:00:00

(1.1.1.1, 224.1.1.1), 00:00:09/00:02:54, flags: T
  Incoming interface: Serial2/0.45, RPF nbr 10.1.45.5
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:00:09/00:00:00, A

(*, 224.0.1.40), 01:51:58/00:02:43, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 01:51:45/00:00:00
    Serial2/0.45, Forward/Dense, 01:51:58/00:00:00

 
Last Updated on Sunday, 12 April 2009 04:04
 
BGP disable connected check PDF Print E-mail
Written by Jason Neatherway   
Tuesday, 03 February 2009 14:17

A few learning notes on BGP disable-connected-check command ....

By default  BGP will check that a eBGP peer is directly connected by comparing the peer address against directly connected interface addresses.  The BGP router will not even try to connect (no packets hit the wire) if the neighbor doesn't first pass the connected test.  Similarly the remote peer will not accept the peer connection if it does not pass the connected test.  This is beyond the IP TTL limitations related to eBGP, eBGP multihop and TTL security - the checking is at the application layer of BGP.

This check is disabled by :

  • neighbor disable-connected-check , or
  • neighbor ebgp-multihop <ttl> , when TTL > 1

The disable-connect-check  command is used when you want to establish peering of directly connect routers using the loopback interface (using the loopback as the BGP source is configured with neighbor update-source).
Last Updated on Tuesday, 03 February 2009 14:19
 
BGP ttl-security and ebgp-multihop PDF Print E-mail
Written by Jason Neatherway   
Monday, 02 February 2009 13:15

 

 A few learning notes on BGP TTL-security and eBGP mulithop ...

By default eBGP transmits packets with TTL=1.  This ensures the TTL will expire after one hop and they won't inadvertantly go further than the directly connected peer.  eBGP follows the normal IP process for the recieved packet and checks for TTL > 0 .... so the default eBGP packets with TTL=1 will pass this (as we'd expect).  There is an inherit risk with this for externally facing BGP routers where packets can be spoofed by some malicious host, say 10 hops away, that will be accpeted and processed based on the default TTL>0 condition.  This type of attack can consume CPU resources on the BG router .. hence TTL security to mitigate this risk.

TTL security will check incoming BGP packets to ensure the TTL >= (255-hops) where the number of hops is the maximum distance of the peer in the neighbor <ip> ttl-security hops <hops>
So for our previous scenario is we configured neighbor 10.1.1.1 ttl-security hops 4  our malicious host 10 hops away would not pass the TTL check unless they could guess and manipulate TTL to the required value.  So this is what ttl-security is all about - a security mitiagition against spoofed BGP packets.

eBGP multihop on the otherhand is about overiding eBGPs default behviour of sending packets with TTL=1, and allowing peering over multiple hops.  It does not change the check for incomming packets.  However you can see how ttl-security also allows eBGP over multiple hops because it changes the TTL to 255 for transmitted packets - hence eBGP multihop is not needed when ttl-security is enabled (they are mutually exclusive).

 

summary of effect of ebgp-multihop and ttl-security
  default for eBGP
 ttl-securityebgp-mulithop
tx BGP packets with TTL
 TTL=1 TTL=255 configured TTL

TTL check for incoming
BGP packets

 TTL > 0
(normal IP operation)

 TTL >= (255-hops)

  TTL > 0
(normal IP operation)

Last Updated on Monday, 02 February 2009 13:32
 
3550 QoS workbook task PDF Print E-mail
Written by Jason Neatherway   
Friday, 07 November 2008 01:26

I've been working through some switching QoS workbook tasks and there wasn't much on the 3550.  So in the interest of covering all bases, here is a scenario I created for myself with 3550 QoS.

I have shared my home-grown scenario and solution bellow.

 

Read more...
Last Updated on Monday, 10 November 2008 06:38
 
run Dynamips+Dynagen in a detachable session with SCREEN PDF Print E-mail
Written by Jason Neatherway   
Sunday, 02 November 2008 12:08

quick learning note ...

With the kids running around my CCIE study is often fragmented ... so I have to stop start all the time.  On top of that my 1 year old likes to bash the keys on my laptop if its left around ... which mean I always close it up before walking away - this would kill the ssh session I used to start Dynagen and so I'd have to restart all my Dynamips lab each time I thought I could get another 10 mins of study in.

I found my answer .... "screen" !!    screen is a shell window manager for Linux that allows you to run virtual terminal sessions.  Once you have started a virtual terminal which gives you a new shell - you can run what ever command line apps you like, create additional sessions and detach from those sessions.  You can then easily re-attach to those session even if your real tty is disconnected (i.e  you close your ssh session).

So what I'm doing now is launching dynamips and dynagen from their virtual terminals using screen.  At the end of the day I can suspend the dynamips routers, detach and disconnect - then log back in to my server the next day, an hour latter ... whenever, re-attach to the virtual terminal and return to the dynagen session and call  resume in dynagen to fire up all the routers again.

Quick start ...

start screen :  screen
get help : Ctrl+a ?
start a new virtual tty window : screen -t myVttyName
get a list of current windows to select : Ctrll+a "
detach from screen : Ctrl+a Ctrl+d
resume a screen session : screen -r

Works nicely ... I'll have a look at the .screenrc file when i get a chance.   This can be used to define config options as well define a set of sessions to launch when screen is started.

 

 

Update:

 

Ok I have nutted out and screen really makes life easy.  I created the screenrc file bellow and saved it as screen.dynamips and then run screen with 

screen -c screen.dynamips

# <screen.dynamips>

# # this basically just shows the current window number and title at the bottom of the terminal
caption always '%{= wb}%50=%n%f %t%{= wb}'

## make some key bindings to navigate around the lab equipment easily
#not sure why but function keys F1 to F9 are refrenced as k1-k9 and k; as F10
#and then F1 is actually F11, F2 is F12 .. wierd I know
bindkey -k k1 select 2  # F1 key for R1
bindkey -k k2 select 3  # F2 key for R2
bindkey -k k3 select 4  # F3 key for R3
bindkey -k k4 select 5  # F4 key for R4
bindkey -k k5 select 6  # F5 key for R5
bindkey -k k6 select 7  # F6 key for R6
bindkey -k k7 select 8  # F7 key for Cat-1
bindkey -k k8 select 9  # F8 key for Cat-2
bindkey -k k9 select 1  # F9 key for the Dynagen console
bindkey -k k; windowlist # F10 lists all the curren sessions
bindkey -k F1 detach    # detaches from the screen manager
bindkey -k F2 quit      # kills all sessions and exits screen
multiuser on
shell -$SHELL
term linux              # sets the TERM env variable (vt100 may be more appropriate for some)

## Start some windows
# 1st Dynamips hypervisor
screen -t dynamips7200 20 /usr/bin/sudo /usr/bin/dynamips -H 7200

# 2nd Dynamips hypervisor
screen -t dynamips7201 21 /usr/bin/sudo /usr/bin/dynamips -H 7201

# a screen to run dynagen and access the dynagen console
screen -t dynagen 1 /usr/bin/dynagen /home/jasonn/dynamips/networkfiles/narbiknet/soup2nuts.net

# a window for a console session to each router
# we just create a new shell - and I then manually use aliases to quickly "run telnet 127.0.0.1 200x"
screen -t R1 2
screen -t R2 3
screen -t R3 4
screen -t R4 5
screen -t R5 6
screen -t R6 7

# the console cable for my C3550s connect to a old linux pc serial port
# for these windows I ssh to that box where I can use minicom to access the console
screen -t Cat1 8 ssh labserv2
screen -t Cat2 9 ssh labserv2

# goto the Dynagen window after startup
select 1

Last Updated on Monday, 03 November 2008 12:26
 
More Articles...
«StartPrev12NextEnd»

Page 1 of 2